Sådan konfigureres Node Exporter korrekt: Praktisk vejledning til overvågning af Prometheus-servere på Linux

At konfigurere Node Exporter korrekt betyder, at jeg indstiller tjenesten, så Prometheus indsamler pålidelige Linux-servermetrikker med klare porte, målrettede Collector-indstillinger og ordentlig sikkerhed. I denne praktiske vejledning gennemgår jeg installation, systemd-opsætning, finjustering af collectorer, sikkerhed, Prometheus-integration, tips til at optimere ydeevnen og nyttige tjek til den daglige drift.

Centrale punkter

• Installation og opstart af tjenesten med egen systemd-enhed
• Collector vælge målrettet, reducere metrikbelastningen
• Sikkerhed ved hjælp af portåbninger og proxy
• Prometheus Scrapes, alarmer og opbevaring
• Ydelse via intervaller, sharding, oprydning

Hvad er Node Exporter?

Jeg indstillede Knudepunkt Installer Exporter på hver Linux-host for at levere systemmetrikker i Prometheus-format. Daemonen leverer data om CPU-belastning, systembelastning, RAM, swap, filsystemer, netværk samt – valgfrit – systemd- og procesdata. Jeg får adgang til endepunktet via HTTP /metrics og ser overskuelige tidsserier, som Prometheus henter cyklisk. Denne tilgang passer til heterogene serverflåder og forbliver gennemsigtig takket være pull-modellen. Jeg drager fordel af en klar opdeling: Eksportøren indsamler, Prometheus gemmer og analyserer.

Arkitekturoversigt: Sådan fungerer Node Exporter og Prometheus sammen

Jeg starter eksportprogrammet på port 9100, styrer jeg Collector og lader Prometheus hente data med jævne mellemrum. Pull-princippet gør det lettere at håndtere firewalls, fordi jeg kun åbner adgangen fra Prometheus til værten. Grafana eller lignende visualiseringsløsninger bygger derefter videre på Prometheus og viser værdierne overskueligt. I produktive miljøer driver jeg flere Prometheus-servere til adskilte ansvarsområder. På den måde holder jeg stierne korte, rollerne klare og administrationen overskuelig.

Installation under Linux: præcis og gentagelig

Jeg downloader den relevante binærfil til linux-amd64 eller målarkitekturen, og tilføj den efter /usr/local/bin/. Derefter opretter jeg en systembruger uden login, for eksempel node_exporter, og tildel ejendomsrettigheder til den binære fil. For at sikre automatisk opstart opretter jeg en systemd-enhed i mappen /etc/systemd/system/ med en simpel ExecStart og en Restart-Policy. Efter systemctl daemon-reload Jeg aktiverer og starter tjenesten, kontrollerer status og åbner curl http://localhost:9100/metrics således. På den måde kan jeg straks se, om målingerne er korrekte, og om tjenesten fungerer som den skal.

Node Exporter som systemd-tjeneste: de vigtigste indstillinger

Jeg definerer i enheden Bruger og Group som dedikeret konto, indstil Type=simple og en tydelig ExecStart. En genstartsstrategi som Genstart=ved fejl hjælper mod kortvarige udfald. Når jeg opdaterer, redigerer jeg enheden eller opretter en drop-in-fil, så ændringerne forbliver overskuelige. Efter hver tilpasning udfører jeg en daemon-reload og genstart tjenesten. Jeg sørger for, at enheden er kompakt, dokumenteret og genanvendelig for alle serverklasser.

Port og listeadresse: konsekvent og sikkert

Som standard lytter jeg på port 9100, men ændr porten afhængigt af projektet, hvis der er konflikter. Indstillingen --web.listen-address giver mulighed for at tilpasse værtsnavn og port, f.eks. 127.0.0.1:9200 ved lokal proxy-offloading. Et ensartet portskema mindsker forvirring i store teams. Jeg registrerer portændringer centralt, så firewalls og sikkerhedslister stemmer overens. Porten forbliver begrænset til Prometheus-serverne og har ikke fri adgang til internettet.

Konfigurer Collector målrettet: kun det, der virkelig tæller

