Hashtag

#OpenTelemetry

180 posts tagged with this hashtag.

OpenTelemetry
@opentelemetry@fosstodon.org

🗓️ Over a year in the making
📈 One of the fastest-growing projects in

Introducing the Ecosystem Explorer

is huge: hundreds of instrumentations across a dozen languages, plus the Collector. Figuring out what telemetry you actually get used to mean deploying first.

Not anymore. The Ecosystem Explorer helps you understand OTel before you start. We’re starting with Java, with plenty more to come.

Got ideas? Come build with us.

opentelemetry.io/blog/2026/int

OpenTelemetry
@opentelemetry@fosstodon.org

OpenTelemetry ❤️ Prometheus!

The and communities are strengthening interoperability, and we want your input!

🛠️ If you’re building with both, check out the client library doc to understand key similarities and differences, plus updates on Prometheus compatibility and exporter spec stabilization. Links in thread.

📄 We’re also supporting an LFX mentorship to improve interoperability docs.

🗳️ Running both together? Take our 3-minute survey! buff.ly/XhVm0Fg

joschi
@joschi@hachyderm.io

Are you living in Sydney, AUS? Are you looking for a job in the platform engineering and space?

This is your chance to join a great startup in the space which recently acquired unicorn status:

jobs.ashbyhq.com/dash0/c71c1a0

jobs.ashbyhq.com

Platform Engineer

ABOUT DASH0 Join Dash0 and help us define the future of observability. We are OpenTelemetry-native, building a delightful, simple, and AI-centric platform that eliminates vendor lock-in and meaningless toil. Shape a product that developers love—all with transparent pricing and cost-control built in. THE OPPORTUNITY Dash0 is building the observability platform that developers actually want to use — OpenTelemetry-native, transparent, and designed to eliminate the lock-in and complexity that define the incumbent players. As we expand engineering capacity globally, we're looking for a Mid-Level Platform Engineer to join our growing team in the Sydney area. This role is fully remote, but you'll be based in the Sydney, Australia area to collaborate regularly in person with the existing regional team member. You'll work across infrastructure, automation, and reliability — owning foundational systems that let our product teams move fast without breaking things. If you're a few years into your platform engineering career and ready to take on real ownership in a fast-moving environment, this is the right next step. What You'll Do - Build and maintain CI/CD pipelines and deployment automation to support continuous, high-quality software delivery - Provision and manage cloud infrastructure using Terraform, keeping things scalable, secure, and well-documented - Partner with product engineering teams to design resilient, cloud-native solutions and review code for quality and standards adherence - Monitor, troubleshoot, and improve platform performance and availability — including on-call coverage when needed - Embed security best practices into platform design, from access controls and encryption through to deployment pipelines - Contribute to platform architecture decisions and help evolve our infrastructure as the product and team scale - Write and maintain technical documentation: architecture diagrams, runbooks, and infrastructure standards What You Bring - 3–5 years of platform, infrastructure, or DevOps engineering experience - Solid Go (GoLang) programming skills — you're writing and reviewing production Go code, not just reading it - Hands-on experience with Terraform or comparable infrastructure-as-code tooling - Working knowledge of containerization and orchestration (Docker, Kubernetes) - Experience building and operating CI/CD pipelines in a cloud environment (AWS, GCP, or Azure) - Strong async communication skills — you're comfortable working across time zones and explaining infrastructure decisions to non-infrastructure engineers - Based in the Sydney, Australia area with the ability to meet the local team in person regularly Nice to Have - Experience with observability tooling, monitoring platforms, or OpenTelemetry instrumentation - Familiarity with security compliance frameworks relevant to SaaS platforms (e.g., SOC 2, ISO 27001) - Experience in a high-growth, venture-backed startup environment Why Dash0 This is a unique opportunity to help build a generational company. Dash0 is backed by top-tier investors including Balderton Capital, Accel and Cherry Ventures and led by a founding team with decades of experience in observability. We're in the middle of a massive growth phase after our Series B — and we're just getting started. If you're looking for a place where a great product meets great people, where momentum is real and your impact is visible from day one — this is it. What we offer: - Competitive salary & meaningful equity participation — you'll own part of what you're building - Flexible, remote-first work environment with offices in New York, Amsterdam, and Munich - €60/month phone & internet allowance - Location-specific benefits - Collaborative, fast-moving team culture with a builder mindset - Clear path for career growth and development - Direct access to founders and leadership

joschi
@joschi@hachyderm.io

Do you want support in ?

Since GitHub is asking for input on their GitHub Actions roadmap, maybe upvoting github.com/orgs/community/disc will give them a nudge to implement it. 😄

github.com

What’s coming to our GitHub Actions 2026 security roadmap - Feedback & Suggestions · community · Discussion #190621

