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

Prometheus Exporter for Pyrometer #480

Merged
merged 29 commits into from
Aug 30, 2022
Merged

Prometheus Exporter for Pyrometer #480

merged 29 commits into from
Aug 30, 2022

Conversation

nicolasochem
Copy link
Contributor

Quoting pyrometer architecture doc:

Primary installation target for initial monitoring implementation is a
personal computer. Consequently, implementation should prioritize
simplicity when it comes to number of individual, isolated components,
processes, their runtime dependencies,
administration/configuration.

Pyrometer is a self-sustaining tool that manages its own alerts and alerting channels. But what if I want to use it as a pure monitoring tool and and off the alert management to my prometheus stack in my kubernetes cluster?

I am introducing a Prometheus exporter for pyrometer. It consumes pyrometer events with the webhook and monitors only one of them: baker health status. It then aggregates the number of unhealthy bakers and exposes this as a prometheus metric.

The exporter is a sidecar so no modifications to pyrometer are required. The sidecar is included in the chart and relies on the utils container (just like the tezos sidecar). The ServiceMonitor and PrometheusRule are also included in the chart.

This gives you:

  • the concept of an active alert that can be fed into an incident management system such as pagerduty.
  • the ability to monitor a baker baking for several addresses, where it is not desirable to alert for an individual unhealthy address, but only when all the configured bakers are unhealtly. The threshold is configured in the chart.

I also add a default config in the values.yaml. Launching the tezos chart with no parameters, and the pyrometer chart with no parameters, will result in pyrometer acting as node monitoring for the node.

Since the beginning of tezos-k8s we have always deployed ingresses
outside of our charts.

Is it the right approach? Maybe not: the default helm chart created with
`helm init` has a pre-configured ingress template file.

This ingress template file is sufficient for our use cases: we can pass
ingress annotations and TLS configuration with values.yaml.

Therefore, we add an option to define the ingress with helm directly.
This allows to remove an ingress definition from the teztnets and
oxheadinfra code bases, simplifying it.

We should consider doing that for Tezos RPC as well.
@nicolasochem nicolasochem changed the base branch from pyrometer_ingress to master August 25, 2022 05:15
@nicolasochem nicolasochem marked this pull request as ready for review August 25, 2022 05:16
@nicolasochem nicolasochem requested a review from harryttd August 25, 2022 05:16
@nicolasochem nicolasochem requested a review from itkach August 25, 2022 05:17
Copy link
Contributor

@harryttd harryttd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good just a couple of questions. Also i didn't test and am assuming it works

charts/pyrometer/values.yaml Outdated Show resolved Hide resolved
charts/pyrometer/values.yaml Show resolved Hide resolved
@nicolasochem nicolasochem requested a review from harryttd August 26, 2022 22:24
@nicolasochem nicolasochem merged commit 2921424 into master Aug 30, 2022
@harryttd harryttd deleted the pyrometer_prometheus branch March 8, 2023 21:30
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

Successfully merging this pull request may close these issues.

2 participants