Dette indlæg er alene udtryk for skribentens egen holdning.

Få styr på loggen!

Af Kåre Kjelstrøm2. november 2007 kl. 10:305
Artiklen er ældre end 30 dage

Logfiler er alsidige størrelser: de rene schweizerknive, der rigtigt anvendt gør det muligt at afsløre fejl, debugge, vise at systemer er oppe, spore forbrydelser, checke performance og meget mere. 

For at sådanne nyttige anvendelser er mulige kræves imidlertid at logfilen indeholder de rigtige oplysninger. Skal loggen bruges til at måle performance, f.eks. for at kunne overholde en Service Level Agreement (SLA) skal man bla. vide hvilken service der blev udført, start tid, slut tid, evt. hvilken server der udførte jobbet, samt hvem klienten var. For senere at kunne fejlsøge på de udførsler der ikke overholdt SLA kravet kunne det måske også være nyttigt at kende evt. input og tid forbrugt i eksterne systemer som databaser, directory servere, web services, etc. 

Logfilernes læserskare finder man blandt systemadministratorer, der holder systemerne i live, programmører der retter fejl, systemejere der holder leverandører oppe på SLA krav og sikkerhedsansvarlige der vogter sensitive data.

I alt andet end de mest trivielle legetøjssystemer har logfiler det med at svulme op og gøre det fuldkommen upraktisk at foretage manuel inspektion - i hvert fald når de anvendes til performancemålinger eller sikkerhedsaudits. Det betyder i praksis, at der må et logovervågningsværktøj til og lige pludselig bliver loggens format vigtigt. 

Artiklen fortsætter efter annoncen

Desværre er det i reglen sådan at logfilers format sjældent finder vej ind i nonfunktionelle krav til it-systemer. Har man et krav f.eks. ifht overholdelse af DS-484 er der måske en strategi for hvornår og hvad der skal logges, men det er næsten 100% sikkert at logformatet ikke er mejslet mere i sten, end at det kan ændre sig med næste bug-release eller juniorudvikler der lige skal rette et par linjer. Sådan har det i hvert fald været med de systemer jeg har stiftet bekendtskab med. 

Der er brug for at logformatet finder vej ind i dokumentationen og betragtes som en teknisk kontrakt på lige linje med andre systemsnitflader: har en systemleverandør behov for at ændre logformatet, sker det i samråd med kunden.

Har du styr på loggen?

5 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
5
4. november 2007 kl. 20:44

Jeg er helt enig, Lasse.

Når man skal definere hvilke logs der skal findes, samt formatet af dem er man nødt til at hente sine krav blandt aftagerne og de arbejdsgange, der skal understøttes for at disse kan udføre deres arbejde.

Som du påpeger tilhører denne kategori af brugere et segment, hvis krav stort set aldrig finder vej til kravslister og dermed først bliver en hovedpine kort inden systemer skal i drift. Men så gør det også ondt.

Hvordan man får påvirket designprocessen så disse brugeres krav kommer med i f.eks. udbudsmateriale og i særdeleshed hvordan man gør det i offentlige projekter kunne jeg godt tænke mig at vide.

/Kåre

4
2. november 2007 kl. 15:17

Jeg ved ikke om jeg ligefrem vil sige at formatet skal specificeres. Og dog, selvfølgelig skal det det - men hvis ikke det sættes i den rigtige sammenhæng, kan det hurtigt blive ret meningsløst. Er der egentlig ikke snarere tale om en detalje som er en konsekvens af et langt mere generelt problem? Hvad med at spørge dem der læser i loggen?

Måske skulle man i stedet betragte det som enhver anden brugergrænseflade. Denne brugergrænseflade er bare vendt "indad" - mod folk i ServiceDesk funktionen, og videre til i første omgang Incident Management og Problem Management når vi taler om fejl, og dernæst Service Delivery når vi taler om performance/service i bredere forstand.

Som enhver anden brugergrænseflade gælder det vel om at den skal medtænkes i systemet som helhed, og helst fra begyndelsen, og under involvering af de brugere - konkrete personer - som ender med at skulle bruge det. Men i de fleste tilfælde tror jeg at netop dette er noget arkitekter er tilbøjelige til at glemme. Eller skære bort, fordi det bliver for dyrt.

Det svarer til at man udvikler en bil (eller en flyvemaskine), og så ikke får specificeret hvordan og hvor ofte forskellige komponenter skal vedligeholdes, eller designer den så den er umådeligt vanskelig at vedligeholde: fx kunne man forestille sig at man kom til at designe bilen, så motoren skulle tages ud for at man kunne komme til at skifte en pære i en forlygte.

Altså, der skal være et UI (ikke nødvendigvis GUI), så man let kan overvåge de ting, som SLAen specificerer skal være i orden, og et UI, så man bliver gjort opmærksom på de problemer der opstår. De er nok rettet mod ServiceDesk funktionen. Når så systemet er i en tilstand hvor SLAen ikke er opfyldt, skal der være endnu et UI, som er henvendt mod Incident og Problem Management: nu har vi ringet efter Autohjælp, sendt de øvrige passagerer med en taxa, og fået bilen slæbt til mekanikeren, og så gælder det om at han faktisk kan komme til at finde og løse problemet. (Endelig skal bilen ind imellem checkes, for at sikre at den kan køre, at bremserne virker, at den ikke er alt for rusten, at alle pærerne lyser korrekt osv - samt at den også har en størrelse og et benzinforbrug der passer til det behov brugeren har. Det er så et UI overfor Service Delivery, som dog nok også vil/bør være kanaliseret igennem ServiceDesk.)

