Monitorovací stack: Prometheus, Grafana, DCGM, Loki pro servery s umělou inteligencí

Server s umělou inteligencí, který nikdo nesleduje, je server, který tiše omezuje provoz, uniká mu VRAM, hromadí chyby ECC nebo je v 03:00 ukončen kvůli chybě OOM – a vy to zjistíte o tři dny později, když se někdo zeptá, proč jeho jemné ladění způsobilo havárii. Většina nejhorších poruchových režimů na GPU je z aplikace neviditelná: tepelný throttle se nezaznamenává do stderr, korekce ECC nezpůsobí okamžitý pád, OOM killer zničí proces a orchestrátor ho čistě restartuje. Bez metrik na samotném hardwaru nic z toho neuvidíte, dokud neuplyne týden.

Standardní sada nástrojů pro správu systémů (htop, df, uptime, syslog) se na to nevztahuje. GPU je nejdražší a nejvíce náchylná k selhání součást šasi a má svůj vlastní telemetrický stack, který vyžaduje explicitní instalaci. Tento článek je názorovým sestavením pro tento stack – Prometheus, Grafana, DCGM-exporter, node_exporter, Loki a Alertmanager – zabaleným jako jedno nasazení Docker-Compose, které provozujeme na každém serveru Kentino AI, který dodáváme.

Publikum je někdo, kdo stojí před 4GPU nebo 8GPU serverem s umělou inteligencí, umí napsat soubor pro Docker Compose a chce odpověď na otázku „co bych měl vlastně monitorovat a při jakém prahu bych měl spustit alarm“.

Standardní zásobník v roce 2026

Pět komponent odvede téměř veškerou práci. Všechno ostatní se přišroubuje.

Celkem hluboko pod 0.5 % jednoho jádra CPU na 96jádrovém EPYC a zhruba 700 MB RAM. Na serveru s 256 GB / 8 GPU se jedná o chybu zaokrouhlování. Argument „monitorování krade cykly z trénování“ přestal platit kolem roku 2019.

Jedno architektonické rozhodnutí, které stojí za to učinit předem: spustit stack na samostatném virtuálním počítači pro správu nebo na malém virtuálním počítači, ne na samotném GPU serveru. Dedikovaný mini-PC, NUC, servisní uzel EPYC nebo virtuální počítač na hypervizoru laboratoře – cokoli, co není GPU server. Dva důvody: když dojde k pádu GPU serveru (panika jádra kvůli nedostatku paměti, porucha zdroje, tepelné vypnutí), stále chcete, aby historie metrik diagnostikovala, co se stalo, a nechcete, aby nekontrolovatelná trénovací úloha soupeřila s Prometheem o paměť a spouštěla ​​vlastní upozornění. DCGM-exporter a node_exporter běží na hostiteli GPU (musí – čtou lokální zařízení); Prometheus, Grafana, Loki a Alertmanager běží na virtuálním počítači pro správu a čtou data dovnitř.

DCGM-exporter — jedna věc, kterou nemůžete přeskočit

Správce datových center GPU (DCGM) od společnosti NVIDIA je podporovaný a autoritativní zdroj pro telemetrii GPU. dcgm-exporter Kontejner zpřístupňuje metriky DCGM ve formátu Prometheus na portu 9400. Je to nejdůležitější komponenta v zásobníku a je to ta věc. nvidia-smi průzkumy nikdy nenahradí.

