I learned a bit about profilers and pyro scope as a tool which has been developed by Grafana. These days we are facing a problem of high CPU spike in our servers, so one of the engineers started using pyro scope. I just went on to study the internals of pyro scope.

Pyroscope as a tool is basically divided into two things:

1. The Collector Agent : This runs inside our server. It uses the profiler of the language itself and accesses the CPU stack as well as some related information of the CPU, like the number of cores it is using, the functional stack that it holds, and how it does it. It does it by using system calls of Linux as an operating system and getting to the kernel space, then figuring out all this information and extracting all this information. It does it on a sampled basis, for example 10 times per second, or what pyro scope generally does, sampling at a rate of 100 times per second per CPU (if it is a per-core CPU). If it is a 16-core CPU, then there are 1,600 operations per second. In a total of 10 seconds, there are 16,000 snapshots of the CPU information. You can easily know what are the functions that were there in the stack trace and how many cores were there in use at that point in time.

2. The Server : All this info is sent to pyroscope. Now how the server knows exactly which function is called. At the time of compilation, when the compilation is happening, it actually creates a memory address to the function named chart, kind of a structure wherein every memory address corresponds to a specific chart. Even though in the stack there is this memory address that is there of the function, the pyro scope profiler or the language profiler automatically gets to know that, "Okay, this memory address corresponds to this function name." In the flame graph, you actually see the function name that was there. It's just that if we have to see some kind of a memory spike and why is it happening, we'll just see the memory spike in the graph and then we'll see the time at that point where it happened. Exactly on the flame graph at that point, what were the functions that were there in the call stack, so you exactly know which function caused this kind of situation.

3. Some Time Series DB : All this data must have been getting plotted on some time series DB from where this data would have been getting accessed.

The best part is that claude can access all of this and read all of this data, so you can just put a monitor on or some kind of a shell on or some kind of a sub-agent down. Since it's able to access all of this data, it's just become simple and super easy, but at the same time you should also know what is actually happening.