Overv?king med Zabbix

Applikasjonsoverv?king

Man m? gj?re 2 ting for ? aktivere automatisk overv?king av en applikasjon:

  1. Definere noen "annotation" parametere i Openshift som definerer metadataen som trenges for ? aktivere/konfigurere overv?king i zabbix.
  2. Levere status informasjon for applikasjonen via HTTP protokollen under e.g. https://applikasjonsnavn.domene/health

"annotation" parametere i Openshift som m? defineres per applikasjon som skal overv?kes er:

I tillegg brukes det disse interne metadata parametere i openshift for en applikasjon:

['metadata']['namespace']
['metadata']['name']
['spec']['host']

Formatet som m? brukes for ? definere status informasjonen for versjon 3 er f?lgende:

{
  "metadata": {
    "updated": 1581397535091,
    "health-file-version": 3
  },

  "components": {

    "component-1": {
      "status": true,
      "severity": "warning"
    },

    "component-2": {
      "status": true,
      "severity": "warning"
    },

    "component-N": {
      "status": true,
      "severity": "warning"
    }
  }
}

Verdier som brukes i json dokumentet er:

Antall komponenter i uio.no/zabbix.monitor.url url'en er avhengig av applikasjonen som leverer status informasjon.

Status p? disse komponenter er fra applikasjonssynspunktet, e.g. hvis en applikasjon trenger en database for ? fungere, kan det hende at databasen er oppe og fungerer uten problemer, men hvis applikasjonen ikke kan koble seg til databasen (e.g. problemer med nettet eller autentisering) vil status p? database komponenten i status url'en v?re 'false' (error).

Det er applikasjonen som m? teste internt og finne ut status p? alle komponentene den bruker og vil levere status for.

Man trenger ikke ? levere statusinformasjon for noen komponenter hvis applikasjonen ikke er avhengig av eksterne komponenter, eller ikke har funksjonalitet for ? finne ut om den har problemer med en eller flere komponenter. I dette tilfellet er det bare url'en til applikasjonen som overv?kes.

Hvis man ikke kan/vil levere status informasjon for noen komponenter, trenger man kun levere json-blokken med 'metadata'-informasjon.

Overv?king av Kubernetes-relaterte objekter

Hvordan fungerer Kubernetes-overv?king med Zabbix?

F?r du begynner ? lage overv?kingsregler, er det nyttig ? forst? hvordan disse systemene jobber sammen:

PrometheusRule (din YAML-fil)
     ↓ (evaluerer PromQL expressions kontinuerlig)
Prometheus (samler metrics fra pods/containers)
     ↓ (n?r en regel triggers)
AlertManager (mottar alerts)
     ↓ (sender kun alerts med severity: critical)
Zabbix scraper-script p? zabbix-proxy-servere, som henter alle alert-definisjoner og tilstand.
     ↓ (oppretter items og triggers)
Zabbix (viser alarmer i dashboards)

Hvordan komponentene fungerer sammen:

Viktig ? vite:

Hvordan navngis items og triggers i Zabbix?

N?r du oppretter en PrometheusRule, vil Zabbix automatisk generere et item med et langt navn. ? forst? hvordan dette navnet bygges opp hjelper deg med ? finne dine alarmer i Zabbix.

Navneformatet:

lld for alert manager rules - critical: Alert manager rules - critical: [GROUP_NAME]_[ALERT_NAME]_critical

Hvordan navnet bygges opp:

Del av navnet Kommer fra Eksempel
lld for alert manager rules - critical: Alert manager rules - critical: Fast prefix fra Zabbix (alltid samme) -
[GROUP_NAME] .spec.groups[].name i din PrometheusRule amedov-test-app
[ALERT_NAME] .spec.groups[].rules[].alert i din PrometheusRule PodCpuUsageExceedingRequest
_critical .spec.groups[].rules[].labels.severity critical

Konkret eksempel:

Hvis du har denne PrometheusRule:

