-
Notifications
You must be signed in to change notification settings - Fork 3
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
Feat/add blackbox probes library #43
base: main
Are you sure you want to change the base?
Feat/add blackbox probes library #43
Conversation
50d4e33
to
5519d53
Compare
2672b6c
to
d909f66
Compare
d909f66
to
b08a263
Compare
ca48af8
to
ce8e4df
Compare
18fd730
to
eff4d9a
Compare
from pydantic import BaseModel, ConfigDict, Field, Json | ||
|
||
# The unique Charmhub library identifier, never change it | ||
LIBID = "1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you need to run charmcraft create-lib
in order to get the unique identifier assigned by Charmhub
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm getting:
Store operation failed:
- permission-required: No publisher or collaborator permission for the blackbox-exporter-k8s charm package
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general LGTM, but I would change some minor things
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this powerful contribution!
Mostly non-code comments.
metadata.yaml
Outdated
@@ -47,3 +47,5 @@ requires: | |||
limit: 1 | |||
catalogue: | |||
interface: catalogue | |||
blackbox-probes: | |||
interface: blackbox_probes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interface: blackbox_probes | |
interface: blackbox_probes | |
description: | | |
Receive a list of probes (server address and probing method) from the provider to query. |
metadata.yaml
Outdated
@@ -47,3 +47,5 @@ requires: | |||
limit: 1 | |||
catalogue: | |||
interface: catalogue | |||
blackbox-probes: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Should the relation name be just
probes
here on the requirer side? - By convention, interface names should be unique in the ecosystem. Is "blackbox-probes" specific enough? Should we name it "blackbox_exporter_probes"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense, changing it.
README.md
Outdated
#### Dynamic Configuration | ||
|
||
The list of probes and the list of modules for probing can also be changed dynamically from other charms. | ||
The charm offers a relation to allow charms to dynamically export endpoints to be probed via Blackbox and custom modules for probing. Those are exported over the blackbox-targets relation using the blackbox_probes interface: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we stick to the official product name?
The charm offers a relation to allow charms to dynamically export endpoints to be probed via Blackbox and custom modules for probing. Those are exported over the blackbox-targets relation using the blackbox_probes interface: | |
The charm offers a relation to allow charms to dynamically export endpoints to be probed via Blackbox Exporter and custom modules for probing. Those are exported over the blackbox-probes relation using the blackbox_probes interface: |
README.md
Outdated
In order for the charm defined probes to be probed via this charm all that is required is to relate the two charms with: | ||
|
||
```shell | ||
juju relate <charm> blackbox |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to be a bit more prescriptive, to avoid ambiguity:
juju relate <charm> blackbox | |
juju relate <charm> blackbox:probes |
README.md
Outdated
juju relate <charm> blackbox | ||
``` | ||
|
||
Charms that seek to provide probes for Blackbox, must do so using the provided blackbox_probes charm library. This library ensures that probes and modules defined by a charm are forwarded correctly to Prometheus, and the metrics displayed in the associated Grafana Dashboard. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Charms that seek to provide probes for Blackbox, must do so using the provided blackbox_probes charm library. This library ensures that probes and modules defined by a charm are forwarded correctly to Prometheus, and the metrics displayed in the associated Grafana Dashboard. | |
Charms that seek to provide probes for Blackbox Exporter, must do so using the provided blackbox_probes charm library. This library ensures that probes and modules defined by a charm are forwarded correctly to Prometheus, and the metrics displayed in the associated Grafana Dashboard. |
## Provider Library Usage | ||
|
||
The Blackbox Exporter charm interacts with its datasources using this charm | ||
library. The goal of this library is to be as simple to use as possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
library. The goal of this library is to be as simple to use as possible. | |
library. |
|
||
The Blackbox Exporter charm interacts with its datasources using this charm | ||
library. The goal of this library is to be as simple to use as possible. | ||
Charms seeking to expose metric endpoints to be probed via Blackbox, must do so |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Afaiu, there are no metric endpoints to begin with, which is why we're using blackbox exporter (?).
is exposed to the Blakcbox Exporter charm. This relation must use the | ||
`blackbox_probes` interface. | ||
The default name for the metrics endpoint relation is | ||
`blackbox-targets`. It is strongly recommended to use the same |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`blackbox-targets`. It is strongly recommended to use the same | |
`blackbox-probes`. It is strongly recommended to use the same |
def __init__(self, *args): | ||
super().__init__(*args) | ||
... | ||
self.probes_provider = BlackboxProbesProvider(self, probes=probes_endpoints_config) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a simple config so short that we could inline it in this example, to better illustrate?
An instantiated `BlackboxProbesProvider` object will ensure that | ||
the list of endpoints to be probed are passed through to Blackbox Exporter, | ||
which will format them to be scraped for Prometheus. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we rephrase this?
Could you please also link to a tandem PR with the provider side of things? Was it supposed to be https://github.com/ubuntu-robotics/cos-registration-server? |
Hello @sed-i, thanks for the review. I'll try to address the comments today and tomorrow. In the meantime, this is the PR with the provider side of things: canonical/cos-registration-server-k8s-operator#13. Just as a reminder, this library PR includes also the changes proposed in PR #41. I've seen you made some comments about those changes. I had to incorporate them because without them I could not properly test blackbox (prometheus would return some errors). I can confirm that with those changes the traefik links work as expected as well as the probes, but if you could double test it it would be great. |
README.md
Outdated
#### Dynamic Configuration | ||
|
||
The list of probes and the list of modules for probing can also be changed dynamically from other charms. | ||
The charm offers a relation to allow charms to dynamically export endpoints to be probed via Blackbox Exporter and custom modules for probing. Those are exported over the probes relation using the blackbox_exporter_probes interface: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The charm offers a relation to allow charms to dynamically export endpoints to be probed via Blackbox Exporter and custom modules for probing. Those are exported over the probes relation using the blackbox_exporter_probes interface: | |
The charm offers a relation to allow charms to forward custom probe spec to Blackbox Exporter. Those are exported over the probes relation using the blackbox_exporter_probes interface: |
README.md
Outdated
interface: blackbox_exporter_probes | ||
``` | ||
|
||
The probes provided dynamically by a charm are merged with the probes defined in a configuration file, same with the modules which are integrated in the blackbox-config file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The probes provided dynamically by a charm are merged with the probes defined in a configuration file, same with the modules which are integrated in the blackbox-config file. | |
The cusrom probes provided via relation data are merged with the probes defined in a configuration file, same with the modules which are integrated in the blackbox-config file. |
README.md
Outdated
juju relate <charm> blackbox:probes | ||
``` | ||
|
||
Charms that seek to provide probes for Blackbox Exporter, must do so using the provided blackbox_exporter_probes charm library. This library ensures that probes and modules defined by a charm are forwarded correctly to Prometheus, and the metrics displayed in the associated Grafana Dashboard. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Charms that seek to provide probes for Blackbox Exporter, must do so using the provided blackbox_exporter_probes charm library. This library ensures that probes and modules defined by a charm are forwarded correctly to Prometheus, and the metrics displayed in the associated Grafana Dashboard. | |
Charms that seek to provide probes for Blackbox Exporter, can do so using the provided blackbox_exporter_probes charm library. This library ensures that probes and modules defined by a charm are forwarded correctly to Prometheus, and the metrics displayed in the associated Grafana Dashboard. |
|
||
The Blackbox Exporter charm interacts with its datasources using this charm | ||
library. | ||
Charms seeking to expose probes for Blackbox, must do so |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Charms seeking to expose probes for Blackbox, must do so | |
Charms seeking to expose probes for Blackbox, may do so |
1. Instantiate the `BlackboxProbesRequirer` object by providing it a | ||
reference to the parent (Blackbox Exporter) charm and, optionally, the name of | ||
the relation that the Blackbox Exporter charm uses to interact with probes | ||
targets. This relation must confirm to the `blackbox_exporter_probes` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
targets. This relation must confirm to the `blackbox_exporter_probes` | |
targets. This relation must conform to the `blackbox_exporter_probes` |
src/charm.py
Outdated
def _merge_scrape_configs( | ||
self, file_probes: dict, relation_probes: List[ProbesJobModel] | ||
) -> List[dict]: | ||
"""Merge the scrape_configs from both file and relation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add to docstring the order of precedence explicitly?
src/charm.py
Outdated
self.container.push(self._config_path, updated_config_data) | ||
self.blackbox_workload.reload() | ||
|
||
def _merge_scrape_configs( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to extract this logic outside of charm code?
src/charm.py
Outdated
for probe in relation_probes: | ||
if not isinstance(probe, dict): | ||
probe = dict(probe) | ||
job_name = probe["job_name"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think name collisions would be accidental, i.e. representing different probes.
Should we differentiate by adding rel-id to the name?
src/charm.py
Outdated
probe["metrics_path"] = probes_path | ||
# The relabel configs come from the official Blackbox Exporter docs; please refer | ||
# to that for further information on what they do | ||
probe["relabel_configs"] = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we extract this into a charm-independent config builder?
tests/unit/test_probes_provider.py
Outdated
rel_id = self.harness.add_relation(RELATION_NAME, "provider") | ||
self.harness.add_relation_unit(rel_id, "provider/0") | ||
self.harness.charm.provider.set_probes_spec() | ||
self.assertEqual(self.harness.charm._stored.num_events, 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of whitebox testing tends to be brittle and difficult to maintain.
See BDD section here.
@giusebar, sorry to bother you, but do you think you have a moment to look at this in the coming weeks? Thanks in advance. |
…parate module, use centralised collect_status in the blackbox-library, improve testing
Issue
Closes #42.
Solution
Draft pull request adding a blackbox_probes library, to allow client charm to provide blackbox Exporter with some endpoints to monitor.