GH GambleHub

Recogida de métricas: Prometheus, Grafana

Recogida de métricas: Prometheus, Grafana

1) Objetivo y marco

La tarea del contorno de métricas es montar y almacenar series de tiempo de forma segura, dar PromQL rápido para RCA, alertas de SLO y dashboards comprensibles. Pareja básica: Prometheus (scrape → store → query) y Grafana (visualización, alertas, anotaciones de lanzamientos). Para almacenamiento largo y consulta global - Thanos/Cortex/Mimir.

2) Modelo de datos y semántica

Serie = nombre de la métrica + conjunto de etiquetas's (clave = valor).
Tipos: counter, gauge, histograma, resumen (en venta - más comúnmente histograma).

Semántica:
  • RED (API): 'rate', 'errors', 'duration' (histogramas).
  • USE (ресурсы): Utilization, Saturation, Errors (CPU/RAM/Disk/Net).
  • Denominación: 'namespace _ subsystem _ metric _ unit' (por ejemplo, 'http _ server _ requests _ total', 'db _ connections _ current').

Anti-cardinalidad: minimice los diferentes valores de label's (sin user_id request_id en label).

3) Exposición y servicio discovery

Exportadores: node_exporter, kube-state-metrics, cAdvisor, DB/Colas (postgres_exporter, redis_exporter, kafka_exporter).
Servicios propios: bibliotecas cliente (Go/Java/Node/Python) → '/metrics '.
Service Discovery: Kubernetes, EC2/ASG, Consul, static files.

Básico 'prometheus. yml '(fragmento):
yaml global:
scrape_interval: 15s evaluation_interval: 15s scrape_configs:
- job_name: 'kubernetes-nodes'
kubernetes_sd_configs: [{ role: node }]
relabel_configs:
- action: labelmap regex: __meta_kubernetes_node_label_(.+)
- job_name: 'apps'
kubernetes_sd_configs: [{ role: pod }]
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep regex: "true"
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
target_label: __metrics_path__
regex: (.+)
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
target_label: __address__
regex: (.+)
replacement: $1
Anotaciones de pod's:
yaml prometheus. io/scrape: "true"
prometheus. io/path: /metrics prometheus. io/port: "8080"

4) Histogramas y latencia

Utilice baquetas explícitas bajo su SLO:
  • Web/API: '[10 ms, 25,50,100,200,400,800,1600]'
  • Pagos/pagos: agregue la cola a 5-10s.
PromQL p95:
promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)
Con Exemplars (si está habilitado):
promql histogram_quantile(0. 95,
sum by (le, route) (rate(traces_spanmetrics_duration_bucket{route="/withdraw"}[5m]))
)

5) Reglas de grabación (reglas de grabación)

Reducen las solicitudes pesadas, estandarizan SLI.

yaml groups:
- name: api_sli interval: 30s rules:
- record: job:http:success_ratio:rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
- record: job:http:duration_p95:5m expr: histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) SLO y alertas (multi-window burn)

SLO 99. 9% de solicitudes exitosas/30d.

yaml groups:
- name: slo_burn rules:
- alert: ErrorBudgetBurnHighShort expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 14 for: 5m labels: { severity: critical }
annotations: { summary: "Fast burn >14x for 5m" }

- alert: ErrorBudgetBurnHighLong expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 6 for: 1h labels: { severity: critical }
annotations: { summary: "Long burn >6x for 1h" }
Alertmanager (simplificado):
yaml route:
receiver: pager group_by: ["service"]
receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true

7) Label-higiene y ahorro

Los nombres de etiquetas son estables y estandarizados: 'service', 'env', 'region', 'route', 'code', 'version'.
Limite la cardinalidad: las métricas con 'route' deben utilizar la plantilla 'http. route '(no la URL completa).
Sampling de la lógica - en tres; No hay user_id en las métricas.
Propiedades de versión ('service. version ') son útiles para comparar la versión antigua/nueva.

8) Escala y HA

Prometheus - vertical y charding por scrape-target:
  • Dos Prometheus (A/B) matarán los mismos objetivos (HA → alertas duplicadas).
  • Thanos: Sidecar a cada Prometheus, Store + Query para consultas globales y almacenamiento a largo plazo (S3/GCS).
  • Alternativa: Cortex/Mimir (escritura remota, multiotenancia, escala horizontal).
Escritura remota (ejemplo):
yaml remote_write:
- url: https://mimir. example. com/api/v1/push basic_auth: { username: tenantA, password: $MIMIR_TOKEN }
Retención de TSDB local:
yaml
--storage. tsdb. retention. time=15d
--storage. tsdb. max-block-duration=2h

9) Grafana: dashboards, alertas, anotaciones

Dashboards estándar:

1. Platform Overview (SLO/RED, error-budget).