spec:
  groups:
  - name: amedov-test-app              # Dette blir GROUP_NAME
    rules:
    - alert: PodCpuUsageExceedingRequest  # Dette blir ALERT_NAME
      labels:
        severity: critical              # Dette blir _critical suffix

Vil itemet i Zabbix hete:

lld for alert manager rules - critical: Alert manager rules - critical: amedov-test-app_PodCpuUsageExceedingRequest_critical

Best practices for navngiving:

CPU og minne-overv?king

Hvis man ?nsker ? overv?ke metrics fra Kubernetes-objekter, som f.eks minnebruk eller CPU-bruk for en pod, og f? alarm p? dette, s? trenger du f?rst ? opprette en PrometheusRule, hvor du definerer en Prometheus expression for det du ?nsker ? generere en alert for. Denne vil s? generere en alert i AlertManager n?r expression returnerer riktig resultat.

Hva denne regelen gj?r

Dette eksemplet overv?ker om pods i ditt namespace bruker mer CPU enn de har bedt om (request). Hvis en pod bruker over 100% av requested CPU i mer enn 10 minutter, f?r du alarm i Zabbix. Dette er nyttig for ? oppdage pods som trenger mer ressurser enn de har f?tt tildelt.

Eksempel p? CPU-overv?king

Nedenfor f?lger eksempel p? hvordan du genererer en alert for CPU-bruk:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: pod-cpu-request-exceeded-alert # Navnet p? PrometheusRule-objektet
  namespace: amedov-test # Prosjektet du skal overv?ke
spec:
  groups:
  - name: amedov-test-app # F.eks om du skal overv?ke en spesifikk komponent av din app, kan du sette navnet her. F.eks nettskjema-backend
    rules:
    - alert: PodCpuUsageExceedingRequest # Dette blir det faktiske navnet p? alarmen i Zabbix, sammen med gruppenavnet overfor
      expr: |
        # Hvor mye CPU podet faktisk bruker (m?lt over siste 5 min)
        sum(rate(container_cpu_usage_seconds_total{container!="",container!="POD"}[5m])) by (pod, namespace)
        /
        # Hvor mye CPU du har requested for poden
        sum(kube_pod_container_resource_requests{resource="cpu",unit="core"}) by (pod, namespace)
        > 1  # Trigger n?r faktisk bruk er over 100% av request (1.0 = 100%)
      for: 10m # Alarmen triggers kun n?r CPU-bruken har v?rt over grensen i 10 minutter sammenhengende
      labels:
        severity: critical # Det er kun severity = critical som blir generert alarmer for i Zabbix
        okd_service: amedov-test # Dette blir generert som en tag p? itemet i Zabbix, slik at du enkelt kan filtrere p? den
      annotations: # Disse annotations blir aldri videresendt til Zabbix, men vises i AlertManager
        summary: "Pod {{ $labels.pod }} exceeding CPU request"
        description: "Pod {{ $labels.pod }} is using {{ $value | humanizePercentage }} of requested CPU"

Hvordan tilpasse denne regelen

Du kan enkelt tilpasse denne regelen til dine behov:

Endre terskelen for CPU-bruk:

> 1     # Trigger ved 100% av request
> 0.8   # Trigger ved 80% av request
> 1.5   # Trigger ved 150% av request

Endre m?leperioden (hvor lenge CPU-bruk m?les):

[5m]    # M?ler gjennomsnittlig CPU-bruk over siste 5 minutter
[10m]   # M?ler gjennomsnittlig CPU-bruk over siste 10 minutter
[1m]    # M?ler gjennomsnittlig CPU-bruk over siste 1 minutt

Endre hvor lenge problemet m? vare f?r alarm:

for: 10m    # Alarm etter 10 minutter med h?y CPU
for: 5m     # Alarm etter 5 minutter med h?y CPU
for: 1m     # Alarm etter 1 minutt med h?y CPU

Overv?ke kun spesifikke pods:

