[Nlnog] SNMP en performance impact

[Robert van der Meulen]

Hoi Funs,

On Mon, 2005-01-17 at 11:23 +0100, Funs Kessen wrote:
> Bij mijn vorige werkgever heb ik voor een SLA project cricket gebruikt
> met wat modificasties hier en daar. Ik zou echter niet meer een RRD based
> systeem gebruiken, omdat je in de knoop komt zodra je op je rollover point
> van je datasources komt. Destijds heb ik ook getest met een SQL backend en
> dan transaction based insertion, wat een stuk sneller was. Het enige
> probleem was dat de data hoeveelheid nogal groot werd, je zult dan dus
> data weg moeten snijden, en dat is een keuze. Wat ook erg belangrijk is
> voor je cycle is de hoeveelheid datasources die je wil pollen, hoe meer
> data sources hoe langer je cycle.

Ik geloof dat ik je code daarvoor wel 's tegen gekomen ben ;)
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).

> Wat ook belangrijk is bij de aparatuur die jij wil pollen is dat je
> dynamisch een "klant" moet kunnen opzoeken, iig eerder was het zo dat
> een klant een moving target was zodra er een kaartje getrokken werd,
> op een en hetzelfde device al, Je zult dus klanten moeten "mappen".
> 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 :/

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

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

> Load wise hoeft het niet veel te zijn, SNMP is heel licht, dus dat is geen
> issue, het is vaak de onderliggende crap en slechte implementatie die ervoor
> zorgt dat er problemen zijn met SNMP. Veel devices supporten niet echt netjes
> bulk retrieval en bouwen voor elke OID die gevraagd wordt de hele table
> opnieuw (net-snmp/snmpx/enz). Daar komt het verhaal ook vandaan dat snmp
> "zwaar" zou zijn voor sommige devices, de brakke implementatie in de
> software van deze devices zorgde er in het verleden nog weleens voor dat
> dingen op hun gezicht gingen. De aparatuur die jij boven noemt heeft er
> relatief weinig last van, er zijn mensen die zeggen van wel, maar het spelen
> 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. 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).

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