Instalace pomocí kontejneru NGC (nvcr.io/nvidia/k8s/dcgm-exporter, aktuálně 4.x (k polovině roku 2026) nebo upstreamový Helm graf pro Kubernetes. Na holém Dockeru jeden docker run --gpus all --rm stačí; démon poté publikuje ~80 metrik na :9400/metricsTy, na kterých skutečně záleží, seřazené podle toho, jak často zachycují skutečné problémy:

Počítadla škrticí klapky jsou klíčová funkce. DCGM_FI_DEV_THERMAL_VIOLATION je monotónní čítač nanosekund, které strávil GPU omezeným výkonem. Vypočítejte jeho rychlost během 5minutového okna a máte přesnou odpověď na otázku „je můj server momentálně tepelně omezený?“. Bez něj byste hádali pouze na základě teploty, což lže – 4090 se při trvalém zatížení zahřeje na 83 °C bez ohledu na to, co ukazuje teplotní panel.

Dvě známé zvláštnosti vývozců DCGM, které stojí za to znát v roce 2026: některé kódy XID (zejména XID 62) se ne vždy objeví prostřednictvím DCGM_FI_DEV_XID_ERRORSa metrika je ukazatelem poslední XID je vidět – takže po obnovení se může stát, že se resetování bez restartu exportéru nepodaří. Zmírněním problému je také sledujte buffer kernel ring přes Loki pro doslovný obsah NVRM: Xid šňůrka (více o tom níže). Pásek a kšandy.

U čistě spotřebitelských karet (RTX 4090, 5090) jsou některé funkce datových center DCGM jen částečné – chybí MIG, na spotřebitelských součástkách Blackwell chybí NVLink, některé čítače ECC vracejí nulu. DCGM stále funguje a hlásí, co je vystaveno; odlehčená komunitní alternativa nvidia_gpu_exporter (který škrábe nvidia-smi) je schůdnou záložní variantou, pokud nechcete řetězec závislostí DCGM. Pro Pro 6000 Blackwell, L40 a L4 – cokoli v řadě datových center / Pro – použijte DCGM, nikoli wrapper.

node_exporter — systémová polovina

Metriky GPU vypovídají jen polovinu příběhu. node_exporter pokrývá zbytek:

Chyba „systémová RAM vyčerpána, OOM killer převezme vLLM, kontejner se čistě restartuje“ je zachycena zde, nikoli DCGM. Sledovat node_memory_MemAvailable_bytes a spustí alarm, když klesne pod 5 % z celkového počtu. V Linuxu se Killer standardně spustí při téměř 0 %, ale do té doby je proces mrtvý.

Prometheus — konfigurace, uchování, dimenzování

Prometheus je databáze časových řad a orchestrátor scrape. Výchozí nastavení jsou rozumná; dvě nastavení, která stojí za to změnit hned na začátku, jsou interval scrape a uchování.

15sekundový interval scrapingu je pro server s umělou inteligencí správným výchozím bodem: dostatečně rychlý na to, aby zachytil teplotní špičku dříve, než se stane trvalým škrticím pásmem, a dostatečně pomalý, aby náklady na časovou řadu zůstaly nízké. Výchozí doba uchování je 15 dní; 30 dní je lepší číslo pro kontext průvodce sestavením, kde můžete porovnat dnešní chování se změnou ladění z minulého měsíce.

Úložný rozpočet při scrapingu 15 s, ~80 metrik DCGM × N GPU + ~400 metrik node_exporter + ~50 metrik vLLM: zhruba 1.5–2 GB týdně, takže 30 dní na 8GPU serveru vyjde na 6–10 GB. Jako zábranu nastavte uchování podle času i podle velikosti:

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

Kterýkoli z limitů spustí zhuštění; vyhrává ten, který je dosažen dříve. Alokace 100 GB vám poskytne více než rok prostoru bez přemýšlení.

Dashboardy Grafana – začněte s předpřipravenými

Nevytvářejte dashboardy od nuly. Komunita to už zvládla.

Nejprve importujte kódy 12239 a 1860. Pokrývají přibližně 90 % toho, na co se skutečně chcete dívat, a byly v průběhu let vylepšovány. Vlastní panely si sestavte až po měsíci, kdy budete vědět, které panely skutečně otevíráte. Drobné úpravy, které stojí za to provést u hardwaru Kentino AI, jsou: nastavení prahových teplot GPU panelů na rozsah vhodný pro Blackwell (5090 throttle blízko 87 °C, RTX Pro 6000 blíže k 90 °C) a přidání panelu pro každý slot PCIe zobrazujícího DCGM_FI_DEV_PCIE_LINK_GEN a DCGM_FI_DEV_PCIE_LINK_WIDTH takže na první pohled vidíte, zda se výška popruhu snížila z x16 na x8.

Loki — protokoly, které vysvětlují, co ukazují metriky

Metriky vám řeknou, co se změnilo; logy vám řeknou proč . Loki je databáze logů Grafany; Promtail je odesílatel, který sleduje soubory a odesílá je. Nasměrujte Promtail na:

• /var/log/syslog a journalctl -k — zprávy OOM jádra, stížnosti na ovladače NVIDIA, výpisy XID
• /var/log/nvidia-installer.log — stav instalace ovladače
• Standardní výstup kontejneru vLLM (prostřednictvím ovladače protokolu Docker JSON)
• Protokoly aplikací z čehokoli, co zákazník spouští

Jediný dotaz s nejvyšší hodnotou na kartě Prozkoumat v Grafaně je:

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

Toto zobrazí všechny zprávy ovladače NVIDIA v bufferu kernel ring – chyby XID, selhání ventilátoru, události výpadku sběrnice, časové limity GSP RPC. Spárujte to s DCGM_FI_DEV_XID_ERRORS Výstraha Prometheus a máte strukturovanou metriku i nestrukturované podrobnosti v jednom panelu.

Standardně neodesíláme logy mimo hostitelský server. Loki je uchovává lokálně s 30denní retencí; SSH tunely se v případě potřeby odesílají do Grafany. Zákazníci, kteří chtějí centralizované logy napříč více servery, mohou Loki nasměrovat na S3 nebo spustit regionální instanci – to je otázka nasazení, nikoli architektury.

Metriky vLLM a SGLang – instrumentujte aplikaci, nejen kov

DCGM vám oznámí, že GPU je zaneprázdněné. Neřekne vám, zda se požadavky na inferenci vrátí za 200 ms nebo 2 s. Pro to se používá obslužná vrstva.

vLLM odhaluje /metrics nativně na stejném portu jako OpenAI API. S výchozím nastavením je koncový bod na adrese :8000/metrics publikuje metriky Prometheus s vllm: předpona (která se stává vllm_ (po Prometheově škrábání). Ty, které stojí za to škrábat:

Kombinace vllm:num_requests_waiting > 0 a DCGM_FI_DEV_GPU_UTIL < 90% znamená, že se fronta zálohuje, když je GPU nečinná – obvykle se jedná o úzké hrdlo tokenizátoru nebo plánovače, nikoli o úzké hrdlo výpočetní kapacity. To se projeví pouze u obou metrik na stejném dashboardu, což je smyslem sjednocení telemetrie aplikací a hardwaru v jednom Prometheu.

NVIDIA NIM zpřístupňuje stejné metriky vLLM pod /v1/metrics bez přejmenování, takže vaše stávající dashboardy vLLM a pravidla upozornění se beze změny přenesou do nasazení obsluhovaného NIM. SGLang publikuje podobnou sadu na svém vlastním portu (výchozí 30000); HTTP server llama.cpp zpřístupňuje menší podmnožinu. Triton publikuje vlastní taxonomii. Ať už obsluhujete cokoli, scrapujte aplikaci – nejen hardware.

Pravidla Alertmanageru – ta, která skutečně dodáváme

Dashboardy jsou hezké. Upozornění jsou užitečná. Níže uvedená pravidla odhalují skutečné problémy na reálném hardwaru zákazníků.

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:

• Pro teplotu grafického procesoru je kritických 87 °C. 5090 se na většině desek otáčí kolem 80 °C. Pokud vaše místnost nedokáže udržet kartu pod 80 °C při trvalém zatížení, máte problém s vytápěním, větráním a klimatizací, nikoli se softwarem.
• Jakékoli neopravitelné ECC vyvolává pohotovostní zařízení. Jediná dvoubitová ECC událost zneplatní cokoli, co bylo na dané stránce VRAM – trénovací krok je chybný, výsledek inference je chybný. Karta potřebuje výměnu, ne restart.
• GPUIdleDuringWork je detektor deadlocku. > 1 GiB alokováno a < 5% využití po dobu 10 minut znamená, že se něco zaseklo. Zachycuje zamrznutí na straně CUDA, která aplikace s radostí ignoruje.
• OOM killer alert je nejčastěji opomíjené pravidlo v jakémkoli nasazení. Linux tiše zabíjí vaši tréninkovou úlohu a Docker ji čistě restartuje. ο poruchový režim, který ročně ztrácí nejvíce hodin inženýrů. Udělejte to hlasitě.
• Smyčka restartu kontejneru zachycuje cykly restartu NIM a vLLM. které zvenku vypadají v pořádku (kontejner „běží“), ale ve skutečnosti se při každém načtení modelu hroutí.

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

DCGM se zastaví u GPU. node_exporter se zastaví u OS. Zbytek šasi – ventilátory, zdroje, okolní teplota, stav úložiště – potřebuje další dva exportéry.

ipmi_exporter (prometheus-community) komunikuje s BMC přes IPMI/RMCP a zobrazuje telemetrii na úrovni šasi: otáčky ventilátoru, vstupní napětí a proud zdroje, položky v protokolu systémových událostí, okolní vstupní teplota, stav watchdogu BMC. Na šasi Supermicro nebo Bone64c s funkčním BMC je to půl dne práce a zachycuje věci, které DCGM doslova nevidí – vadný zdroj na sestavě s dvěma zdroji a 8 GPU se projeví jako pokles napětí v datech senzoru IPMI několik minut předtím, než GPU přejde na XID 79. Spusťte jej na hostiteli (potřebuje /dev/ipmi0) nebo vzdáleně s uloženými přihlašovacími údaji BMC pomocí vzoru exportéru pro více cílů.

smartctl_exporter (nebo starší smart_exporter) čte atributy NVMe a SATA SMART: indikátor opotřebení média, dostupné rezervní disky, teplotu, počet chyb. Zátěžová zátěž umělé inteligence je na NVMe brutální – zavaděče datových sad, zápisy kontrolních bodů a mezipaměti HuggingFace posouvají cílové hodnoty opotřebení podniků na spotřebitelských discích o měsíce. Metrika, na kterou je třeba upozornit, je nvme_available_spare klesá pod 20 % a nvme_percentage_used (indikátor opotřebení) stoupá nad 80 %. Selhání disku je druhou nejčastější hardwarovou chybou na vytíženém serveru s umělou inteligencí po závadách rozšiřujícího zdroje/záložního zdroje.

Kompletní nasazení monitorování Kentino s umělou inteligencí zahrnuje obojí. Mezní náklady jsou minuty; hodnota při prvním tichém výpadku ventilátoru nebo dosažení maximální hodnoty DWPD procesoru Samsung 990 Pro jsou hodiny.

Skutečný Docker-Compose pro virtuální stroj MGM

Co vlastně nasazujeme na management boxu. Úprava host.docker.internal (nebo použijte název hostitele/IP adresu GPU serveru) k nasměrování Prometheusu na exportní porty hostitele GPU.

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 hostiteli GPU (samostatné psaní zpráv na serveru GPU):

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

Konfigurace scrape Prometheus na virtuálním počítači mgmt:

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 pracovní stack pro laboratoř s jedním až třemi servery. Po čtyřech nebo pěti serverech přepněte konfiguraci scrape Prometheus na zjišťování služeb na základě souborů nebo – pokud používáte Kubernetes – na dodávaný Helm graf DCGM-exporter od GPU Operator a Prometheus Operator. ServiceMonitor CRD (Centrum distribuce).

OpenTelemetry, Pixie, eBPF — obrázek z roku 2026

Poznámka k pohyblivým dílkům, protože otázka se vždycky objeví.

OpenTelemetry je standard CNCF pro instrumentaci pozorovatelnosti a od začátku roku 2026 jsou všechny tři typy signálů (metriky, trasování, protokoly) stabilní. Pipeline OTel Collector nahrazuje v mnoha organizacích agenty specifické pro dodavatele jako univerzální telemetrický router. Pro server s umělou inteligencí je pragmatickou odpovědí v roce 2026: ponechat Prometheus pro metriky (DCGM-exporter a node_exporter nativně mluví Prometheus a vaše pravidla upozornění jsou v PromQL) a přidat OTel Collector, pokud a kdy potřebujete distribuované trasování napříč grafem obsluhujícím inferenci (požadavek → API brána → vLLM → volání nástroje → vektorová databáze → odpověď). Pro instalaci na jednom serveru s jedním modelem za nginx OTel zvyšuje náklady bez hodnoty. 71 % organizací, které „používají oba“, používá Prometheus pro kovy a OTel pro trasování aplikací – rozumné rozdělení.

Skřítek je nástroj pro sledování nativní na Kubernetes, který využívá eBPF ke shromažďování metrik, trasování a protokolů na úrovni jádra bez změn kódu. Vývoj, který stojí za to sledovat v roce 2026, je práce na eBPF na GPU (bpftime, eGPU, otevřené moduly jádra NVIDIA), které rozšiřují instrumentaci eBPF do jader GPU pomocí běhové PTX injekce. Toto je dnes na výzkumné úrovni a není součástí žádného produkčního balíčku, který dodáváme. Prozatím je podporovaným řešením DCGM.

Kontinuální profilování (Grafana Phlare, Pyroscope) je třetím doplňkem, o kterém stojí za to vědět. U inferenčních úloh, kde ovládáte kód frameworku (vlastní záplaty vLLM, optimalizace tokenizátoru), vám říká, které funkce zatěžují CPU. Pro čisté obsluhování modelů se skladovými kontejnery je to zbytečné.

Co se porouchá (monitorovací vydání)

Předvídatelné režimy selhání samotného zásobníku, seřazené podle četnosti selhání:

• Prométheův disk se zaplní. Výchozí doba uchování je 15 dní; my jsme nastavili 30 dní se stropem 20 GB. Po více než 60 dnech na vytíženém serveru počítejte s desítkami GB. Nastavte dobu uchování podle času i velikosti.
• DCGM-exporter ztrácí grafické karty po aktualizaci ovladače. Příznak: všechny panely GPU zhasnou. Oprava: restartujte kontejner; spusťte jej znovu nvidia-ctk runtime configure pokud se běhové prostředí posunulo.
• Správce upozornění není nakonfigurován pro přijímač, který skutečně používáte. Lidé se postaví proti Prometheovi a Grafaně, zapomenou ukázat Alertmanageru e-mail nebo Slack a o šest měsíců později zjistí, že se žádné upozornění nikdy nespustilo. Otestujte to úmyslným spuštěním. GPUTempCritical se stresovou pracovní zátěží nebo použití amtool alert add spustit syntetický výstražný signál hned první den.
• Exploze kardinality z popisků na požadavek. Neoznačujte metriky vLLM pomocí user_id or request_idPrometheus k tomu není určen – databázi budete OOM.
• Únik hesla Grafana přes prostředí pro psaní. Používejte tajné kódy Dockeru, ne GF_SECURITY_ADMIN_PASSWORD v bloku prostředí. docker inspect a protokoly úniku hodnot prostředí.
• Ukazatel XID, který se neresetuje. Jak již bylo uvedeno, ukazatel XID exportéru DCGM se po zotavení může zaseknout na poslední zjištěné hodnotě. Zkombinujte metriku s Lokiho... NVRM: syslog tail, aby se předešlo falešné důvěře.

Upřímný pohled

Většina laboratoří nainstaluje Grafanu jednou, vytvoří dashboard, který tým obdivuje týden, a už se na něj nikdy nepodívá. Dashboard je uspokojivý artefakt; není to to, co zachycuje vaše problémy. Upozornění jsou to, co vaše problémy zachycuje. Nastavte Alertmanager se skutečným přijímačem (e-mail, Slack, PagerDuty) a malou sadou vysoce přesných pravidel – teplota GPU, ECC double-bit, XID, OOM killer, smyčka restartu kontejneru – a laďte je, dokud se nebudou spouštět pouze tehdy, když je něco skutečně špatně. Udělejte to jako první. Pak vytvořte dashboardy pro ladění po incidentu.

Druhá polovina upřímného závěru: v měřítku Kentina s jedním serverem dostanete z tohoto zásobníku upozornění asi jednou za měsíc a většinou se jedná o falešně pozitivní výsledek, který si ignorujete. Tak systém funguje. Hodnota spočívá v upozornění, které se spustí v den, kdy se rozšiřující karta začne ohřívat, dva dny předtím, než karta dosáhne XID 79, kdy je ještě čas znovu zapojit kabel namísto RMA GPU. Tato jediná událost zaplatí za veškeré monitorovací úsilí a mnohonásobně se to vyplatí.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy vítány na adrese info@kentino.com.