2. API de Route (RPS/5xx/p95, comparación 'versión').

3. K8s Cluster/Nodes (control-plane, saturation).

4. DB/Cache/Queues (lag/locks/hit ratio/backlog).

5. Per-Release (antes/después, anotaciones de lanzamientos de CI).

Grafana Alerting: disparadores por PromQL, rotación on-call, mute-times «ventana de lanzamientos».

Annotations: CI agrega un evento de lanzamiento con 'commit', 'image. tag ', un enlace a pipeline.

10) Kubernetes: que es obligatorio medir

Control-plane: `apiserver_request_total`, etcd leader/fsync, scheduler latency.
Workloads: restarts, 'container _ cpu _ cfs _ throttled _ seconds _ total', OOM, Pending/Evicted, infracciones PDB.
Red: drops, conntrack, 'kube-proxy' errores.
Cuotas/límites: Solicitudes vs Límites, HPA/VPA, saturation nodos.

11) DB/caché/cola: señales clave

PostgreSQL/MySQL: `connections`, `locks`, `deadlocks_total`, `xact_commit/rollback`, replication lag.
Redis: hit ratio, `evictions`, latency `instantaneous_ops_per_sec`.
Kafka/RabbitMQ: consumer lag, unacked, ISR, disk usage.

Ejemplos de PromQL:
promql
Queue backlog sum by (topic) (kafka_consumergroup_lag)> 1000

Postgres replication lag max(pg_replication_lag_seconds) > 2

12) Seguridad y multi-tenencia

RBAC a Prometheus/Grafana, datasource-permishens.
Cadena TLS/mTLS entre componentes.
Aislamiento de inquilinos: Prometheus o tenant-label individuales en Cortex/Mimir; límites de serie y solicitud.
Secretos en alertas/notificaciones - prohibidas (use ticket ID en lugar de PII).

13) Integración con lanzamientos y giros automáticos

Reglas de SLO → AnalysisTemplate (Argo Rollouts) o CI-gate.
Cuando se activan burn-alerts - pause/rollback canary; en el logotipo/anotación: enlace a la versión.
Comparación de la versión estable y canaria a través de la etiqueta 'versión'.

14) Errores típicos (anti-patrones)

Cardinalidad incontrolada de la etiqueta's (user_id, url. full, claves dinámicas).
Mezclar prod y stage en el mismo clúster sin etiqueta 'env'.
Sólo gauge sin RED/USE; sin histogramas p95/p99.
Alertas por «hierro» sin referencia a SLO → ruido.
La ausencia de reglas de grabación → solicitudes «pesadas» en incidentes prod.
No hay anotaciones de lanzamientos → es difícil igualar los cambios y la degradación.

15) Lista de verificación de implementación (0-45 días)

0-10 días

Node/kube-state/cAdvisor exportadores; '/metrics 'en servicios.
Bases de datos RED/USE; baquetas estándar de histogramas.
Habilitar anotaciones de versiones de CI.

11-25 días

Reglas de grabación para SLI; alertas multi-window burn.
HA Prometheus (doble scrape), copia de seguridad de las configuraciones de GitOps.
Alertmanager: rutas/modo silencioso/rotación on-call.

26-45 días

Escritura remota en Thanos/Cortex/Mimir, almacenamiento a largo plazo.
Optimización de la cardinalidad, límites en series, consultas.
SLO-gaming lanzamientos y auto-rollback integración.

16) Métricas de madurez

Cobertura RED/USE para servicios clave ≥ 95%.
Tiempo de ejecución medio de PromQL «pesado» <2 c (p95) debido a las reglas de grabación.
Relación de alertas útiles/ruidosas> 3:1.
Cardinalidad bajo control: <10M series activas por racimo, sin ráfagas.
El 100% de las versiones tienen una anotación en Grafana y una correlación de métricas antes/después.

17) Snippets útiles

Comparación de stable vs canary por versión

promql histogram_quantile(0. 95,
sum by (le, version) (rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m]))
)

Errores de 5xx en las rutas

promql topk(5,
sum by (route) (rate(http_requests_total{status=~"5.."}[5m]))
)

CPU saturation contenedor

promql rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1

Asociación de métricas con tries (Exemplars habilitados)

promql sum (rate (http_request_duration_seconds_bucket[5m])) by (le) # clickable to the track

18) Conclusión

Prometheus + Grafana es el estándar de facto para métricas. La semántica y la disciplina ganan: RED/USE, label's ordenados, histogramas bajo SLO, reglas de grabación y alertas SLO. Agregue HA y almacenamiento a largo plazo, anotaciones de lanzamiento e integración con retroceso automático, y obtendrá un contorno de métricas rápido, escalable y económico que le ayudará a tomar decisiones en la venta.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.