[Nlnog] SNMP en performance impact

[Funs Kessen]

Hi Robert,

> Ik geloof dat ik je code daarvoor wel 's tegen gekomen ben ;)
>
Hehe, ow ja dat... :)

> Het probleem zit 'm opzich niet zo zeer in 't opslaan/verwerken van de
> gegevens ('t gaat 'm meer om 't bijhouden van een configuratiesnapshot
> dan om operationele statistieken).
>
Nee dat klopt, maar het probleem zit hem dan vooral in het feit dat je
niks en dan ook echt helemaal niks wil baseren op bestaande databases
met configuratie data, mischien nog net wel de IPs van de devices waar
je bij wil maar verder dan dat ook echt niks. 
 
> > Je wil namelijk ook niet dat als een engineer iets modificeert je weer
> > opnieuw die klant moet gaan configureren op de een of andere manier
> > in je systeem, dat wordt namelijk veel werk, en vaak gewoon niet gedaan.
> Dat kan zeker een probleem zijn, inderdaad - het 'in sync' houden van
> netwerk en database is geen easy feat :/
>
Dit is inderdaad een van de grotere problemen voor bedrijven die veel
verschillende "management suites" door elkaar heen gebruiken. De 
discrepantie tussen alle data is al genoeg om je een hartverzakking 
te geven :). Het wordt nog erger als er geen leading, of 180 achtige
constructie is.
 
> > Een andere optie is RTG, dat leek mij wel wat, maar daar ben ik destijds
> > niet aan toe gekomen, omdat zoals altijd het gisteren af moest zijn.
> > Later ben ik ook nog bezig geweest met een threaded engine in combinatie
> > met een SQL backend, maar de aandacht verslapte nogal snel :)
> Zoiets had ik ook in gedachten inderdaad - met name het handig queue-en
> en combineren van queries die je uit hebt staan lijkt me een voordeel.
> Enige mate van caching is ook nuttig - zolang 't niet te veel is ;)
> 
Hmm dan is het wel voordelig om het transaction based te doen, vooral
omdat als je een transaction start de data niet gecommit wordt totdat
je hem daadwerkelijk commit, ipv dat je continu aan het wachten bent.
Een nadeel is inderdaad dat het niet meer moet worden dan er verwerkt
kan worden :)

> > Mijn vraag hiernaast is dan ook nog wat regelmatige basis is ?, elke vijf
> > minuten, elke tien minuten, elke minuut ? En wat voor data wil je specifiek
> > pollen ?
> Mwa, veel minder regelmatig; dagelijks, of wellicht nog minder frequent.
> Het gaat echt specifiek om configuratiedata - welke circuits zijn er,
> met welke parameters en route.
>
Hmm komt me bekend voor, maar dat is heel erg goed te doen, je kunt
denk ik het hele netwerk in minder dan een kwartier wel in kaart brengen
iig customer data, ik weet niet precies welke data je allemaal wil hebben.
Er is echter een belangrijke keuze die je moet maken, en dat heeft weer
te maken met de toepassing van die data. Ga je het op een per-customer
basis aanpakken of op een per-device en dan all die devices aan elkaar
knopen ?
 
> > met de devices leert mij dat de retrieval van SNMP data niet voor problemen
> > zorgt.
> Nouja, daar gaat 't me inderdaad voornamelijk om. Als ik grote
> hoeveelheden data naar binnen haal, wil ik niet dat 'r dingen 'averechts
> beinvloed' worden. 
>
Ik zou me daar niet teveel zorgen over maken, je kunt die devices flink
op hun flikker geven voordat ze niet meer responden, en dan bedoel ik ook
echt flink. Ik heb in ieder geval nooit meegemaakt dat door een SNMP 
retrieval een van de devices barfde.

> Voor een aantal veelgebruikte zaken gebruik ik nu al
> caches (ook omdat 't zinloos is om dat soort semi-statische data vaker
> dan 1x per dag op te halen).
>
Dat klopt zeker, de configuraties zijn daar ook wel handig voor. dat
deed ik voor een tool die gebruikt werd om lijnen up te graden. Daarvoor
had ik gewoon een configuration parser geschreven. Die eerst keek of de 
configuratie aanwezig was, en zo niet hem ging halen van het device.

Grtz,

Funs

-- 
Funs Kessen
funsk at nl.demon.net