Overvågningsstak: Prometheus, Grafana, DCGM, Loki til AI-servere

En AI-server, som ingen holder øje med, er en server, der lydløst drosler, lækker VRAM, akkumulerer ECC-fejl eller bliver OOM-dræbt klokken 03:00 – og man finder ud af det tre dage senere, når nogen spørger, hvorfor deres finjustering producerede noget vrøvl. De fleste af de værste fejltilstande på en GPU-boks er usynlige fra applikationen: termisk drossel logger ikke til stderr, ECC-korrektioner får ikke noget til at gå ned med det samme, OOM-dræberen æder en proces, og orkestratoren genstarter den uden problemer. Uden metrikker på selve hardwaren ser man ikke noget af dette, før det allerede har kostet en uge.

Standard sysadmin-værktøjssættet (htop, df, uptime, syslog) dækker det ikke. GPU'en er den dyreste komponent i kabinettet og den mest fejlbehæftede, og den har sin egen telemetristak, der kræver eksplicit installation. Denne artikel er den velfunderede version af den stak - Prometheus, Grafana, DCGM-exporter, node_exporter, Loki og Alertmanager - pakket som en enkelt docker-compose-implementering, vi kører på alle Kentino AI-servere, vi leverer.

Publikummet er en person, der står oprejst med en 4-GPU eller 8-GPU AI-server, som kan skrive en docker-compose-fil og ønsker svaret på "hvad skal jeg egentlig overvåge, og ved hvilken tærskel skal jeg alarmere?".

Standardstakken i 2026

Fem komponenter klarer næsten alt arbejdet. Alt andet er en bolt-on.

I alt godt under 0.5% af én CPU-kerne på en 96-core EPYC og cirka 700 MB RAM. På en 256 GB / 8-GPU server er dette en afrundingsfejl. Argumentet "overvågning stjæler cyklusser fra træning" holdt op med at være sandt omkring 2019.

Den ene arkitektoniske beslutning, der er værd at træffe på forhånd: kør stakken på en separat administrations-VM eller en lille boks, ikke på selve GPU-serveren. En dedikeret mini-PC, en NUC, en EPYC-servicenode eller en VM på laboratoriets hypervisor - alt, der ikke er GPU-boksen. To grunde: Når GPU-serveren går ned (kernelpanik på grund af out-of-memory, PSU-trip, termisk nedlukning), ønsker du stadig, at metrics-historikken diagnosticerer, hvad der skete, og du ønsker ikke et løbsk træningsjob, der konkurrerer med Prometheus om hukommelse og udløser sin egen alarm. DCGM-exporter og node_exporter kører på GPU-værten (de skal - de læser lokale enheder); Prometheus, Grafana, Loki og Alertmanager kører på administrations-VM'en og scraper indad.

DCGM-eksportør — den ene ting du ikke kan springe over

NVIDIAs Data Center GPU Manager (DCGM) er den understøttede, autoritative kilde til GPU-telemetri. dcgm-exporter Containeren eksponerer DCGM-metrikker i Prometheus-format på port 9400. Det er den vigtigste komponent i stakken, og det er det, der nvidia-smi afstemninger vil aldrig erstatte.

Installer via NGC-containeren (nvcr.io/nvidia/k8s/dcgm-exporter, i øjeblikket 4.x fra midten af ​​2026) eller upstream Helm-diagrammet for Kubernetes. På bare Docker, en docker run --gpus all --rm er nok; dæmonen udgiver derefter ~80 metrikker på :9400/metricsDem der rent faktisk betyder noget, rangeret efter hvor ofte de opdager reelle problemer:

Gasspjældstællerne er den afgørende funktion. DCGM_FI_DEV_THERMAL_VIOLATION er en monotonisk tæller på nanosekunder, som GPU'en brugte på at drosle. Beregn dens hastighed over et 5-minutters vindue, og du har et præcist svar på "er min server termisk begrænset lige nu?". Uden den gætter du udelukkende ud fra temperaturen, hvilket er en løgn - en 4090 vil drosle ved 83 °C ved en vedvarende arbejdsbelastning, uanset hvad temperaturpanelet viser.

To kendte DCGM-eksportør-særheder, der er værd at kende i 2026: nogle XID-koder (især XID 62) dukker ikke altid op gennem DCGM_FI_DEV_XID_ERRORS, og metrikken er en målestok for sidste XID set — så det kan mislykkes at nulstille efter en gendannelse uden at genstarte eksportøren. Afhjælpningen er at også se kernel-ringbufferen via Loki for den bogstavelige NVRM: Xid snor (mere om det nedenfor). Bælte og seler.

For rene forbrugerkort (RTX 4090, 5090) er nogle DCGM-datacenterfunktioner delvise — MIG er ikke til stede, NVLink er fraværende på Blackwell-forbrugerdele, visse ECC-tællere returnerer nul. DCGM fungerer stadig og rapporterer, hvad der er eksponeret; det lette community-alternativ. nvidia_gpu_exporter (som skraber nvidia-smi) er en brugbar fallback, hvis du ikke ønsker DCGMs afhængighedskæde. For Pro 6000 Blackwell, L40 og L4 — alt i datacenter/pro-serien — skal du bruge DCGM, ikke wrapperen.

node_exporter — systemhalvdelen

GPU-målinger fortæller kun halvdelen af ​​historien. node_exporter dækker resten:

Fejltilstanden "system-RAM opbrugt, OOM-killer tager vLLM, container genstarter korrekt" registreres her, ikke af DCGM. Se node_memory_MemAvailable_bytes og alarm når det falder til under 5% af det samlede antal. På Linux aktiveres killer-funktionen som standard ved næsten 0%, men på det tidspunkt er din proces død.

Prometheus — konfiguration, fastholdelse, størrelsesjustering

Prometheus er tidsseriedatabasen og scrape-orkestratoren. Standardindstillingerne er rimelige; de ​​to indstillinger, der er værd at ændre på dag ét, er scrape-interval og retention.

Et scrape-interval på 15 sekunder er det rigtige udgangspunkt for en AI-server: hurtigt nok til at fange en termisk stigning, før den bliver en vedvarende hastighedsreduktion, langsomt nok til at tidsserieomkostningerne forbliver moderate. Standardværdien for opbevaring er 15 dage; 30 dage er et bedre tal i en build-guide-kontekst, hvor du kan sammenligne dagens adfærd med sidste måneds ændring i tuning.

Lagerbudget ved 15 s scrape, ~80 DCGM-metrikker × N GPU'er + ~400 node_exporter-metrikker + ~50 vLLM-metrikker: cirka 1.5-2 GB pr. uge, så 30 dage lander på 6-10 GB på en 8-GPU-boks. Indstil både retention efter tid og efter størrelse som et beskyttelsesrækværk:

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

Begge grænser udløser komprimering; den der rammes først vinder. En allokering på 100 GB giver dig over et år med plads uden at skulle tænke dig om.

Grafana dashboards — start med de præbyggede

Byg ikke dashboards fra bunden. Det har fællesskabet gjort.

Importer først 12239 og 1860. De dækker ~90% af det, du rent faktisk vil se på, og er blevet forfinet over årene. Byg først dine egne efter en måned, når du ved, hvilke paneler du rent faktisk åbner. De mindre ændringer, der er værd at foretage for Kentino AI-hardware, er: indstilling af GPU-temperaturtærskelpanelerne til Blackwell-passende intervaller (5090-gasspjæld nær 87 °C, RTX Pro 6000 tættere på 90 °C) og tilføjelse af et panel pr. PCIe-slot, der viser DCGM_FI_DEV_PCIE_LINK_GEN og DCGM_FI_DEV_PCIE_LINK_WIDTH så du med et hurtigt blik kan se, om en riser er faldet fra x16 til x8.

Loki — logfiler, der forklarer, hvad metrikkene viser

