You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently working with a Kubernetes deployment that one of the best ways to collect data would be to just have each node configure and monitor its own health endpoint and individually push its updates into the database.
Problem is I really just need to filter the collectors pulled during the HealthCheckReportCollector hosted service loop, problem is it's a sealed class with internal class elements (so makes it non-trivial to just override that or even just fork the class).
Not sure if I'm going about this wrong (I could have each node add itself to the DB and use a central hosted health UI to pull all of the node's statuses, but that requires DNS changes for direct pod access via pod name and setup of the DB context independent of the other services).
Seems like being able to make each node responsible for a push (kind of like how we support Publishers but more direct to Health UI's DB) would be an easily desired setup.
Please excuse any nonsensical rambling or whatnot, I've been up all night shaking this as part of a monitoring overhaul. 🙃
The text was updated successfully, but these errors were encountered:
I'm currently working with a Kubernetes deployment that one of the best ways to collect data would be to just have each node configure and monitor its own health endpoint and individually push its updates into the database.
Problem is I really just need to filter the collectors pulled during the
HealthCheckReportCollector
hosted service loop, problem is it's a sealed class with internal class elements (so makes it non-trivial to just override that or even just fork the class).Not sure if I'm going about this wrong (I could have each node add itself to the DB and use a central hosted health UI to pull all of the node's statuses, but that requires DNS changes for direct pod access via pod name and setup of the DB context independent of the other services).
Seems like being able to make each node responsible for a push (kind of like how we support Publishers but more direct to Health UI's DB) would be an easily desired setup.
Please excuse any nonsensical rambling or whatnot, I've been up all night shaking this as part of a monitoring overhaul. 🙃
The text was updated successfully, but these errors were encountered: