Metricile și logurile aplicației
Endpoint-ul /metrics
Expuneți local Ticketing API:
kubectl port-forward service/ticketing-api -n cc-lab5 8080:80
Într-un al doilea terminal:
curl http://localhost:8080/livez
curl http://localhost:8080/readyz
curl http://localhost:8080/metrics | head -n 40
Aplicația expune patru metrici relevante pentru laborator:
| Metrică | Tip | Semnificație |
|---|---|---|
http_requests_total | counter | numărul cererilor finalizate, pe metodă, rută și status |
http_request_duration_seconds | histogram | distribuția duratelor, folosită pentru percentile |
http_requests_in_progress | gauge | cererile procesate în momentul curent |
tickets_created_total | counter | tichetele create cu succes |
Generați câteva date:
curl http://localhost:8080/tickets
curl -X POST http://localhost:8080/tickets \
-H 'Content-Type: application/json' \
-d '{"title":"Observabilitate","priority":"high","reporter":"student"}'
curl http://localhost:8080/tickets/999
Verificați seriile:
curl --silent http://localhost:8080/metrics \
| grep -E '^(http_requests_total|tickets_created_total)'
ServiceMonitor
Prometheus nu descoperă automat orice endpoint /metrics. Chart-ul creează un
ServiceMonitor care selectează Service-ul Ticketing API și colectează portul numit http:
kubectl get servicemonitor ticketing-api -n cc-lab5 -o yaml
Observați relația:
ServiceMonitor selector -> etichetele Service-ului -> portul http -> /metrics
Loguri structurate
Urmăriți logurile în timp ce trimiteți cereri:
kubectl logs deployment/ticketing-api -n cc-lab5 --follow --tail=20
Fiecare cerere produce un eveniment cu:
request_id- metoda și ruta normalizată
- statusul HTTP
- durata în milisecunde
- instanța care a răspuns.
Trimiteți un identificator cunoscut și căutați-l în loguri:
curl -H 'X-Request-ID: lab5-demo' http://localhost:8080/tickets
kubectl logs deployment/ticketing-api -n cc-lab5 --tail=100 \
| grep lab5-demo
Această corelare pornește de la un simptom agregat în metrici și ajunge la o cerere concretă.