feat: surface Knowledge Graph insights and service linking on checks - #1736
feat: surface Knowledge Graph insights and service linking on checks#1736VikaCep wants to merge 14 commits into
Conversation
Script size changes
Totals
|
d15d3c0 to
63acbf1
Compare
63acbf1 to
2426fb6
Compare
Signed-off-by: Virginia Cepeda <virginia.cepeda@grafana.com>
Replace the on/off switch with a collapsible "Add service link" section. service_name/namespace are resolved through a single CAL-aware hook, so the KG section and the cost attribution label rows edit the same values and stay in sync. CAL rows for those labels upgrade to a combobox with KG service suggestions, and a live indicator shows whether the pair matches a known Service entity.
…s query The KG relation was flipped from SyntheticCheck -MONITORS-> Service to Service -MONITORED_BY-> SyntheticCheck so alertBackPropagate carries a failing check's insight onto the monitored service. Updates the Cypher neighbourhood query, its test, and the form help text to match.
…fields Show the service name and namespace rows directly instead of behind a "+ Service link" button, and drop the remove action — each value is cleared through its own combobox, with no validation on either field. Hide service_name/namespace from the custom labels when the Knowledge Graph app is installed (they previously showed twice), and redirect anyone typing either key back to the service link section.
8c3fa5f to
eabe41a
Compare
* feat: replace scenes nodegraph with custom KG-style Connected services graph Renders the check's neighbourhood with a bespoke SVG renderer matching the Knowledge Graph's entity graph design: layered layout, insight rings, SM logo on check nodes, insights popup on node hover with a KG deep link, curved sibling edges, and edge hover highlighting with connection tooltips. Data comes straight from the Cypher query via react-query instead of scenes. * fix: make connected services be expanded by default * fix: refetch the connected services graph on the standard dashboard interval Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
|
bugbot review |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
bugbot review |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit b641708. Configure here.
| uid: 'grafanacloud-knowledgegraph', | ||
| type: 'grafana-knowledgegraph-datasource', | ||
| name: 'Knowledge Graph', | ||
| } as DataSourceInstanceSettings; |
There was a problem hiding this comment.
Partial datasource test cast
Low Severity
KG_DATASOURCE is a partial object asserted with as DataSourceInstanceSettings, which violates the project rule to use typed fixture factories instead of casts in tests. Existing datasource fixtures in src/test/fixtures/datasources.ts already follow the full typed-literal pattern.
Triggered by learned rule: Use typed factory functions for test fixtures instead of as any / as unknown as Type casts
Reviewed by Cursor Bugbot for commit b641708. Configure here.
ckbedwell
left a comment
ckbedwell
left a comment
There was a problem hiding this comment.
Few questions and nits -- the main one is looking at the syncing of the dashboard time range with the KG query.
There was a problem hiding this comment.
Are we recreating the graph view here? Do they not expose their own component?
There was a problem hiding this comment.
Yeah, I asked about this but unfortunately this is not available as an exposed component. Perhaps we can move this out as a shared utility between consumers as Russ mentioned in the conversation.
2 participants
Part of #1615
Problem
Synthetic Monitoring checks are disconnected from the rest of a user's observability stack. When a check is failing or slow, there is no path inside the product from the check to the service it monitors, that service's dependencies, or its current health. Users have to jump between Synthetic Monitoring and other tools (Application Observability, Kubernetes Monitoring, alerts) to understand why. There is also no way, from within Synthetic Monitoring, to tell the Knowledge Graph which service a check is actually monitoring.
Solution
This PR adds the Synthetic Monitoring side of the Knowledge Graph (KG) integration, in three places:
1. Knowledge Graph insights on the check dashboard. The check page embeds the KG assertions widget (the health rings), scoped to the check's
SyntheticCheckentity and the current time range. Users get error, latency and health insights for the check inline, without leaving Synthetic Monitoring.2. Linking a check to a Knowledge Graph service. The Labels section of the check form gains optional service name and namespace fields. Suggestions are fetched live from the Knowledge Graph, and the values are stored as the
service_nameandnamespacelabels on the check. This is what lets the Knowledge Graph draw theMONITORED_BYrelationship between the service and the check. A live indicator shows whether the selected pair matches a known Service entity. When these labels are declared as cost attribution labels, both surfaces edit the same values and stay in sync.3. Connected services graph on the check dashboard. A "Connected services" section renders the check's Knowledge Graph neighbourhood as an inline graph: the service the check monitors, plus that service's immediate callers and dependencies. Nodes carry the KG insight rings, so an unhealthy neighbour surfaces as a root cause hint right on the check page. Hovering a node shows its insights with a link to the entity in the Knowledge Graph. The data comes from a Cypher query against the KG datasource that walks
MONITORED_BYto the linked check and one hop ofCALLSin both directions. The section is expanded by default. When the check is not linked to a service yet, it shows a zero state whose button links straight to the Labels section of the edit form. An "Open in Knowledge Graph" link opens the full entity graph.Feature flag and rollout
All three surfaces render only when both of these are true:
grafana-asserts-app) is installed on the stack, andsynthetic-monitoring-knowledge-graphfeature flag is enabled.The flag exists because the Knowledge Graph app has a large installed base that predates this integration.
SyntheticCheckentities only start appearing once the entity discovery rules land in the KG platform (theasserts-adiside of this project), so without a flag those stacks would see empty sections. With the flag, this PR is safe to merge as soon as it is approved: everything stays dormant until we enable the flag per stack, and the flag also works as a kill switch if anything misbehaves.Review guide
The diff is large, but more than half of it has already been reviewed:
ConnectedServices.*,ConnectedServicesGraph.tsx,useKGDS.tsand the KG test fixtures, about 1,600 lines): reviewed and approved separately in feat: add Connected services graph to the check dashboard #1774, then merged into this branch unchanged.KnowledgeGraphServiceLink.*,KnowledgeGraphValueCombobox.tsx,knowledgeGraphApi.tsand the changes to the label form components, about 1,100 lines, roughly half of it tests): this is the main part to review.KnowledgeGraphInsights.tsxplus two lines in each scene dashboard): small.knowledgeGraph.hooks.ts,types.ts): the shared gate described above.Design doc
This is the Synthetic Monitoring side of the Design Doc: Synthetic Monitoring × Knowledge Graph Integration (v2), covering work units 2.5, 2.6 and 2.7. The doc is approved.
Additional context
This PR pairs with the KG platform changes in
asserts-adi(theSyntheticCheckentity type, the entity discovery rules and theMONITORED_BYrelationship) and theasserts-app-pluginchanges that add the entity Metrics tab and the link back to Synthetic Monitoring (#3461). Until those rules are deployed andSyntheticCheckentities exist in the graph, everything in this PR stays dormant behind the feature flag.