nav.ref Mars 2012

nav.ref@lister.sikt.no

5 participants
7 discussions

[nav-ref] Møtereferat + omprioritering
by Vidar Faltinsen 30 Mar '12

30 Mar '12

Heisan, - og takk for i går! Nok et veldig nyttig møte, der vi fikk mange gode innspill. Vi er veldig fornøyd med hvordan dette fungerer :) Jeg har skrevet referat: https://openwiki.uninett.no/gigacampus:navref_290312 I forhold til nye ideer: Det dette koker ned til er om vi skal endre på vår eksisterende prioritering som følge av møtet. Jeg har revidert den opprinnelige 13 punkts lista til 10 punkter, der jeg sier at de tre øverste er tatt/blir tatt uansett. Har da: https://openwiki.uninett.no/gigacampus:topp5_101111?&#liste_pr_30_mars_2012 Altså: 1 Tilby fullverdig tolopogilink alarmfunksjon 2 Utvid IP deviceinfo med et “room view” 3 Tilby netbios støtte 4 Vis topologi ut fra en svitsj 5 Utvid mulighetene til NAV bar search 6 Implementer Maintenance forbedring 7 Inkluder IP forbruk stat/DHCP statistikk 8 Tilpass NAV til smartphone 9 Tilby Mac prefiks søk (søke basert på vendor) 10 Inkluder nettkartet vlanview Så har dere kommet med en rekke nye moment som står i referatet. Morten kan ta en titt og gi noen røffe estimater på omfang arbeid på de ulike punktene (og skrive dette inn på wikien) Dernest kan dere gi en revidert topp 5 liste, husk her den dere ga i november: https://openwiki.uninett.no/gigacampus:topp5_101111 Basert på den input dere gir kan vi sette det sammen og se om jobbkøen vår endres en del. Uansett - god påske folkens! mvh - Vidar

1 0

[nav-ref] Ting jeg noterte på samling
by Vidar Faltinsen 29 Mar '12

29 Mar '12

Heisan, Så Gro-Anita sin liste. Fare for overlapp - her er ting på min liste: macwatch * hist: liste alt utstyr (vendor) som ikke skal være på et vlan * ferdigdefinert filter/filtergruppe for Macwatch (og annet) * legg inn description i varslingen * opsjon for å begrense varsling til den som har registrert macadressen sensor * Uia: støtt Uptimedevices miljøsensor * UiT: ser ingen grafer fra sensoren i cricket... hva er feil? rapport bug i direkte naboskapskandidat * trykk på interface - crasher hvis spesialtegn (tror det var #) linkdeteksjon * legg til flapping støtte for linkdeteksjon threshold * hysterese i terskelmonitor * nettboks til venstre, matrise til høyre - gir bedre oversikt * sette terskler på en gruppe bokser * benevning * absolutt vs relativ * knapp for sletting * lenke til graf fra description (f.eks. cpu1min) alert profiles * nye ferdiglagde filtre når vi kommer med ny funksjonalitet * "something went wrong"-sida * skriv der: "Please enable djangodebug in nav.conf and report" * looging conf * bør følge med - og med forklaring * pping.conf * dokumenter debug levels i configfila mvh - Vidar

1 0

[nav-ref] Fwd: NAV - kommentarer
by Vidar Faltinsen 29 Mar '12

29 Mar '12

Heisan, gode innspill som kan vurderes av nav-ref! - Vidar -------- Original Message -------- Subject: NAV - kommentarer Date: Thu, 29 Mar 2012 07:36:58 +0200 From: Helge Stranden <helge.stranden(a)uninett.no> To: Vidar Faltinsen <vidar.faltinsen(a)uninett.no> CC: Gunnar Boe <gunnar.boe(a)uninett.no> Hei Vidar, Aller først, takk for nyttige kursdager. Jeg har tillatt meg å skrive ned de to NAV-kommentarene jeg nevnte om litt om i pausen igår, så dere har de om det er tema som evt. tas opp til vurdering nå eller senere. 1) Hvis det er en strategi at NAV skal benyttes i større grad også av næringslivet der ute, så er min erfaring at de store aktørene bl.a. i oljebransjen har et stramt regime som sier at Linux-OS som skal benyttes på server-siden i organsisasjonen skal være RedHat Enterprise standard (evt. CentOS) og i noen tilfeller SuSE Enterprise. Derfor burde man kanskje tilby oppdaterte RPM'er for disse miljøene, gjerne statiske varianter også slik at dependensies issues minimeres. Det beste ville kanskje være et YUM repository. Terskelen for å i det hele tatt vurdere produktet for disse er at det er enkelt å få det testet ut, kjørende på det de har definert som standard Linux-distro i egen organisasjon. 2) Treshold: Hvis NAV i fremtiden i tillegg til fokusområdet idag skal benyttes til å monitorere komponenter for fysisk infrastruktur, for eks. kjølesystemer, så vil en utvidelse av Treshold funksjonaliteten være kjærkommen. Jeg har erfaringer fra bl.a. store kjøleløsninger fra APC, der de også varsler om treshold-verdiene endres veldig raskt eller i moderat tempo. En rask og kritisk endring er for eks. hvis isvannet plutselig får langt høyere temperatur utenfor ordinær arbeidstid. Det gir en indikasjon på om hvor kritisk situasjonen er, og om hvor lang tid man har på seg til å møte opp onsite for å gjøre nødvendige tiltak for å hindre skade på utstyr pga. vesentlig temperaturøkning. -- Med vennlig hilsen *Helge Stranden | *Senior Rådgiver IKT Infrastruktur – Uninett AS telefon: 73 55 79 80 mobil: 48 36 24 06 uninett.no

1 0

[nav-ref] NAV-notater fra i dag
by Gro-Anita Hillestad Vindheim 28 Mar '12

28 Mar '12

Tanker som dukket opp i løpet av dagen, både fra salen og eget hode. GA * metanav - tool-dok. Masse fin tekst, men når ble den oppdatert? (dvs hvilken versjon skal jeg bruke til denne dok.?) * Report - advanced "[NOT] NULL"-søk. Eks. ingenting i "Connected to"-feltet * toolbox-side redusert størrelse - eller liste uten de store boksene - bare ikonene? * Sefland - PoE. Mulig å ta inn dette som sensor? * threshold mgr - benevning ikke med på f.eks cpu1min -- absoluttverdi vs prosent, etc - fane 2 conf. thresholds. -- Mulig med matrise view? Hvis man vil ha det, da. -- Det kan bli en veldig stor matrise... - profil for terskler. f.eks "alle GSW". -- Legge til en boks til en profil manuelt, eller automatisk medlem av profilen -- Bør settes pr profil -- Automatiske grupper bør ha mulighet for unntak - bedre slettemulighet. Knapp i stedet for å fjerne tallet! - fane 3 exeeded threshold. Bør være unødvendig å trykke fopr å ekspandere. -- link til grafen som har exceeded seg. * Alertprofiles Flere forhåndsgenererte filtre/filtergrupper * "Throttling" av alarmer. -- Synes det ofte kommer mangel på "oppsamling av alarmer" med nye verktøy. -- Hva med en generell sak på tvers av verktøy? * Hvordan feilsøke NAV - Hva med å legge ut en fin liste over ting som skal/bør med i en bugrapport? - nav.conf -> innkommenter DJANGO_DEBUG, restart apache, reload siden * IP device Info. Mulighet for å collapse bokser, f.eks? Sensor/statistikk-lista kan bli veldig lang. I det minste legge de lengste nederst... (Vanskelig å finne igjen "Configure ports") Står på 3.12-planen :) Last updated - fin rapport. Men HVA var det som ble oppdatert? -- Bør (hvis mulig) brytes ned til type oppdatering (oidprofiling, linkstate, ...) - Kunne det lages en webside som henter inn de forskjellige intervalldataene fra *.conf Så blir det enklere å sjekke når det burde vært samlet inn data.

1 0

[nav-ref] Agenda nav-ref møte #2: 29/3 2012
by Vidar Faltinsen 20 Mar '12

20 Mar '12