expr: |
  sum(rate(container_cpu_usage_seconds_total{container!="",container!="POD",pod=~"my-app-.*"}[5m])) by (pod, namespace)
  /
  sum(kube_pod_container_resource_requests{resource="cpu",unit="core",pod=~"my-app-.*"}) by (pod, namespace)
  > 1

Overv?ke minnebruk i stedet for CPU:

expr: |
  sum(container_memory_working_set_bytes{container!="",container!="POD"}) by (pod, namespace)
  /
  sum(kube_pod_container_resource_requests{resource="memory",unit="byte"}) by (pod, namespace)
  > 1  # Trigger n?r minnebruk er over 100% av request

Etter at den blir lagt til i et prosjekt, tar det det ca. 5 min f?r automatikken i Zabbix fanger det opp, og genererer en item.

For ? se at itemen er p? plass, logger du deg inn p? Zabbix, hvor du s?ker opp host-objektet til clusteret som innholder itemene, ie. api.<cluster-navn>, f.eks api.okd-dev.uio.no, og ser etter det nye itemet. For eksempelet over, vil itemet bli kalt lld for alert manager rules - critical: Alert manager rules - critical: amedov-test-app_PodCpuUsageExceedingRequest_critical. Alarmen vil bli trigget n?r alerten har status Firingi AlertManager, mens selve triggeren i Zabbix vil ha severity Average, s? ha det i bakhodet n?r du genererer dashboardet hvor du vil inkludere denne alarmen.

Hvis du genererer en alert som ikke ryddes vekk automatisk, s? vil den bli liggende igjen i Zabbix til du enten l?ser det som genererer alerten, eller silencer alerten i Openshift.
For alarmen over, s? vil den l?se seg automatisk, n?r podens CPU-bruk har g?tt ned.

Overv?king av CronJobs

Dette eksemplet overv?ker om CronJobs i ditt namespace kj?rer som de skal. Hvis en CronJob ikke har hatt en vellykket kj?ring p? over 2 minutter, f?r du alarm. Dette er nyttig for ? oppdage CronJobs som feiler eller har stoppet opp.

Viktig: Denne regelen er kun et eksempel. Du m? tilpasse tidsvinduet (2 minutter i eksemplet) til hvor ofte din CronJob skal kj?re. Hvis CronJobben kj?rer hver time, b?r du sette terskelen til f.eks 70 minutter for ? f? alarm hvis den ikke kj?rer.

F?lgende regel kan brukes for ? overv?ke en K8S CronJob:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: cronjob-test
  namespace: amedov-test
spec:
  groups:
  - name: app-cronjob  # Gruppenavn som identifiserer hvilken CronJob/komponent dette gjelder
    rules:
    - alert: cronJobNotRunning
      annotations:
        description: 'cronjob is not running'
        summary: cronjob is not running
      expr: (time() - kube_cronjob_status_last_successful_time{namespace="amedov-test"})/60 > 2
      # Forklaring av expression:
      # time() = n?v?rende tid (i sekunder siden epoch)
      # kube_cronjob_status_last_successful_time = tidspunkt for siste vellykkede kj?ring
      # Differansen deles p? 60 for ? f? minutter
      # > 2 betyr at alarmen triggers hvis det har g?tt mer enn 2 minutter siden siste vellykkede kj?ring
      for: 1m  # Alarmen triggers hvis tilstanden har vart i 1 minutt
      labels:
        severity: critical  # Kun critical alerts sendes til Zabbix
        okd_service: "amedov-test"  # Tag for filtrering i Zabbix

Denne alerten vil dukke opp i Zabbix som lld for alert manager rules - critical: Alert manager rules - critical: app-cronjob_cronJobNotRunning_critical.

Tilpass tidsvinduet til hvor ofte CronJobben kj?rer:

# CronJob som kj?rer hvert 5. minutt - alarm hvis ikke kj?rt p? 7 minutter:
expr: (time() - kube_cronjob_status_last_successful_time{namespace="amedov-test"})/60 > 7

