If you've ever wanted to contribute to #OpenTelemetry but weren't sure how to get started, I've got your back! ✌️
Want to learn more? Check out my blog post: https://medium.com/cloud-native-daily/how-to-contribute-to-opentelemetry-5962e8b2447e
opentelemetry
I've been thinking about adding federation health monitoring to #Fedify—not as a separate data store or custom API, but by extending the existing #OpenTelemetry integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.
Does this sound useful to you? I'm curious whether people building on Fedify—or running federated servers in general—would actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.
Leading your organization to use #OpenTelemetry is a challenge. In addition to all the usual project hurdles, you’ll face one of these two situations: convince your teams to use OTEL, or convince them to move from the telemetry tool they are already using to OTEL. Most people don’t want to change. You’ll need lots of effort and baby steps. My tip is the following: the fewer the changes, the higher your chances of success.