Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support evaluating metrics and switching states #2162

Open
ripienaar opened this issue Apr 12, 2024 · 1 comment
Open

Support evaluating metrics and switching states #2162

ripienaar opened this issue Apr 12, 2024 · 1 comment

Comments

@ripienaar
Copy link
Member

To deliver on the hopes of reacting to metric values we'd need to initiate state changes.

I imagine you could add some queries to the metric watcher using expr and based on their boolean returns you'd do success/fail transitions.

Today we support storing the metrics to machine data (#2157) but I'd like to eventually improve on that by storing in a small localised tsdb, think hours of data not days, so that expr functions can do things lke average over recent metrics etc

But we can start with just the stored data for now

@ripienaar
Copy link
Member Author

ripienaar commented Apr 14, 2024

name: demo
type: expression
state_match:
  - X
  - Y
fail_transition: FAIL
success_transition: SUCCESS
interval: 1m
properties:
  fail_when: ... # expression thats true or false, on true it will trigger fail transition
  success_when: ... # expression thats true or false, on true it will trigger success transition

false from the expressions will just be ignored. We'd add a few functions to allow looking up data etc

The data layer should get a new hook where these watchers can register for updates so they will get notified if data changes and also when they enter the matching states. It will also check on interval to cater for external updates to data

We'd need some flip-flop or true-if-already-true induced repeated transitions. Typically I think such a watcher would be sat on state_match on both the success and fail target states so it would be possible that once true each true will trigger. So will need to cache previous state like many others watchers do and ignore if previous == current to avoid this.

ripienaar added a commit to ripienaar/go-choria that referenced this issue Apr 16, 2024
Watcher can be used to flip states based on the contents of data, facts
and more

Signed-off-by: R.I.Pienaar <[email protected]>
ripienaar added a commit to ripienaar/go-choria that referenced this issue Apr 16, 2024
Watcher can be used to flip states based on the contents of data, facts
and more

Signed-off-by: R.I.Pienaar <[email protected]>
ripienaar added a commit that referenced this issue Apr 16, 2024
(#2162) Adds a expression watcher
ripienaar added a commit to ripienaar/go-choria that referenced this issue Apr 16, 2024
ripienaar added a commit that referenced this issue Apr 16, 2024
(#2162) Consistency update with other watchers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant