Loki til central loghåndtering inden for hosting

Sørg for en klar adskillelse mellem Loki, Alloy og Grafana

Central logstyring starter ved de systemer, der genererer hændelser: Linux-værter, virtuelle servere, containere og applikationer. Det er her, der opstår f.eks. journalposter fra systemd, Nginx-adgangs- og fejllogfiler eller standardudskrifter fra Docker-containere. Grafana Alloy læser sådanne kilder, kan behandle dem inden afsendelse og videresender dem til Loki. Alloy fungerer dermed som dataindsamler, ikke som det centrale loglager.

Grafana Loki modtager logdataene, samler dem og gemmer dem til senere forespørgsler. Et objektslager kan i den forbindelse opbevare de gemte data. Grafana leverer ofte brugergrænsefladen til Explore, dashboards og alarmer, men hører teknisk set ikke til Loki selv. Denne adskillelse gør det lettere at fordele ansvaret for ændringer, nedbrud og adgangsrettigheder på en overskuelig måde.

I et lille eksempel på hosting læser Alloy på en VPS systemd-journalen samt Nginx-filer og containerlogfiler. Det sender de udvalgte linjer til Loki; en administrator gennemser dem derefter i Grafana i stedet for at skulle logge ind på hver enkelt host for at foretage en indledende fejlanalyse. Foran Loki bør en reverse proxy eller et identitetslag håndtere login, TLS, routing og eventuelt tildeling af klienter.

Den centrale aggregering forkorter søgevejene, men erstatter hverken årsagsanalysen eller driftsprocesserne. Beskyttelse af adgang skal fastlægge, hvem der må læse hvilke data; princippet om dataminimering afgør allerede inden afsendelsen, hvilke felter der skal fjernes. Også en plan for sikkerhedskopiering og gendannelse er en opgave, man selv skal varetage: Loki gør eksisterende logfiler tilgængelige, men garanterer ikke i sig selv deres beskyttelse, fuldstændighed eller lovmæssigt sikker opbevaring.

I praksis er Loki derfor først en fordel, når man har lavet en oversigt over kilderne: Hvilke logfiler er nyttige i driften og ved håndtering af hændelser, hvilke indeholder fortrolige oplysninger eller personoplysninger, og hvem har brug for adgang? Først disse svar bestemmer filtre, opbevaring og adgangsrettigheder. At centralisere alle Linux-logfiler uden forudgående gennemgang flytter blot følsomme oplysninger til et lager, der er lettere at søge i.

Forståelse af streams, labels og LogQL

Loki organiserer indgående linjer ikke primært som et fuldtekstindeks. Det samler dem på baggrund af klient-ID’et og deres mærkesæt til et Strøm sammen. Selve logdataene ligger komprimeret i chunks; indekset forbinder labelsæt med disse chunks. Ved en søgning indsnævrer Loki derfor først de relevante streams ved hjælp af labels og indlæser derefter de pågældende data for at filtrere eller parse dem yderligere.

Etiketter bør udtrykke en varig og overskuelig sammenhæng: for eksempel env, service og med stabile servere host. I container-miljøer kan det også være hensigtsmæssigt at anvende klynger, navneområder eller applikationer. Hver unik kombination udgør dog en strøm. Anmodnings-, bruger- og sporings-ID’er, skiftende container-ID’er eller klient-IP-adresser genererer et meget stort antal værdier og hører derfor normalt ikke hjemme i labels.

I tilfælde af sjældne detaljerede undersøgelser forbliver sådanne dynamiske oplysninger i loglinjen og analyseres først ved forespørgsel, f.eks. via JSON- eller Logfmt-parsing. Ofte anvendte kontekstdata med høj kardinalitet kan være mere egnede som strukturerede metadata. Det er afgørende at teste datamodellen på reelle kilder inden implementeringen, i stedet for at mærke alle tilgængelige felter ufiltreret.

En LogQL-forespørgsel, der udelukkende læser Nginx-fejl, kan se sådan ud. Den hører f.eks. hjemme i Grafana Explore eller LogCLI og forudsætter, at de valgte labels rent faktisk blev tildelt under indsamlingen.

{env="prod", service="nginx"} |= " 500 "