# CronJob som kj?rer hver time - alarm hvis ikke kj?rt p? 70 minutter:
expr: (time() - kube_cronjob_status_last_successful_time{namespace="amedov-test"})/60 > 70

# CronJob som kj?rer daglig - alarm hvis ikke kj?rt p? 25 timer:
expr: (time() - kube_cronjob_status_last_successful_time{namespace="amedov-test"})/3600 > 25

Overv?ke en spesifikk CronJob (hvis du har flere):

expr: (time() - kube_cronjob_status_last_successful_time{namespace="amedov-test",cronjob="my-cronjob-name"})/60 > 70

F? alert hvis CronJob feiler (i stedet for bare ikke kj?rer):

- alert: cronJobFailed
  expr: kube_cronjob_status_failed{namespace="amedov-test"} > 0
  for: 5m
  labels:
    severity: critical
    okd_service: "amedov-test"
  annotations:
    summary: "CronJob {{ $labels.cronjob }} has failed"
    description: "CronJob {{ $labels.cronjob }} has {{ $value }} failed jobs"

Feils?king og verifisering

N?r du har opprettet en PrometheusRule, er det viktig ? verifisere at den fungerer som forventet. Her er en steg-for-steg guide for ? sjekke at alt er satt opp riktig.

Verifisere at PrometheusRule er opprettet

F?rste steg er ? sjekke at PrometheusRule er opprettet i Kubernetes:

# Se alle PrometheusRules i ditt namespace
oc get prometheusrule -n <namespace>

# Se detaljer om en spesifikk regel
oc describe prometheusrule <rule-name> -n <namespace>

Hvis PrometheusRule ikke finnes, sjekk at YAML-filen er korrekt og kj?r oc apply -f <fil.yaml>.

Sjekke at itemet dukker opp i Zabbix

Etter at PrometheusRule er opprettet:

  1. Vent 5 minutter - Zabbix-automatikken sjekker for nye alerts hvert 5. minutt
  2. Logg inn p? Zabbix: https://monitor.uio.no
  3. S?k etter host: api.<cluster-navn> (f.eks api.okd-dev.uio.no)
  4. G? til "Items" for hosten
  5. S?k etter ditt item: Bruk gruppenavn eller alert-navn for ? finne det

Itemet vil hete: lld for alert manager rules - critical: Alert manager rules - critical: <group-name>_<alert-name>_critical

Sjekke alerts i AlertManager

For ? se om din PrometheusRule faktisk triggers og sender alerts til AlertManager:

  1. ?pne Alerts-fanen under Obvserve i Openshift web ui: https://console-openshift-console.apps.<cluster>.uio.no/dev-monitoring/ns/amedov-test/alerts/
    • Eksempel: https://console-openshift-console.apps.okd-dev.uio.no/dev-monitoring/ns/amedov-test/alerts
  2. Sjekk alert status:
    • Inactive: Regelen er ok, ingen problemer detektert
    • Pending: Regelen har trigget, men venter p? for: perioden
    • Firing: Alerten er aktiv og sendt til Zabbix

Teste PromQL expressions

Hvis du er usikker p? om PromQL-uttrykket ditt fungerer:

?pne nettleseren p? https://console-openshift-console.apps.okd-dev.uio.no/dev-monitoring/ns/amedov-test/metrics og g? til "Metrics"-fanen. Her kan du:

Vanlige problemer og l?sninger

Problem: Itemet dukker ikke opp i Zabbix

Mulige ?rsaker:

Problem: Alarmen trigger ikke selv om problemet eksisterer

Mulige ?rsaker:

Problem: Alarmen forsvinner ikke n?r problemet er l?st

Mulige ?rsaker:

L?sning: G? til Alerts-fanen og silence alerten manuelt hvis den ikke auto-resolves. For CronJobs, s?rg for at jobben kj?rer p? nytt.

Problem: Kan ikke finne itemet i Zabbix

Mulige ?rsaker: