# Python runtime metrics Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fapm-v2%2Ffeatures%2Fruntime-metrics%2Fpython.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fapm-v2%2Ffeatures%2Fruntime-metrics%2Fpython.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.) The **Runtime** tab in the [APM entity drilldown](https://coralogix.com/docs/user-guides/apm-v2/entity-drilldown.md) shows a Python service's runtime internals - CPU, resident memory, thread count, garbage collection by generation, and CPU and memory detail - on the same screen as its traces and span metrics. A Python service can degrade in ways the traces don't explain: memory climbing without coming back down, threads piling up, the interpreter spending its time in garbage collection, or the global interpreter lock (GIL) turning a busy process into a queue. The Runtime tab surfaces those signals. Use it to: * **Tell a leak from churn**: watch **Resident memory** against **generation 2** collections. * **Catch thread buildup**: a **Thread count** that only rises means threads never finish. * **Spot GIL and scheduling contention**: rising **involuntary** context switches. * **Isolate one bad instance**: use the instances filter and the per-instance heatmap. ## What you need[​](#what-you-need "Direct link to What you need") * Coralogix [APM](https://coralogix.com/docs/user-guides/apm-v2/getting-started/apm-onboarding-tutorial.md) installed, with a Python service reporting to it. * **Python runtime instrumentation**: the OpenTelemetry [`opentelemetry-instrumentation-system-metrics`](https://pypi.org/project/opentelemetry-instrumentation-system-metrics/) package, exporting over OTLP, with `service.name` and `k8s.pod.name` on the metrics. For the full setup, see [Send Python runtime metrics](https://coralogix.com/docs/user-guides/apm-v2/features/runtime-metrics/send-python-metrics.md). The section appears only for a **service** whose detected language is Python and that is reporting Python runtime metrics. A Python service not yet reporting shows a zero state with setup steps; databases never show it. Note Python runtime metrics do not yet have an official OpenTelemetry semantic-convention specification - they come from a contrib instrumentation package. CPython also reports no garbage-collection overhead metric, so the Runtime tab has no GC-overhead panel for Python (unlike Java). ## Layout[​](#layout "Direct link to Layout") Open the **Runtime** tab for a Python service to load a **Python instances** filter at the top (it defaults to all instances, aggregated), above a set of collapsible sections: **Instance heatmap**, **Runtime summary**, **Overview**, **Garbage collection**, and **CPU and memory detail**. A panel or summary card with no data to plot is hidden rather than drawn empty. Memory values are shown in MB (binary MiB under the hood). [![The Python Runtime tab: the Runtime summary cards (CPU utilization, Resident memory, Thread count, Gen-2 collections) and the Overview charts.](/docs/assets/images/runtime-python-overview-1a74487afb4f40fd6afac7ccbe268d28.webp)](https://coralogix.com/docs/assets/images/runtime-python-overview-1a74487afb4f40fd6afac7ccbe268d28.webp) ### Instance heatmap[​](#instance-heatmap "Direct link to Instance heatmap") Shown when more than one instance reports. Each row is one instance, color-coded by severity; select a row to filter every panel below to that instance. Columns: **Throughput**, **Latency P95**, **CPU %**, **Resident MB**, **Threads**, and **Gen-2 /min**. [![The Python instances filter and the Instance heatmap: one row per instance, with the Throughput, Latency P95, CPU %, Resident MB, Threads, and Gen-2 /min columns.](/docs/assets/images/runtime-python-heatmap-ddc77a571397fb04591afbea837992b9.webp)](https://coralogix.com/docs/assets/images/runtime-python-heatmap-ddc77a571397fb04591afbea837992b9.webp) ### Runtime summary[​](#runtime-summary "Direct link to Runtime summary") Four at-a-glance cards: **CPU utilization** (share of one core), **Resident memory**, **Thread count**, and **Gen-2 collections** (per minute across the service). ### Overview[​](#overview "Direct link to Overview") | Panel | What it shows | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CPU utilization** | Share of one CPU core the process used, averaged across instances. A process near 100% is saturating a core under the GIL, so adding threads won't help. | | **Resident memory** | Memory the process holds in RAM, with generation 2 collections per minute on a second axis. RSS that keeps climbing while gen-2 collections run is objects being retained. | | **Thread count** | Live threads in the process. A count that keeps rising means threads are started and never finish. | ### Garbage collection[​](#garbage-collection "Direct link to Garbage collection") | Panel | What it shows | | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Collections by generation** | Collection runs per minute, by generation. Frequent generation 0 collections are normal churn; generation 2 climbing means objects survive to the oldest generation - how retention shows up. | | **Collected objects by generation** | Objects freed per minute, by generation. Most should die young in generation 0; a generation 2 that collects little while memory grows means objects are retained. | | **Uncollectable objects** | Objects per minute the collector found but couldn't free, usually reference cycles. This should stay at zero - any steady value is a leak that needs a code change. | [![The Garbage collection section (collections and collected objects by generation, and uncollectable objects) with the CPU and memory detail section below it.](/docs/assets/images/runtime-python-gc-17d93d31b2cb7778448dc3aede2de0a5.webp)](https://coralogix.com/docs/assets/images/runtime-python-gc-17d93d31b2cb7778448dc3aede2de0a5.webp) ### CPU and memory detail[​](#cpu-and-memory-detail "Direct link to CPU and memory detail") | Panel | What it shows | | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CPU time user vs system** | CPU seconds used per interval, split by where they were spent. System time growing faster than user time points at the kernel: heavy I/O, many small syscalls, or memory pressure. | | **Memory resident vs virtual** | Resident (RSS) is what the process holds in RAM; virtual (VMS) includes everything it has mapped. RSS climbing without coming down is a leak; VMS growing alone is usually allocator reservations. | | **Context switches voluntary vs involuntary** | Times per second the process gave up the CPU. Voluntary switches track I/O and lock waits; involuntary switches climbing is the readable sign of GIL and scheduling contention. | ## Next steps[​](#next-steps "Direct link to Next steps") To start sending these metrics to the tab, see [Send Python runtime metrics](https://coralogix.com/docs/user-guides/apm-v2/features/runtime-metrics/send-python-metrics.md).