Continuous profiling start-up Polar Signals recently open sourced its “Prometheus for profiles” project Parca under the Apache 2 License of GitHub. The software is introduced as a means to collect data to help teams understand incidents better, point out code paths to optimise in order to improve performance, and save money along the way.
However, Polar Signals’ overall goals go a little beyond that as little details such as the name Parca suggests. According to founder Frederic Branczyk, it was chosen as a reference to the Program for Arctic Regional Climate Assessment, since the hope is that optimisation options unveiled by Parca can help reduce unnecessary resource usage and therefore carbon emissions.
Instead of focusing on traces, observability project Parca follows an approach of continuous sampling profiling. This systematic way of capturing aspects of code execution such as CPU or memory usage is meant to keep overhead small enough so that it can be used in production, but also collect enough data to come up with statistically significant information. Profiles are obtained via agents or pulling from targets (pushing to Parca is also an option), and then written into the storage that is one of the major components of the project.
The second major Parca building block is an eBPF-based profiler called Parca Agent. It uses Kubernetes or systemd to automatically discover targets from which to capture CPU profiles (others still to come). From here on, things work a little similar to Prometheus, as profile series are labeled “identically to Prometheus time-series” using Kubernetes and systemd metadata, the written data can be filtered by using label-selectors, and there’s a UI to query and visualise profiles.
Besides the agent and server, Parca makes use of a multi-dimensional data model, a label-selector based query language, and a query engine built with profiling data in mind. To get an infrastructure-wide overview of what is happening during code execution, users can merge time-ranges of profiles into single reports. Other than that there are options to graph profiles over time and dig into spikes, or create differential graphs to find out what has caused changes in system behaviour.
The similarities to Prometheus aren’t by accident, as many will know Branczyk from his role as maintainer for Prometheus and Thanos — also, the design is meant to “maximize the utility of combining Parca with a Prometheus setup” for all-around better observability.
Polar Signals first received some interest earlier this year when the company introduced the observability space to its SaaS offering Continuous Profiler and the pprof profile sharing service. Since many organisations tend to shy away from profiling because of the modifications necessary to get started, the company presented the Perfessor sidecar utility to lower that entry barrier.
In the last couple of months Polar Signal also gained some interest amongst investors, which led to the company just closing a $4 million seed round which should provide it with the funds to hire additional developers. It will be interesting to see the company’s focus moving forward. If the goal really is a reduction of resource use for the greater good it will likely need more than a profiling tool. After all, common practice in the field leans more towards spotting idle resources and just giving them something to do rather than freeing them up for others.