Prometheus metricleri toplar, log ve trace ile islem yapmaz.

Akis genelde asagida ki gibi

Application Pod
↓
Service
↓
ServiceMonitor
↓
Prometheus Operator
↓
Prometheus
↓
Grafana

• Önce Application bir API endpointten metriclerini sunuyor.
• Sonra service ile Pod baglaniyor (standard uygulama)
  • spec:
    selector:
    app.kubernetes.io/name: ttt-smt
    app.kubernetes.io/instance: ttt-tps8008
• Service ile ServiceMonitor baglaniyor.
  • selector:
    matchLabels:
    app.kubernetes.io/name: ttt-smt
    app.kubernetes.io/instance: ttt-tps8008
    • Bu kismin anlami –> bu labellari olan service i bul demek.
  • Ayrica
  • Scraping yapilacak endpoitn de tanimlaniyor
  • endpoints:
    port: http
    path: /prometheus
• Prometheus Operatorü
  • asagidakileri sürekli takip eder
    • ServiceMonitors
    • PodMonitors
    • PrometheusRules
    • Probes
    • ScrapeConfigs
  • Bunlari API olarak
    • monitoring.coreos.com
  • cünkü prometheus kurulurken setting olarak
    • serviceMonitorSelector:
      matchLabels:
      release: prometheus
    • Bunun anlami sudur sadece asagida ki label olan serviceMonitorleri tara.
      • metadata:
        labels:
        release: prometheus

Ayni app ten birden cok deployment yapildiginda mesela Feature branch vs ayrim icin labelleri kullanmak iyidir ancak birden cok label olusturmak gereklidir.

app.kubernetes.io/name=ttt-smt
app.kubernetes.io/instance=ttt-tps8008
app.kubernetes.io/component=smt
namespace=ttt-tps8008

bu labellari alan prometheus asagida ki gibi görüyor.

namespace="ttt-tps8008"
service="ttt-tps8008-smt"
pod="ttt-tps8008-smt-xxxxx"
instance="10.42.1.12:8080"
job="ttt-tps8008-smt"

PromQl

Kendi basina ayri bir konu