Selektoren foran pipelinen begrænser først til produktionsstrømme fra Nginx-tjenesten; først |= " 500 " Søg efter teksten. Kvaliteten af en forespørgsel afhænger dog af tidsperioden, logvolumenet, lagringsforsinkelser og etikettdesign. Loki kan derfor ikke love en fast svartid. Små tidsvinduer og præcise, stabile selektorer er et fornuftigt udgangspunkt for en trinvis undersøgelse.

Hvilken Loki-arkitektur passer til hosting?

Til en enkelt VPS, et laboratorium eller små logmængder er monolitisk drift Ofte er dette den mest overskuelige måde at komme i gang på: En Loki-proces samler de nødvendige komponenter. I dokumentationen angives denne tilstand til eksperimenter samt små læse- og skrivemængder på op til ca. 20 GB logfiler dagligt. Dette er en vejledning fra producenten til dette anvendelsesområde, ikke en kapacitetsgaranti for enhver lagrings-, forespørgsels- eller mærkningsstruktur.

Hvis tilgængelighedskravene stiger, uden at de enkelte Loki-roller skal skaleres målrettet, kan man overveje en monolitisk drift med høj tilgængelighed. Til meget store klynger eller Kubernetes-miljøer, hvor komponenterne skal skaleres separat, er microservices-tilstanden beregnet. Denne granularitet fjerner dog ikke behovet for planlægning: Den øger antallet af driftskomponenter og dermed også omfanget af diagnosticering og vedligeholdelse.

Simple Scalable Deployment-tilstanden er ikke en neutral mellemvej for nye beslutninger. Grafana har markeret SSD som forældet og annonceret, at den vil blive fjernet med Loki 4.0. Hvis man i dag skal opbygge et system, bør man derfor vurdere en monolitisk tilgang med passende tilgængelighed eller microservices ud fra det faktiske skaleringsbehov, i stedet for at planlægge en overgangsarkitektur på lang sigt.

Det er ikke kun de dagligt genererede gigabyte, der er afgørende for beslutningen. Også spidsbelastninger ved skrivning, antallet og kardinaliteten af strømmene, den nødvendige klientadskillelse, opbevaring samt teamets viden om Kubernetes og distribuerede komponenter er relevante faktorer. Projekter med globalt distribueret levering kræver under alle omstændigheder en klar afgrænsning mellem centrale driftstjenester og edge-komponenter; dette passer også godt sammen med artiklen om Webhosting til edge-rendering og decentral levering.

Start i det små, hvis logkilder, labels og adgang endnu ikke er fastlagt på en stabil måde. En arkitekturændring bør begrundes i observerede krav, f.eks. målrettet skalering eller højere tilgængelighed, og ikke i en generel forventning om fremtidig vækst. På den måde forbliver indsatsen for Loghåndtering i forhold til fordelene ved den centrale søgning og håndtering af hændelser.

Indsaml Linux-logfiler sikkert med Alloy

Inden opsætningen skal der laves en oversigt over kilderne: Hvilke logfiler er faktisk nyttige i driften og ved håndtering af hændelser? På en Linux-webserver er det ofte systemd-journalen, Nginx-adgangs- og fejllogfiler, PHP-FPM, SSH-hændelser og cron-jobs. Når der er tale om containere, kommer udskrifterne fra runtime og applikationsspecifikke logfiler oveni. Lige så vigtigt er det at foretage en forudgående kontrol af adgangskoder, API-nøgler, session-ID’er og personoplysninger; sådanne oplysninger må ikke videregives centralt uden nærmere gennemgang.

Ved nye installationer er Grafana Alloy Den understøttede metode til indsamling og videresendelse. Promtail bør ikke længere planlægges som standard til dette formål: Dets livscyklus udløb den 2. marts 2026, og dokumentationen henviser til Alloy eller en anden understøttet klient i forbindelse med migrationer og nye konfigurationer. En eksisterende Promtail-installation kræver derfor en planlagt migrering i stedet for en automatisk videreførelse.

