Grafana has released the OpenLIT Operator, a Kubernetes-native solution for monitoring AI workloads without requiring code changes. The integration with Grafana Clouds AI Observability suite promises…
Grafana Cloud AI Observability and the OpenLIT Operator point to a practical operational pattern for LLM workloads on Kubernetes: instrument by policy, collect with OpenTelemetry, and make cost, latency, and quality visible without asking every application team to wire tracing by hand.
OpenTelemetry is deprecating the Span Events API to eliminate confusion and unify event handling through log-based events correlated with spans.
Key portions of the OpenTelemetry declarative configuration specification have been marked stable, including the JSON schema, YAML representation, and SDK operations for parsing and instantiation.
OpenTelemetry’s declarative configuration model just reached a stable milestone. That’s not a cosmetic win — it’s a shift toward consistent, policy-friendly telemetry configuration across languages, SDKs, and (increasingly) the Collector. Here’s what’s stabilized, what’s not, and how platform teams should plan adoption.
Collector-contrib v0.146.0 brings OTTL context inference to the Filter Processor, reducing config footguns and making filtering rules more readable. Here’s what changes for platform teams running OTel at scale.
The OpenTelemetry project says key parts of its declarative configuration spec are now stable, including the data model schema and YAML representation. That’s a quiet milestone with big implications: versionable config, safer rollout patterns, and vendor-neutral ‘observability as code.’
Collector-contrib v0.146.0 adds context inference to the Filter Processor, letting teams write readable, intent-first OTTL conditions instead of juggling internal contexts. Here’s what changes, how evaluation works, and how to adopt it safely.
OpenTelemetry’s eBPF Instrumentation project shipped its first alpha release. Here’s what you gain (and what you still don’t) when you shift observability left—down into the kernel.
OpenTelemetry’s eBPF instrumentation (OBI) is now shipping an initial release, pushing the ecosystem toward low-friction, kernel-level telemetry—especially for large fleets where manual instrumentation doesn’t scale. Here’s what eBPF-based signals are good for, where they’re risky, and how to roll them out safely in production.
OpenTelemetry’s eBPF Instrumentation project (OBI) just hit its first release. That’s a milestone for low-overhead, zero-code observability—but it also raises new questions about privilege, fleet rollout, and data governance.
Logs are expensive because repetition is free to emit and costly to store. The OTel Collector’s log deduplication processor offers a new middle path: compress noise at ingest while preserving incident context.
OpenTelemetry is now mainstream, and the project’s own ‘2025 year in review’ highlights a less-discussed scaling story: documentation localization, contributor growth, and the operational maturity required when observability becomes an industry baseline.
A quiet but important trend: vendors are shifting OpenTelemetry collector distribution to CDNs. That changes reliability, patch velocity, and how platform teams should govern observability agents.
The Collector is easy to deploy but surprisingly easy to misconfigure at scale. This guide focuses on the practical knobs—pipelines, batching, tail sampling, memory limits, and auth—to turn ‘telemetry works’ into ‘telemetry is reliable.’
OpenTelemetry adoption is running into a new bottleneck: operating collector fleets. IBM Instana just made OpAMP-powered fleet management generally available, highlighting a shift from ‘instrumentation’ to ‘collector ops’ as the next maturity step.
Grafana is positioning its Assistant as an agent grounded in your telemetry and transparent about queries. Here’s how to evaluate that claim—and operationalize it safely.
