Observability

openobserve18.8k★

OpenObserve handles logs, metrics, traces, and frontend monitoring in one tool. It pitches itself as a Datadog and Splunk alternative, but the real story is the storage architecture. Parquet columnar files in S3 instead of an Elasticsearch cluster, which the team claims cuts storage cost by 140x. Built in Rust, ships as a single binary, OpenTelemetry-native, AGPL. Single-binary mode runs in under two minutes and handles a real workload before you need to scale. High-availability mode adds clustering and federated multi-region search, but that side trends toward enterprise features. Querying is SQL for logs and traces, PromQL or SQL for metrics. No proprietary query language to learn. Solo and small teams: self-host the single binary on a $20 VPS and forget about Datadog bills. Mid-sized teams: HA mode plus S3 storage scales to terabytes per day for a fraction of what hosted observability costs. Large teams: cluster federation and SSO are paid enterprise add-ons. Worth pricing against Datadog's renewal quote. The catch: AGPL means commercial use of the code with modifications has to follow AGPL terms. If you embed OpenObserve in a hosted product, talk to a lawyer first.

Fluentd13.5k★

It takes logs in from applications, servers, containers, and cloud services, transforms them if needed, and routes them to whatever storage or analysis tool you use. Fully free under Apache 2.0. CNCF graduated project. 700+ community plugins cover every source and destination you can think of. The architecture is simple: input plugins (where logs come from), filter plugins (transform/parse), output plugins (where logs go). Treasure Data (the company behind Fluentd) offers enterprise support and their own managed log analytics platform, but Fluentd itself is completely free. The catch: Fluentd is written in Ruby, and for high-throughput scenarios, it can be resource-heavy. That's why Fluent Bit exists, a lightweight, C-based alternative from the same project. For Kubernetes, most people run Fluent Bit as a DaemonSet (one per node) that forwards to a central Fluentd instance. The plugin ecosystem is powerful but plugin quality varies; some community plugins are abandoned. And debugging Fluentd configuration issues when logs aren't flowing is tedious.

opentelemetry-collector-contrib4.6k★

The OpenTelemetry Collector is the vendor-neutral pipeline for your telemetry data: metrics, logs, traces all flowing through one binary. This contrib repo adds the receivers, exporters, and processors that make it actually useful in production. Prometheus, Jaeger, Kafka, AWS CloudWatch, Datadog, and dozens more. Setup ranges from "download a binary and point it at your backend" to "build a custom distro with exactly the components you need." The Collector Builder tool lets you compile a purpose-built binary with only what you use. No bloat, no unused code listening on ports. Solo devs running a few services: plug this in front of Grafana Cloud's free tier and you have production-grade observability for zero dollars. Teams already paying for Datadog or New Relic: this is how you collect once and ship anywhere, or migrate vendors without re-instrumenting everything. The catch: configuration is YAML and the docs assume you already know what a receiver and exporter are. The learning curve is real if you are new to observability pipelines.

opentelemetry-ebpf-profiler3.1k★

This profiler attaches to your Linux system via eBPF and captures stack traces across every running process without touching your application code. No agents to install, no libraries to load, no recompilation. It supports C/C++, Go, Rust, Python, Java, Node.js, PHP, Ruby, Perl, and the dotnet runtime. All of it runs at roughly 1% CPU overhead. The "no instrumentation" part is what matters. Traditional profilers (pprof, py-spy, async-profiler) require you to pick a language and instrument that specific runtime. This profiler sees everything: kernel space, system libraries, and application code in one unified stack trace. For debugging performance issues that cross language boundaries or involve system calls, nothing else gives you this view. You need Linux kernel 5.4 or newer (4.19 with a specific patch), and it runs on amd64 and arm64. It feeds into the OpenTelemetry ecosystem, so your profiling data lands in whatever backend you already use for traces and metrics (Grafana, Jaeger, and the like). Solo developers probably do not need continuous profiling. Teams running multi-service production systems will find this indispensable. The catch: Linux only. No macOS, no Windows. And eBPF profiling requires elevated permissions, which means your security team will have opinions about deploying it in production.

opentelemetry-java-instrumentation2.5k★

This is how you get it. One JAR file, one JVM flag, and it auto-instruments your Spring Boot, Kafka, gRPC, JDBC, and dozens of other libraries. Zero code changes. CNCF project, Apache 2.0, completely free. The agent itself is trivial to deploy. Add it to your JVM startup, point it at an OTLP endpoint, done. The real ops burden is the backend: you need somewhere to send the data. OpenTelemetry Collector plus Jaeger or Grafana Tempo is the common self-hosted stack. That's a meaningful setup, but it's a one-time cost shared across all your services. Solo devs and small teams can point it at a managed backend (Grafana Cloud free tier, Honeycomb, Datadog) and skip the infrastructure entirely. Larger teams running their own Grafana/Tempo stack get full control and zero per-host licensing. The agent is vendor-neutral by design, so you're never locked to one backend. The catch: it's Java-only. If you're running a polyglot stack, you need separate OpenTelemetry agents for Python, Node, Go, etc. And "zero code changes" means "zero code changes until you need custom spans," at which point you're adding SDK calls anyway.