STAC-22541: Derived state monitors #1602
Merged
Conversation
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
craffit
reviewed
Apr 14, 2025
|
|
||
| ## Overview | ||
|
|
||
| In Observability scenarios where logical (business) components lack direct monitors but are affected by issues in their technical dependencies, you can use the derived-state-monitor to propagate health states to them. |
Contributor
There was a problem hiding this comment.
... you can use the derived-state-monitor function to derive a state from the connected technical components for a the logical component.
craffit
reviewed
Apr 14, 2025
| ## Overview | ||
|
|
||
| In Observability scenarios where logical (business) components lack direct monitors but are affected by issues in their technical dependencies, you can use the derived-state-monitor to propagate health states to them. | ||
| This monitor traverses component dependencies and selects the most critical health state based on direct observations (e.g., from metrics), ignoring any already-derived states. It starts from a group of components defined by `componentTypes` and propagates health upwards to the top-level logical components. |
Contributor
There was a problem hiding this comment.
... It will apply the derived state to all components selected through the componentTypes parameter.
craffit
reviewed
Apr 14, 2025
|
|
||
| In Observability scenarios where logical (business) components lack direct monitors but are affected by issues in their technical dependencies, you can use the derived-state-monitor to propagate health states to them. | ||
| This monitor traverses component dependencies and selects the most critical health state based on direct observations (e.g., from metrics), ignoring any already-derived states. It starts from a group of components defined by `componentTypes` and propagates health upwards to the top-level logical components. | ||
| During traversal, only components with observed (non-derived) health states are considered for health propagation. Components with derived states are skipped in evaluation but still traversed to reach deeper dependencies—for example, logical components depending on other logical components. |
craffit
reviewed
Apr 14, 2025
| * The function has a single argument `componentTypes` where you can express the different component types as a single string of `,` separated values | ||
| * The function offers two values to use in the remediation guide, `causeName` being the component name where the state is propagated from and its `causeComponentUrnForUrl` to be able to create a link | ||
|
|
||
| The monitor can be implement using the guide at [Add a threshold monitor to components using the CLI](/use/alerting/k8s-add-monitors-cli.md) No newline at end of file |
craffit
approved these changes
Apr 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.