Målinger fortæller dig, hvad der er ændret; logfiler fortæller dig hvorfor . Loki er Grafanas logdatabase; Promtail er den afsender, der indsamler filer og sender dem. Ret Promtail mod:

• /var/log/syslog og journalctl -k — kernel OOM-meddelelser, klager over NVIDIA-drivere, XID-dumps
• /var/log/nvidia-installer.log — driverinstallationsstatus
• vLLM container stdout (via Docker JSON-logdriveren)
• Applikationslogfiler fra alt, hvad kunden kører

Den forespørgsel med den højeste værdi i Grafanas faneblad Udforsk er:

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

Dette viser alle NVIDIA-drivermeddelelser i kernel-ringbufferen — XID-fejl, blæserfejl, hændelser, der er gået af bussen, GSP RPC-timeouts. Par det med DCGM_FI_DEV_XID_ERRORS Prometheus-alarmen, og du har både den strukturerede metrik og den ustrukturerede detalje i én rude.

Vi sender ikke logs off-host som standard. Loki opbevarer dem lokalt med 30-dages opbevaring; on-call SSH-tunneler overføres til Grafana efter behov. Kunder, der ønsker centraliserede logs på tværs af flere servere, kan henvise Loki til S3 eller køre en regional instans – det er et implementeringsspørgsmål, ikke et arkitekturspørgsmål.

vLLM- og SGLang-målinger — instrumentér appen, ikke kun metallet

DCGM fortæller dig, at GPU'en er optaget. Den fortæller dig ikke, om inferensanmodninger returneres om 200 ms eller 2 s. Til det formål instrumenterer du serveringslaget.

vLLM-eksponeringer /metrics native på samme port som OpenAI API'en. Med standardindstillingerne er slutpunktet ved :8000/metrics udgiver Prometheus-målinger med vllm: præfiks (som bliver vllm_ efter Prometheus-skrab). Dem der er værd at skrabe:

Kombinationen vllm:num_requests_waiting > 0 og DCGM_FI_DEV_GPU_UTIL < 90% betyder, at køen sikkerhedskopieres, mens GPU'en er inaktiv – normalt en flaskehals i tokenizer- eller scheduler-tilstand, ikke en beregningstilstand. Det ser man kun med begge metrikker i det samme dashboard, hvilket er hele pointen med at forene app- og hardwaretelemetri i én Prometheus.

NVIDIA NIM eksponerer de samme vLLM-målinger under /v1/metrics uden at omdøbe dem, så dine eksisterende vLLM-dashboards og alarmregler overføres uændret til en NIM-serveret implementering. SGLang udgiver et lignende sæt på sin egen port (standard 30000); llama.cpps HTTP-server eksponerer et mindre delmængde. Triton udgiver sin egen taksonomi. Uanset hvad du serverer, skal du scrape applikationen - ikke kun hardwaren.

Alertmanager-regler — de regler, vi faktisk sender

Dashboards er flotte. Alarmer er nyttige. Reglerne nedenfor er dem, der har opdaget reelle problemer på rigtig kundehardware.

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 }

Meningsfulde opfordringer i disse regler:

• 87 °C er kritisk for GPU-temperaturen. En 5090 drosler ned i de høje 80'ere på de fleste bundkort. Hvis dit rum ikke kan holde kortene under 80 °C ved vedvarende belastning, har du et HVAC-problem, ikke et softwareproblem.
• Ethvert ukorrigerbart ECC kalder den tilgængelige vagt. En enkelt dobbelt-bit ECC-hændelse ugyldiggør det, der var på den VRAM-side — et træningstrin er forkert, et inferensresultat er forkert. Kortet skal udskiftes, ikke genstartes.
• GPUIdleDuringWork er deadlock-detektoren. > 1 GiB allokeret og < 5% utilgængeligt i 10 minutter betyder, at noget sidder fast. Opfanger CUDA-sidede hængninger, som applikationen ignorerer med glæde.
• OOM killer alert er den mest oversete regel i enhver implementering. Linux dræber stille og roligt dit træningsjob, og Docker genstarter det rent. og fejltilstand, der spilder flest ingeniørtimer om året. Gør det højlydt.
• Containergenstartsløkke fanger NIM- og vLLM-genstartscyklusser der ser sunde ud udefra (containeren "kører"), men som faktisk går ned ved hver modelindlæsning.

