Summary
A regression to the cos_agent library was released in versions 0.23 (Dec 12, 2025) and 0.24 (Feb 5, 2026). This was resolved in the latest version of the library 0.25 which can be upgraded to, by running charmcraft fetch-lib in your charm’s repo.
Are you affected
- Charms:
grafana-agent,opentelemetry-collector, etc. - Interface:
cos_agent
When relating your VM charm over the cos_agent interface, you may still see your charm and the related charm (likely grafana-agent or opentelemetry-collector) in active/idle status even though there are rules in the databag with a broken structure. When these rules are loaded by the respective snaps, they panic and fail to start. You can confirm that this is the case by running:
juju ssh <unit_name> sudo snap info grafana-agent
juju ssh <unit_name> sudo snap logs grafana-agent
and checking for the snap services to be inactive or panic in the logs.
Correct behavior as of version 0.25
When cos_agent requirer side (e.g., grafana-agent or otelcol snaps) tries to scrape the configs, it won’t fail because the library defaults a job_name for all scrape_configs.
We proactively updated the behavior to append a small hash of the sorted scrape_config contents to the job_name. This helps to keep the job_name fields deterministic, avoiding fracturing timeseries. You will notice that new job names will have the following format:
<app>_<job_or_default>_<8hex-hash>- e.g.
otelcol_default_93c0e860
Existing deployments will see a one-time job_name change (index removed), which itself fractures timeseries once. After that, names are stable across future config changes.