Heisan, Møtet blir på vårt møterom Turkis (som det nå heter) i 5 etg. Fra kl 09-15. Vi foreslår følgende agenda: 0900-1030 Hva vi har gjort siden sist + planer for 3.12. Justering av 3.12 planer? 3.13 ideer. (3.12 = 13/9, 3.13 = des) 1030-1100 Kaffe 1100-1230 Topology breakdown. Dere satt forbedret datakvalitet høyt. 3.11 slippes 8/3 (en uke etter skjema). Dvs dere rekker å se på en 3.11 installasjon _før_ møtet. Er det noen flere issues med feil i topologi eller andre data? Ta med eksempler til møte - så tar vi det opp. Vil ikke gå i detalj der og da - men diskutere evt problemer. 1230-1330 Lunch 1330-1500 Kravspekk nytt nettkart Vi ansetter to studenter i sommer som skal jobbe med dette. De trenger en kravspek. Lekse _før_ møte - skriv ned momenter/ krav som må være på plass i nytt nettkart. Før vi reiser hvert til vårt avtaler vi nytt møte til høsten. Forslag: 4/10 eller 11/10. Vi ønsker også å invitere dere til middag kvelden før, kl 19. Innspill til agendaen er velkomne. mvh - Vidar

3 3

Re: [nav-ref] Om Link down og slikt (tolopogilink alarmfunksjon)
by Borge Brunes 07 Mar '12

07 Mar '12

morten.brekkevold(a)uninett.no said: > Det spiller ingen rolle hvilket delsystem som genererer hendelser. Det er > eventEngine som evaluerer hendelser og bestemmer hvorvidt det skal genereres > alarm. I know. Bare jeg som formulerte meg litt knotet. > Egentlig skyggestatus finnes bare på boksnivå, i.e. boxShadow. En > boxDown-hendelse som ser ut til å skyldes skyggeforhold oversettes til en > boxShadow-alarm i stedet for å bli sendt som en boxDown-alarm. Dette gjøres > altså på bakgrunn av topologi-informasjon. > > Ingen andre "enheter" i NAV-sammenheng har egen skyggestatus, ikke engang > tjenester. > > Det er derimot, som sagt, opp til eventEngine hvorvidt det skal genereres > alarm for en hendelse. Denne avgjørelsen tas lokalt i den pluginen som > behandler en hendelse. Det er ikke alle hendelser som har egen plugin, og de > behandles da bare på generelt vis, og da er det ingen tilbakeholdenhet med å > varsle alle hendelser umiddelbart. Men det jeg ikke skjønner er hvorfor ikke alle hendelser blir sjekket opp mot skyggestatus? Er det i det hele tatt situasjoner man ønsker å få melding om at X er nede på boks så lenge boksen er nede? Børge

3 3

Re: [nav-ref] Om Link down og slikt (tolopogilink alarmfunksjon)
by Borge Brunes 02 Mar '12

02 Mar '12

morten.brekkevold(a)uninett.no said: >> Slik jeg ser det så er det unødvendig og skaper bare ekstra støy >> at det sendes ut "Link down" når boksen bak "Link down" allerede >> er meldt nede. > >> Imidlertid så er det svært nyttig å få melding dersom en link går ned >> uten at boksen bak går ned. Gjelder selvsagt bare for bokser med >> redundante uplinker. > Er enig i tankegangen her. Pr. i dag gjør ikke eventEngine noen > særbehandling av linkState-events, de bare dyttes ukritisk til alarmkøen. > Det medfører også et annet problem vi har observert: Noen konfigurerte alle > HP-switchene sine til å sende linktraps til NAV. De hadde en rekke porter > som flapper som bare det, og ble dermed bombardert med alarmer fra NAV. > Sett bort i fra at de ikke burde ukritisk sende alle slike traps til NAV > (hvem bryr seg om linkstate-alarmer på aksessporter?), så burde eventEngine > gjøre som for boxState/moduleState og innføre karantenetid på > linkState-alarmer, slik at flapping ikke utløser alarmskred. Dette er > forøvrig nevnt her: https://bugs.launchpad.net/nav/+bug/939429 > Ser ut som noen(tm) må knekke noen Java-knoker likevel ;P Jeg er litt usikker på jeg er helt med her. Er det ikke slik at det er to forskjellige måter at linkState-events kan oppstå: 1) det sendes snmp-traps til trapmottak (snmptrapd) 2) ipdevpoll Pt. så har ikke vi satt opp boksene vår til å sende traps til NAV så jeg har bare sett på ipdevpoll. Min oppfatning av problemstillingen er at uansett "delsystem" (link-state, snmpagent down, tjenesteovervåker osv) så må skyggestatus sjekkes. Det er ingen vits å sende melding om link-down, tjenste X osv er nede dersom boksen er nede. Man gjør vel dette i dag når en box bak en ruter går ned? Dette med skyggestatus har jo vært en av styrkene til NAV. Børge

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

nav.ref Mars 2012