Konfigurationsmønsteret er overskueligt: En kilde læser filer, journalen eller containerlogfiler; en valgfri behandling kan frasortere uønskede linjer eller bearbejde felter; derefter videregives loki.write dataene til Loki. Alloy leverer komponenter til blandt andet filer, systemd-journaler, Docker, Kubernetes, Syslog og Windows-hændelser. Valget af kilde afhænger af, hvor applikationen pålideligt sender sine hændelser.

En skabelon er endnu ikke en produktionsklar konfiguration. Filrettighederne skal kun give Alloy-processen den nødvendige læseadgang; adgang til logfiler, måladresse, certifikatvalidering, TLS, buffering ved netværksforstyrrelser og håndtering af nedbrud skal kontrolleres afhængigt af den enkelte installation. Adgangsdata og klientoplysninger hører ikke hjemme i fælles, distribuerede eksempelfiler. Start med få kilder, kontroller indhold og omfang, og udvid først derefter registreringen.

Filtrering på agenten mindsker hverken ansvaret for kilden eller erstatter et autorisationskoncept. Den forhindrer dog, at kendte debug-udskrifter eller klart identificerede fortrolige oplysninger overhovedet kommer ind i den centrale database. For fagligt nødvendigt indhold bør det være muligt at spore, hvilken tjeneste der sender det, hvem der senere må læse det, og hvor længe det er nødvendigt.

Mærkningskoncept og planlægning før lanceringen

En Mærkekoncept fastlægger, i hvilken stabil kontekst logfilerne kan findes. Til flere værter og miljøer egner sig f.eks. env, cluster, namespace, app, service og, hvis henvisningen er af varig karakter, et værtsnavn. Værdierne skal være begrænsede og forudsigelige. Hver enkelt mængde af forskellige labels udgør sin egen strøm; derfor har modellen direkte indflydelse på indlæsning, indeksering og efterfølgende forespørgsler.

Request-, trace- og bruger-ID’er, klient-IP-adresser samt dynamiske container-ID’er er derimod ikke egnede mærker. De genererer for mange forskellige værdier og dermed mange små strømme. Oplysninger med høj kardinalitet kan om nødvendigt medtages som strukturerede metadata. Ved en lejlighedsvis undersøgelse er det ofte mere fornuftigt først at hente logindholdet ved forespørgslen med json, logfmt, pattern eller regexp at parse.

Tabellen giver ikke en prognose for lagerpladsbehovet, men et grundlag for beslutningstagning. Især opbevaringsperioden er en del af planen, da den ikke kan udledes af logfilerne: Faglige opbevaringskrav, sikkerhedsbehov og sletningsregler kan afvige fra hinanden. Gendannelsesmuligheden er ligeledes et særskilt krav; automatisk sletning af udløbne logfiler erstatter ikke et backup- eller genopstartskoncept.

En brugbar første standard kan for eksempel være env, service og host anvendes til klassiske webservere; containerplatforme supplerer kun i så fald cluster og namespace, hvis disse virkelig udvælger dem under fejlsøgningen. Skemaet bør afstemmes med udviklere og driftsafdelingen. Efterfølgende, uensartede mærker gør det vanskeligt at sammenligne miljøer og gør den centrale søgning mindre pålidelig.

I planlægningen er det ikke kun det, der kan registreres teknisk, der tæller, men også ansvarsfordelingen. Et team bør have ansvaret for kilder og filtre, mens et andet team eventuelt skal stå for lagring og adgang. På den måde bliver det tydeligt, om et manglende felt i logformatet skal tilføjes, behandles som strukturerede metadata eller bevidst undlades at indsamle.

Sikre klienter og adgang på en ordentlig måde

Loki kan behandle logdata på en klient-specifik måde. Når klientadskillelse er aktiveret, forventer Loki følgende header for hver forespørgsel X-Scope-OrgID. Denne header er dog hverken en login-oplysning eller et bevis på autorisation: Ellers kunne en klient selv bestemme dens værdi. Loki indeholder ikke et komplet autentificeringslag; beskyttelse og tvungen tildeling skal finde sted før dette.

En sikker proces starter ved den pålidelige reverse proxy eller identitetslag. Efter en vellykket login identificerer dette lag den autoriserede organisation, tildeler klient-ID’et på serversiden, påtvinger TLS og videresender kun tilladte forespørgsler til Loki. Direkte Loki-endepunkter, der er tilgængelige fra nettet, ville omgå denne kontrol. Også skriveadgang fra agenter kræver en entydigt afgrænset identitet og en beskyttet overførselsvej.