Jeg vælger Collector bevidst for at styre datamængden og beregningstiden. Standardmoduler til CPU, hukommelse, filsystemer og netværk forbliver som regel aktive. Hvis det er nødvendigt, aktiverer jeg specielle moduler som --collector.systemd eller --collector.processes, for at kunne overvåge tjenester og processer mere nøje. Uønskede moduler deaktiverer jeg med --no-collector.X, så Prometheus skal behandle færre tidsserier. Jeg dokumenterer det valgte for hver serverrolle, så teamet arbejder ensartet.

Textfile Collector: Indlæsning af egne måleværdier uden fejl

Jeg bruger Textfile Collector til enkeltperson Nøgletal, som standardmodulerne ikke leverer. En oversigt som /var/lib/node_exporter/textfile_collector indsamler .prom-filer i Prometheus-format. Skripterne skriver atomart ved at oprette midlertidige filer og erstatte dem til sidst, så der ikke vises halvfærdige værdier. På den måde overfører jeg forretningsstatistikker, batch-status eller kø-længder direkte til Prometheus. Jeg overholder navnekonventioner for at gøre analyser og dashboards overskuelige.

Sikkerhed i produktionsdriften: Adgang kun for autoriserede personer

Jeg begrænser portadgangen via Firewall konsekvent mod scrape-kilderne. En forudplaceret reverse proxy håndterer TLS eller mTLS efter behov og varetager autentificeringen. Jeg kører tjenesten uden root-rettigheder og tildeler minimale filrettigheder til log- og tekstfilstier. I adskilte netværk sikrer jeg desuden adgangen via VPN eller private undernetværk. På den måde forbliver detaljerede systemoplysninger beskyttet og er kun synlige for overvågningsinfrastrukturen.

Integration i Prometheus: Scrapes, labels, alarmer

Jeg lægger i den prometheus.yml et job som job_name: node til, indsæt et meningsfuldt scrape_interval (ofte 15 sek.) og indtaster mål eller serviceopdagelse. Ensartede etiketter (f.eks. miljø, rolle, placering) gør det nemmere at oprette filtre og dashboards. Til hyppige analyser definerer jeg optagelsesregler og aflaster dermed ad hoc-forespørgsler. Alarmer udløses på baggrund af aggregerede målinger, f.eks. for CPU-belastning, RAM, swap, diskplads og netværksfejl. For at få et overblik over udnyttelse og belastningsspidser henviser jeg til min kompakte CPU- og belastningsanalyse, der forklarer de typiske nøgletal på en praktisk måde.

Overvågning af Node Exporter selv: Tillid er godt, kontrol er bedre

Jeg observerer den Jobstatus i Prometheus og indstiller alarmer, der udløses, hvis en host ikke er blevet scrappet i længere tid. Jeg tjekker regelmæssigt eksportørernes versioner for hurtigt at kunne udnytte fejlrettelser og nye moduler. Derudover måler jeg antallet af tidsserier pr. host for tidligt at opdage, hvis en ændring i collectoren øger belastningen. Dashboards får panelmeddelelser om den seneste vellykkede hentning. På den måde opdager jeg forstyrrelser hurtigt og reagerer uden omveje.

Ydelsesoptimering og skalering: Hold styr på belastningen

Jeg kontrollerer Intervaller afhængigt af miljøets størrelse og formål: 15 sekunder for kernesystemer, 30–60 sekunder for mindre kritiske servere. Ved selektivt at vælge collectorer reducerer jeg antallet af metrics og forespørgselstiderne. Jeg holder mine egne tekstfil-metrikker slanke, sletter gamle data og navngiver dem konsekvent. Hvis flåden vokser kraftigt, fordeler jeg belastningen på flere Prometheus-instanser og adskiller ansvarsområderne. Den følgende tabel viser gennemprøvede justeringsmuligheder og deres effekt i driften.

