---
title: "Prometheus | Skills We Assign For | Azendo"
description: "Prometheus for metrics — scraping, PromQL, cardinality limits, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/prometheus/"
---

[Skills](https://azendo.co/skills/) Observability 

# Prometheus.

Prometheus is a metrics system that scrapes numeric time series from instrumented targets and stores them locally, queried through PromQL. It is the de facto standard for Kubernetes monitoring and pairs with Alertmanager for routing.

## Where Prometheus fits on a long engagement.

The pull model suits dynamic infrastructure well. Prometheus discovers targets through service discovery and scrapes them, so a pod that appears is monitored without anything being configured, and one that disappears simply stops being scraped.

Cardinality is the constraint that decides whether a Prometheus deployment stays healthy. Every distinct label combination is a separate time series, so a label carrying user IDs or request paths produces millions of series and exhausts memory. It is the single most common way teams take their own monitoring down.

## What an assigned team does with Prometheus.

Metrics accumulate. Every team adds instrumentation, nobody removes it, and a year later the system is storing a great deal of data nobody queries while the alerts that matter are buried among it.

Periodic review of what is collected and what is alerted on is ongoing work, agreed as part of a [committed monthly capacity](https://azendo.co/pricing/) for platform.

## What we use Prometheus for.

* Monitoring that follows dynamic workloads Service discovery, so new instances are observed without configuration.
* Cardinality kept under control Label discipline, so high-cardinality values never reach the metric names.
* Alerts on symptoms rather than causes Paging on what users experience, with metrics available for the diagnosis afterwards.

## How Prometheus capacity is assigned.

Metrics and alerting work is assigned under [devops as a service](https://azendo.co/services/cloud-and-devops/), with cardinality treated as a design constraint rather than discovered at capacity.

## Roles we assign Prometheus for

* [Site Reliability Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/site-reliability-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in observability

* [SLO and error budget design — skill we assign for](https://azendo.co/skills/slo-and-error-budget-design/)
* [OpenTelemetry — skill we assign for](https://azendo.co/skills/opentelemetry/)
* [CloudWatch — skill we assign for](https://azendo.co/skills/cloudwatch/)
* [PagerDuty — skill we assign for](https://azendo.co/skills/pagerduty/)
* [Observability — skill we assign for](https://azendo.co/skills/observability/)
* [Sentry — skill we assign for](https://azendo.co/skills/sentry/)
* [Logging — skill we assign for](https://azendo.co/skills/logging/)
* [audit logging — skill we assign for](https://azendo.co/skills/audit-logging/)

## Tell us what your roadmap needs Prometheus for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)