Open Source Worth Watching Right Now (4) Observability and Security

• Introduction — volume is cost, and what does not get wired in does not get used
• Snapshot
• Instrumentation — separating yourself from the vendor
• Storage and querying
• The option that comes as one piece
• Runtime — the field of view eBPF created
• Supply chain and code
• Check before you adopt
• Links

Introduction — volume is cost, and what does not get wired in does not get used

Observability and security are different fields by nature, but they fail in similar ways.

On the observability side, collecting all the data costs more than you can absorb, and cutting it back means the data is missing exactly when you need it. On the security side, no matter how accurate a tool is, if it is not sitting inside the pipeline nobody looks at its output. That is why, in both areas, where it plugs in matters as much as what it does.

What follows is not a ranking but a map organized by the layer each project handles.

Snapshot

All figures as of 2026-08-12.

Instrumentation — separating yourself from the vendor

open-telemetry/opentelemetry-collector is the component that produced the most practical change in this field. Applications export in a standard format, and the collector receives that, filters it, samples it, and forwards it to whichever backend you want. Swapping out your observability tooling drops from a redeployment of the application to a configuration change.

Its star count is among the lowest on this list, which is a good example of that number having nothing to do with importance. The project is simply split across many repositories, so attention is spread thin. This is exactly why you should not rank projects by star count.

Storage and querying

VictoriaMetrics/VictoriaMetrics is a Prometheus-compatible time series store, focused on holding the same data with fewer resources. If you already run Prometheus and have hit a wall on retention period and cost, it is the natural next step.

grafana/loki keeps costs down by storing logs around labels rather than a full-text index. In exchange, it is not good at searching for an arbitrary string across everything. Get the label design wrong and the advantage disappears.

grafana/pyroscope covers continuous profiling. It lets you take resource usage problems that metrics and traces cannot narrow down and follow them all the way to the code level.

Of the three, Loki and Pyroscope are AGPL-3.0. AGPL is OSI-approved open source, but it is a strong copyleft whose disclosure obligation reaches as far as the case where you offer modified code as a network service. Running it as-is inside your own company and modifying it to serve external customers are two different scopes of review.

The option that comes as one piece

SigNoz/signoz and openobserve/openobserve bundle collection, storage, and dashboards into a single product, aimed at teams that want to stand up a self-hosted observability stack quickly.

Their license shapes are not the same. In its LICENSE file, SigNoz declares that the ee/ and cmd/enterprise/ directories follow a separate license and that everything outside them is MIT. OpenObserve is AGPL-3.0. You can read the source of both, but the terms are not identical, so check which feature falls under which terms before you adopt either.

Runtime — the field of view eBPF created

falcosecurity/falco judges kernel events against rules to catch suspicious behavior inside containers. cilium/tetragon builds on the same foundation and aims not only at observation but at policy enforcement.

The strength of this family is that it instruments without any change to the application, but it is sensitive to kernel version and deployment environment. If you cannot freely choose the node image on managed Kubernetes, check the supported range first. And if you switch it on without tuning the rules, alerts pour in and you end up in a state where nobody looks at them.

Supply chain and code

aquasecurity/trivy sweeps images, file systems, repositories, and even Kubernetes resources with a single command. It looks not only at vulnerabilities but at misconfigurations and leaked secrets as well.

# Example: check the image and the repository together before deploying
trivy image --severity HIGH,CRITICAL registry.example.com/app:1.4.2
trivy fs --scanners vuln,secret,misconfig .

gitleaks/gitleaks finds credentials in commit history. For a secret that has already been pushed, the answer is revocation rather than recovery, so placing it in a commit hook and in CI has far more effect than checking after the fact.

semgrep/semgrep handles pattern-based static analysis of code. The practical value is that you can write the rules yourself to match your team conventions. The repository license is LGPL-2.1, and the add-on features and rules that are offered commercially come under separate terms, so keep the two apart when you look at them.

sigstore/cosign signs artifacts and verifies them. With signatures, the core is not producing them but enforcing verification. If you do not verify at the deployment stage, a signature is decoration.

Check before you adopt

Check the full license text yourself, and route commercial adoption through legal review. This post is not legal advice.

The common failure in this area is covering up the problem by adding more tools. Before you bring in a new tool, decide first who will look at its output and what they will decide from it. A dashboard nobody looks at and an alert nobody fixes generate nothing but cost.

Repository details (stars, license, recent activity) were checked directly on GitHub on 2026-08-12 and are point-in-time values. The numbers and the status change.

Links

Series: Previous post — Infrastructure and Databases · Next post — Data and ML Pipelines

Related posts on this blog:

• eBPF-Based Observability and OpenTelemetry
• Cilium eBPF Datapath Architecture
• Container Security and Supply Chain Image Scanning

Tools: Hash Generator · HTTP Status Codes