Prometheus Monitorización Alertas PromQL
La monitorización con Prometheus recopila, almacena y consulta métricas de series temporales en todas las capas de su stack, desde los nodos de Kubernetes hasta los endpoints de las aplicaciones. Diseñamos y operamos stacks completos de observabilidad con Prometheus para equipos de ingeniería de EE. UU. y la UE: recopilación de métricas con exporters, alertas basadas en PromQL, enrutamiento con Alertmanager, dashboards de Grafana y almacenamiento a largo plazo con Thanos o Mimir. El resultado: un seguimiento coherente de los SLO, una detección rápida de incidentes y una pista de auditoría operativa defendible.
La monitorización con Prometheus recopila, almacena y consulta métricas de series temporales en todas las capas de su stack, desde los nodos de Kubernetes hasta los endpoints de las aplicaciones. Diseñamos y operamos stacks completos de observabilidad con Prometheus para equipos de ingeniería de EE. UU. y la UE: recopilación de métricas con exporters, alertas basadas en PromQL, enrutamiento con Alertmanager, dashboards de Grafana y almacenamiento a largo plazo con Thanos o Mimir. El resultado: un seguimiento coherente de los SLO, una detección rápida de incidentes y una pista de auditoría operativa defendible.
Retos
Las etiquetas de alta cardinalidad —ID de usuario, ID de solicitud, campos de texto libre— hacen crecer exponencialmente el número de series temporales, consumen memoria y ralentizan las consultas. Sin una estrategia de higiene de métricas, Prometheus se vuelve inestable con un crecimiento normal del tráfico.
El almacenamiento local de Prometheus no está pensado para retenciones de varios meses ni para la federación de consultas entre regiones. Los equipos que usan solo Prometheus carecen de datos históricos para planificar la capacidad, elaborar informes de SLA y analizar incidentes más allá de dos semanas.
Las alertas basadas en umbrales y sin lógica de burn rate multiventana generan muchos falsos positivos, y los ingenieros de guardia acaban ignorando o silenciando las alertas hasta que se les pasa un incidente real. Ajustarlas exige entender el modelo de presupuesto de errores.
Una única instancia de Prometheus es un punto único de fallo. Replicar sin deduplicación genera alertas duplicadas. Ejecutar Prometheus en modo de alta disponibilidad con la deduplicación correcta en la capa de consulta exige una arquitectura pensada a propósito.
PromQL es potente pero poco intuitivo; unos intervalos de rate, selectores de etiquetas o llamadas a histogram_quantile incorrectos devuelven resultados erróneos sin avisar. A medida que crecen los archivos de reglas, el rendimiento de las consultas se degrada si no hay recording rules.
Mantener a mano los targets de scrape de cientos de servicios es lento y propenso a errores. Hay que entender y ampliar correctamente el service discovery nativo de Kubernetes, los pipelines de relabelling y los valores por defecto de kube-prometheus-stack para las cargas de trabajo no estándar.
Soluciones
Auditamos las métricas existentes, definimos presupuestos de cardinalidad, imponemos convenciones de etiquetas mediante linting en el CI y reescribimos los exporters de alta cardinalidad, para evitar la presión sobre la memoria antes de que degrade el rendimiento de Prometheus.
Desplegamos el sidecar de Thanos o Mimir para una retención a largo plazo respaldada por almacenamiento de objetos, lo que permite consultas históricas de varios meses, federación entre clústeres y un archivado económico compatible con S3.
Implementamos alertas de SLO multiventana y multi-burn-rate según el modelo de Google SRE, configuramos árboles de enrutamiento de Alertmanager con niveles de severidad, inhibición y deduplicación, y conectamos el envío a PagerDuty, Opsgenie o Slack.
Ejecutamos réplicas de Prometheus emparejadas con configuraciones de scrape idénticas, añadimos Thanos o Mimir como capa de deduplicación de consultas y configuramos volúmenes persistentes y un respaldo con remote-write, con lo que se elimina la pérdida de datos al reiniciar un pod.
Creamos dashboards de Grafana a partir de recording rules —agregaciones precalculadas que mantienen baja la latencia de las consultas a gran escala— y publicamos los dashboards como código (aprovisionamiento JSON) para obtener visualizaciones reproducibles y con control de versiones.
Desplegamos y ajustamos kube-prometheus-stack, configuramos recursos PodMonitor y ServiceMonitor para todas las cargas de trabajo, ampliamos el relabelling de scrape para espacios de nombres no estándar e integramos exporters de aplicaciones a medida.
Stack
Prometheus, PromQL, Alertmanager, node_exporter, blackbox_exporter, exporters a medida, recording rules, Grafana, Thanos, Mimir, kube-prometheus-stack, service discovery de Kubernetes, Pushgateway, OpenMetrics.
Cumplimiento
Evidencias de disponibilidad para SOC 2 · monitorización continua para NIS2 · higiene de etiquetas según el RGPD · pista de auditoría de SLO
Casos
Plataforma de transporte con conductor con tres apps (conductor, pasajero y despachador), con GPS en tiempo real, verificación de documentos y doble método de pago en efectivo y con tarjeta.
Hub unificado de un ecosistema cripto que agrega varios tokens: datos de exchanges en vivo, búsqueda, gráficos y punto de entrada directo para la compra.
App multiplataforma de noticias deportivas y portal web: CMS mediante un bot de Telegram en lugar de un panel de administración a medida y un pipeline de publicación en Markdown.
Por qué YuSMP
Prometheus y su ecosistema son proyectos graduados de la CNCF y neutrales respecto a los proveedores. Los datos de sus métricas residen en su infraestructura y nunca se le factura por métrica ni por alerta. Construimos sobre estándares —OpenMetrics, PromQL, Grafana— que cualquier ingeniero puede operar.
Diseñamos las alertas en torno a los burn rates del presupuesto de errores, no a umbrales en bruto. Las alertas saltan cuando la fiabilidad que percibe el usuario está realmente en riesgo: así se reduce el volumen de avisos y los ingenieros de guardia reciben un contexto accionable en lugar de ruido.
Entregamos los stacks de Prometheus como código —valores de Helm, Jsonnet o Terraform— con runbooks, recording rules y aprovisionamiento de Grafana versionados en su repositorio. Su equipo puede ampliar, volver a desplegar y auditar toda la capa de observabilidad sin depender de nosotros.
Preguntas frecuentes
Prometheus es de código abierto y se aloja en infraestructura propia; Datadog es un SaaS gestionado. Prometheus le da pleno control sobre la retención de datos, la cardinalidad y el coste, sin facturación por host ni por métrica. Datadog reduce la carga operativa y añade APM, gestión de logs y monitorización sintética en un solo producto. Recomendamos Prometheus cuando se necesita previsibilidad de costes a gran escala, una residencia de datos estricta por el RGPD o una integración profunda y nativa con Kubernetes sin dependencia de un proveedor.
El control de la cardinalidad empieza en el diseño de las métricas: cada valor de etiqueta debe proceder de un conjunto acotado. Auditamos los exporters existentes, imponemos convenciones de etiquetas en el CI con promtool, descartamos las etiquetas de alta cardinalidad en la fase de relabelling antes de la ingesta y supervisamos el número de series temporales por job con una alerta ante crecimientos inesperados. Para las métricas de alta cardinalidad ya existentes, introducimos recording rules que agregan antes del almacenamiento.
Cuando se necesita una retención superior a entre dos y cuatro semanas, federación de consultas entre clústeres o una verdadera alta disponibilidad con deduplicación. Thanos añade un sidecar que envía los bloques TSDB al almacenamiento de objetos (S3, GCS) y una capa de consulta que deduplica las réplicas de Prometheus. Mimir es la alternativa escalable horizontalmente, con una opción de despliegue en un único binario. Ambos amplían Prometheus a meses o años de retención al coste del almacenamiento de objetos, que es un orden de magnitud más barato que el disco local.
Las alertas basadas en umbrales generan un exceso de ruido. Implementamos alertas de SLO multiventana y multi-burn-rate: una ventana de consumo rápido (de cinco a sesenta minutos) detecta caídas repentinas; una ventana de consumo lento (de seis a veinticuatro horas) detecta degradaciones graduales. Alertmanager enruta por severidad, aplica reglas de inhibición (suprimir el aviso si hay una alerta crítica activa), deduplica entre réplicas de alta disponibilidad y envía notificaciones de resolución. Cada alerta incluye un enlace al runbook.
Prometheus es el almacén de métricas y el motor de consultas; Grafana es la capa de visualización y dashboards. Grafana consulta a Prometheus (o a Thanos/Mimir) a través del data source de PromQL. Aprovisionamos los dashboards como JSON o Jsonnet versionados en el repositorio, sin necesidad de configurarlos a mano. Las recording rules precalculan las agregaciones costosas para que los tiempos de carga de los dashboards se mantengan rápidos con independencia del rango de tiempo o de la cardinalidad.
Usamos instancias de Prometheus con sharding —cada shard hace scrape de un subconjunto de targets mediante relabelling con consistent hashing— y Thanos o Mimir como capa de consulta global. kube-prometheus-stack gestiona los recursos ServiceMonitor y PodMonitor para que las nuevas cargas de trabajo se descubran automáticamente. Las recording rules sacan la agregación del momento de la consulta. Las métricas del Horizontal Pod Autoscaler se sirven desde una instancia independiente de kube-state-metrics para que la latencia de scrape no afecte al stack principal.
Prometheus usa un modelo pull: hace scrape de endpoints HTTP en un intervalo configurado. Así el inventario de targets es explícito y la depuración resulta más sencilla. Pushgateway existe para el caso limitado de los trabajos por lotes de corta duración que terminan antes de un intervalo de scrape. Evitamos Pushgateway en los servicios de larga duración: genera problemas de métricas obsoletas y elimina la propiedad de autorreparación del pull. Para cargas serverless o efímeras, usamos remote-write para enviar directamente a Mimir.
Respuesta en 1 día hábil. NDA a petición.
Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.