Skip to content

Comments

[DPE-9444] Switch to ops tracing (16/edge)#1264

Open
dragomirp wants to merge 7 commits into16/edgefrom
dpe-9444-tracing
Open

[DPE-9444] Switch to ops tracing (16/edge)#1264
dragomirp wants to merge 7 commits into16/edgefrom
dpe-9444-tracing

Conversation

@dragomirp
Copy link
Contributor

@dragomirp dragomirp commented Feb 16, 2026

Switch to ops tracing and remove the old charm libs.

Checklist

  • I have added or updated any relevant documentation.
  • I have cleaned any remaining cloud resources from my accounts.

@dragomirp dragomirp added the enhancement New feature, UI change, or workload upgrade label Feb 16, 2026
@github-actions github-actions bot added the Libraries: OK The charm libs used are OK and in-sync label Feb 16, 2026
@codecov
Copy link

codecov bot commented Feb 16, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.96%. Comparing base (f2aeb85) to head (4c05c50).

❌ Your project check has failed because the head coverage (68.96%) is below the target coverage (70.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files
@@             Coverage Diff             @@
##           16/edge    #1264      +/-   ##
===========================================
- Coverage    68.97%   68.96%   -0.01%     
===========================================
  Files           16       16              
  Lines         3816     3809       -7     
  Branches       575      574       -1     
===========================================
- Hits          2632     2627       -5     
+ Misses         982      980       -2     
  Partials       202      202              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Comment on lines -191 to -206
@trace_charm(
tracing_endpoint="tracing_endpoint",
extra_types=(
GrafanaDashboardProvider,
LogProxyConsumer,
MetricsEndpointProvider,
Patroni,
PostgreSQL,
PostgreSQLAsyncReplication,
PostgreSQLBackups,
PostgreSQLLDAP,
PostgreSQLProvider,
TLS,
RollingOpsManager,
),
)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's no shared auto-instrumentation. Traces would show up as juju hooks.

Copy link
Contributor

Choose a reason for hiding this comment

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

do individual ops events (e.g. if there's more than one ops event in a juju hook) show up?

if not, does the tracing add any value? since we can get timings from the debug-log

Copy link
Contributor

Choose a reason for hiding this comment

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

I am planning a talk with Ops team the next office house (to restore profiling capabilities without re-implementing it in charm).

yes, it is a functional regression, but ops[tracing] if currently focused on distributed tracing and not on charm profiling. Anyway we have to migrate as charm lib has been deprecated and CVE affected.

Copy link
Contributor

Choose a reason for hiding this comment

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

to restore profiling capabilities

I'm not sure how useful they were initially (never used in production afaik because of the overhead), and they came at a cost of harder to understand tracebacks. I think detailed profiling could be interesting, but using an approach similar to parca—i.e. sampling instead of tracing; not modifying the workload


what I was wondering is what the existing ops tracing currently adds over the debug log

Ops creates the root span and a separate span when calling each observer

https://documentation.ubuntu.com/ops/latest/explanation/tracing/

it sounds like multiple ops events in a juju event are traced separately? not sure if I am understanding correctly

Copy link
Contributor Author

Choose a reason for hiding this comment

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

do individual ops events (e.g. if there's more than one ops event in a juju hook) show up?

if not, does the tracing add any value? since we can get timings from the debug-log

It's a mixed bag, IMHO. We get more details from ops itself, but less from the charm code:
trace

According to https://documentation.ubuntu.com/ops/latest/explanation/tracing/#division-of-responsibilities only some of the charm code is expected to be instrumented.

Copy link
Contributor

Choose a reason for hiding this comment

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

oh it's nice the hook commands are instrumented!

[[package]]
name = "protobuf"
version = "4.25.8"
version = "6.33.5"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated protobuf.

@dragomirp dragomirp marked this pull request as ready for review February 19, 2026 15:30
@dragomirp dragomirp requested review from a team, carlcsaposs-canonical, juju-charm-bot, marceloneppel and taurus-forever and removed request for a team February 19, 2026 15:30
Comment on lines -191 to -206
@trace_charm(
tracing_endpoint="tracing_endpoint",
extra_types=(
GrafanaDashboardProvider,
LogProxyConsumer,
MetricsEndpointProvider,
Patroni,
PostgreSQL,
PostgreSQLAsyncReplication,
PostgreSQLBackups,
PostgreSQLLDAP,
PostgreSQLProvider,
TLS,
RollingOpsManager,
),
)
Copy link
Contributor

Choose a reason for hiding this comment

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

do individual ops events (e.g. if there's more than one ops event in a juju hook) show up?

if not, does the tracing add any value? since we can get timings from the debug-log

Comment on lines -191 to -206
@trace_charm(
tracing_endpoint="tracing_endpoint",
extra_types=(
GrafanaDashboardProvider,
LogProxyConsumer,
MetricsEndpointProvider,
Patroni,
PostgreSQL,
PostgreSQLAsyncReplication,
PostgreSQLBackups,
PostgreSQLLDAP,
PostgreSQLProvider,
TLS,
RollingOpsManager,
),
)
Copy link
Contributor

Choose a reason for hiding this comment

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

I am planning a talk with Ops team the next office house (to restore profiling capabilities without re-implementing it in charm).

yes, it is a functional regression, but ops[tracing] if currently focused on distributed tracing and not on charm profiling. Anyway we have to migrate as charm lib has been deprecated and CVE affected.

@github-actions github-actions bot added Libraries: Out of sync The charm libs used are out-of-sync and removed Libraries: OK The charm libs used are OK and in-sync labels Feb 20, 2026
pyproject.toml Outdated
@@ -32,8 +32,6 @@ poetry-core = "*"
Copy link
Member

Choose a reason for hiding this comment

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

This comment can be removed, right? If so, I believe it can also be removed in canonical/pgbouncer-k8s-operator#687 and #1279.

@dragomirp dragomirp changed the title [DPE-9444] Switch to ops tracing [DPE-9444] Switch to ops tracing (16/edge) Feb 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature, UI change, or workload upgrade Libraries: Out of sync The charm libs used are out-of-sync

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants