[Nlnog] SNMP en performance impact

[Robert van der Meulen]

Hoi,

Quoting Funs Kessen (funsk at nl.demon.net):
> > 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. 

Nou, precies - netwerk als uitgangspunt.

<snip meer over inconsequent netwerk vs. databases>

> > > 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 :)

Nouja, da's een kwestie van handig verdelen, inderdaad ;)

> > 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 ?

Voor dit soort zaken lijkt 't me gekkenwerk om customer-voor-customer dingen
na te gaan lopen; veel te veel duplicate data die je ophaalt, overhead. In
feite kan je 't best gewoon een device leegzuigen, en 't knoopwerk achteraf
doen (en hopen dat er niet teveel is veranderd in de tussentijd).

> > > 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.

Hmm, 't enige wat ik (vaak) heb, is 't afbreken van SNMP sessies bij 't doen
van grote walks. Vooral v1 devices zijn daar goed in (wegens de afwezigheid
van bulk mogelijkheid).

> > 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.

Ik heb inderdaad 'n redelijk deel in databases zitten - dat komt de snelheid
en 'load' behoorlijk ten goede.

Groetjes,
	Robert
-- 
/^"- '-(\__/)-' -"^\
    '-.' oo '.-' Holy Jesus! What are these goddamn animals?!
       `-..-'       
            Finger rvdm at db.debian.org for my GPG key.