Emne	Indstilling	Effekt	Hint
Scrape-interval	15 sek. / 30 sek. / 60 sek.	Færre skrammer mindsker Belastning	Der skal tages højde for kritikalitet pr. værtsklasse
Collector-udvalg	kun de nødvendige moduler	Reducerer tidsserier	Dokumentere listen for hver rolle
Tekstfil-indsamler	kompakte .prom-filer	Mindre omkostninger til syntaksanalyse	Skriv præcist, formuler klart
Etikettkardinalitet	Kontroller etiketterne	Forhindrer Eksplosion i serierne	Undgå ID’er og meget variable værdier
Opdeling	Opdeling af Prometheus	Skalerer scrapes og forespørgsler	Adskille ansvarsområder

Når det gælder lagringssystemer, lægger jeg særlig vægt på IO-værdier og ventetider pr. enhed samt filsystem. Min vejledning er et godt udgangspunkt Overvågning af diskforsinkelser, der sammenfatter typiske symptomkæder og måleværdier. Jeg kobler disse værdier sammen med CPU-ventetid og -belastning for sikkert at kunne indkredse flaskehalse. Jeg indkapsler forespørgsler i optagelsesregler, så dashboards indlæses hurtigt. På den måde forbliver analyse og drift hurtig og overskuelig.

Visualisering med Grafana: få et klart overblik, handle hurtigt

Jeg bruger færdige dashboards til CPU, RAM, disk, netværk og systemd, men tilpasser dem til mine etiketter. Et oversigtsdashboard viser status, udnyttelse og mistænkelige værter, mens detaljesiderne går mere i dybden. Jeg beskriver panelerne kort, så alle forstår betydningen af nøgletallene. Variabelvælgere gør det hurtigere at skifte mellem værter eller roller. Hvis du ønsker et komplet overblik, finder du under Overvågningsstack med Grafana Vejledning i opbygning af en højtydende stack.

Overskuelig pakning og versionsstyring: bevar reproducerbarheden

Jeg sikrer, at installationerne kan gentages, ved eksplicit at fastlægge versioner og kontrollere kontrolsummer. Til flådeopsætninger pakker jeg Node Exporter som et internt pakkeformat (f.eks. DEB/RPM) med en fast stistruktur og en fast systembruger. Opdateringer ruller jeg ud trinvist og dokumenterer den anvendte version for hvert miljø. Hvor det er relevant, gemmer jeg startparametrene i en EnvironmentFile, så ændringer ikke foretages direkte i unit-filen, og så versioneringen forbliver overskuelig. Jeg tester først nye udgivelser i staging, før jeg distribuerer dem bredt.

Eksempel på konfiguration: systemd-unit og hardening

Jeg bruger en enkel, men pålidelig enhed og tilføjer om nødvendigt hærdningsindstillinger:

[Unit]
Description=Prometheus Node Exporter
After=network-online.target
Wants=network-online.target

[Service]
Bruger=node_exporter
Gruppe=node_exporter
ExecStart=/usr/local/bin/node_exporter \
  --web.listen-address=0.0.0.0:9100 \
  --collector.systemd \
  --collector.processes \
  --collector.filesystem.fs-types-exclude='^(tmpfs|devtmpfs|overlay|squashfs)$' \
  --collector.filesystem.mount-points-exclude='^/(sys|proc|dev|run)($|/)'
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

For produktive værter styrker jeg tjenesten yderligere uden at begrænse dens læserettigheder til /proc og /sys at bryde. Det skriver jeg som drop-in (/etc/systemd/system/node_exporter.service.d/hardening.conf) til:

[Service]
NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectSystem=strict
ProtectHome=true
ProtectControlGroups=true
ProtectKernelTunables=true
ProtectKernelModules=true
LockPersonality=true
MemoryDenyWriteExecute=true
CapabilityBoundingSet=
AmbientCapabilities=
RestrictNamespaces=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
SystemCallFilter=@system-service

Efter hver ændring: systemctl daemon-reload og en ren genstart. Til fejlfindingsformål aktiverer jeg midlertidigt et højere logniveau via --log.level=debug, for at se oplysninger om indsamling og parsering.

Collector-finjustering til praksismiljøer

Jeg finder en balance mellem synlighed og belastning ved hjælp af målrettede filtre:

