Lagre Eventlog fra XP-klienter i en felles db

[N_R]

Hei,

 

har en liten "nøtt" som dere database-guruer kanskje finner interessant.

 

Uten å gå i detalj, så har jeg fått i oppdrag å se på om vi kan samle inn Eventloggen fra klientene våre i en felles database, som allerede inneholder en del driftsverktøy. Tanken er da at man kan gjøre en del "detektivarbeid" som å se etter feil på disker, ugyldige innloggingsforsøk osv fra det samme web-verktøyet som vi allerede bruker i dag. Klientene står nemlig fint plassert rundt omkring i Nord-Europa, så det er ingen mulighet til å koble til Computer Management remotely slik man kan gjøre på et lokalnett osv.

 

Naturlignok så blir det en del loglinjer etterhvert, hvorav veldig mye av teksten også er den samme. Spørsmålet blir da hvordan man kan begrense dette mest mulig.

 

Man kan bruke normalisering, men det hjelper heller ikke alltid siden det somregel kan være stort sett like meldinger, men med en liten variasjon. Et typisk eksempel vil være noe sånt som "The computer successfully downloaded a file at: 10:26:13 14-12-2006". Dette vil i praksis føre til en ny linje i tabellen hvor man har tekststrenger man normaliserer mot. (Bør legge til at vi i vår Eventlog har en del ekstra logger av denne typen)

 

 

(Dette er et "duste-eksempel", men ha tålmodighet med meg for at jeg ikke orket å scrolle gjennom hele eventloggen for å finne et som var bedre )

 

<melding 1>

Tjenesten IMAPI CD-Burning COM Service gikk inn i tilstanden Kjører.

 

Hvis du vil ha mer informasjon, se Hjelp og støtte på http://go.microsoft.com/fwlink/events.asp.

</>

 

<melding2>

Tjenesten IMAPI CD-Burning COM Service gikk inn i tilstanden stoppet.

 

Hvis du vil ha mer informasjon, se Hjelp og støtte på http://go.microsoft.com/fwlink/events.asp.

</>

 

Jeg ønsker meg altså et system hvor jeg i størst mulig grad kan finne likheter mellom tekst-felt i loggen som er GANSKE like, men sjelden HELT like- hadde de vært det hadde jeg bare normalisert, og problemet hadde vært ute av verden.

 

 

Jeg har googlet og lest på nettet, men finner egentlig ingen bra oppskrift på dette. Finnes det noe Best Practices her? Noen som har en link eller mer info?

 

Jeg heller mer og mer mot en slags kombinasjonsløsning, hvor jeg har litt logikk i databasen, og litt i .Net webservicesene som lagerer og henter ut dataene. Men da blir det mye "klipp og lim" når jeg skal sette det sammen igjen.

 

Kan jeg putte det rett i databasen hadde det vært glimrende (CLR to the rescue? Ikke noe erfaring med det.... ...men kan lære ved behov!), vi kommer til å holde oss på MS SQL i overskuelig fremtid.

 

 

Ble litt knotete post dette, men jeg håper jeg har gjort meg forstått angående hva jeg har behov for å gjøre, og hvordan jeg har tenkt å løse det? Alle kommentarer og innspill mottaes med stor takk!

 

NR

[roac]

Kombinasjonen EventID og Source bør i de fleste tilfeller unikt identifisere en situasjon, eller i det minste en gruppe situasjoner.

 

Ellers finnes det jo en rekke ferdige verktøy hvis du ikke hadde måtte ha det i samme database som dere bruker pr i dag, men kanskje noen kan tilpasses? How to Centralize Windows Event Logs

[N_R]

Ja, vi kommer langt med det du nevner, men utfordringen ligger som sagt i våre custom Eventlog entries. Vi har allerede en applikasjon som logger til Eventloggen, OG til vår sentrale server. Litt dobbelt opp, men bedre med en logg for mye enn for lite. Også veldig kjekt å ha dersom en tekniker står ute på en lokasjon og bare har tilgang til den lokale boksen. Da titter han bare i vår custom Eventlog, og finner det meste han trenger å vite.

 

Vi må strengt tatt ikke ha det i det samme verktøyet, men det hadde absolutt vært en fordel. Har man to verktøy må man for eksempel være 100% sikker på at man ser på loggene for akkurat den samme boksen i to forskjellige systemer. Dette kan man gjøre nogenlunde feilsikkert, men muligheten for feil vil alltid være tilstede. Et annet moment er at support-personellet ikke alltid jobber lokalt mot serverne, så de jobber ofte bare direkte mot web-grensesnittet. Dette vil det også bli mer og mer av etterhvert som vi flytter flere servere til serverhotell - som jo er en fornuftig strategi.

 

En annen ting er at vi da slipper å lage en del logikk på klienten for rapportering til serveren. For eksempel har vi nå laget en funksjon som logger ugyldige oppstarter, for å identifisere strømavbrudd, ustabile bokser osv. Hadde vi allerede hatt Eventlog-funksjonen jeg etterspør, kunne vi laget denne logikken på serveren, uten å måtte oppdatert klientene med en ny versjon. Klienten ville aldri trengt å rapportere oppstarter, utvidelse av virtuelt minne (som indikrerer memory leaks osv), hva det nå måtte være - vi kunne laget all logikken sentralt på serveren. Det ville bli mindre å programmere og ikke minst - mindre å teste, som tar vel så mye tid.

 

Jeg vurderer det dithen at vi om nødvendig legger inn Eventloggen rad for rad uten normalisering eller komprimering, og heller sorterer ut/sletter de tingene som ikke er interressant. Det løser mitt problem, men kunden kan jeg nok se for meg ønsker alle linjene - og da må vi prøve å optimalisere litt for å få med oss alt

[j000rn]

Hva med å bare logge alt, men kun spare på eventloggene for f.eks. de siste 30 dagene? Dermed vil ikke datamengden bli uhåndterlig stor. I tillegg kan dere jo etterhvert sette på filtere som automatisk sletter (/ikke logger) event'er som ikke er interesante.

 

Om dere absolutt MÅ spare på eventlog'en kan det være greit å ikke ha disse i databasen, men dumpe de til daglige (etter 30 dager) CSV filer som blir komprimert (gjerne av Windows, slik at de fortsatt er søkbare).

[N_R]

Ja, vi har begynt å se på hva vi faktisk TRENGER av denne loggen - og det er i grunn ikke så mye. Vi kommer tilå beholde noe sånt som 7-30 dager av logg og deretter slette den. Viktige ting (kanskje 1%?) plukker vi ut og lagrer i en egen tabell først.

 

Jeg har kanskje ikke lagt nok vekt på at det egentlig ikke er den vanlige Eventloggen som er viktig, men de custom loggene som programvaren vår lager - og det er DEN biten som utgjør mesteparten av loggmengden, IKKE det XP genererer. Men samme prinsippet gjelder i grunn her, vi kan slette ting som ikke er så viktig, og også aggregere (?) og lage en statistikk for hver måned istedet for å ta vare på hver eneste lille linje.

 

Så det blir en litt dirty løsning, men tror det er den beste totalt sett. Det blir DEN jobben å prøve å gjøre det på en "smart" måte, jo mer jeg leser om det jo mer jobb ser jeg for meg at det blir......