🏷️ Discussion Type Product Feedback 💬 Feature/Topic Area Other Discussion Details We recently published a blog post outlining capabilities GitHub is actively investing in and developing for Actions...

OpenTelemetry
@opentelemetry@fosstodon.org

and CloudNativeCon EU is next week! If you'll be in Amsterdam, come say hi!

will be in the Project Pavilion at booth 19A for the entire day on Tuesday, March 24.

For the remainder of the event, find us at the ad-hoc meeting tables right next to the Project Pavilion.

We hope to see you there!

OpenTelemetry
@opentelemetry@fosstodon.org

🤔 Have you ever wondered how real organizations use the Collector in production? What architecture do they choose and why? How do they deploy it? How do they configure it to meet the requirements of a production system?

Check out the new blog series launched by the Developer Experience SIG! These posts will highlight end-user stories from a variety of industries, architectures, and company sizes. The first one is up today!

opentelemetry.io/blog/2026/dev

OpenTelemetry
@opentelemetry@fosstodon.org

‼️ is deprecating the Span Events API.

Our aim is to remove the confusion and duplication caused by having two overlapping ways to emit events: span events and log-based events. New code should write events as logs that are correlated with the current span. The older "span events" style will be phased out over time, but existing data and views that show events on spans will keep working.

Read our latest post to learn more about how you can prepare.

opentelemetry.io/blog/2026/dep

Fedify: ActivityPub server framework
@fedify@hollo.social

I've been thinking about adding federation health monitoring to —not as a separate data store or custom API, but by extending the existing 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.

Fedify: ActivityPub server framework
@fedify@hollo.social

I've been thinking about adding federation health monitoring to —not as a separate data store or custom API, but by extending the existing 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.

Fedify: ActivityPub server framework
@fedify@hollo.social

I've been thinking about adding federation health monitoring to —not as a separate data store or custom API, but by extending the existing 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.

Fedify: ActivityPub server framework
@fedify@hollo.social

I've been thinking about adding federation health monitoring to —not as a separate data store or custom API, but by extending the existing 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.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

I've been thinking about adding federation health monitoring to —not as a separate data store or custom API, but by extending the existing 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.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

I've been thinking about adding federation health monitoring to —not as a separate data store or custom API, but by extending the existing 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.

OpenTelemetry
@opentelemetry@fosstodon.org

⏳️ Years in the making...

The project is delighted to announce that declarative configuration is stable!

With implementations in five languages and two more in the works, declarative config brings greater configuration consistency across languages and more flexibility than environment variables can offer.

Congratulations to everyone who contributed to this momentous accomplishment!

opentelemetry.io/blog/2026/sta

OpenTelemetry
@opentelemetry@fosstodon.org

With the latest release of the Collector, the Filter Processor now includes OTTL context inference. In the legacy configuration, writing filters required understanding the Collector’s internal telemetry hierarchy. Context inference removes this complexity: instead of organizing conditions by context blocks, write a flat list using basic configuration style. Want details? 👇️ 👇️

opentelemetry.io/blog/2026/ott

Nick Istre
@nickistre@floss.social

So now it's my turn for a post. A couple decades in , specializing in systems, and . I can do , and . Languages I've worked in include , , and , and I can learn more. Open to hybrid work in the Seattle area or remote work, contract or full-time. Feel free to contact me or boost!

linkedin.com/in/nicholas-p-ist

linkedin.com

Nicholas P Istre - Samsung SDS America | LinkedIn

I am a programmer with a wide breadth of experience in server, network, and database… · Experience: Samsung SDS America · Education: University of Louisiana at Lafayette · Location: Greater Seattle Area · 303 connections on LinkedIn. View Nicholas P Istre’s profile on LinkedIn, a professional community of 1 billion members.

Nick Istre
@nickistre@floss.social

So now it's my turn for a post. A couple decades in , specializing in systems, and . I can do , and . Languages I've worked in include , , and , and I can learn more. Open to hybrid work in the Seattle area or remote work, contract or full-time. Feel free to contact me or boost!

linkedin.com/in/nicholas-p-ist

linkedin.com

Nicholas P Istre - Samsung SDS America | LinkedIn

I am a programmer with a wide breadth of experience in server, network, and database… · Experience: Samsung SDS America · Education: University of Louisiana at Lafayette · Location: Greater Seattle Area · 303 connections on LinkedIn. View Nicholas P Istre’s profile on LinkedIn, a professional community of 1 billion members.

Damien
@dmathieu@fosstodon.org

talk on auto-instrumentation.

"Using the Go SDK is too complicated" (their example was actually a bit hypocritical, as you do not need to manually instrument every HTTP handler).
"Write YAML instead, it's quite simple". 🤔

OpenTelemetry
@opentelemetry@fosstodon.org

The website and documentation SIG is taking a look back at 2025:

