Skip to content

[8.19] [Streams] Grok UI integration with enrichment page (#219146)#221887

Merged
kibanamachine merged 2 commits intoelastic:8.19from
kibanamachine:backport/8.19/pr-219146
May 29, 2025
Merged

[8.19] [Streams] Grok UI integration with enrichment page (#219146)#221887
kibanamachine merged 2 commits intoelastic:8.19from
kibanamachine:backport/8.19/pr-219146

Conversation

@kibanamachine
Copy link
Contributor

Backport

This will backport the following commits from main to 8.19:

Questions ?

Please refer to the Backport tool documentation

## Summary

Closes elastic/streams-program#173.

From a high level this takes the UI components / models in the Grok UI
package from a POC level to a polished level, and then integrates those
with the Enrichment / Extraction page in the Streams UI. The Grok UI
package is completely agnostic to it's consumer, so these package
resources should be ready to integrate with any part of Kibana (we want
to eventually bring this to Discover, for example).

## Notes for the reviewer

Quite a few notes, but hopefully they help navigate the code and
decisions made.

- The `PreviewTable` now allows a custom `renderCellValue` prop, this is
used when we are dealing with a **draft** Grok processor.

- With processors we have a saved state (these don't run in the
simulation), a staged state (configured and added but not saved, these
are used in the simulation), and a draft state (freshly added, but not
staged / saved yet, these are used in the simulation). The Grok
highlighting is only available in the simulation table when the Grok
processor if in a **draft** state, this is because we can't cleanly
differentiate between staged processors at the moment which one exactly
is being edited (multiple edit panels can be opened at once). I have
discussed this with @tonyghiani and @patpscal and we've agreed this is
fine to start with, with
elastic#218955 and
moving to only one edit at a time we will be able to roll this out to
editing staged processors as well as the draft processor.

- Custom sample data is **always** available, so there is always a way
to test the patterns with highlights etc.

- In the Grok UI package there is a read only version of the sample
component, this is for things like cell rendering within a table and
provides it's tooltips via EUI. There is also an "input" version which
is backed by Monaco (tooltips also provided by Monaco). The styling
differs on the tooltips a bit between the two for this reason, I will
try and enhance / override the Monaco styles so they adhere to our
colour palette / themes etc in a followup.

- Giorgos had suggested using the `/_ingest/processor/grok` ES endpoint
to fetch the patterns, however I couldn't find a convenient way to do
this yet without adding an API endpoint somewhere (since this needs an
ES client). I've deferred this for now, but it's why I've preempted
`setup()` being modelled as `async`.

- I had to pass `formControl` around in a bit of an ugly way in the
patterns editor, this was purely due to the `useForm()` hook not working
as I expected in that part of the hierarchy.

- We only need a single `GrokCollection` instance, as such this is
stored in the top level state machine.

- We technically have two areas where state is managed. We have the
state machines and then we have the form state managed by React Hook
Form. The form state is synchronised back to the state machines when
processor changes are made. This Grok integration work introduces a new
need which is for resources to be shared between the processors panel
and the simulation panel, in this case the same `DraftGrokExpression`
instances. There are multiple ways this could have been modelled, with
various pros and cons, but I wanted to keep the paradigm we have now
which is that the processor definitions in the state machine are
"complete" (in the sense they're converted) and not partial form state.
The `DraftGrokExpressions` are integrated directly with the form state,
and synchronised back to a new `resources` property in the state
machine.

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
(cherry picked from commit 216ac7e)
@kibanamachine kibanamachine added the backport This PR is a backport of another PR label May 29, 2025
@kibanamachine kibanamachine enabled auto-merge (squash) May 29, 2025 08:14
@elasticmachine
Copy link
Contributor

elasticmachine commented May 29, 2025

💔 Build Failed

Failed CI Steps

History

cc @Kerry350

@Kerry350
Copy link
Contributor

/ci

@kibanamachine kibanamachine merged commit f3c5c92 into elastic:8.19 May 29, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport This PR is a backport of another PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants