Time-series profiling with Grafana Phlare reveals performance bottlenecks you didn’t know existed.

Time-Series Observability with Grafana Phlare: Beyond Metrics and Logs

A technical deep dive into how Grafana Phlare is revolutionizing full-stack observability by adding high-resolution, time-aligned profiling to the cloud-native monitoring stack.

In a cloud-native world dominated by microservices, ephemeral workloads, and distributed architectures, traditional observability tools — logs, metrics, and traces — often fall short in surfacing the root causes of performance issues. Enter Grafana Phlare, an open-source continuous profiling tool built to extend observability into the realm of CPU and memory usage over time, tightly integrated with the Grafana ecosystem.

Grafana Phlare introduces time-series-based profiling, offering unprecedented insight into “why” your code behaves the way it does — not just “what” happened or “when.” This blog explores how Phlare fills the observability gap left by Prometheus, Loki, and Tempo, and how developers and DevOps engineers can integrate it seamlessly into their stack.

Why Traditional Observability Isn’t Enough

Most observability setups rely on the “three pillars”:

1. Metrics — collected via Prometheus
2. Logs — handled by Loki
3. Traces — powered by Tempo

While useful, they lack:

• Code-level granularity: You can see something’s wrong but not which function caused it.
• Resource attribution: Metrics tell how much, but not where in the code CPU/memory was used.
• Historical flame graphs: You can’t visualize performance regressions over time.

That’s where profiling comes in.

What Is Continuous Profiling?

Profiling is the process of analyzing a program’s resource usage while it runs. It typically involves generating flame graphs that show which functions or threads consume the most CPU or memory. Profilers have traditionally been used in development or QA environments — not in production.

Grafana Phlare changes that by enabling safe, low-overhead profiling in live environments. It collects time-series profiling data continuously and stores it in a Prometheus-like TSDB, allowing time-aligned correlation with metrics and traces.

How Grafana Phlare Works

Phlare architecture comprises:

1. Agents (like pyroscope): Deployed as sidecars or in-process libraries to collect profiling data.
2. Phlare Ingestor: Accepts profiling data via HTTP (pprof format).
3. Phlare Store: Time-series DB optimized for profiling.
4. Grafana Integration: Unified dashboard for metrics, logs, traces, and now profiles.

Phlare supports the pprof format natively, meaning it can integrate with any language or runtime that supports pprof, such as:

• Go (net/http/pprof)
• Python (via py-spy or pyroscope)
• Java (async-profiler)
• Node.js (clinic.js)

Profiling Example: A Go Service with Phlare

Step 1: Enable pprof in your Go app

import _ "net/http/pprof"go func() {     log.Println(http.ListenAndServe("localhost:6060", nil)) }()

Step 2: Run Pyroscope agent or Phlare CLI to collect data

pyroscope exec --name my-go-app ./myapp

Step 3: Send data to Grafana Phlare

pyroscope server --storage phlare --phlare-url=http://phlare:4100

Step 4: View in Grafana

You can now explore:

• Flame graphs across time
• Correlation with metrics (e.g., CPU usage vs. function call)
• Drill-down into performance hotspots

Phlare’s Architecture: Designed for Scalability

Grafana Phlare follows a microservices architecture optimized for high-throughput ingestion and efficient long-term storage. Key architectural decisions include:

• Horizontally scalable ingest and query nodes
• Object storage (e.g., S3, GCS) as the backend
• Prometheus-compatible labels for profiling data
• Sharding + caching layers for fast queries

This makes Phlare suitable not just for small dev teams but also large-scale, multi-tenant observability backends in enterprise environments.

Security and Compliance Considerations

Profiling in production raises obvious concerns:

• Data exposure: Profilers may capture sensitive information like environment variables or call paths.
• Overhead: Profiling agents should not impact app performance.
• Compliance: Need to ensure profiling metadata is handled per GDPR/CCPA norms.

Grafana Phlare addresses this with:

• Minimal overhead profiling (1–2% CPU usage)
• Configurable retention and data purging
• TLS and auth integration for secure endpoints

Use Cases for Grafana Phlare

• Root-cause analysis of CPU spikes in Kubernetes clusters
• Performance regression tracking during CI/CD pipelines
• Resource optimization by identifying inefficient code paths
• Security forensics when analyzing suspicious function calls
• Live application debugging in production with flame graphs

Integrating Phlare into DevOps Pipelines

You can embed Phlare into your observability-as-code workflow:

• Use Helm charts for Phlare deployment in K8s
• Integrate with Grafana dashboards and Prometheus alerts
• Automate flamegraph snapshots on CI/CD test failures
• Correlate profile snapshots with tracing (Tempo) and logging (Loki)

This provides a 360-degree view from request trace → metric → log → CPU profile.

Conclusion

As software systems grow increasingly complex, monitoring only what happened is no longer enough — we also need to understand why. Grafana Phlare fills a crucial gap in the observability stack by offering continuous, time-series profiling at scale, tightly integrated with metrics, logs, and traces.

With Phlare, you can proactively discover performance regressions, optimize compute usage, and debug production issues — all while leveraging your existing Grafana ecosystem.

Whether you’re managing containerized microservices, GPU-intensive AI workloads, or edge compute devices, Grafana Phlare brings visibility to the code level like never before.