- Eight localization teams produced nearly 75k lines of translation! 🚀
- PRs merged grew 50%! 📈
- Ten contributors were promoted to SIG leadership! 🔟

Looking to get started in open source? Documentation is a great entry point! Check out our new blog post for all the exciting achievements from last year and how you can join us this year.

opentelemetry.io/blog/2026/202

OpenTelemetry
@opentelemetry@fosstodon.org

❓ A question to start the year: what can you learn from analyzing thousands of Slack messages?

The project answers this question in our first blog post of 2026. Using a combination of sentiment analysis, frustration indicators, and topic correlation of aggregated Slack data, we identified the top challenges for users. We'll be working to address these issues over the course of the year. Come join us!

opentelemetry.io/blog/2026/sla

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Fedify: ActivityPub server framework
@fedify@hollo.social

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a framework for building servers that participate in the . It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

  • activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
  • activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
  • activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

  • activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
  • activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

  • MemoryKvStore — filters in-memory keys by prefix
  • SqliteKvStore — uses LIKE query with JSON key pattern
  • PostgresKvStore — uses array slice comparison
  • RedisKvStore — uses SCAN with pattern matching and key deserialization
  • DenoKvStore — delegates to Deno KV's built-in list() API
  • WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

github.com

fedify/CHANGES.md at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

Grafana Labs
@grafana@grafana.social

🇪🇸 2026 is heading to Barcelona, Spain from 20-22 Apr!

Get ready to feel on tapas the world at our biggest community conference of the year.

This conference goes beyond . It’s also about all of the other open source projects in our ecosystem (, , Loki, etc.), plus related data source plugins and collectors.

Sign up to receive notifications when 30% discount tickets go on sale: grafana.com/events/grafanacon/

GrafanaCON 2026 Save the Date for 20-22 April, 2026 in Barcelona, Spain.
ALT text

GrafanaCON 2026 Save the Date for 20-22 April, 2026 in Barcelona, Spain.

Grafana Labs
@grafana@grafana.social

🇪🇸 2026 is heading to Barcelona, Spain from 20-22 Apr!

Get ready to feel on tapas the world at our biggest community conference of the year.

This conference goes beyond . It’s also about all of the other open source projects in our ecosystem (, , Loki, etc.), plus related data source plugins and collectors.

Sign up to receive notifications when 30% discount tickets go on sale: grafana.com/events/grafanacon/

GrafanaCON 2026 Save the Date for 20-22 April, 2026 in Barcelona, Spain.
ALT text

GrafanaCON 2026 Save the Date for 20-22 April, 2026 in Barcelona, Spain.

OpenTelemetry
@opentelemetry@fosstodon.org

There is no open source without community.

Today we're delighted to announce the winners of the second annual Community Awards! These individuals were nominated by their peers for their exceptional efforts to the project over the past year.

Congratulations to the winners! And thank you to the entire community for your hard work! We literally couldn't do it without you.

opentelemetry.io/blog/2025/com

OpenTelemetry
@opentelemetry@fosstodon.org

📢 日本のOpenTelemetry（OTel）エンドユーザーの皆様へ！

OTel End User SIGとOTel日本語ローカライズチームが、OTel活用事例を紹介するオンラインイベントを開催します。

💬 あなたの経験を共有しましょう
✨ 発見した素晴らしい知見を披露しましょう

特集インタビューにご協力いただける方は、返信をお願いします。ぜひあなたのストーリーを共有させてください！🫶

OpenTelemetry
@opentelemetry@fosstodon.org

📢 日本のOpenTelemetry（OTel）エンドユーザーの皆様へ！

OTel End User SIGとOTel日本語ローカライズチームが、OTel活用事例を紹介するオンラインイベントを開催します。

💬 あなたの経験を共有しましょう
✨ 発見した素晴らしい知見を披露しましょう

特集インタビューにご協力いただける方は、返信をお願いします。ぜひあなたのストーリーを共有させてください！🫶

Thomas Vitale ☀️
@thomasvitale@mastodon.online

The goal of Arconia OpenTelemetry is to provide a single dependency you can add to your Spring Boot application to get unified Java observability with minimal configuration and maximum compatibility with both OpenTelemetry and Micrometer ecosystems.



thomasvitale.com/spring-boot-o

thomasvitale.com

Spring Boot Observability with Arconia OpenTelemetry

Arconia OpenTelemetry enhances observability for Spring Boot by combining the standardization of OpenTelemetry with the robustness of Micrometer.

OpenTelemetry
@opentelemetry@fosstodon.org

Everyone knows is designed to provide useful attributes that can be easily filtered and aggregated by any backend. But what happens when the data itself is complex?

We are excited to announce upcoming support for capturing complex data across all signals starting with OTLP 1.9.0. With this advancement, you'll be able to observe real-world systems, libraries, and applications whose properties are sometimes complex. Learn more in our latest post.

