Observabilitatea clusterului: Prometheus, Grafana și OpenTelemetry
„Dacă nu o poți măsura, nu o poți gestiona.” Pentru un cluster Kubernetes de producție, aceasta înseamnă a avea vizibilitate pe trei dimensiuni: metrici (cât consumă fiecare componenta), jurnal (ce se întâmplă în sistem), e urmă (cum se deplasează cererile prin microservicii). Prometheus + Grafana + stiva Loki + OpenTelemetry este răspunsul open-source la această nevoie.
În acest articol vom construi o stivă completă de observabilitate pentru Kubernetes: vom instala kube-prometheus-stiva pentru metricile de infrastructură, vom configura Loki pentru jurnalele agregate și vom integra OpenTelemetry Collector pentru a colecta urme distribuite de aplicații și a le transmite către Tempo (backend de trasare Grafana). Rezultatul este o platformă de observabilitate unificată afisat in Grafana.
Ce vei învăța
- Instalați kube-prometheus-stack: Prometheus Operator, kube-state-metrics, Node Exporter
- Creați ServiceMonitor și PodMonitor pentru eliminarea automată a aplicațiilor
- PrometheusRule pentru alertele de cluster critice (OOMKill, CrashLoopBackOff etc.)
- Loki + Promtail pentru jurnalele agregate cu etichete Kubernetes
- OpenTelemetry Collector - Conductă de telemetrie configurabilă
- Grafana Tempo pentru urmărirea distribuită
- Tablouri de bord Grafana prefabricate pentru Kubernetes
- Corelația metrică-log-urme în Grafana (exemplare)
Arhitectura stivei de observabilitate
Înainte de instalare, să înțelegem cum se leagă componentele între ele:
- Prometeu: Colectați valori cu HTTP scraping. Păstrați datele timp de 15-30 de zile
- metrica-state-kube: Expune valorile privind starea obiectelor K8s (Deployment, Pod etc.)
- Exportator de noduri: Expune valorile hardware ale nodului (CPU, disc, rețea)
- Loki: Jurnalele Pod agregate. Nu indexează conținutul, ci doar etichetele
- Promtail: DaemonSet care trimite jurnalele containerului către Loki
- OpenTelemetry Collector: Primește urme/metrice/jurnal de la aplicații și le direcționează către backend
- Ora Grafana: Backend pentru urmărirea distribuită (urme)
- Grafana: Interfață de utilizare unificată pentru a vedea valorile (Prometheus), jurnalul (Loki), urmărirea (Tempo)
Instalarea kube-prometheus-stack
# Installa kube-prometheus-stack (include Prometheus, Alertmanager, Grafana, kube-state-metrics, Node Exporter)
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
# values.yaml per produzione
cat > kube-prometheus-values.yaml << 'EOF'
# Prometheus
prometheus:
prometheusSpec:
retention: 30d
retentionSize: "50GB"
storageSpec:
volumeClaimTemplate:
spec:
storageClassName: ssd
resources:
requests:
storage: 100Gi
# Scrape tutte le ServiceMonitor/PodMonitor nel cluster
serviceMonitorSelectorNilUsesHelmValues: false
podMonitorSelectorNilUsesHelmValues: false
ruleSelectorNilUsesHelmValues: false
resources:
requests:
cpu: 500m
memory: 2Gi
limits:
cpu: 2000m
memory: 8Gi
# Alertmanager
alertmanager:
alertmanagerSpec:
storage:
volumeClaimTemplate:
spec:
storageClassName: ssd
resources:
requests:
storage: 10Gi
config:
global:
slack_api_url: "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
route:
receiver: 'slack-critical'
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
routes:
- receiver: 'slack-critical'
matchers:
- alertname =~ ".*Critical.*"
- receiver: 'slack-warning'
matchers:
- severity = warning
receivers:
- name: 'slack-critical'
slack_configs:
- channel: '#alerts-critical'
send_resolved: true
title: '[{{ .Status | toUpper }}] {{ .GroupLabels.alertname }}'
text: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'
- name: 'slack-warning'
slack_configs:
- channel: '#alerts-warning'
send_resolved: true
# Grafana
grafana:
enabled: true
ingress:
enabled: true
hosts:
- grafana.company.com
persistence:
enabled: true
size: 10Gi
# Datasource Loki pre-configurato
additionalDataSources:
- name: Loki
type: loki
url: http://loki.monitoring.svc:3100
jsonData:
derivedFields:
- datasourceUid: tempo
matcherRegex: '"traceID":"(\w+)"'
name: TraceID
url: '${__value.raw}'
- name: Tempo
type: tempo
url: http://tempo.monitoring.svc:3100
# kube-state-metrics
kube-state-metrics:
metricLabelsAllowlist:
- pods=[team,environment,app]
- deployments=[team,environment,app]
EOF
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--create-namespace \
--version 65.0.0 \
-f kube-prometheus-values.yaml
# Verifica
kubectl get pods -n monitoring
kubectl get servicemonitors -A
ServiceMonitor pentru Aplicație Scraping
Operatorul Prometheus folosește ServiceMonitor e PodMonitor pentru a configura dinamic răzuirea valorilor aplicației. Nu are rost modificați configurația Prometheus:
# servicemonitor-api-service.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: api-service-monitor
namespace: team-alpha-production
labels:
team: team-alpha # label per selezionare questo monitor
spec:
selector:
matchLabels:
app: api-service # seleziona il Service con questo label
endpoints:
- port: metrics # nome della porta nel Service
interval: 30s
path: /metrics
# Basic auth se le metriche sono protette
# basicAuth:
# username: { name: metrics-auth, key: username }
# password: { name: metrics-auth, key: password }
namespaceSelector:
matchNames:
- team-alpha-production
---
# Aggiungi la porta metrics al Service dell'applicazione
apiVersion: v1
kind: Service
metadata:
name: api-service
namespace: team-alpha-production
labels:
app: api-service
spec:
selector:
app: api-service
ports:
- name: http
port: 8080
- name: metrics # porta dedicata alle metriche
port: 9090
targetPort: 9090
Alertă critică de cluster
# prometheusrule-kubernetes-alerts.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: kubernetes-critical-alerts
namespace: monitoring
labels:
prometheus: kube-prometheus
spec:
groups:
- name: kubernetes.critical
rules:
# Pod in CrashLoopBackOff
- alert: PodCrashLoopBackOff
expr: |
rate(kube_pod_container_status_restarts_total[15m]) > 0
AND
kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} == 1
for: 5m
labels:
severity: critical
annotations:
summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} in CrashLoopBackOff"
# Pod OOMKilled
- alert: PodOOMKilled
expr: |
kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1
for: 0m
labels:
severity: warning
annotations:
summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} terminato per OOM"
description: "Aumenta i memory limits del container {{ $labels.container }}"
# Nodo sotto pressione di memoria
- alert: NodeMemoryPressure
expr: kube_node_status_condition{condition="MemoryPressure",status="true"} == 1
for: 2m
labels:
severity: critical
annotations:
summary: "Nodo {{ $labels.node }} sotto MemoryPressure"
# PVC quasi pieno
- alert: PersistentVolumeFillingUp
expr: |
kubelet_volume_stats_available_bytes /
kubelet_volume_stats_capacity_bytes < 0.15
for: 5m
labels:
severity: warning
annotations:
summary: "PVC {{ $labels.namespace }}/{{ $labels.persistentvolumeclaim }} al 85% della capacita"
# Deployment con zero repliche disponibili
- alert: DeploymentUnavailable
expr: kube_deployment_status_replicas_available == 0
for: 5m
labels:
severity: critical
annotations:
summary: "Deployment {{ $labels.namespace }}/{{ $labels.deployment }} ha 0 repliche disponibili"
Loki + Promtail pentru jurnalele agregate
# Installa Loki (modalita monolitica per cluster medio)
helm repo add grafana https://grafana.github.io/helm-charts
helm install loki grafana/loki \
--namespace monitoring \
--set loki.commonConfig.replication_factor=1 \
--set loki.storage.type=filesystem \
--set singleBinary.replicas=1 \
--set monitoring.selfMonitoring.enabled=false
# Installa Promtail (DaemonSet che invia log a Loki)
helm install promtail grafana/promtail \
--namespace monitoring \
--set config.clients[0].url=http://loki.monitoring.svc:3100/loki/api/v1/push \
--set config.snippets.extraScrapeConfigs='
- job_name: kubernetes-pods
kubernetes_sd_configs:
- role: pod
pipeline_stages:
- cri: {}
- labeldrop:
- filename
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_team]
target_label: team
- source_labels: [__meta_kubernetes_pod_label_app]
target_label: app
- source_labels: [__meta_kubernetes_namespace]
target_label: namespace'
# Query Loki in Grafana (LogQL):
# Tutti i log error del team-alpha:
# {namespace="team-alpha-production"} |= "ERROR"
# Error rate per app negli ultimi 5 minuti:
# sum(rate({namespace="team-alpha-production"} |= "ERROR" [5m])) by (app)
# Log strutturati JSON - estrai campo:
# {app="api-service"} | json | level="error" | line_format "{{.message}}"
OpenTelemetry Collector pentru Urme distribuite
# Installa OpenTelemetry Operator
kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml
---
# otel-collector.yaml - pipeline di telemetria
apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
name: otel-collector
namespace: monitoring
spec:
mode: DaemonSet # un collector per nodo
config:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
timeout: 1s
send_batch_size: 1024
# Aggiunge metadati Kubernetes ai trace (namespace, pod name, etc.)
k8sattributes:
auth_type: "serviceAccount"
passthrough: false
extract:
metadata:
- k8s.pod.name
- k8s.namespace.name
- k8s.deployment.name
- k8s.node.name
labels:
- tag_name: team
key: team
from: pod
# Campionamento: mantieni solo 10% dei trace in produzione (volume alto)
probabilistic_sampler:
sampling_percentage: 10
exporters:
otlp/tempo:
endpoint: http://tempo.monitoring.svc:4317
tls:
insecure: true
prometheus:
endpoint: "0.0.0.0:8889"
const_labels:
cluster: production
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, k8sattributes, probabilistic_sampler]
exporters: [otlp/tempo]
metrics:
receivers: [otlp]
processors: [batch, k8sattributes]
exporters: [prometheus]
Instalarea Grafana Tempo
# Installa Grafana Tempo
helm install tempo grafana/tempo-distributed \
--namespace monitoring \
--set storage.trace.backend=local
# Alternativa: Tempo monolitico per cluster piccoli/medi
helm install tempo grafana/tempo \
--namespace monitoring \
--set tempo.storage.trace.backend=filesystem \
--set tempo.storage.trace.local.path=/var/tempo
Tabloul de bord Grafana pentru Kubernetes
Grafana are un catalog de tablouri de bord prefabricate. Importați aceste ID-uri din interfața de utilizare (Tablouri de bord > Import):
| Tablouri de bord | ID Grafana | Utilitate |
|---|---|---|
| Prezentare generală a clusterului Kubernetes | 7249 | Prezentare generală CPU/Memorie/Pod în funcție de nod |
| Implementări Kubernetes | 8588 | Starea implementării, rata de repornire, replici |
| Node Exporter Full | 1860 | Valori hardware pentru nod (CPU, disc, rețea) |
| Kubernetes PVC | 13646 | Utilizarea depozitului din PVC |
| Tabloul de bord Loki | 15141 | Jurnalele agregate, rata de eroare, exploratorul de jurnal |
| Controler de intrare NGINX | 9614 | Rata de solicitare, latența, codul de stare de intrare |
Corelația Metrics-Log-Trace (Exemple)
Adevărata putere a acestei stive este corelaţie: dintr-o metrică a latență mare puteți merge direct la urmărirea corespunzătoare și de la urmă la jurnalele de Pod la acea vreme. Aceasta se numește Exemplar:
# Abilita gli exemplar in Prometheus (già abilitati in kube-prometheus-stack)
# Nell'applicazione, includi il traceID nell'histogram metric:
# Go/Python con OpenTelemetry:
# Quando crei un histogram, aggiungi l'exemplar con il trace ID corrente
# Il Prometheus scraper lo raccoglie e lo conserva
# In Grafana:
# 1. Vai alla dashboard API latency
# 2. Vedi un picco di latenza
# 3. Clicca il diamante (exemplar) sul grafico
# 4. Grafana ti apre automaticamente il trace in Tempo
# 5. Dal trace, clicca sul servizio con errore
# 6. Grafana mostra i log di quel Pod in Loki per quel timestamp
# Questo flusso metriche → trace → log e il "holy grail" dell'osservabilita
Cele mai bune practici pentru observabilitatea Kubernetes
Lista de verificare a observabilității producției
- USE Metoda pentru resurse: Pentru fiecare resursă (CPU, memorie, disc, rețea): Utilizare, Saturație, Erori. Acestea sunt cele 3 alerte fundamentale pentru fiecare nod
- Metoda RED pentru servicii: Pentru fiecare serviciu: Rată (req/s), Erori (rata erori), Durată (latență). Alertă pe toate trei
- Alerte bazate pe SLO: Nu alertați cu privire la fiecare anomalie, ci numai atunci când utilizați bugetul pentru erori SLO. Mai puțin zgomot, mai mult semnal
- Retentie diferentiata: Valori brute 15 zile, agregate lunare 1 an. Jurnal brut 7 zile, jurnal de audit 1 an
- Eșantionare pentru piese: Nu păstrați 100% din urme în producție - costă prea mult. 1-10% este suficient pentru depanare
- Etichete consistente: Fiecare metrică, jurnal și urmărire trebuie să aibă echipă, mediu, aplicație, versiune pentru filtrare
Concluzii și pașii următori
O stivă completă de observabilitate — Prometheus pentru metrici, Loki pentru jurnalele, OpenTelemetry + Trace Time — transformă Kubernetes dintr-o cutie neagră într-un sistem de înțeles. Corelația dintre cele trei semnale din Grafana reduce drastic timpul Depanare medie de la ore la minute.
Următorul și ultimul articol din această serie — Kubernetes Multi-Cloud cu Federația e Submariner - abordează provocarea de a gestiona mai multe clustere de la diferiți furnizori de cloud ca și cum au fost doar unul, extinzând toate conceptele acestei serii la multi-cluster.
Următorul articol din serie
Serii înrudite
- Observabilitate și OpenTelemetry — analiza aprofundată a instrumentarului aplicației
- GitOps cu ArgoCD — Argo Rollouts folosește Prometheus pentru analiza automată a canarelor







