GH GambleHub

Coleta de métricas: Prometheus, Grafana

Coleta de métricas: Prometheus, Grafana

1) Alvo e moldura

A tarefa do circuito de métricas é montar e armazenar filas de tempo com segurança, dar um PromQL rápido para RCA, alertas SLO e dashboards compreensíveis. Par básico: Prometheus (scrape → store → query) e Grafana (visualização, alertas, anotações de lançamento). Para armazenamento longo e consulta global - Thanos/Cortex/Mimir.

2) Modelo de dados e semântica

Série = nome da métrica + conjunto de label 'ov (chave = valor).
Tipos: counter, gauge, historograma, summary (com mais frequência historograma).

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

Anti-cardealidade: Minimize os diferentes valores de label 'ov (sem user _ id, request _ id em label).

3) Exposição e discovery de serviços

Exportadores: node _ expórter, kube-state-metrics, cAdvisor, BD/Filas (postgres _ expositores, redis _ expositores, kafka _ expositor).
Serviços próprios: bibliotecas de clientes (Go/Java/Node/Python) → '/metrics'.
Service Discovery: Kubernetes, EC2/ASG, Consul, static files.

Básico 'prometheus. yml '(fatia):
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
Anotações pod' ov:
yaml prometheus. io/scrape: "true"
prometheus. io/path: /metrics prometheus. io/port: "8080"

4) Histogramas e latency

Use baquetes expostos sob seu SLO:
  • Web/API: '[10ms, 25,50,100,200,400,800,1600]'
  • Pagamentos/pagamentos: adicione a cauda até 5-10s.
PromQL p95:
promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)
Com o Excempars (se incluído):
promql histogram_quantile(0. 95,
sum by (le, route) (rate(traces_spanmetrics_duration_bucket{route="/withdraw"}[5m]))
)

5) Regras de grafia (recording rulas)

Reduz os pedidos pesados, normaliza o 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 e alertas (multi-window burn)

SLO 99. 9% dos pedidos de sucesso/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) Higiene e economia

Os nomes label 'ov são estáveis e normalizados:' service ',' eng ',' region ',' road ',' code ',' version '.
Limite a cardenalidade: as métricas com 'rota' devem usar o modelo 'http. road '(e não o URL completo).
O sampling da lógica está nas caravanas; nas métricas, nada de user _ id.
Propriedades de lançamento ('service. version ') são úteis para comparar a versão antiga/nova.

8) Escala e HA

Prometheus - vertical e charding por scrape-target:
  • Dois Prometheus (A/B) traçam os mesmos alvos (HA → alertas duplicados).
  • Thanos: Sidecar para cada Prometheus, Store + Query para consultas globais e armazenamento a longo prazo (S3/GCS).
  • Alternativa: Cortex/Mimir (remote-write, multiplicidade, escala horizontal).
Remote write (exemplo):
yaml remote_write:
- url: https://mimir. example. com/api/v1/push basic_auth: { username: tenantA, password: $MIMIR_TOKEN }
Retenhn TSDB local:
yaml
--storage. tsdb. retention. time=15d
--storage. tsdb. max-block-duration=2h

9) Grafana: dashboards, alertas, anotações

Dashboards padrão:

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

2. API by Road (RPS/5xx/p95, comparação 'version').

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

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

5. Per-Release (antes/depois, anotações de lançamento de CI).

Grafana Alerting: desencadeadores de PromQL, rotação on-call, mute-times «janelas de lançamento».

Anotações: CI adiciona um evento de lançamento com 'commit', 'imagem. tag ', referência ao Pipeline.

10) Kubernetes: o que é obrigatório medir

Control-plane: `apiserver_request_total`, etcd leader/fsync, scheduler latency.
Workloads: Restartes, 'container _ cpu _ cfs _ throttled _ segunds _ total', OU, Pending/Evicted, PDB violações.
Rede: drops, connack, 'kube-proxy' erros.
Quotas/limites: Requests vs Limits, HPA/VPA, saturação de nós.

11) BD/cachês/filas: sinais-chave

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.

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

Postgres replication lag max(pg_replication_lag_seconds) > 2

12) Segurança e multi-tenência

RBAC para Prometheus/Grafana, datasource-permissivos.
A cadeia TLS/mTLS no ingress/entre os componentes.
Isolamento de locatários: individuais Prometheus ou tenant-label em Cortex/Mimir; limites para série e consulta.
Segredos em alertas/notações são proibidos (use o ID do tíquete em vez do PII).

13) Integração com lançamentos e revezamentos automáticos

Regras SLO → AnalysisTemplate (Argo Rollouts) ou CI-gate.
Quando o burn-alert é acionado - pause/rollback canary; no login/anotação - referência de lançamento.
Comparação entre a versão estável e canarela através do label 'version'.

14) Erros típicos (anti-pattern)

Cardinalidade descontrolada label 'ov (user _ id, url. full, chaves dinâmicas).
Misturar prod e estágio em um único cluster sem 'eng' label.
Só Gaúge sem RED/USE; sem histogramas p95/p99.
Alertas de ferro sem ligação com o SLO → barulho.
Falta de recording rures → pedidos «pesados» em incidentes de prod.
Sem anotações de lançamento → é difícil comparar alterações e degradações.

15) Folha de cheque de implementação (0-45 dias)

0-10 dias

Node/kube-state/cAdvisor exportadores; '/metrics' em serviços.
Red/USE base dashboards; baquetas de histograma padrão.
Incluir anotações de lançamento da CI.

11 a 25 dias

Recording rulas para SLI; multi-window burn alert.
HA Prometheus (duplo scrape), cópia de segurança de configs GitOps.
Alertmanager: itinerário/modo silencioso/rotativo on-call.

26-45 dias

Remote-write em Thanos/Cortex/Mimir, armazenamento prolongado.
Otimização da radicalidade, limites de série, pedidos.
SLO-gating lançamentos e auto-rollback integração.

16) Métricas de maturidade

Cobertura RED/USE para serviços essenciais ≥ 95%.
Tempo médio de execução de «pesados» <2 c (p95) através de recording rulas.
Relação de alertas úteis/ruidosas> 3:1.
A cardealidade está sob controle: <10M de série ativa por cluster, sem picos.
100% dos lançamentos têm anotação em Grafana e mapeamento de métricas antes/depois.

17) Snippets úteis

Comparação de stable vs canary em versão

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

Erros 5xx nas rotas

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

CPU saturação contêiner

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

Comunicação entre métricas e trailers (Exemplars incluídos)

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

18) Conclusão

Prometheus + Grafana é um padrão de facto para métricas. Semântica e disciplina vencem: RED/USE, label's com cuidado, histogramas com SLO, recording rulas e alertas SLO. Adicione HA e armazenamento de longo prazo, anotações de lançamento e integração com reversíveis automáticos - e você terá um circuito rápido, escalável e econômico de métricas que ajuda a tomar decisões de venda.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Telegram
@Gamble_GC
Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.