Problemet bliver ikke mindre af, at IT-systemer - i modsætning til biler - ikke skal være "på værksted" ret længe, før det bliver et alvorligt problem i sig selv. Og en enkelt "mekaniker" kender måske kun en lille del af alle de komponenter som udgør systemet. Der minder IT-systemer måske mere om flyvemaskiner. Men hvor man i flyverdenen har meget rigoristiske procedurer for alting, er der jo desværre en tendens i IT til at "hvis bare vi kan få den i luften i en fart, så er det godt nok." Og nogle fly tilbringer vel næsten mere tid på jorden under forebyggende vedligeholdelse, end de er i luften. Tænk hvis man skulle lave en flyvemaskine der skulle være i luften hele tiden? Det der kommer nærmest det krav, er rumstationer. Designer vi IT-systemer som om det var rumstationer? Burde vi måske gøre det - bare en lille smule?

I så fald er det vist ret væsentligt, at man kan diagnosticere på det aktive system hvis det er nødvendigt, uden at det påvirker performance; at man kan udskifte vitale komponenter uden at det kræver at man er nede i timer. Osv. Hvis der ikke er tænkt på det i designet af systemet, er det nærmest umuligt at lave bagefter. Desværre er det som oftest først bagefter, når performance ikke lever op til den aftalte SLA, og man ikke kan finde ud af hvorfor, at man finder ud af man har brug for det. Så er det man griber til desperate hacks og "cowboyprogrammering"...

Jeg kommer til at tænke på Ole Bechs blog fra forleden: Det havde nok ikke været så rart at sidde i en Apollo 13 solgt af IT-sælgere og derpå designet af IT-arkitekter med de pris/funktion betingelser der er i IT-markedet.

Så ja, få styr på loggen. Men måden at gøre det på, er altså efter min mening at betragte logfilerne som en (lille) del af de "glemte" UIer, som henvender sig til tre alt for ofte oversete "bruger"kategorier: drift/overvågning/servicedesk, incident/problem management (hele vejen tilbage til arkitekter og udviklere) og i sidste instans projektets SLM og ledelse. Får man styr på det, så får man også "automatisk" styr på loggen.

Eller hvad?

-Lasse

3
2. november 2007 kl. 14:20

Jep: Krav til applikationslogning bør defineres ud fra retningslinjer udstukket af en ansvarlig it-arkitekt, der kigger på tværs af organisationen. Hvis det overlades til det enkelte projekt at drømme nye modeller op hver gang opnår man heller ikke den situation jeg efterlyser i indlægget.

Om loggen udelukkende bør ligge i en database vil jeg nok stille spørgsmål ved: det kan være fornuftigt at pumpe logdata ind i en database på et tidspunkt mhbp. at analysere det, men det skal være afkoblet fra realitdslogning: I fht. at logge hurtigt, gøre det lettere at lave backups, styre mængden af data med roterende logfiler mm. mener jeg ikke den holder.

Jeg har også oplevet det som uhyre nyttigt at have et "request-id" der bæres med rundt. Log4j har NDC, som gør det muligt at knappe et sådant id på den kørende tråd, så det går an så længe der ikke laves kald på tværs af processer eller skiftes tråd.

Log4j løser imidlertid ikke ret meget mere: Man får nogle få standardfelter foræret (thread-id, log-level, time, etc.) og skal så selv opfinde resten. ofte ender det med at indholdet af "Message" bliver overladt til programmøren, der så stopper inputparameterværdier ind efter sindstilstand og hvilken side af sengen han tilfældigvis stod ud af den morgen.

Der skal mere styring evt. via frameworks til hvis man vil sikre at logformatet kan anvendes noget fornuftigt.

NB: Jeg bor også stadig her i landet ;-)

2
2. november 2007 kl. 13:40

Jeg tror at programmer som Log4xxx er med til at standardisere logformater - men det er naturligvis en god ting at tænke over det på forhånd - fordelen ved at logge i en database er at det er nemt at lave udtræk som viser det man gerne vil have fremfor alt.

1
2. november 2007 kl. 13:38

Jeg vil starte med at sige at jeg endnu ikke har fundet det gyldne æble omkring logning (ellers havde jeg nok skrevet fra Bahamas :-) ), men et par observationer har jeg da. Dels så gælder det vel om at få adskildt programmeringsmæssige fejl fra forretningsmæssige fejl (altså hvem skal tage sig af fejlen). Desuden skal fejl have et unikt nummer som skal gå igen hen over diverse lag (præsentation, middle, business, database) for at forenkle fejlsøgningen.

Hvis det er muligt så bør loggen ligge i en database fremfor i filsystemet. Det skal så håndteres hvis databasen går ned hvordan man så får besked aligevel.

Derudover så er det jo et problem som skal håndteres centralt i organisationen (det behøver konsulenter ikke altid at kerere sig om :-) ). Problemet er jo at de enkelte projektledere oftest i god mening prøver at logge mest muligt om netop deres applikation for at finde fejl. Det gør bare at datamængderne kommer til at vokse til astronomiske højder (hvorfor Google ikke laver noget til at håndtere logning, forstår jeg ikke). Et par enkelte løsninger vil være at uddanne programmørerne til at lave ordenlig logningsamt rydde op af og til og evt en top10 liste over de programmer som "sviner" mest.