Kabinet og lagerplads — IPMI og SMART

DCGM stopper ved GPU'en. node_exporter stopper ved operativsystemet. Resten af ​​kabinettet - blæsere, strømforsyninger, omgivende temperatur, lagertilstand - har brug for to eksportører mere.

ipmi_exporter (prometheus-community) kommunikerer med BMC via IPMI/RMCP og viser telemetri på chassisniveau: omdrejninger pr. ventilator, PSU-indgangsspænding og -strøm, systemhændelseslogposter, omgivende indgangstemperatur, BMC watchdog-tilstand. På et Supermicro- eller Bone64c-chassis med en fungerende BMC er dette en halv arbejdsdag og fanger ting, som DCGM bogstaveligt talt ikke kan se — en defekt PSU på dual-PSU 8-GPU-buildet vises som et spændingsfald i ipmi-sensordataene minutter før en GPU springer til XID 79. Kør det på værten (det skal bruge /dev/ipmi0) eller eksternt med gemte BMC-legitimationsoplysninger ved hjælp af multi-target-eksportørmønsteret.

smartctl_exporter (eller den ældre smart_exporter) læser NVMe- og SATA SMART-attributter: indikator for slid på medier, tilgængelig reserve, temperatur, fejlantal. AI-arbejdsbelastninger er brutale på NVMe — datasætindlæsere, checkpoint-skrivninger og HuggingFace-cacher presser slidmål for virksomheder på flere måneder på drev i forbrugerklassen. Metrikken til at alarmere er nvme_available_spare falder til under 20% og nvme_percentage_used (slidindikatoren) stiger over 80 %. Drevfejl er den næstmest almindelige hardwarefejl på en travl AI-server efter riser/PSU-klassen.

En komplet Kentino AI-overvågningsimplementering inkluderer begge dele. Marginalomkostningerne er minutter; værdien første gang en ventilator fejler lydløst, eller en Samsung 990 Pro rammer sit DWPD-loft, er timer.

En rigtig docker-compose til administration af VM'en

Hvad vi rent faktisk implementerer på administrationsboksen. Juster host.docker.internal (eller brug GPU-serverens værtsnavn/IP) til at pege Prometheus mod GPU-værtens eksportørporte.

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 }

På selve GPU-værten (separat compose, på GPU-serveren):

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

Prometheus-scrapekonfigurationen på den virtuelle styringsmaskine:

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"]

Det er en fungerende stak til et laboratorium med én til tre servere. Skift Prometheus-scrapekonfigurationen til filbaseret serviceopdagelse, eller – hvis du bruger Kubernetes – til GPU-operatørens medfølgende DCGM-eksporter Helm-diagram og Prometheus-operatørens. ServiceMonitor CRD'er.

OpenTelemetry, Pixie, eBPF — billedet fra 2026

En bemærkning om de bevægelige dele, for spørgsmålet dukker altid op.

OpenTelemetry er CNCF-standarden for observerbarhedsinstrumentering, og fra starten af ​​2026 er alle tre signaltyper (metrikker, spor, logfiler) stabile. OTel Collector-pipelinen erstatter leverandørspecifikke agenter i mange organisationer som den universelle telemetri-router. For en AI-server er det pragmatiske svar i 2026: behold Prometheus til metrikker (DCGM-exporter og node_exporter bruger Prometheus som standard, og PromQL er det, dine alarmregler indeholder), og tilføj en OTel Collector, hvis og når du har brug for distribueret sporing på tværs af en inferensserverende graf (request → API gateway → vLLM → tool call → vector DB → response). For en enkeltserverinstallation med én model bag nginx tilføjer OTel omkostninger uden værdi. De 71% af organisationerne, der "bruger begge", bruger Prometheus til metallerne og OTel til app-spor - en fornuftig opdeling.