Adgangsretningslinjerne fastlægger, hvem der må læse eller indtaste logfiler. De erstatter hverken filtrering af fortrolige oplysninger eller databeskyttelseskontrollen: Tokens, session-id’er og personoplysninger kan også udgøre et problem inden for en korrekt tildelt klient. Dataminimering skal derfor allerede finde sted ved kilden og under behandlingen, mens rettigheder begrænser den resterende mængde data efter opgaver og klienter.

I distribuerede hostingarkitekturer er det en fordel at betragte adgangspunktet som en separat sikkerhedsgrænse. Artiklen om decentral hosting og de arkitektoniske aspekter herved forklarer, hvorfor distribuerede komponenter ikke ophæver det centrale ansvar for identiteter og dataadgang. For Loki betyder det konkret: Hver videresendelse skal på en sporbar måde kunne henføres til en pålidelig instans og en fastlagt klientregel.

Regelmæssige kontroller bør derfor ikke kun omfatte dashboards. Kontroller, om proxyen afviser anonyme adgangsforespørgsler, om en foruddefineret klient-header kan overskrives af klienten, og om skrivekonti kun når de tilsigtede mål. Sådanne kontroller garanterer ikke fuldstændig sikkerhed, men afslører tidligt typiske sårbarheder mellem login, routing og loglagring.

Kontrolleret drift af opbevaring og lagring

Centrale logfiler bør ikke blot opbevares, så længe der er plads i objektslagringen. De Fastholdelse skal være i overensstemmelse med lovmæssige, kontraktmæssige og virksomhedsinterne opbevaringsforpligtelser – og ligeledes med det tidspunkt, hvor data ikke længere er til nytte for fejlanalysen. Uden aktiveret opbevaring opbevares logfiler, der sendes til Loki, ifølge dokumentationen på ubestemt tid. Dette kan medføre øgede omkostninger, risici for databeskyttelsen og et større omfang af en senere gendannelse.

I TSDB og BoltDB-Shipper håndterer Compactor de konfigurerede sletningsfrister. Den bør køre som en enkelt instans og have et permanent arbejdsbibliotek, så dens arbejde ikke går tabt ved en genstart. Objektlageret indeholder både log-chunks og indeksdata; dets udformning er derfor en del af driftskonceptet og ikke kun af kapacitetsplanlægningen.

Forskellige opbevaringsperioder for de enkelte logstrømme kan være hensigtsmæssige, f.eks. hvis sikkerhedshændelser skal opbevares længere end detaljerede debug-udskrifter. Sådanne strømrelaterede regler kræver en opbevaringsperiode på mindst 24 timer og fungerer udelukkende med label-selektorer. Indholdsbaserede filtre eller vilkårlige LogQL-udtryk er ikke beregnet til dette formål. Derfor skal mærkerne allerede pålideligt afspejle den faglige kontekst, inden opbevaringsreglerne bygger videre på dem.

Advarsel: En generel livscyklusregel, der gælder for hele storage-bucket’en, kan fjerne indeks- eller klyngestatusobjekter og forringe forespørgsler. Det er bedre at anvende en målrettet sletningsstrategi, der tager højde for Loki-opbevaringsperioder, lagringsklasser og separate buckets eller præfikser. Opbevaring erstatter desuden ikke en sikkerhedskopi: Den fastlægger den planlagte sletning af logdata, mens gendannelseskrav definerer, hvilke konfigurationer, adgangsveje og eventuelt lagringsdata der skal være tilgængelige efter et nedbrud.

Identificere fejlbølger og kontrollere optagelsesproblemer

I Grafana Explore kan man undersøge hændelser fra flere værter inden for et fælles tidsrum. Det gør det nemmere at håndtere en hændelse: I stedet for at logge ind på webserverne én efter én kan undersøgelsen først indsnævres efter miljø og tjeneste. En samlet søgning viser dog kun sammenhænge, ikke automatisk årsagen; metrics, traces, deployments og applikationstilstand er stadig vigtige supplerende oplysninger til diagnosen.

I tilfælde af en fejlbølge kan LogQL udlede en måling ud fra relevante linjer. Den følgende forespørgsel tæller eksempelvis Nginx-linjer med HTTP-status 500 som en frekvens over fem minutter. Den danner grundlag for en analyse eller en alarm, men siger ikke noget om, hvilken værdi der er kritisk i den enkelte applikation.

sum(rate({env="prod", service="nginx"} |= " 500 " [5m]))

En fornuftig Alarmtærskelværdi beregnes ud fra den normale fejlrate, applikationens adfærd og eksisterende overvågningssignaler. En enkelt 500-fejl kan vurderes forskelligt, alt efter om den opstår i en sjældent brugt administrationsfunktion eller ved en checkout. Kontroller derfor først historiske mønstre, og knyt alarmen til et klart ansvarligt team, inden den eskaleres til produktionsmiljøet.

Hvis Loki returnerer 429 under skrivning, bør grænserne ikke hæves uden videre. Først skal det afklares, om en tjeneste genererer usædvanligt mange linjer, om en løkke gentager fejl, eller om dynamiske labels genererer et stort antal små streams. Loki begrænser indlæsningen globalt og pr. stream for at beskytte platformen. Først efter denne kontrol kan man afgøre, om filtrering, etikettkorrektioner eller en begrundet justering af grænserne er nødvendig.

Anvend Loki på en passende og ansvarlig måde

For en enkelt VPS med Nginx, systemd og få containere kan Loki i monolitisk tilstand skabe en overskuelig, central søgefunktion, forudsat at logkilder, lagerplads og adgang er klart reguleret. I dokumentationen anbefales denne tilstand til eksperimenter og små læse- og skrivevolumener; ca. 20 GB logfiler dagligt er her en vejledende angivelse fra producenten, ikke en kapacitetsgaranti for enhver lagrings-, forespørgsels- eller mærkningsstruktur.

Flere Linux-webservere drager særlig fordel af en fælles tidslinje for web-, log- og applikationshændelser. Ved container-implementeringer er det afgørende, at der anvendes en stabil mærkningsmodel for miljø og tjeneste, for at denne søgning forbliver håndterbar. Meget store Kubernetes-miljøer eller roller, der specifikt skal skaleres separat, kan retfærdiggøre microservices-tilstanden, men medfører i så fald betydeligt større drifts- og fejlanalyseomkostninger. Ved nyplanlægning er SSD ikke en permanent standardmulighed, da denne tilstand er markeret som forældet.

En platform med klientunderstøttelse kræver desuden en robust adgangskæde. Loki adskiller forespørgsler via klient-id’et, men stiller ikke et komplet autentificeringslag til rådighed. En pålidelig proxy eller identitetslag skal autentificere adgang, håndhæve TLS og foretage tilknytningen på serversiden. En understøttet agent er også en del af grundlaget: Promtail understøttes ikke længere; til nye installationer er Grafana Alloy for eksempel den anbefalede løsning.

• Enkeltstående VPS: Fastlæg en kildeoversigt, filtre for fortrolige oplysninger og en enkel, kontrollerbar opbevaringsperiode inden implementeringen.
• Flere værter: Aftal faste mærker for miljø og tjeneste, så den centrale søgning rent faktisk forkorter håndteringsforløbet for hændelser.
• Containerplatform: Brug ikke dynamiske ID’er som labels; overvåg løbende antallet af streams og optagelsesadfærd.
• Flerklientdrift: Implementer autentificering, serverbaseret klienttildeling og tilladelser, inden Loki-endepunkter frigives.
• Alle miljøer: Dokumenter gendannelseskravene, og kontroller regelmæssigt konfigurationen, lagringskonceptet samt sletningsfristerne.

Hvis der mangler ejere af logkilder, en strategi for følsomt indhold eller klare gendannelsesmål, bør man først og fremmest dette Driftsgrundlag skal afklares. Loki kan samle logfiler og gøre dem søgbare, men erstatter hverken dataminimering, sikkerhedskopier, adgangskontrol eller en faglig årsagsanalyse. Fordelen kommer først til udtryk, når teknik, ansvarsfordeling og opbevaring planlægges i fællesskab.