Monitoring: Prometheus, Grafana, DCGM a Loki pre AI servery

AI server, ktorý nikto nesleduje, je server, čo ticho throttluje, uniká mu VRAM, hromadí ECC chyby alebo ho o 03:00 zabije OOM killer — a zistíte to až o tri dni neskôr, keď sa niekto spýta, prečo jeho fine-tune vyprodukoval nezmysly. Väčšina tých najhorších porúch na GPU stroji je z aplikácie neviditeľná: tepelný throttling sa nezapíše do stderr, ECC korekcie hneď nič nezhodia a keď OOM killer zožerie proces, orchestrátor ho čisto reštartuje. Bez metrík z hardvéru samotného sa o ničom z toho nedozviete skôr, než Vás to bude stáť týždeň.

Štandardná výbava sysadmina (htop, df, uptime, syslog) na to nestačí. GPU je najdrahší komponent v šasi a zároveň ten najporuchovejší — a má vlastnú telemetriu, ktorú treba explicitne zapojiť. Tento článok je názorová zostava práve pre ňu — Prometheus, Grafana, DCGM-exporter, node_exporter, Loki a Alertmanager — zabalená do jediného docker-compose nasadenia, ktoré prevádzkujeme na každom AI serveri Kentino, ktorý expedujeme.

Je určený tomu, kto rozbieha AI server so štyrmi alebo ôsmimi GPU, vie napísať docker-compose súbor a hľadá odpoveď na otázku „čo mám vlastne sledovať a pri akej hranici mám alarmovať“.

Štandardný stack v roku 2026

Päť komponentov urobí takmer všetku prácu. Všetko ostatné je už len nadstavba.

Spolu to je hlboko pod 0,5 % jedného jadra na 96-jadrovom EPYC-u a zhruba 700 MB RAM. Na serveri s 256 GB a ôsmimi GPU je to zaokrúhlovacia chyba. Argument „monitoring kradne cykly tréningu“ prestal platiť niekedy okolo roku 2019.

Jedno architektonické rozhodnutie stojí za to urobiť hneď na začiatku: stack prevádzkujte na samostatnom manažment VM alebo malom stroji, nie na samotnom GPU serveri. Vyhradené mini-PC, NUC, servisný uzol na EPYC-u alebo VM na laboratórnom hypervízore — čokoľvek, čo nie je samotný GPU stroj. Dôvody sú dva: keď GPU server spadne (kernel panic z nedostatku pamäte, výpadok zdroja, tepelné vypnutie), stále chcete mať históriu metrík, aby ste zistili, čo sa stalo — a zároveň nechcete, aby sa zdivený tréningový job bil s Prometheom o pamäť a spúšťal vlastný alert. DCGM-exporter a node_exporter bežia na GPU hostovi (inak to ani nedá — čítajú lokálne zariadenia); Prometheus, Grafana, Loki a Alertmanager bežia na manažment VM a ťahajú dáta dovnútra.

DCGM-exporter — jediná vec, ktorú nemôžete vynechať

NVIDIA Data Center GPU Manager (DCGM) je podporovaný a smerodajný zdroj telemetrie GPU. Kontajner dcgm-exporter vystavuje metriky DCGM vo formáte Prometheus na porte 9400. Je to najdôležitejší komponent celého stacku a zároveň niečo, čo pollovanie cez nvidia-smi nikdy nenahradí.

Inštalujte cez NGC kontajner (nvcr.io/nvidia/k8s/dcgm-exporter, k polovici roka 2026 vo verzii 4.x) alebo cez upstream Helm chart pre Kubernetes. Na holom Dockeri stačí jediný docker run --gpus all --rm ; démon potom publikuje zhruba 80 metrík na :9400/metrics. Tie, na ktorých naozaj záleží, zoradené podľa toho, ako často odhalia reálny problém:

Počítadlá throttlingu sú tá najcennejšia funkcia. DCGM_FI_DEV_THERMAL_VIOLATION je monotónne počítadlo nanosekúnd, ktoré GPU strávila v throttlingu. Spočítajte jeho mieru v päťminútovom okne a máte presnú odpoveď na otázku „je môj server práve teraz tepelne obmedzený?“. Bez toho hádate iba z teploty, a tá klame — 4090 začne pri trvalej záťaži throttlovať už pri 83 °C bez ohľadu na to, čo ukazuje teplotný panel.

Dve známe zvláštnosti DCGM-exportera, ktoré sa v roku 2026 oplatí poznať: niektoré XID kódy (najmä XID 62) sa nie vždy prejavia cez DCGM_FI_DEV_XID_ERRORS, a metrika je gauge posledného zachyteného XID — takže sa po zotavení nemusí resetovať, kým exporter nereštartujete. Riešením je zároveň sledovať cez Loki kernel ring buffer a hľadať v ňom reťazec NVRM: Xid (viac k tomu nižšie). Istiť sa dvakrát.

Pri čisto spotrebiteľských kartách (RTX 4090, 5090) sú niektoré dátocentrové funkcie DCGM len čiastočné — MIG nie je, NVLink na spotrebiteľských Blackwelloch chýba a určité ECC počítadlá vracajú nulu. DCGM aj tak funguje a hlási to, čo je vystavené; ľahká komunitná alternatíva nvidia_gpu_exporter (ktorá číta nvidia-smi) je použiteľná náhrada, ak nechcete ťahať celý reťazec závislostí DCGM. Pri Pro 6000 Blackwell, L40 a L4 — teda pri čomkoľvek z dátocentrovej či pro línie — použite DCGM, nie tento wrapper.

node_exporter — systémová polovica

Metriky GPU hovoria len polovicu príbehu. node_exporter pokrýva ten zvyšok:

Scenár „došla systémová RAM, OOM killer zabil vLLM, kontajner sa čisto reštartoval“ zachytíte tu, nie cez DCGM. Sledujte node_memory_MemAvailable_bytes a alarmujte, keď klesne pod 5 % z celku. V Linuxe killer štandardne zasahuje až pri hodnotách blízkych nule — vtedy je však Váš proces už mŕtvy.

Prometheus — konfigurácia, retencia, dimenzovanie

Prometheus je časová databáza a orchestrátor zberu. Predvolené nastavenia sú rozumné; hneď prvý deň sa však oplatí zmeniť dve veci — interval zberu a retenciu.

Pätnásťsekundový interval zberu je pre AI server správny štart: dosť rýchly na to, aby zachytil teplotný skok skôr, než sa z neho stane trvalý throttling, a dosť pomalý na to, aby náklady na časové rady zostali skromné. Retencia je štandardne 15 dní; 30 dní je lepšie číslo, keď chcete porovnávať dnešné správanie so zmenou ladenia spred mesiaca.

Rozpočet úložiska pri 15 s zbere, ~80 metrík DCGM × N GPU + ~400 metrík node_exportera + ~50 metrík vLLM: zhruba 1.5–2 GB týždenne, takže 30 dní na stroji s ôsmimi GPU vyjde na 6–10 GB. Pre istotu nastavte retenciu aj podľa času, aj podľa veľkosti:

command:
  - "--storage.tsdb.retention.time=30d"
  - "--storage.tsdb.retention.size=20GB"

Kompakciu spustí ktorýkoľvek z limitov — vyhráva ten, ktorý sa dosiahne skôr. Pri alokácii 100 GB máte rezervu na viac než rok bez toho, aby ste nad tým museli rozmýšľať.

Dashboardy v Grafane — začnite hotovými

Nestavajte dashboardy od nuly. Komunita to už urobila za Vás.

Najskôr importujte 12239 a 1860. Pokrývajú zhruba 90 % toho, na čo sa naozaj chcete pozerať, a roky ich niekto brúsil. Vlastné stavajte až po mesiaci, keď už viete, ktoré panely naozaj otvárate. Pre AI hardvér Kentino sa oplatí urobiť dve drobné úpravy: nastaviť panely s teplotnými hranicami GPU na rozsahy vhodné pre Blackwell (5090 throttluje okolo 87 °C, RTX Pro 6000 bližšie k 90 °C) a pridať panel pre každý PCIe slot, ktorý ukáže DCGM_FI_DEV_PCIE_LINK_GEN a DCGM_FI_DEV_PCIE_LINK_WIDTH , aby ste na prvý pohľad videli, či riser nespadol z x16 na x8.

Loki — logy, ktoré vysvetlia, čo metriky ukazujú

Metriky Vám povedia, čo sa zmenilo; logy povedia, prečo. Loki je logovacia databáza od Grafany, Promtail je odosielateľ, ktorý súbory sleduje a posiela ďalej. Promtail nasmerujte na:

• /var/log/syslog a journalctl -k — OOM hlásenia jadra, sťažnosti ovládača NVIDIA, výpisy XID
• /var/log/nvidia-installer.log — stav inštalácie ovládača
• stdout kontajnera vLLM (cez Docker JSON log driver)
• Aplikačné logy čohokoľvek, čo zákazník prevádzkuje

Najhodnotnejší dotaz v záložke Explore v Grafane je:

{job="syslog"} |= "NVRM:"

Vytiahne každú správu ovládača NVIDIA z kernel ring bufferu — XID chyby, zlyhania ventilátorov, udalosti typu „karta vypadla zo zbernice“, timeouty GSP RPC. Skombinujte ho s alertom DCGM_FI_DEV_XID_ERRORS v Prometheovi a máte štruktúrovanú metriku aj neštruktúrovaný detail v jednom okne.

Logy štandardne neposielame mimo hosta. Loki ich drží lokálne s 30-dňovou retenciou a služba na pohotovosti sa v prípade potreby pripojí do Grafany cez SSH tunel. Zákazníci, ktorí chcú centralizované logy naprieč viacerými servermi, môžu Loki nasmerovať na S3 alebo prevádzkovať regionálnu inštanciu — to je otázka nasadenia, nie architektúry.

Metriky vLLM a SGLang — merajte aj aplikáciu, nielen železo

DCGM Vám povie, že je GPU vyťažená. Nepovie Vám, či sa inferenčné požiadavky vracajú za 200 ms alebo za 2 s. Na to treba merania priamo vo vrstve, ktorá model obsluhuje.

vLLM vystavuje /metrics natívne na rovnakom porte ako OpenAI API. Pri predvolených nastaveniach endpoint na :8000/metrics publikuje metriky Prometheus s prefixom vllm: (z ktorého sa po zbere Prometheom stane vllm_ ). Tie, ktoré sa oplatí zbierať:

Kombinácia vllm:num_requests_waiting > 0 a DCGM_FI_DEV_GPU_UTIL < 90% znamená, že sa fronta hromadí, zatiaľ čo GPU zaháľa — obyčajne ide o úzke miesto v tokenizéri alebo plánovači, nie vo výpočte. Uvidíte to len vtedy, keď máte obe metriky v jednom dashboarde — a práve preto sa oplatí zjednotiť telemetriu aplikácie aj hardvéru v jednom Prometheovi.

NVIDIA NIM vystavuje rovnaké metriky vLLM pod /v1/metrics bez premenovávania, takže Vaše existujúce dashboardy a pravidlá alertov prejdú na nasadenie s NIM bez zmeny. SGLang publikuje podobnú sadu na vlastnom porte (predvolene 30000), HTTP server llama.cpp vystavuje menšiu podmnožinu a Triton má vlastnú taxonómiu. Nech už prevádzkujete čokoľvek, zbierajte metriky z aplikácie — nielen z hardvéru.

Pravidlá Alertmanagera — presne tie, ktoré dodávame

Dashboardy sú pekné. Alerty sú užitočné. Nižšie uvedené pravidlá sú práve tie, ktoré odhalili reálne problémy na reálnom zákazníckom hardvéri.

groups:
  - name: gpu
    interval: 30s
    rules:
      - alert: GPUTempCritical
        expr: DCGM_FI_DEV_GPU_TEMP > 87
        for: 30s
        labels: { severity: critical }
        annotations:
          summary: "GPU {{ $labels.gpu }} thermal critical ({{ $value }} °C)"

      - alert: GPUThermalThrottling
        expr: rate(DCGM_FI_DEV_THERMAL_VIOLATION[5m]) > 0
        for: 1m
        labels: { severity: warning }

      - alert: GPUECCUncorrectable
        expr: increase(DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[10m]) > 0
        labels: { severity: critical }
        annotations:
          summary: "GPU {{ $labels.gpu }} uncorrectable ECC — schedule replacement"

      - alert: GPUXIDError
        expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
        labels: { severity: critical }

      - alert: GPUPowerEnvelopeExceeded
        expr: DCGM_FI_DEV_POWER_USAGE > 590  # 5090 nominal 575 W; alarm above sustained ceiling
        for: 5m
        labels: { severity: warning }

      - alert: GPUIdleDuringWork
        expr: DCGM_FI_DEV_GPU_UTIL < 5 and DCGM_FI_DEV_FB_USED > 1024
        for: 10m
        labels: { severity: warning }
        annotations:
          summary: "GPU {{ $labels.gpu }} idle with VRAM allocated — likely hung"

  - name: system
    interval: 30s
    rules:
      - alert: HostMemoryLow
        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.05
        for: 2m
        labels: { severity: critical }

      - alert: OOMKillerFired
        expr: increase(node_vmstat_oom_kill[5m]) > 0
        labels: { severity: critical }

      - alert: ContainerRestartLoop
        expr: rate(container_start_time_seconds[15m]) > 3
        for: 10m
        labels: { severity: warning }

  - name: serving
    interval: 30s
    rules:
      - alert: vLLMQueueBacklog
        expr: vllm:num_requests_waiting > 10
        for: 5m
        labels: { severity: warning }

      - alert: vLLMHighLatency
        expr: histogram_quantile(0.95, rate(vllm:e2e_request_latency_seconds_bucket[5m])) > 10
        for: 5m
        labels: { severity: warning }

Názorové rozhodnutia v týchto pravidlách:

• 87 °C ako kritická teplota GPU. 5090 na väčšine dosiek throttluje niekde nad 85 °C. Ak Vaša miestnosť neudrží karty pri trvalej záťaži pod 80 °C, máte problém so vzduchotechnikou, nie so softvérom.
• Každá neopraviteľná ECC chyba budí pohotovosť. Jediná dvojbitová ECC udalosť znehodnotí všetko, čo bolo v danej stránke VRAM — tréningový krok je zlý, výsledok inferencie je zlý. Karta potrebuje výmenu, nie reštart.
• GPUIdleDuringWork je detektor zaseknutia. Viac než 1 GiB alokovanej pamäte a menej než 5 % vyťaženia po dobu 10 minút znamená, že niečo viazne. Odhalí to zaseknutia na strane CUDA, ktoré aplikácia vesele ignoruje.
• Alert na OOM killer je najprehliadanejšie pravidlo v každom nasadení. Linux ticho zabije Váš tréningový job a Docker ho čisto reštartuje — a práve toto je tá porucha, ktorá ročne premrhá najviac inžinierskych hodín. Nech je počuť.
• Slučka reštartov kontajnera odhalí reštartovacie cykly NIM a vLLM, ktoré zvonku vyzerajú zdravo (kontajner „beží“), no v skutočnosti padajú pri každom načítaní modelu.

Šasi a úložiská — IPMI a SMART

DCGM končí pri GPU. node_exporter končí pri operačnom systéme. Na zvyšok šasi — ventilátory, zdroje, teplotu okolia, zdravie úložiská — potrebujete ešte dva exportery.

ipmi_exporter (prometheus-community) komunikuje s BMC cez IPMI/RMCP a vynáša telemetriu na úrovni šasi: otáčky jednotlivých ventilátorov, vstupné napätie a prúd zdrojov, záznamy systémového logu udalostí, teplotu nasávaného vzduchu, stav BMC watchdogu. Na šasi Supermicro alebo Bone64c s funkčným BMC je to pol dňa práce a odhalí veci, ktoré DCGM doslova nevidí — umírajúci zdroj v zostave s ôsmimi GPU a dvoma zdrojmi sa v dátach ipmi senzorov prejaví ako prepad napätia niekoľko minút predtým, než GPU vyhodí XID 79. Spusťte ho na hostovi (potrebuje /dev/ipmi0) alebo vzdialene s uloženými prihlasovacími údajmi BMC podľa vzoru multi-target exportera.

smartctl_exporter (alebo starší smart_exporter) číta SMART atribúty NVMe a SATA: ukazovateľ opotrebenia média, dostupnú rezervu, teplotu, počty chýb. AI workloady sú k NVMe brutálne — načítavanie datasetov, zápisy checkpointov a cache HuggingFace vytlačia spotrebiteľský disk na enterprise hranicu opotrebenia za niekoľko mesiacov. Alarmujte na metrike nvme_available_spare pri poklese pod 20 % a na nvme_percentage_used (ukazovateľ opotrebenia) pri náraste nad 80 %. Zlyhanie disku je na vyťaženom AI serveri druhá najbežnejšia hardvérová porucha hneď po triede riser/zdroj.

Kompletné monitorovacie nasadenie Kentino AI obsahuje oboje. Náklad navýše sú minúty; hodnota pri prvom tichom zlyhaní ventilátora alebo keď Samsung 990 Pro narazí na svoj strop DWPD, sa ráta v hodinách.

Reálny docker-compose pre manažment VM

To, čo na manažment stroji naozaj nasadzujeme. Upravte host.docker.internal (alebo použite hostname či IP GPU servera), aby Prometheus mieril na porty exporterov na GPU hostovi.

version: "3.8"

networks:
  monitoring: { driver: bridge }

volumes:
  prometheus_data:
  grafana_data:
  loki_data:

services:
  prometheus:
    image: prom/prometheus:v3.0.0
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./rules:/etc/prometheus/rules:ro
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--storage.tsdb.retention.time=30d"
      - "--storage.tsdb.retention.size=20GB"
      - "--web.enable-lifecycle"
    ports: ["9090:9090"]
    networks: [monitoring]

  grafana:
    image: grafana/grafana:11.4.0
    restart: unless-stopped
    environment:
      - GF_SECURITY_ADMIN_PASSWORD__FILE=/run/secrets/grafana_pw
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning:ro
    secrets: [grafana_pw]
    ports: ["3000:3000"]
    networks: [monitoring]

  alertmanager:
    image: prom/alertmanager:v0.28.0
    restart: unless-stopped
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
    ports: ["9093:9093"]
    networks: [monitoring]

  loki:
    image: grafana/loki:3.3.0
    restart: unless-stopped
    command: -config.file=/etc/loki/loki.yml
    volumes:
      - ./loki.yml:/etc/loki/loki.yml:ro
      - loki_data:/loki
    ports: ["3100:3100"]
    networks: [monitoring]

secrets:
  grafana_pw: { file: ./secrets/grafana_pw.txt }

Priamo na GPU hostovi (samostatný compose, na GPU serveri):

services:
  dcgm-exporter:
    image: nvcr.io/nvidia/k8s/dcgm-exporter:4.5.1-4.8.0-ubuntu22.04
    restart: unless-stopped
    runtime: nvidia
    environment: [NVIDIA_VISIBLE_DEVICES=all]
    cap_add: [SYS_ADMIN]
    ports: ["9400:9400"]

  node-exporter:
    image: prom/node-exporter:v1.9.0
    restart: unless-stopped
    pid: host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - "--path.procfs=/host/proc"
      - "--path.sysfs=/host/sys"
      - "--path.rootfs=/rootfs"
    ports: ["9100:9100"]

  ipmi-exporter:
    image: prometheuscommunity/ipmi-exporter:v1.10.0
    restart: unless-stopped
    privileged: true
    volumes: ["/dev/ipmi0:/dev/ipmi0"]
    ports: ["9290:9290"]

  smartctl-exporter:
    image: prometheuscommunity/smartctl-exporter:v0.13.0
    restart: unless-stopped
    privileged: true
    ports: ["9633:9633"]

  promtail:
    image: grafana/promtail:3.3.0
    restart: unless-stopped
    volumes:
      - /var/log:/var/log:ro
      - ./promtail.yml:/etc/promtail/promtail.yml:ro
    command: -config.file=/etc/promtail/promtail.yml

Konfigurácia zberu Prometheus na manažment VM:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - /etc/prometheus/rules/*.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: dcgm
    static_configs:
      - targets: ["k-ai-01.lan:9400", "k-ai-02.lan:9400"]

  - job_name: node
    static_configs:
      - targets: ["k-ai-01.lan:9100", "k-ai-02.lan:9100"]

  - job_name: ipmi
    static_configs:
      - targets: ["k-ai-01.lan:9290", "k-ai-02.lan:9290"]

  - job_name: smart
    static_configs:
      - targets: ["k-ai-01.lan:9633", "k-ai-02.lan:9633"]

  - job_name: vllm
    metrics_path: /metrics
    static_configs:
      - targets: ["k-ai-01.lan:8000"]

Toto je funkčný stack pre laboratórium s jedným až tromi servermi. Nad štyri až päť serverov prepnite konfiguráciu zberu na service discovery zo súborov — alebo, ak ste na Kubernetes, na Helm chart DCGM-exportera z GPU Operatora a na CRD ServiceMonitor z Prometheus Operatora.

OpenTelemetry, Pixie, eBPF — obraz roku 2026

Poznámka k veciam, ktoré sa stále hýbu — pretože táto otázka príde vždy.

OpenTelemetry je štandard CNCF pre inštrumentáciu observability a od začiatku roka 2026 sú stabilné všetky tri typy signálov (metriky, trasy, logy). Pipeline OTel Collector v mnohých organizáciách nahrádza agentov jednotlivých dodávateľov v roli univerzálneho smerovača telemetrie. Pre AI server znie pragmatická odpoveď v roku 2026 takto: metriky nechajte na Prometheovi (DCGM-exporter a node_exporter hovoria Prometheom natívne a Vaše pravidlá alertov sú v PromQL) a OTel Collector pridajte až vtedy, keď potrebujete distribuované trasovanie naprieč inferenčným grafom (požiadavka → API gateway → vLLM → volanie nástroja → vektorová databáza → odpoveď). Pri jednoserverovej inštalácii s jedným modelom za nginxom pridá OTel náklady bez hodnoty. Tých 71 % organizácií, ktoré „používajú oboje“, má Prometheus na železo a OTel na trasy aplikácií — rozumné rozdelenie.

Pixie je nástroj observability natívny pre Kubernetes, ktorý cez eBPF zbiera metriky, trasy a logy na úrovni jadra bez zásahu do kódu. Z roku 2026 stojí za sledovanie práca na eBPF priamo na GPU (bpftime, eGPU, otvorené kernel moduly NVIDIA), ktorá rozširuje inštrumentáciu eBPF do GPU kernelov cez injekciu PTX za behu. Dnes je to na úrovni výskumu a nie je súčasťou žiadneho produkčného stacku, ktorý dodávame. Zatiaľ je podporovanou odpoveďou DCGM.

Kontinuálne profilovanie (Grafana Phlare, Pyroscope) je tretia nadstavba, o ktorej sa oplatí vedieť. Pri inferenčných workloadoch, kde máte pod kontrolou kód frameworku (vlastné patche vLLM, optimalizácie tokenizéra), Vám povie, ktoré funkcie pália CPU. Pri čistom servírovaní modelov v bežných kontajneroch je to zbytočné.

Čo sa pokáže (monitorovacie vydanie)

Predvídateľné poruchy samotného stacku, zoradené podľa toho, ako často štipnú:

• Prometheu sa zaplnil disk. Predvolená retencia je 15 dní; my nastavujeme 30 so stropom 20 GB. Nad 60 dní na vyťaženom stroji rátajte s desiatkami GB. Retenciu nastavte podľa času aj podľa veľkosti.
• DCGM-exporter po aktualizácii ovládača stratí GPU. Príznak: všetky GPU panely zostanú prázdne. Riešenie: reštartujte kontajner a ak sa runtime presunul, spustite znova nvidia-ctk runtime configure .
• Alertmanager nie je nastavený na prijímateľa, ktorého naozaj používate. Ľudia rozbehnú Prometheus a Grafanu, zabudnú nasmerovať Alertmanager na e-mail alebo Slack a o pol roka zistia, že žiadny alert nikdy nevyšiel. Otestujte to tak, že zámerne vyvoláte GPUTempCritical záťažovým testom, alebo použite amtool alert add a hneď prvý deň vyšlite syntetický alert.
• Explózia kardinality z labelov na úrovni požiadavky. Neoznačujte metriky vLLM labelmi user_id ani request_id. Prometheus na to nie je stavaný — databázu tým položíte na nedostatok pamäte.
• Únik hesla Grafany cez prostredie v compose. Použite Docker secrets, nie GF_SECURITY_ADMIN_PASSWORD v bloku environment. docker inspect aj logy premenné prostredia prezradia.
• XID gauge, ktoré sa neresetuje. Ako sme spomenuli, XID gauge v DCGM-exporteri môže po zotavení zostať visieť na poslednej videnej hodnote. Skombinujte túto metriku so sledovaním NVRM: v syslogu cez Loki, aby ste si nedali falošnú istotu.

Ako to je naozaj

Väčšina laboratórií si raz nainštaluje Grafanu, postaví dashboard, ktorý tím týždeň obdivuje, a už sa naň nikdy nepozrie. Dashboard je príjemný artefakt, ale nie je to on, čo odhalí Váš problém. Problémy odhalia alerty. Nastavte Alertmanager so skutočným prijímateľom (e-mail, Slack, PagerDuty) a s malou sadou presných pravidiel — teplota GPU, dvojbitové ECC, XID, OOM killer, slučka reštartov kontajnera — a laďte ich dovtedy, kým nebudú spúšťať len vtedy, keď je naozaj niečo zle. Toto urobte najskôr. Dashboardy stavajte až potom, pre debugovanie po incidente.

Druhá polovica pravdy: pri jednoserverovej škále Kentino dostanete z tohto stacku alert možno raz za mesiac a vo väčšine mesiacov to bude falošný poplach, ktorý si odfiltrujete. To je známka toho, že systém funguje. Hodnota je v tom jedinom alerte, ktorý príde v deň, keď sa začne piecť riser — dva dni predtým, než karta vyhodí XID 79, keď je ešte čas prepojiť kábel namiesto reklamácie GPU. Táto jediná udalosť zaplatí celé úsilie s monitoringom, a to mnohonásobne.

---

Toto je súčasť Kentino Wiki, referenčnej série o AI výpočtoch, robotike a systémoch, ktoré ich spájajú. Pripomienky a opravy uvítame na info@kentino.com.