• Filsystemer: Jeg udelukker pseudo-filsystemer og midlertidige monteringer (--collector.filesystem.fs-types-exclude og --collector.filesystem.mount-points-exclude), for at undgå meningsløse serier.
• Processer: --collector.processes giver nyttige summer, men genererer yderligere serier. Jeg aktiverer den kun på værter, hvor antallet af processer giver et signal (f.eks. batch- eller worker-knudepunkter).
• Netværk: Den netstat-Collector kan, afhængigt af kernen og forbindelserne, generere mange labels. Jeg tjekker kardinaliteten i Staging og slår den ellers målrettet fra.
• Tryk/PSI: Moderne kerner leverer trykmålinger (--collector.pressure, ofte aktiveret som standard). Jeg bruger dem til tidligt at opdage flaskehalse i CPU, IO og hukommelse.
• NVMe/RAID: Specifikke samlere (f.eks. nvme) aktiverer jeg kun der, hvor hardwaren er til stede – på den måde forbliver dashboards meningsfulde.

Jeg tester samlere selektivt via forespørgselsparameteren collect[], uden at ændre startparametrene. Et eksempel: curl 'http://localhost:9100/metrics?collect[]=systemd&collect[]=processes'. Så kan jeg straks se, hvilken indflydelse de enkelte samlere har.

Textfile Collector: Bedste praksis fra driften

Jeg skriver metrikker atomart: Skripter genererer først .tmp-filer og erstatter dem til sidst med mv. Hver fil indeholder kun én logisk gruppe og er højst et par kilobyte stor. Jeg overlader håndteringen af tidsstempler til Prometheus; selve filerne behøver ingen tidsstempler. Hvis jeg sletter en .prom-filen, forsvinder de tilhørende serier efter den næste scrape. Jeg dokumenterer navneområder (f.eks. business_*) og holder labelværdierne stabile for at kontrollere kardinaliteten. Hvor værdierne svinger meget, udjævner jeg dem allerede i scripts (f.eks. ved at beregne et gennemsnit), så dashboards kører mere stabilt.

Sikkerhed: Firewall- og proxy-varianter

Jeg satser først og fremmest på netværkssegmentering: Eksportprogrammet lytter kun internt, og firewallen tillader udelukkende Prometheus-IP-adresserne. Et eksempel med nftables på en host:

table inet filter {
  chain input {
    type filter hook input priority 0;
    ct state established,related accept
    iif lo accept
    tcp dport 9100 ip saddr { 10.0.0.10, 10.0.0.11 } accept
    tcp dport 9100 drop
  }
}

Når der er behov for kryptering, sætter jeg en lokal reverse proxy foran, som håndterer TLS eller mTLS og kun til 127.0.0.1:9100 videresender. Alternativt bruger jeg – forudsat at versionen understøtter det – eksportørens indbyggede webkonfiguration via en --web.config.fil, så autentificering og certifikater fortsat administreres centralt. Tjenesten kører som udgangspunkt uden privilegier, med minimale rettigheder til sit eget bibliotek og skriver kun der, hvor det virkelig er nødvendigt (f.eks. stien til tekstfiler).

Prometheus-integration i detaljer: Omdøbning, grænseværdier, alarmer

Jeg holder jobbeskrivelser korte og ensartede. En praktisk jobbeskrivelse med grænser og opdatering af etiketter ser sådan ud:

scrape_configs:
- job_name: node
  scrape_interval: 30s
  scrape_timeout: 10s
  sample_limit: 10000
  static_configs:
  - targets: ['host1:9100','host2:9100']
    labels:
 env: prod
 role: web
  relabel_configs:
  - source_labels: [__address__]
    target_label: instance
    regex: '([^:]+)(?::\d+)?'
    replacement: '$1'
  metric_relabel_configs:
  - source_labels: [device]
    regex: '^(ram|loop|zram|dm-).*'
    action: drop

Med metric_relabel_configs Jeg mindsker kardinaliteten ved at frasortere enheder, der ikke giver meget information. Til alarmer bruger jeg enkle, men robuste regler:

grupper:
- navn: node_basic
  regler:
  - alarm: NodeDown
    udtryk: up{job="node"} == 0
    i: 5m
    mærker: {alvorlighed: kritisk}
  - alert: HighCPU
    expr: 1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) > 0,9
    for: 10m
    labels: {severity: warning}

Til overvågning af belastningen bruger jeg scrape_duration_seconds og scrape_samples_scraped pr. mål. På den måde kan jeg se, hvis en ekstra aktiveret samler øger afhentningstiden eller serienummeret uforholdsmæssigt meget.

Drift i containere og Kubernetes

Jeg installerer Node Exporter i containere tæt på værten, så /proc og /sys forbliver synlige fra værten. Til det formål monterer jeg disse stier som skrivebeskyttede i containeren og bruger hostNetwork for ensartede porte. I Kubernetes kører jeg eksportøren som et DaemonSet pr. node og holder sikkerhedskonteksterne restriktive (ingen unødvendige privilegier). Jeg tager højde for Cgroup-v2-miljøer, når jeg vælger collector; vigtige collectorer som meminfo, tryk, filsystem og CPU forbliver grundlaget. Jeg kontrollerer efter implementeringer med en direkte krølle mod pod’en for at kontrollere, om de forventede hostmetrik-stier virkelig læses.

Fejlfinding og kvalitetssikring

• Forbindelse: Jeg tjekker curl -s http://localhost:9100/metrics | head på målværten og, set fra Prometheus’ synspunkt, tilgængeligheden via den åbne port.
• Samlertest: Om collect[] testede jeg de enkelte collectorer uden at ændre den globale konfiguration.
• Logs: Jeg hæver logniveauet midlertidigt (--log.level=debug), for at undgå parsefejl eller rettighedsproblemer ved /proc//sys synlig.
• Versionsstyring: Med node_exporter_build_info sammenligner jeg versioner og planlægger opgraderinger målrettet.
• Serier i fokus: Metrikken scrape_samples_scraped{job="node"} Jeg bruger dette som et omtrentligt tal for antallet af serier pr. vært. Et spring opad tyder på nye samlere eller en eksplosion i antallet af etiketter.
• Timeouts: Jeg holder scrape_timeout under scrape_interval og observer scrape_timeout_seconds, for at opdage flaskehalse i god tid.

Kapacitet og opbevaring: Planlægning frem for overraskelser

Jeg indstiller datalagringen i Prometheus efter anvendelsesscenarie: korte intervaller for kernesystemer, længere lagring for tendenser. Når flåden vokser, skalerer jeg horisontalt ved hjælp af sharding (f.eks. efter lokation eller team) og adskiller query- og ingest-belastningen. Ved behov skriver jeg desuden målinger til en langtidskomponent via Remote-Write. Jeg holder aktivt øje med kardinaliteten og rydder konsekvent op i ubrugte målinger eller labels – især når det gælder målinger fra tekstfiler, som hurtigt kan vokse i omfang.

Praktiske råd til heterogene vognparker

• IPv6-only-værter: Jeg er med [::]:9100 og sørg for, at der er passende firewall-regler.
• Speciel hardware: Jeg aktiverer kun hardwarespecifikke collectorer, hvor det giver mening, og dokumenterer forskellene i rolleprofilerne.
• Løbende opdateringer: Jeg opdaterer i batcher og holder øje med det undervejs op, scrape_duration_seconds og scrape_samples_scraped, for straks at kunne opdage regressioner.
• Dokumentation: Jeg noterer de faktiske startparametre for hver rolle. Det sparer diskussioner og gør fejlanalyser nemmere.

Kort sagt: min køreplan for praksis

Jeg installerer den Knudepunkt Jeg eksporterer som en separat systemd-tjeneste, angiver port og lytteadresse og sikrer adgangen strengt. Jeg vælger bevidst samlerne, tilføjer de nødvendige værdier via tekstfilsamleren og holder antallet af målinger lavt. I Prometheus indstiller jeg fornuftige intervaller, vedligeholder labels, definerer registreringsregler og alarmer for CPU, RAM, diske og netværk. Jeg overvåger selv eksportøren, planlægger opdateringer og kontrollerer regelmæssigt antallet af serier pr. vært. Med en overskuelig visualisering reagerer jeg hurtigere, opdager tendenser tidligt og sikrer, at min overvågning af Linux-serverne fungerer pålideligt i hverdagen.