opentelemetry.io/blog/2025/com

OpenTelemetry
@opentelemetry@fosstodon.org

Help spotlight the people moving forward. Nominations for the 2025 OpenTelemetry Community Awards are open until November 6th. Take a minute to nominate: opentelemetry.io/blog/2025/com

opentelemetry.io

2025 OpenTelemetry Community Awards

OpenTelemetry is a community-driven project, fueled by a group of awesome humans who are actively revolutionizing the field of observability with their contributions. Whether it’s through code, documentation, project management, outreach, adoption, or simply helping others answer technical questions on our CNCF Slack, we want to recognize these contributions and the people behind them — because we’re all human, and we all like that warm fuzzy feeling of appreciation. We are thrilled to announce the second annual OpenTelemetry Community Awards! This is your chance to nominate individuals who have made a notable impact to OpenTelemetry over the past year. Everyone can nominate anyone in the community, be they a contributor, end-user, or community member.

Sean Hood
@seanhood@hachyderm.io

Came across this over the weekend: rotel.dev/docs/category/aws-la

A lightweight collector in Rust (because ofc it's Rust)

It does seem to cut down on coldstart times within compared to the upstream OTEL Lambda layer (github.com/open-telemetry/open) not the ADOT one, haven't compared that.

github.com

GitHub - open-telemetry/opentelemetry-lambda: Create your own Lambda Layer in each OTel language using this starter code. Add the Lambda Layer to your Lambda Function to get tracing with OpenTelemetry.

Create your own Lambda Layer in each OTel language using this starter code. Add the Lambda Layer to your Lambda Function to get tracing with OpenTelemetry. - open-telemetry/opentelemetry-lambda

OpenTelemetry
@opentelemetry@fosstodon.org

New blog post for everyone who wants to get started with contributing to : opentelemetry.io/blog/2025/con

opentelemetry.io

How to Contribute to OpenTelemetry

You might have heard about OpenTelemetry, found it interesting and want to get involved, but the path to contribution isn’t immediately clear. You might start messaging people asking to get assigned to issues, or just give a shout out saying “I’m here to help, just let me know”, but you never hear back. So how can you actually start contributing to OpenTelemetry? Open source thrives on community, mutual support, and the collaborative development of innovative technology. It also comes with challenges, especially if you’re new to this ecosystem.

Pedro Piñera
@pedro@mastodon.pepicrft.me

TIL about the OpenLit for AI observability. It builds on and supports it

github.com/openlit/openlit

github.com

GitHub - openlit/openlit: Open source platform for AI Engineering: OpenTelemetry-native LLM Observability, GPU Monitoring, Guardrails, Evaluations, Prompt Management, Vault, Playground. 🚀💻 Integrates with 50+ LLM Providers, VectorDBs, Agent Frameworks and GPUs.

Open source platform for AI Engineering: OpenTelemetry-native LLM Observability, GPU Monitoring, Guardrails, Evaluations, Prompt Management, Vault, Playground. 🚀💻 Integrates with 50+ LLM Providers,...

OpenTelemetry
@opentelemetry@fosstodon.org

🚀 Vești bune pentru comunitatea din România!

Documentația OpenTelemetry are acum o pagină de prezentare disponibilă în limba română 🇷🇴

Construim acest proiect împreună și ne-ar bucura să avem alături mai mulți contribuitori vorbitori de română. Dacă vrei să ajuți, te așteptăm pe canalul -localization-ro de pe Slack-ul CNCF.

Hai să facem observabilitatea accesibilă pentru toată lumea!

opentelemetry.io/ro/

OpenTelemetry
@opentelemetry@fosstodon.org

Every established enterprise has that one system. It’s the one running in the corner, performing a critical function for years. It’s reliable, but it’s also a black box. No one wants to touch it for fear of breaking it. 🫣

But what if you could make that black box more transparent with no risk? Check out our latest blog post to learn how to instrument legacy applications without touching the code. Gain visibility, even in the cobwebby corners! 🕸️

opentelemetry.io/blog/2025/ope

OpenTelemetry
@opentelemetry@fosstodon.org

Our latest blog post explains how the End User SIG created a clear, low-effort, data-driven way for the community to signal the work that matters most.

So the next time you’re browsing issues, don’t just read and leave. When you find an issue that describes a problem you’re also facing or a feature you’d like to see implemented, give the issue description a 👍 reaction. That’s it! Like and subscribe. That’s the signal.

opentelemetry.io/blog/2025/iss

OpenTelemetry
@opentelemetry@fosstodon.org

Our latest blog post walks you through how to use basic grammar to name your custom spans. Follow this best practice to create clear, consistent names with low cardinality. Your future self thanks you!

opentelemetry.io/blog/2025/how

opentelemetry.io

How to Name Your Spans

One of the most fundamental yet often overlooked aspects of good instrumentation is naming. This post is the first in a series dedicated to the art and science of naming things in OpenTelemetry. We’ll start with spans, the building blocks of a distributed trace, and give you the most important takeaway right at the beginning: how to name the spans that describe your unique business logic. Naming your business spans While OpenTelemetry’s automatic instrumentation is fantastic for covering standard operations (like incoming HTTP requests or database calls), the most valuable insights often come from the custom spans you add to your own business logic. These are the operations unique to your application’s domain.

OpenTelemetry
@opentelemetry@fosstodon.org

⏳ Haven’t shared your experience with the OpenTelemetry Collector yet? There’s still time!

Our follow-up survey is still open, and we’re inviting all Collector users to help us understand:
- What’s improved
- What still needs work
- How we can better support your use cases

Even if you responded to the first survey, we’d love your updated perspective.

📝 Take 5 minutes and tell us what’s up → buff.ly/Ghoh5H9

OpenTelemetry
@opentelemetry@fosstodon.org

New blog post! in Practice: Alibaba's OpenTelemetry Journey

opentelemetry.io/blog/2025/oti

opentelemetry.io

OTel in Practice: Alibaba's OpenTelemetry Journey

In the latest session of OTel in Practice, engineers Huxing Zhang and Steve Rao shared Alibaba’s journey adopting OpenTelemetry within their services. The discussion focused on a wide range of topics, from Java agents to Go compile-time instrumentation, and of course Gen-AI observability! Focusing on Java, Alibaba initially used an in-house solution based on Pinpoint, but faced limitations with framework support and asynchronous context propagation. It was then that they decided to migrate to OpenTelemetry to leverage its strong ecosystem and status as an industry standard.

OpenTelemetry
@opentelemetry@fosstodon.org

OpenTelemetry Collector users — we want to hear from you (again)!

Last year, we did a survey to learn how you’re using the Collector. The response shaped a lot of our thinking. Now we’re back with a quick follow-up.

Tell us what’s changed, what’s working, and what’s still rough.

👉 forms.gle/42j5rV7rhousorjDA

docs.google.com

OTel Collector Follow-up Survey

This follow-up survey helps the OTel Collector SIG track how usage patterns and needs have evolved since our previous survey. Your responses will help us see what's working, what's changed, and where we should focus our efforts next. 📅 It will run for one month from the day it's published. ⌚ It will only take a few minutes to complete.

OpenTelemetry
@opentelemetry@fosstodon.org

📣 This Wednesday, 16th July at 4PM CST / 10AM CET join us for a new session of OTel in Practice with Huxing Zhang and Steve Rao.

🔭 Discover how Alibaba has approached adoption within their internal platform and services. We’ll cover challenges and learnings from large-scale migrations, and the journey that has led them to be active contributors to OpenTelemetry!

📅 RSVP at community.cncf.io/j/jjqff3gapt

community.cncf.io

OTel in Practice: Alibaba's OpenTelemetry Journey | CNCF

Virtual Event - Join us for a new session of OTel in Practice with Huxing Zhang, Staff Engineer at Alibaba and OTel Go Compile-Time Inst...

OpenTelemetry
@opentelemetry@fosstodon.org

Introducing...the Injector! The Injector, recently donated by , helps you automatically instrument your applications no matter the programming languages used. Learn more in our latest blog post!

opentelemetry.io/blog/2025/ote

opentelemetry.io

Adding Automatic Instrumentation to Your App, Made Easy with the OpenTelemetry Injector

As OpenTelemetry adoption grows across infrastructure and application layers, easing the operational burden of instrumentation remains a shared priority. Today, we’re excited to highlight a recent donation from Splunk to the OpenTelemetry community: a host-based mechanism to automatically inject OpenTelemetry Automatic Instrumentation into your app on any Linux host. This component has reached production stability and is now being donated to the community as the OpenTelemetry Injector. It helps streamline OpenTelemetry deployment across languages and systems.

OpenTelemetry
@opentelemetry@fosstodon.org

Earlier this year, we heard from contributors in our Contributor Experience Survey. Now we're ready to release the results! Our latest blog post explains everything we learned from the contributor community. Your responses will guide us as we improve the project and the contribution experience.

Thank you to all the contributors who took time to complete the survey and provide thoughtful feedback!

opentelemetry.io/blog/2025/con

OpenTelemetry
@opentelemetry@fosstodon.org

Our newest blog post walks you through how to expose the Collector securely using the Gateway API and mutual TLS.

opentelemetry.io/blog/2025/exp

opentelemetry.io

Exposing OTel Collector in Kubernetes with Gateway API & mTLS

The goal of this blog post is to demonstrate how you can expose an OpenTelemetry (OTel) Collector running inside Kubernetes to the outside world securely, using the Kubernetes Gateway API and mutual TLS (mTLS) for authentication and encryption. As observability becomes increasingly critical in modern distributed systems, centralizing telemetry data via OTel Collectors deployed in one or many Kubernetes clusters is common practice. Often, services or agents running outside your Kubernetes cluster need to send data to these Collectors. Exposing internal services requires careful consideration of security and standardization. This is where the Kubernetes Gateway API and mTLS shine.

OpenTelemetry
@opentelemetry@fosstodon.org

🚨 Just 2 days to go! Have you RSVP’d for the next OTel Me session?

We’re chatting with Oluwatomisin Taiwo and Andrei Morozov about how they're using at Compass Digital. Don't miss it.

🗓️ June 10, 2024
🕐 13:00 EDT | 19:00 CEST | 10:00 PDT

📌 Register here: buff.ly/2oGtiAq

DiazCarrete
@DiazCarrete@hachyderm.io

baggage vs. attributes in OpenTelemetry

opentelemetry.io/docs/concepts

opentelemetry.io/docs/specs/ot

"Baggage can be used regardless of whether Distributed Tracing is used." w3.org/TR/baggage/

w3.org

Propagation format for distributed context: Baggage

This specification defines a standard for representing and propagating a set of application-defined properties associated with a distributed request or workflow execution.

OpenTelemetry
@opentelemetry@fosstodon.org

Do you work on an RPC framework or use them extensively? Check out the newest blog post announcing the RPC Semantic Convention stabilization project!

opentelemetry.io/blog/2025/sta

opentelemetry.io

Announcing the RPC Semantic Conventions stabilization project

The Semantic Conventions SIG is excited to kick off the RPC stabilization effort! Following the stabilization of the database conventions in May 2025, we’re continuing our work to stabilize key areas—and RPC is next. It takes a village to define a solid convention, especially for a space as diverse as RPC technologies, which include gRPC, JSON-RPC, Apache Dubbo, and many others. If you work on one of these frameworks, use them extensively, or are simply interested in learning more, come join us—we’d love your help!

OpenTelemetry
@opentelemetry@fosstodon.org

🎙️ Join us for the next edition of OTel Me. This time, we’ll hear from Oluwatomisin Taiwo and Andrei Morozov of Compass Digital as they share their organization's journey.

🗓️ June 10, 2024
🕐 13:00 EDT | 19:00 CEST | 10:00 PDT
🎤 Co-hosted by Adriana Villela and Andrej Kiripolski

📌 RSVP here: community.cncf.io/events/detai

OpenTelemetry
@opentelemetry@fosstodon.org

Join the community in Hong Kong for + CloudNativeCon China 2025.

opentelemetry.io/blog/2025/kub

opentelemetry.io

Join us for OpenTelemetry Talks and Activities at KubeCon + CloudNativeCon China 2025

The OpenTelemetry project invites you to join members of the OpenTelemetry community at KubeCon + CloudNativeCon China (registration) in Hong Kong from June 10 to 11, 2025. This post covers all currently scheduled activities related to OpenTelemetry that are happening during KubeCon. Check back for updates before the start of the conference! KubeCon talks and maintainer sessions Antipatterns in Observability: Lessons Learned and How OpenTelemetry Solves Them by Steve Flanders, Splunk Tuesday, June 10 • 13:45 - 14:15 Advancing Observability With Compile-Time Auto-Instrumentation in Golang by Liu Ziming, Alibaba Cloud & Przemek Delewski, Quesma Tuesday, June 10 • 14:30 - 15:00 OpenTelemetry Project Update by Zihao Rao, Alibaba Cloud; Hui Wang, VictoriaMetrics; Jared Tan, DaoCloud Tuesday, June 10 • 16:15 -16:45 Unified Observability in gRPC: Metrics and Tracing Using OpenTelemetry Plugin by Purnesh Dixit, Google Wednesday, June 11 • 11:00 - 11:30 Join us Come listen, learn, and get involved in OpenTelemetry. See you in Hong!

OpenTelemetry
@opentelemetry@fosstodon.org

এখন থেকে এর হোমপেজ বাংলায়ও উপলব্ধ!
বাংলাভাষী ডেভেলপারদের জন্য অবজারভেবিলিটি শেখা এখন আরও বেশি সহজ।
এখানে দেখুন: opentelemetry.io/bn

---

We’re excited to share that the OpenTelemetry homepage is now available in Bengali!
This makes it easier for Bengali-speaking developers to get started with observability.
Visit here: opentelemetry.io/bn

Grafana Labs
@grafana@grafana.social

We've made the initial code drop of Grafana Beyla to , under the new project name OpenTelemetry eBPF Instrumentation.

Here's a closer look at why we’re donating Beyla, what it means for users and the broader open source community, and what’s next: grafana.com/blog/2025/05/07/op

grafana.com

Introducing OpenTelemetry eBPF Instrumentation: Why we donated Grafana Beyla to OpenTelemetry | Grafana Labs

We’re excited to share that we’ve made the initial code drop of Grafana Beyla to OpenTelemetry, under the new project name OpenTelemetry eBPF Instrumentation.

Grafana Labs
@grafana@grafana.social

We've made the initial code drop of Grafana Beyla to , under the new project name OpenTelemetry eBPF Instrumentation.

Here's a closer look at why we’re donating Beyla, what it means for users and the broader open source community, and what’s next: grafana.com/blog/2025/05/07/op

grafana.com

Introducing OpenTelemetry eBPF Instrumentation: Why we donated Grafana Beyla to OpenTelemetry | Grafana Labs

We’re excited to share that we’ve made the initial code drop of Grafana Beyla to OpenTelemetry, under the new project name OpenTelemetry eBPF Instrumentation.

OpenTelemetry
@opentelemetry@fosstodon.org

Phase 2 of the OTel-Arrow project is underway! Find out more in our newest blog post.

opentelemetry.io/blog/2025/ote

-arrow

opentelemetry.io

OpenTelemetry Protocol with Apache Arrow - Phase 2 Announcement

We are excited to announce the next phase of the OpenTelemetry Protocol with Apache Arrow project (OTel-Arrow). We began this project several years ago with the goal of bridging between OpenTelemetry data and the Apache Arrow ecosystem. Apache Arrow is a framework designed for zero-copy exchange of structured data between column-oriented data producers and consumers. We believe that having OpenTelemetry data accessible to external systems through Apache Arrow will lead to powerful integrations, with the potential for new telemetry systems and applications to emerge. For large streams of telemetry, we know that column-oriented data handling is substantially more efficient, with improved data compression and performance.

OpenTelemetry
@opentelemetry@fosstodon.org

We hope everyone is enjoying KubeCon EU!

Today's blog post is all about the community. In a follow-up to his KubeCon talk of the same name, Governance Committee member Juraci Paixão Kröhling shares his interviews with community members, learning what they love and hate about . Whether you're an end user or a project contributor, we hear you and value your feedback!

opentelemetry.io/blog/2025/ote

opentelemetry.io

OTel Sucks (But Also Rocks!)

OpenTelemetry (OTel) is often touted as the future of observability, promising vendor neutrality and comprehensive data collection. But what’s the reality for those who use it daily? We sat down with several engineers and SREs to get their unfiltered thoughts on OTel. The result? A candid conversation about the good, the bad, and the sometimes frustrating aspects of working with OTel. In preparation for the KubeCon talk OTel Sucks (But Also Rocks!), Juraci spoke with community members and gathered a wealth of valuable insights. Due to time constraints, not all the material could be included in the presentation, so this is an attempt to do justice to the community’s contributions.

OpenTelemetry
@opentelemetry@fosstodon.org

The JavaScript SDK 2.0 is here!

opentelemetry.io/blog/2025/ote

opentelemetry.io

Announcing the OpenTelemetry JavaScript SDK 2.0

Exciting news: OpenTelemetry JavaScript has released SDK 2.0! Migration guide For a detailed description of breaking changes, see the migration guide: Upgrade to OpenTelemetry JS SDK 2.x. What is JS SDK 2.x? JS SDK 2.x encompasses new releases of the @opentelemetry/* JavaScript packages published from the opentelemetry-js repository, except the API and semantic-conventions packages. The package versions for this new major will be >=2.0.0 for the stable and >=0.200.0 for the unstable packages. Details on the full list of packages can be found in the migration guide.

OpenTelemetry
@opentelemetry@fosstodon.org

The JavaScript SDK 2.0 is here!

opentelemetry.io/blog/2025/ote

opentelemetry.io

Announcing the OpenTelemetry JavaScript SDK 2.0

Exciting news: OpenTelemetry JavaScript has released SDK 2.0! Migration guide For a detailed description of breaking changes, see the migration guide: Upgrade to OpenTelemetry JS SDK 2.x. What is JS SDK 2.x? JS SDK 2.x encompasses new releases of the @opentelemetry/* JavaScript packages published from the opentelemetry-js repository, except the API and semantic-conventions packages. The package versions for this new major will be >=2.0.0 for the stable and >=0.200.0 for the unstable packages. Details on the full list of packages can be found in the migration guide.

OpenTelemetry
@opentelemetry@fosstodon.org

The JavaScript SDK 2.0 is here!

opentelemetry.io/blog/2025/ote

opentelemetry.io

Announcing the OpenTelemetry JavaScript SDK 2.0

Exciting news: OpenTelemetry JavaScript has released SDK 2.0! Migration guide For a detailed description of breaking changes, see the migration guide: Upgrade to OpenTelemetry JS SDK 2.x. What is JS SDK 2.x? JS SDK 2.x encompasses new releases of the @opentelemetry/* JavaScript packages published from the opentelemetry-js repository, except the API and semantic-conventions packages. The package versions for this new major will be >=2.0.0 for the stable and >=0.200.0 for the unstable packages. Details on the full list of packages can be found in the migration guide.

OpenTelemetry
@opentelemetry@fosstodon.org

The JavaScript SDK 2.0 is here!

opentelemetry.io/blog/2025/ote

opentelemetry.io

Announcing the OpenTelemetry JavaScript SDK 2.0

Exciting news: OpenTelemetry JavaScript has released SDK 2.0! Migration guide For a detailed description of breaking changes, see the migration guide: Upgrade to OpenTelemetry JS SDK 2.x. What is JS SDK 2.x? JS SDK 2.x encompasses new releases of the @opentelemetry/* JavaScript packages published from the opentelemetry-js repository, except the API and semantic-conventions packages. The package versions for this new major will be >=2.0.0 for the stable and >=0.200.0 for the unstable packages. Details on the full list of packages can be found in the migration guide.

OpenTelemetry
@opentelemetry@fosstodon.org

This week on March 20! We've got our very first repeat guest lined up for OTel Me, our end user Q&A. Join us to find out how the team at Relativity, an early adopter, have handled the various project changes over the last 3 years, and what's next for them.

OpenTelemetry
@opentelemetry@fosstodon.org

Last week before our Survey closes. Take it and help us enhance the contributor experience. We appreciate your time and feedback! buff.ly/MXTzSdD

opentelemetry.io

The OpenTelemetry Contributor Experience Survey is open!

TL;DR Take our OpenTelemetry Contributor Survey and help us enhance the contributor experience. We appreciate your time and feedback! Since its founding, OpenTelemetry has had thousands of contributors from around the world, including end users, vendors, and students. Last summer some members of the OpenTelemetry project came together to create the Contributor Experience SIG, which is focused on ensuring that contributors of all types have a great experience with the OpenTelemetry project. Since then, the SIG has worked on several initiatives, including an Outreachy project to develop up-to-date contributor docs.

OpenTelemetry
@opentelemetry@fosstodon.org

SIG Mainframe is looking for your feedback! Please fill out the following survey: buff.ly/3PZdpaW

opentelemetry.io

OpenTelemetry on Mainframe Priorities Survey

The OpenTelemetry project and The Open Mainframe Project established the SIG “OpenTelemetry on Mainframe” at the beginning of 2024. Our focus is to enable OpenTelemetry on the mainframe for improved end-to-end observability and to support mainframe participation in hybrid cloud applications. The SIG launched a new survey that calls for your participation. Background While there are many definitions of observability, we will refer here to the ability to receive actionable insight about the behavior of hybrid applications spanning multiple landing zones such as public and private cloud and mainframe environments.

Grafana Labs
@grafana@grafana.social

🎉 Grafana Beyla 2.0 is here! Check out new features related to distributed tracing, deployments, and deeper alignment with .

grafana.com/blog/2025/02/10/gr

grafana.com

Grafana Beyla 2.0: distributed traces, scalable Kubernetes deployments, and more | Grafana Labs

Grafana Beyla 2.0 is here, delivering a number of new features related to distributed tracing, Kubernetes deployments, and deeper alignment with OpenTelemetry.

Grafana Labs
@grafana@grafana.social

🎉 Grafana Beyla 2.0 is here! Check out new features related to distributed tracing, deployments, and deeper alignment with .

grafana.com/blog/2025/02/10/gr

grafana.com

Grafana Beyla 2.0: distributed traces, scalable Kubernetes deployments, and more | Grafana Labs

Grafana Beyla 2.0 is here, delivering a number of new features related to distributed tracing, Kubernetes deployments, and deeper alignment with OpenTelemetry.

OpenTelemetry
@opentelemetry@fosstodon.org

There's still time to give gift of feedback! ❤️🔭🎁 Are you a developer using ? Then take our OTel developer experience survey to let us know what you think! Your feedback helps us make improvements to the project. Survey runs through January 31st, 2025.

buff.ly/4gyZ6VP

joschi
@joschi@hachyderm.io

I usually don't post about work-related stuff except for ranting or asking technical questions, but this time I'll make an exception:

Today, Dash0 went out of beta and I am very proud to be part of the magnificent team making this Native solution possible. 😀

If you’re looking for an observability solution, such as , , , or , then give it a spin!

Start your free 14-days trial at www.dash0.com!

Honeycomb.io
@honeycombio@mastodon.social

As we take our first steps into the fediverse, we are wondering - are there specific things you'd like to see from us?

Obviously we plan to keep posting about & , with our usual meanderings into engineering management & . And you'll never pry us away from or snark.

Also: if you're wondering why we followed you here, it's because you were following us on Twitter and we wanted you to know we were here!