Document the cluster event log alerts - #208
Draft
boddumanohar wants to merge 1 commit into
Draft
Conversation
The Kubernetes alerting page covered only the metrics-based rules. The optional event log rules are configured entirely differently and fail in ways that give an operator nothing to go on, so the page now covers all eight of them: what each fires on, what suppresses it, and whether it clears on recovery or on a timer. The enablement section leads with the trap. All three of the monitoring stack, the eventAlerts flag, and a cluster ID and secret must be set, and a missing cluster ID renders no data sources and no rules at all, with no error anywhere. Because the ID and secret only exist once `cluster create` has run, a fresh install always starts in that state and needs a second upgrade to finish. Two further behaviors are written down because neither is discoverable: Grafana reads its provisioning only at startup, so a chart upgrade that touches only the ConfigMap leaves the running rules unchanged until the pod restarts, and a rule that cannot reach its data source still lists normally while reporting health=error, which makes "the rules are present" an insufficient check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
🤖: Deployment available as https://docstest.simplyblock.io/docs-event-log-alerts |
boddumanohar
marked this pull request as draft
September 2, 2026 15:07
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documents the optional event-log-driven alert rules on the Kubernetes alerting page, which previously covered only the metrics-based rules.
Companion to simplyblock/simplyblock-operator#474, which adds the rules themselves.
What is documented
cluster createhas run, a fresh install always begins in that state and needs a second upgrade to finish.logLimit,interval,for, andplugin.preinstalled, each with the reason it matters.health=error, so confirming the rules exist is not sufficient on its own.suspendstill notifies, four alerts clear on a timer, and nothing is notified at all until a receiver is configured.Two behaviors are written down because neither is discoverable from the interface: Grafana reads its provisioning only at startup, so a chart upgrade touching only the ConfigMap leaves the running rules unchanged until the pod restarts, and the REST data source plugin is downloaded on every pod start unless it is baked into the image.
Checks
house-stylecheckers pass.reference/cli/cluster.mdlinks match the existing rows on the page and resolve at build time viascripts/cli-reference-gen.py.Open question for review
There is a parallel
docs/non-kubernetes/operations/monitoring/alerts.mdwith near-identical content. These rules are chart-driven and so Kubernetes-only as written, and that page is untouched. If the non-Kubernetes install can enable them too, it needs its own version.