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

AI server, na který se nikdo nedívá, je server, který potichu throttluje, ztrácí VRAM, nasbírává ECC chyby nebo ho ve 03:00 sejme OOM killer — a Vy se to dozvíte o tři dny později, až se někdo zeptá, proč jeho fine-tune vyplodil nesmysly. Většina nejhorších poruchových stavů na GPU stroji je z aplikace neviditelná: tepelný throttling se neloguje do stderr, ECC opravy hned nic neshodí, OOM killer sežere proces a orchestrátor ho čistě restartuje. Bez metrik ze samotného hardwaru nic z toho neuvidíte, dokud Vás to nestojí týden práce.

Standardní sysadminská výbava (htop, df, uptime, syslog) na to nestačí. GPU je nejdražší a zároveň nejporuchovější komponenta v šasi a má vlastní telemetrickou vrstvu, kterou je potřeba explicitně zapojit. Tento článek je názorový návod, jak takovou vrstvu postavit — Prometheus, Grafana, DCGM-exporter, node_exporter, Loki a Alertmanager — zabalený do jediného docker-compose nasazení, které provozujeme na každém AI serveru Kentino, který expedujeme.

Článek je psaný pro toho, kdo staví AI server se 4 nebo 8 GPU, umí napsat docker-compose soubor a chce odpověď na otázku „co mám vlastně monitorovat a při jaké hodnotě mám alarmovat“.

Standardní stack v roce 2026

Pět komponent odvede téměř všechnu práci. Všechno ostatní je nadstavba.

Dohromady hluboko pod 0.5% jednoho jádra na 96jádrovém EPYCu a zhruba 700 MB RAM. Na serveru s 256 GB a 8 GPU je to chyba zaokrouhlení. Argument „monitoring ukrajuje výkon tréninku“ přestal platit někdy v roce 2019.

Jedno architektonické rozhodnutí stojí za to udělat hned na začátku: provozujte stack na samostatném management VM nebo malém stroji, ne na samotném GPU serveru. Vyhrazené mini-PC, NUC, servisní uzel na EPYCu nebo VM na laboratorním hypervizoru — cokoli, co není GPU stroj. Dva důvody: když GPU server spadne (kernel panic z nedostatku paměti, výpadek zdroje, tepelné vypnutí), budete chtít mít historii metrik, abyste zjistili, co se stalo; a nechcete, aby utržený trénink soupeřil s Prometheem o paměť a sám spustil alert. DCGM-exporter a node_exporter běží na GPU hostiteli (jinak to nejde — čtou lokální zařízení); Prometheus, Grafana, Loki a Alertmanager běží na management VM a scrapují dovnitř.

DCGM-exporter — to jediné, co se vynechat nedá

Data Center GPU Manager (DCGM) od NVIDIE je podporovaný a autoritativní zdroj GPU telemetrie. Kontejner dcgm-exporter vystavuje DCGM metriky ve formátu Prometheus na portu 9400. Je to zdaleka nejdůležitější součást celého stacku a je to přesně to, co dotazování nvidia-smi nikdy nenahradí.

Nainstalujte jej z NGC kontejneru (nvcr.io/nvidia/k8s/dcgm-exporter, aktuálně 4.x k polovině roku 2026) nebo z upstream Helm chartu pro Kubernetes. Na holém Dockeru stačí jedno docker run --gpus all --rm; démon pak publikuje zhruba 80 metrik na :9400/metrics. Ty, na kterých skutečně záleží, seřazené podle toho, jak často odhalí reálný problém:

Čítače throttlingu jsou ta nejcennější funkce. DCGM_FI_DEV_THERMAL_VIOLATION je monotónní čítač nanosekund, které GPU strávilo v throttlingu. Spočítejte jeho četnost v okně 5 minut a máte přesnou odpověď na otázku „je můj server právě teď tepelně limitovaný?“. Bez něj jen hádáte z teploty, a ta klame — 4090 bude při trvalé zátěži throttlovat na 83 °C bez ohledu na to, co ukazuje teplotní panel.