Pixie er et Kubernetes-native observationsværktøj, der bruger eBPF til at indsamle metrikker, spor og logs på kerneniveau uden kodeændringer. Den udvikling i 2026, der er værd at følge, er eBPF-on-GPU-arbejdet (bpftime, eGPU, NVIDIAs åbne kernemoduler), der udvider eBPF-instrumentering til GPU-kerner via runtime PTX-injektion. Dette er i dag på forskningsniveau og ikke en del af nogen af ​​de produktionsstak, vi leverer. For nuværende er DCGM det understøttede svar.

Kontinuerlig profilering (Grafana Phlare, Pyroscope) er en tredje tilføjelse, der er værd at kende til. For inferens-workloads, hvor du kontrollerer framework-koden (brugerdefinerede vLLM-patches, tokenizer-optimeringer), fortæller den dig, hvilke funktioner der bruger CPU'en. For ren modelservering med standardcontainere er det overkill.

Hvad går i stykker (overvågningsudgave)

Forudsigelige fejltilstande for selve stakken, rangeret efter hvor ofte de bider:

• Prometheus-disken fyldes op. Standardopbevaring er 15 dage; vi sætter 30 med et loft på 20 GB. Planlæg med ti GB i de sidste 60 dage på en travl boks. Indstil opbevaring efter både tid og størrelse.
• DCGM-eksportøren mister GPU'er efter en driveropgradering. Symptom: Alle GPU-paneler bliver tomme. Løsning: Genstart containeren; kør igen nvidia-ctk runtime configure hvis kørselstiden flyttede sig.
• Alertmanager er ikke konfigureret til den modtager, du rent faktisk bruger. Folk sætter sig op i Prometheus og Grafana, glemmer at pege Alertmanager på e-mail eller Slack og opdager seks måneder senere, at ingen alarm nogensinde er blevet udløst. Test ved bevidst at aktivere GPUTempCritical med en stressende arbejdsbyrde, eller brug amtool alert add at udløse en syntetisk alarm på dag ét.
• Kardinalitetseksplosion fra etiketter pr. anmodning. Mærk ikke vLLM-målinger med user_id or request_idPrometheus er ikke designet til det — du vil OOM-e databasen.
• Grafana-adgangskodelækage via compose-miljø. Brug Docker-hemmeligheder, ikke GF_SECURITY_ADMIN_PASSWORD i miljøblokken. docker inspect og logfiler lækker miljøværdier.
• XID-måler, der ikke nulstilles. Som nævnt kan DCGM-eksportørens XID-måler holde sig til den sidst observerede værdi efter gendannelse. Kombiner metrikken med Lokis NVRM: syslog-hale for at undgå falsk tillid.

Den ærlige holdning

De fleste laboratorier installerer Grafana én gang, bygger et dashboard, som teamet beundrer i en uge, og ser det aldrig igen. Dashboardet er et tilfredsstillende artefakt; det er ikke det, der fanger dine problemer. Alarmer er det, der fanger dine problemer. Opsæt Alertmanager med en rigtig modtager (e-mail, Slack, PagerDuty) og et lille sæt højpræcisionsregler - GPU-temperatur, ECC double-bit, XID, OOM killer, container restart loop - og finjuster dem, indtil de kun aktiveres, når noget rent faktisk er galt. Gør dette først. Byg derefter dashboards til fejlfindingshistorien efter hændelsen.

Den anden halvdel af den ærlige vinkel: på Kentino-skala med én server får du måske en alarm fra denne stak en gang om måneden, og de fleste måneder vil det være en falsk positiv, du fravælger. Det er systemet, der fungerer. Værdien er den alarm, der udløses den dag, en riser begynder at koge, to dage før kortet når XID 79, hvor der stadig er tid til at genindsætte et kabel i stedet for at RMA en GPU. Den ene hændelse betaler for hele overvågningsindsatsen, og den betaler for den mange gange.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.