Chyby 4xx/5xx z Traefiku v Zabbixe bez Promethea

Chyby 4xx/5xx z Traefiku v Zabbixe bez Promethea

Obsah

Traefik stojí pred množstvom aplikácií: ako reverse proxy pre Docker, ako ingress controller v Kubernetes alebo ako edge router na jednom VM. Vďaka tomu je to najlepšie miesto, kde vidieť, či sú vaše aplikácie zdravé z pohľadu používateľa — každá neúspešná požiadavka ním prechádza.

Traefik poskytuje podrobné metriky vo formáte Prometheus. Zvyčajná rada znie „pridajte Prometheus a Grafanu“. Ak je však váš monitoring Zabbix, prevádzkovať druhý monitorovací stack len na čítanie jedného endpointu je zbytočné. Zabbix vie Prometheus metriky spracovať sám.

Template: custom-zabbix-templates/traefik-metrics — Zabbix 6.4 a novší, bez externých skriptov.

Čo získate

Pre každú službu v Traefiku (whoami@docker, api@internal, myapp-web@kubernetescrd, …) template automaticky vytvorí:

Položka Význam
Service Requests Počet požiadaviek od poslednej kontroly
Service Requests – 4xx Errors Chyby klienta (súčet všetkých kódov 4xx)
Service Requests – 5xx Errors Chyby servera (súčet všetkých kódov 5xx)
Service Response bytes Prenos odoslaný klientom

K tomu dva prototypy triggerov pre každú službu: viac ako N chýb 4xx a viac ako N chýb 5xx za 5 minút.

Nové služby sa nájdu automaticky — nasadíte kontajner s Traefik labelmi a objaví sa v Zabbixe bez akejkoľvek konfigurácie. Služby, ktoré zmiznú, sa automaticky odstránia.

Ako to funguje

  1. Položka Zabbix agenta web.page.get[{$TRAEFIK.API}] stiahne stránku s metrikami.
  2. Predspracovanie prevedie text vo formáte Prometheus (traefik_service_requests_total{service=…, code=…}) na JSON a krátky JavaScript krok zoskupí stavové kódy na 2xx/4xx/5xx pre každú službu.
  3. Low-level discovery vytvorí položky pre každú službu; predspracovanie simple change premení stále rastúce počítadlá na „počet požiadaviek od poslednej kontroly“.

Všetko sa deje vnútri Zabbixu — žiadny exporter, žiadny cron, žiadny Python.

Nastavenie

1. Zapnite v Traefiku Prometheus metriky, ideálne na samostatnom entry pointe, ktorý nie je publikovaný do internetu:

# traefik.yml (static configuration)
entryPoints:
  metrics:
    address: "127.0.0.1:8082"

metrics:
  prometheus:
    entryPoint: metrics
    addServicesLabels: true

To isté cez CLI prepínače: --entryPoints.metrics.address=127.0.0.1:8082 --metrics.prometheus=true --metrics.prometheus.entryPoint=metrics --metrics.prometheus.addServicesLabels=true.

Overenie: curl -s http://127.0.0.1:8082/metrics | grep traefik_service_requests_total.

2. Importujte template v Zabbixe (Data collection → Templates → Import) a pripojte ho k hostu, na ktorom beží Traefik. Host potrebuje Zabbix agenta, pretože metriky sťahuje agent — vďaka tomu môže port s metrikami zostať naviazaný na localhost.

3. Nastavte makrá:

Makro Príklad Význam
{$TRAEFIK.API} http://127.0.0.1:8082/metrics URL metrík z pohľadu Zabbix agenta
{$TRAEFIK.4XX_ERRORS} 50 Upozorniť, keď služba vráti viac chýb 4xx za 5 minút
{$TRAEFIK.5XX_ERRORS} 5 Upozorniť, keď služba vráti viac chýb 5xx za 5 minút

Note

Oba prahy sú predvolene 0, čo triggery vypína — template len zbiera údaje, kým sa nerozhodnete, čo pre vás znamená „priveľa chýb“. Prahy platia pre všetky služby na hoste.

Ako zvoliť prahy

  • Chyby 5xx sú váš problém — backend nebeží, nestíha alebo padá. Na väčšine služieb stojí za pozornosť aj pár chýb za 5 minút.
  • Chyby 4xx sú väčšinou problém klienta (404 od skenerov, 401 pri vypršaných reláciách), preto nastavte vyšší prah a používajte ho na odhalenie nezvyčajných nárastov: vlna 401/403 môže znamenať pokazené prihlasovanie alebo pokus o credential stuffing.
  • Pred nastavením prahov si pozrite údaje za týždeň. Položky „Service Requests“ ukážu bežnú úroveň prevádzky každej služby.

Zhrnutie

  • Traefik už poskytuje všetko potrebné; Zabbix to vie čítať priamo.
  • Každá služba sa nájde automaticky, s požiadavkami, chybami 4xx, 5xx a prenosom.
  • Entry point s metrikami nechajte na localhoste a nech ho sťahuje Zabbix agent.
  • Nastavte prahy pre 4xx/5xx — dovtedy sú triggery vypnuté.

Prevádzkujete Traefik v Dockeri alebo Kubernetes a chcete okolo neho poriadny monitoring? Ozvite sa.

comments powered by Disqus

Súvisiace články

Monitoring stavu diskov na VMware ESXi pomocou smartctl

Monitoring stavu diskov na VMware ESXi pomocou smartctl

Samostatné ESXi hosty a malé vSphere klastre často bežia na lokálnych SATA alebo SAS diskoch — v homelabe, na pobočke alebo na zálohovacom serveri. Keď niektorý z týchto diskov začne zlyhávať, chcete sa to dozvedieť z monitoringu, nie z datastoru, ktorý sa zrazu prepne do režimu iba na čítanie.

Čítať ďalej
Priebežné testovanie pravidiel firewallu v Zabbixe: čo má — a čo nemá — byť dostupné

Priebežné testovanie pravidiel firewallu v Zabbixe: čo má — a čo nemá — byť dostupné

Segmentácia siete vyzerá na diagrame skvele: DMZ sa nedostane do VLAN s databázami, kancelárske stanice sa nedostanú k management rozhraniam serverov, zálohy sú dostupné iba zo zálohovacieho servera. Potom prejde rok. Niekto pridá dočasné pravidlo „any-any“, aby odladil problém. Migrácia firewallu prevedie politiky trochu inak. Nová VLAN vznikne skopírovaním starej.

Čítať ďalej
Ako monitorovať domáce internetové pripojenie — a dokázať to poskytovateľovi

Ako monitorovať domáce internetové pripojenie — a dokázať to poskytovateľovi

Videohovor zamrzne, hra laguje, obchodný terminál sa znova pripája. Speedtest o päť minút neskôr ukáže 500 Mbit/s a všetko vyzerá v poriadku. Zavoláte poskytovateľovi, ten „na linke nevidí žiadny problém“ a odporučí reštartovať router.

Čítať ďalej