Hei Morten,
morten.brekkevold(a)uninett.no said:
> On Wed, 25 Jul 2012 13:55:27 +0200 Borge Brunes <borge.brunes(a)uit.no> wrote:
>
> > Hei,
> >
> > om denne saken spesielt:
> > Ifm. en sak vi skulle feilsøke så dukket det opp noe som
> > forvirret oss. Vi var på jakt etter en mac-adr i nettet
> > da vi oppdaget at innsamlingen av cam og arp-data hadde
> > stoppet opp (ipdevpoll gikk som den skulle).
> >
> > Selv om innsamlingen hadde stoppet opp for
> > lenge siden så fikk man likevel opp status "still active" under
> > "End time" i machinetracker. machinetracker gjør altså
> > en antakelse om at mac&arp-adr. lever evig dersom den
> > er sett før innsamlingen stoppet opp, selv om den ikke
> > er sett på en boks. Hvorfor det? Jeg mener at dette
> > er feil. arp/mac-adr er ikke samlet inn på over en
> > mnd. og da kan man ikke si at den er "still active"
> >
> >
> > om slike ting generelt:
> > i første møtet i NAV-ref-gruppa som diskuterte vi veien
> > videre og vi ble enig om at datakvaliteten i NAV burde bedres.
> > Man skal kunne stole på de dataene man har i NAV.
> > Slik jeg ser det så er overnevnte et eks. på det motsatte.
>
> Dette er et godt og konkret innspill, Børge. Da vi etterspurte hva som lå
> bak formuleringen "heve datakvaliteten" tidligere i år var det relativt
> få konkrete svar å spore, bortsett fra mumling om "topologi".
>
> På helt generelt grunnlag kan jeg foreslå at cam- og arp-innslag i
> databasen kan utsettes for en expiry-mekanisme som er uavhengig av
> innsamling. Dvs. at dersom en arp/cam-record ikke er blitt bekreftet av
> innsamleren innen en viss tid, så vil den automatisk bli lukket. Ulempen
> er at dersom innsamleren skal bekrefte alle åpne innslag til enhver tid,
> vil det føre til bloat i databasen. Alternativt kan innsamleren bare
> bekrefte med timestamp at den har kjørt ferdig for en gitt boks, slik at
> expiry er relativt til dette tidspunktet.
Problemet er slik jeg ser det at systemet ikke har noen mekanisme for å
handtere feilsituasjoner. I dette tillfellet så hadde innsamleren ikke
samlet inn noe data (men heller ikke stoppet). Kanskje burde det gjøres
en sjekk etter at innsamleren er ferdig? Eks. når innsamleren melder
at den er ferdig med å samle inn CAM-innslag fra en boks så burde det sjekkes
hvorvidt den faktisk har samlet inn data.
Det kan selvsagt dukke opp tilfeller
hvor en switch ikke har noen devicer bak seg og at dermed ikke er samlet inn
CAM-innslag, men det får vi leve med. Det er uansett nyttig å vite om at
en switch står og trekker strøm uten gjøre noe fornuftig.
Slik har jeg tenk at ting fungerer. ARP-innsamling starter og henter
inn ARP-data fra box:
1) Dersom man oppdager ny IP-adr. så legges denne inn i en tabell med
tidsstempel for når den ble oppdaget og tagges med AKTIV
2) Dersom en IP-adr. som samles inn eksisterer fra før av med status AKTIV
så oppdateres tidstempel for sist sett.
3) Innsamling avsluttes og ryddejobb starter
4) Dersom det ligger IP-adr. i tabellen med status AKTIV og med tidsstempel
eldre enn når siste innsamling ble avsluttet så tagges IP-adr. med IKKE-AKTIV
(Dukker IP-adr opp igjen så betraktes IP-adr. som ny). UNNTATT
5) Dersom ikke tidsstempel på noen av de AKTIVE IP-adr. ble oppdatert
(altså ikke sett) eller det ikke kom til noen nye IP-adr. så må det gå
ut varsel (se tekst om varsel lenger ned i eposten) og IP-adr. settes
til status DATARÅTE el.
6) ryddejobb avsluttes
Nårjeg så gjør en spørring gjennom web-gresesnittet på en IP-adr.
så bør det opplyses (i tillegg til dagens info)
- hvilke GW/GSW IP-adr. ble samlet inn på og
- når ble siste innsamling av ARP-data foretatt på denne GW/GSW
- status på evnt. IP-adr. i punkt 5 må da være DATARÅTE el.
Litt usikker på jeg fikk forklart dette på en møte som var
forståelig, men Ingeborg skjønte det etter hvert :-)
> Helt spesifikt, til din problemstilling, lurer jeg på hvordan dere
> bekreftet at "innsamleren" hadde stoppet opp? Hadde NAV sluttet å logge
> ARP og CAM-innslag for alle bokser dere overvåker, eller bare for
> bestemte bokser? Hadde den sluttet å logge _både_ ARP og CAM eller bare
> en av delene?
Se post fra Ingeborg i dag som gikk utenom nav-ref.
> Dette er nyttig informasjon, da ARP og CAM samles inn av to forskjellige
> jobber, til forskjellige tidspunkt og individuelt pr. boks, i motsetning
> til tidligere, da både ARP-innsamling og CAM-innsamling var individuelle
> prosesser som kjørte fra cron og samlet inn for alle bokser i "runder".
>
>
> > På møtet ivret jeg for et internt system-check som fanget
> > opp feilsituasjoner som f.eks.
> > - cam/arp-innsamling har stoppet opp
> > - bokser av type GW uten ruterporter
> > - bokser av type SW uten switcheporter
> > - annen datainnsamling som ikke virker som den skal.
> > - osv.
> >
> > Jeg ivrer enda mer for et slikt system nå :-)
>
> Hvilket grensesnitt skal et slikt system ha?
>
> * Skal systemsjekken kjøres manuelt av administrator, eller som en
> cronjobb?
>
> * Dersom systemsjekken kjører automatisk i cron, hvem skal overvåke at
> systemsjekkeren virker?
>
> * Skal systemsjekken ha en statusside på web og/eller CLI?
>
> * Skal feil i systemsjekken sendes som alarmer i alert profiles, eller
> bare direkte som mail til ADMIN_MAIL fra nav.conf?
Her tenker jeg at systemcheck må/kan gjøres på ulike nivåer, og at
varsler skjer via alarmer i alert profiles og/eller ADMIN_MAIL fra nav.conf
Eks.
1) Ny box legges inn med type GW. Når den så legges inn så burde man sjekke
at: - at boxen har ruterporter
- at boxen ikke har vensentlig mindre støttede OIDer enn tilsvarende
bokser som allerde ligger inne.
- etc.
Feiler overnevnte check så burde det sendes ut alarm i alert profiles
2) Nevnte checker bør kjøres (via cron?) med gjevne mellomrom slik at evnt.
bug innført i nye versjoner av NAV blir fanget opp. I tillegg til varsel
så kan det kanskje være lurt med en statusside som sier noe om hvilke
checker som kjører og når de sist har kjørt
3) Siden den nye boxen er type GW så bør det finnes flere enn 2 x antall.
aktive egne ruterporter i arp-tabell. Dette må det sjekkes på når
ARP-innsamleren har kjørt.
Børge
> --
> Morten Brekkevold
> UNINETT