Dvě známé zvláštnosti DCGM-exporteru, které je v roce 2026 dobré znát: některé XID kódy (zejména XID 62) se přes DCGM_FI_DEV_XID_ERRORS vždy neprojeví a metrika je gauge s posledním viděným XID — po zotavení se tedy nemusí vynulovat, dokud exporter nerestartujete. Obrana je zároveň sledovat kernel ring buffer přes Loki na doslovný řetězec NVRM: Xid (více níže). Jistota na dvakrát.

U čistě spotřebních karet (RTX 4090, 5090) jsou některé datacentrové funkce DCGM jen částečné — MIG chybí, NVLink na spotřebních Blackwellech není, některé ECC čítače vracejí nulu. DCGM přesto funguje a hlásí to, co je dostupné; odlehčená komunitní alternativa nvidia_gpu_exporter (která scrapuje nvidia-smi) je použitelná náhrada, pokud nechcete závislosti DCGM. Pro Pro 6000 Blackwell, L40 a L4 — tedy cokoli z datacentrové / pro řady — použijte DCGM, ne tuto nadstavbu.

node_exporter — systémová polovina

GPU metriky vyprávějí jen polovinu příběhu. Zbytek pokryje node_exporter:

Poruchový scénář „došla systémová RAM, OOM killer sebral vLLM, kontejner se čistě restartoval“ odhalíte tady, ne přes DCGM. Sledujte node_memory_MemAvailable_bytes a alarmujte, jakmile klesne pod 5% celkové kapacity. V Linuxu killer ve výchozím stavu vystřelí až někde u 0%, ale to už je Váš proces po smrti.

Prometheus — konfigurace, retence, dimenzování

Prometheus je databáze časových řad a zároveň orchestrátor scrapování. Výchozí nastavení jsou rozumná; dvě hodnoty stojí za změnu hned první den — interval scrapování a retence.

Interval scrapování 15 s je pro AI server správný začátek: dost rychlý na to, aby zachytil tepelný špičák dřív, než se z něj stane trvalý throttling, a dost pomalý na to, aby náklady na časové řady zůstaly nízké. Retence je ve výchozím stavu 15 dní; 30 dní je lepší číslo pro situaci, kdy budete chtít porovnat dnešní chování s loňskou úpravou ladění.

Rozpočet úložiště při scrapu po 15 s, ~80 DCGM metrikách × N GPU + ~400 metrikách node_exporteru + ~50 metrikách vLLM: zhruba 1.5–2 GB týdně, takže 30 dní vyjde na 6–10 GB u stroje s 8 GPU. Nastavte pro jistotu retenci podle času i podle velikosti:

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

Kompaktaci spustí kterýkoli z limitů; platí ten, který se naplní dřív. Alokace 100 GB Vám bez přemýšlení dá rezervu na víc než rok.

Grafana dashboardy — začněte hotovými

Nestavte dashboardy od nuly. Komunita to už udělala.

Naimportujte nejdřív 12239 a 1860. Pokrývají zhruba 90% toho, na co se reálně chcete dívat, a roky se ladily. Vlastní stavte až po měsíci, až budete vědět, které panely opravdu otevíráte. Drobné úpravy, které se u hardwaru Kentino AI vyplatí: nastavit panely teplotních prahů GPU na rozsahy odpovídající Blackwellu (5090 throttluje kolem 87 °C, RTX Pro 6000 spíš kolem 90 °C) a přidat panel pro jednotlivé PCIe sloty s DCGM_FI_DEV_PCIE_LINK_GEN a DCGM_FI_DEV_PCIE_LINK_WIDTH, abyste na první pohled viděli, jestli riser nespadl z x16 na x8.

Loki — logy, které vysvětlí, co metriky ukazují

Metriky Vám řeknou, co se změnilo; logy řeknou proč. Loki je logová databáze od Grafany, Promtail je odesílač, který sleduje soubory a posílá je dál. Namiřte Promtail na:

• /var/log/syslog a journalctl -k — kernelové OOM hlášky, stížnosti ovladače NVIDIA, výpisy XID
• /var/log/nvidia-installer.log — stav instalace ovladače
• stdout vLLM kontejneru (přes Docker JSON log driver)
• Aplikační logy čehokoli, co zákazník provozuje

Nejcennější jednotlivý dotaz v záložce Explore v Grafaně je:

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

Vytáhne každou hlášku ovladače NVIDIA z kernel ring bufferu — XID chyby, selhání ventilátorů, odpadnutí karty ze sběrnice, timeouty GSP RPC. Spárujte to s Prometheus alertem na DCGM_FI_DEV_XID_ERRORS a máte v jednom okně strukturovanou metriku i nestrukturovaný detail.

Logy ve výchozím stavu mimo hostitele neposíláme. Loki je drží lokálně s retencí 30 dní; pohotovost se v případě potřeby přes SSH tunel připojí do Grafany. Zákazníci, kteří chtějí centralizované logy z více serverů, mohou Loki namířit na S3 nebo provozovat regionální instanci — to je otázka nasazení, ne architektury.

Metriky vLLM a SGLang — měřte aplikaci, nejen železo

DCGM Vám řekne, že GPU je zaneprázdněné. Neřekne Vám, jestli se inferenční požadavky vracejí za 200 ms, nebo za 2 s. Na to musíte osadit měřením servingovou vrstvu.

vLLM vystavuje /metrics nativně na stejném portu jako OpenAI API. Ve výchozím nastavení endpoint na :8000/metrics publikuje Prometheus metriky s prefixem vllm: (z něhož se po scrapu Prometheem stane vllm_). Ty, které stojí za scrapování:

Kombinace vllm:num_requests_waiting > 0 a DCGM_FI_DEV_GPU_UTIL < 90% znamená, že fronta narůstá, zatímco GPU zahálí — obvykle jde o úzké hrdlo v tokenizéru nebo plánovači, ne ve výpočtu. Uvidíte to jen tehdy, když máte obě metriky v jednom dashboardu, a přesně v tom je smysl sjednocení aplikační a hardwarové telemetrie v jednom Prometheu.

NVIDIA NIM vystavuje tytéž vLLM metriky pod /v1/metrics a bez přejmenování, takže Vaše stávající vLLM dashboardy i alertovací pravidla fungují na nasazení s NIM beze změny. SGLang publikuje obdobnou sadu na vlastním portu (výchozí 30000); HTTP server llama.cpp vystavuje menší podmnožinu. Triton publikuje vlastní taxonomii. Ať už provozujete cokoli, scrapujte aplikaci — nejen hardware.

Pravidla pro Alertmanager — ta, která skutečně nasazujeme

Dashboardy jsou hezké. Alerty jsou užitečné. Následující pravidla odhalila reálné problémy na reálném zákaznickém hardwaru.

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á rozhodnutí v těchto pravidlech:

• 87 °C jako kritická teplota GPU. 5090 na většině desek throttluje v pásmu vysokých 80 °C. Pokud Vaše místnost neudrží karty při trvalé zátěži pod 80 °C, máte problém s klimatizací, ne se softwarem.
• Jakákoli neopravitelná ECC chyba budí pohotovost. Jediná dvoubitová ECC chyba znehodnotí obsah dané stránky VRAM — tréninkový krok je špatně, výsledek inference je špatně. Karta potřebuje výměnu, ne restart.
• GPUIdleDuringWork je detektor zablokování. Víc než 1 GiB alokované paměti a méně než 5% využití po dobu 10 minut znamená, že se něco zaseklo. Odchytí zatuhnutí na straně CUDA, která aplikace vesele ignoruje.
• Alert na OOM killer je nejčastěji opomíjené pravidlo v každém nasazení. To, že Linux potichu zabije Váš tréninkový běh a Docker ho čistě restartuje, je ten poruchový scénář, který ročně spolyká nejvíc inženýrských hodin. Ať je slyšet.
• Smyčka restartů kontejneru odhalí restartovací cykly NIM a vLLM, které zvenku vypadají zdravě (kontejner přece „běží“), ale ve skutečnosti padají při každém načtení modelu.

Šasi a úložiště — IPMI a SMART

DCGM končí u GPU. node_exporter končí u operačního systému. Zbytek šasi — ventilátory, zdroje, okolní teplota, zdraví úložiště — vyžaduje dva další exportéry.

ipmi_exporter (prometheus-community) komunikuje s BMC přes IPMI/RMCP a zpřístupní telemetrii na úrovni šasi: otáčky jednotlivých ventilátorů, vstupní napětí a proud zdrojů, záznamy ze systémového event logu, teplotu nasávaného vzduchu, stav BMC watchdogu. Na šasi Supermicro nebo Bone64c s funkčním BMC je to půl dne práce a odchytí věci, které DCGM doslova vidět nemůže — umírající zdroj v 8GPU sestavě se dvěma zdroji se v IPMI datech projeví poklesem napětí několik minut předtím, než karta vyhodí XID 79. Spusťte jej na hostiteli (potřebuje /dev/ipmi0) nebo vzdáleně s uloženými přihlašovacími údaji k BMC pomocí vzoru multi-target exportéru.

smartctl_exporter (nebo starší smart_exporter) čte SMART atributy NVMe a SATA disků: indikátor opotřebení média, dostupnou rezervu, teplotu, počty chyb. AI workloady jsou na NVMe brutální — načítání datasetů, zápisy checkpointů a cache HuggingFace vyčerpají enterprise limity opotřebení na spotřebních discích během měsíců. Alarmovat se vyplatí na nvme_available_spare klesající pod 20% a na nvme_percentage_used (ukazatel opotřebení) stoupající nad 80%. Selhání disku je druhá nejčastější hardwarová závada na vytíženém AI serveru hned po třídě riser/zdroj.

Kompletní monitorovací nasazení Kentino AI obsahuje obojí. Vícepráce je otázkou minut; hodnota v okamžiku, kdy poprvé potichu selže ventilátor nebo Samsung 990 Pro narazí na svůj DWPD strop, se počítá v hodinách.

Reálný docker-compose pro management VM

Co na management stroji skutečně nasazujeme. Upravte host.docker.internal (nebo použijte hostname/IP GPU serveru) tak, aby Prometheus mířil na porty exportérů na GPU hostiteli.

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 }

Na samotném GPU hostiteli (samostatný compose, na GPU serveru):

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

Scrape konfigurace Promethea na management 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"]

To je funkční stack pro laboratoř s jedním až třemi servery. Nad čtyři pět serverů přepněte scrape konfiguraci Promethea na service discovery ze souborů — nebo, pokud jedete na Kubernetes, na Helm chart DCGM-exporteru z GPU Operatoru a CRD ServiceMonitor od Prometheus Operatoru.

OpenTelemetry, Pixie, eBPF — jak to vypadá v roce 2026

Poznámka k věcem, které se hýbou, protože ta otázka padne vždycky.

OpenTelemetry je standard CNCF pro instrumentaci observability a od začátku roku 2026 jsou všechny tři typy signálů (metriky, trasování, logy) stabilní. Pipeline OTel Collectoru v mnoha organizacích nahrazuje agenty jednotlivých dodavatelů v roli univerzálního směrovače telemetrie. Pro AI server zní pragmatická odpověď v roce 2026 takto: metriky nechte na Prometheu (DCGM-exporter a node_exporter mluví Prometheem nativně a Vaše alertovací pravidla jsou v PromQL) a OTel Collector přidejte teprve tehdy, až budete potřebovat distribuované trasování napříč inferenčním grafem (požadavek → API gateway → vLLM → volání nástroje → vektorová databáze → odpověď). U jednoserverové instalace s jedním modelem za nginxem přidá OTel náklady bez užitku. Oněch 71% organizací, které „používají obojí“, používá Prometheus na železo a OTel na aplikační trasování — rozumné dělení.

Pixie je observability nástroj pro Kubernetes, který pomocí eBPF sbírá metriky, trasování a logy na úrovni jádra bez zásahu do kódu. Vývoj roku 2026, který stojí za sledování, je práce na eBPF nad GPU (bpftime, eGPU, otevřené kernelové moduly NVIDIE), která rozšiřuje instrumentaci eBPF do GPU kernelů pomocí runtime injektáže PTX. Dnes je to na úrovni výzkumu a součástí žádného produkčního stacku, který dodáváme. Prozatím je podporovanou odpovědí DCGM.

Průběžné profilování (Grafana Phlare, Pyroscope) je třetí nadstavba, o které je dobré vědět. U inferenčních workloadů, kde máte pod kontrolou kód frameworku (vlastní patche vLLM, optimalizace tokenizéru), Vám ukáže, které funkce spalují CPU. U čistého servingu modelů ve standardních kontejnerech je to zbytečný luxus.

Co se rozbíjí (monitorovací edice)

Předvídatelné poruchy samotného stacku, seřazené podle toho, jak často koušou:

• Prometheu se zaplní disk. Výchozí retence je 15 dní; my nastavujeme 30 se stropem 20 GB. Nad 60 dní na vytíženém stroji počítejte s desítkami GB. Nastavte retenci podle času i velikosti.
• DCGM-exporter po upgradu ovladače ztratí GPU. Projev: všechny GPU panely zůstanou prázdné. Náprava: restartovat kontejner; pokud se runtime přesunul, spustit znovu nvidia-ctk runtime configure.
• Alertmanager není nastavený na příjemce, kterého skutečně používáte. Lidé postaví Prometheus a Grafanu, zapomenou Alertmanager namířit na e-mail nebo Slack a o půl roku později zjistí, že nikdy nevyskočil jediný alert. Otestujte to tak, že schválně vyvoláte GPUTempCritical zátěžovým během, nebo hned první den vystřelte syntetický alert přes amtool alert add.
• Exploze kardinality kvůli štítkům na úrovni požadavků. Neštítkujte vLLM metriky přes user_id nebo request_id. Prometheus na to není stavěný — shodíte databázi na nedostatek paměti.
• Únik hesla do Grafany přes proměnné v compose. Použijte Docker secrets, ne GF_SECURITY_ADMIN_PASSWORD v bloku environment. docker inspect i logy hodnoty proměnných vyzradí.
• XID gauge, který se nevynuluje. Jak bylo zmíněno, XID gauge DCGM-exporteru může po zotavení zůstat viset na poslední viděné hodnotě. Zkombinujte metriku se sledováním syslogu na NVRM: v Loki, ať nemáte falešný pocit jistoty.

Upřímně řečeno

Většina laboratoří si jednou nainstaluje Grafanu, postaví dashboard, který tým týden obdivuje, a pak už se na něj nikdy nepodívá. Dashboard je uspokojivý artefakt, ale Vaše problémy neodchytí. Problémy odchytí alerty. Nastavte Alertmanager se skutečným příjemcem (e-mail, Slack, PagerDuty) a s malou sadou přesných pravidel — teplota GPU, dvoubitové ECC, XID, OOM killer, smyčka restartů kontejneru — a laďte je, dokud nezačnou střílet jen tehdy, když je opravdu něco špatně. Tohle udělejte jako první. Dashboardy stavte až potom, kvůli rozboru po incidentu.

Druhá půlka upřímného pohledu: v měřítku jednoho serveru Kentino Vám tento stack pošle alert možná jednou za měsíc a většinu měsíců půjde o planý poplach, který přestanete vnímat. To je známka toho, že systém funguje. Hodnota je v tom alertu, který přijde v den, kdy se riser začne vařit — dva dny předtím, než karta vyhodí XID 79, kdy je ještě čas přepojit kabel místo reklamace GPU. Jediná taková událost zaplatí celé monitorovací úsilí, a to mnohonásobně.

---

Toto je součást Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.