.png.jpg?quality=80)
Når loggene allerede vet svaret
Når noe feiler klokka to om natta, ligger svaret som regel i loggene. Problemet er at det ligger der sammen med to hundre tusen andre linjer. LogPilot gjør det siste steget — fra «her er loggene» til «her er det som skjedde» — til noe som tar minutter.
Feilen er sjelden ett sted
En moderne feilsituasjon fordeler seg. Kubernetes har restartet en pod. nginx svarer 502. PostgreSQL har logget en lås som ventet for lenge. Applikasjonen har kastet et stack trace som peker på noe helt annet.
Fire kilder, fire formater, fire konvensjoner for tidsstempel. Den som feilsøker bruker den første halvtimen på å legge dem ved siden av hverandre — før analysen i det hele tatt begynner.
Én tidslinje, så en prioritert liste
LogPilot leser 15 loggformater — blant andre Kubernetes/CRI-O, Docker, nginx, PostgreSQL, log4j, syslog, Tomcat, WebSphere og DataPower — normaliserer dem til én felles tidslinje, og kjører et regelverk over resultatet.
Ut kommer en triagerapport: hva skjedde, i hvilken rekkefølge, og hvor vi bør begynne å lete. Hendelsesgruppene samler beslektede funn, slik at én underliggende feil blir ett problem — ikke tolv symptomer spredt utover rapporten.
Å lagre logger er ikke å forstå dem
De fleste med produksjon i drift har allerede et sted loggene havner — OpenSearch, Elasticsearch, Splunk eller noe tilsvarende. De verktøyene løser en reell oppgave: ta imot store mengder linjer, indeksere dem og gjøre dem søkbare.
LogPilot gjør ikke noe av dette, og skal ikke gjøre det. Løsningen eier verken lagring, oppbevaringstid eller søkeindeks.
Forskjellen er hva slags spørsmål som besvares. En søkemotor svarer presist på det du spør om: vis meg alle 500-svar mellom klokka to og tre. Den sier ingenting om hvilken av de fire tingene som skjedde samtidig som var årsaken. Det er et annet arbeid.
Praktisk betyr det at en kunde som allerede har en loggplattform ikke trenger å bytte den ut. Analysen legger seg over, den erstatter ikke.
Har du ingen slik plattform fra før, leverer vi Item Application Monitor som en egen, driftet tjeneste: vi indekserer loggene, setter opp alarmene og gir deg en assistent du kan spørre på norsk. Det er aktuelt der loggingen i dag er filer på en server og verktøyet er grep — der feilsøkingen fort blir en hel arbeidsdag, og nedetiden varer like lenge. Egen tjeneste, egne kunder, ikke en del av LogPilot. Men premisset er det samme: analyse er lite verdt hvis loggene ikke er søkbare først.
Regler der regler er best
Et regelverk er presist og forutsigbart, men det finner bare det noen har beskrevet på forhånd. Språkmodellen leser tidslinjen på tvers av systemene og foreslår en årsakssammenheng — den delen et erfarent menneske ellers gjør i hodet, og som er vanskelig å skrive ned som en regel.
Løsningen støtter fire modelleverandører — Anthropic, OpenAI, Google og Mistral — og hver kunde bruker sin egen API-nøkkel, kryptert per arbeidsområde.
Eller ingen av dem. Skal ingen logglinjer til en ekstern leverandør i det hele tatt, kan løsningen i stedet peke på en modell kunden kjører selv. Kjøres LogPilot også i kundens eget miljø, forlater ingen data huset — analysen skjer der loggene allerede ligger.
Modellen får også si hva den mangler. Sammen med funnene lister analysen opp hvilke logger den ikke har sett, hva hver av dem ville avklart, og hvor mye det haster — slik at neste steg blir å hente én bestemt fil, ikke å lete videre i blinde.
En loggfil er full av hemmeligheter
Logger inneholder Authorization-headere, JWT-er, AWS-nøkler og databasepassord som ligger inne i tilkoblingsstrenger. Å sende en loggfil til en språkmodell uten å tenke, er å sende alt det til en tredjepart.
Ingen tekst når en modell uten å ha passert en maskeringsgrind først.
Grinden har tre nivåer, fra av til streng, og mønstrene dekker bearer-tokens, basic auth, JWT-er, AWS-nøkkelpar og credentials skjult inne i URL-er. Der biblioteket finnes kompileres de med RE2, som garanterer lineær kjøretid.
Skillet mellom kunder er løst på samme premiss: det ligger i databasen, ikke i applikasjonskoden. Med row-level security i PostgreSQL returnerer en spørring uten riktig kontekst null rader — ikke feil rader. Det er forskjellen på en feil som er synlig og en som er stille.
Standardmønstrene dekker det som er sensitivt overalt. Det som er sensitivt i én virksomhet, vet bare den virksomheten selv — derfor kan kunden legge inn sine egne mønstre i tillegg.
Der AI gir verdi
Det som har gitt mest verdi i LogPilot er ikke at modellen formulerer seg godt. Det er at den tar den delen av arbeidet som er mønstergjenkjenning over store informasjonsmengder — 200 000 logglinjer som skal bli til én forklaring, med regelverket til å finne det som lar seg beskrive på forhånd og modellen til å foreslå resten.
Har dere prosesser med mye informasjon og manuelt analysearbeid som burde kunne gjøres smartere?
Da tar vi gjerne en prat.