Onderwerp: Nieuw open source monitoring tool

Oorspronkelijk geplaatst door Martijn Koot

@Randy - we bieden nog geen IPv6 maar we kunnen er wel mee testen hier.

Sorry, we bieden wel IPv6...

Heb je uberhaupt wel eens gekeken naar een tool als Zabbix? Dat kortweg af doen dat die tools alleen maar vertellen dat het stuk is, is klinklare onzin.
Het hele nut van monitoring software is dat je niet alleen bijhoudt of iets het doet maar ook hoe, waarom niet als dat het geval mocht zijn en wat de verwachting is voor in de toekomst. Elke grote, enterprise gerichte, monitoring tool is daar voor geschikt.

Waarom zou de daemon van N2 door blijven werken als alle andere daemons van het systeem ophouden? (andere tools hebben ook lokale agents, SNMP monitoring is maar een onderdeel)

Je hebt niks aan een monitoring tool wanneer het niet compleet is. Ik zie de huidige versie te weinig bieden om een goed monitoring alternatief te vervangen en je gaat niet 2 verschillende systemen implementeren. De implmentatie van een monitoring systeem is meer dan 3x klikken dus die tijd wil je niet dubbel spenderen.
Blijft mij vraag dus staan waarom het wiel opnieuw uitgevonden dient te worden i.p.v. de resources te gebruiken om bij te dragen aan reeds bestaande producten.

Een zabbix omgeving hier zit nu op 6 miljoen records, ik begrijp uit jouw tekst dat de database bestaat uit platte tekst. Hoe wil je dat performant houden?

hoe zit het met het toevoegen van extra checks, zoals bvb een eenvoudige checker voor de status van mysql replicatie, of het uitlezen van de belasting uit een lighttpd of een apache?

Oorspronkelijk geplaatst door gjtje

Heb je uberhaupt wel eens gekeken naar een tool als Zabbix? Dat kortweg af doen dat die tools alleen maar vertellen dat het stuk is, is klinklare onzin.

Bedankt voor je vraag. Het gaat om een verschil van elementaire aanpak. Die van N2 heeft meer focus op informatie uit de host zelf. Het is primair agent-based. De aanpak van nagios en soortgelijke producten is primair poll-based. Beide benaderingen zijn overigens prima uitbreidbaar met extensies richting de andere. Plannen voor poll-based uitbreidingen (wellicht zelfs met gebruikmaking van nagios) zijn er voor N2 in elk geval ook.

Oorspronkelijk geplaatst door gjtje

Waarom zou de daemon van N2 door blijven werken als alle andere daemons van het systeem ophouden? (andere tools hebben ook lokale agents, SNMP monitoring is maar een onderdeel)

Het beantwoorden van een tcp-connectie naar aanleiding van een poll request van buiten (zoals bij de nagios-agent bijvoorbeeld nog steeds nodig is) blijkt in de praktijk zwaarder dan het versturen van 640 bytes uit een reeds gealloceerde buffer over een al geopende udp socket. Is het proces oncrashbaar? Hell, no. Maar data blijft in de praktijk wel binnenkomen op momenten waar tcp agents of snmpd pollen leidt tot niets dan timeouts.

Oorspronkelijk geplaatst door gjtje

De implmentatie van een monitoring systeem is meer dan 3x klikken dus die tijd wil je niet dubbel spenderen.

We hebben geprobeerd om provisioning van nieuwe hosts zo makkelijk mogelijk te houden. Met een beetje voorwerk is het vrij eenvoudig om nieuwe machines automatisch in N2 te krijgen zonder in te hoeven loggen voor nieuwe configuratie op het monitoringsysteem.

Het initieel opzetten van n2 vergt natuurlijk wel wat tijd. Maar het was voor ons de investering meer dan waard. Daarom hebben wij het ook open source aangeboden.

Oorspronkelijk geplaatst door gjtje

Blijft mij vraag dus staan waarom het wiel opnieuw uitgevonden dient te worden i.p.v. de resources te gebruiken om bij te dragen aan reeds bestaande producten.

Omdat een frisse aanpak soms tot betere resultaten leidt en omdat een frisse aanpak de andere open source projecten kan stimuleren. Wij kennen niemand die nog steeds tevreden browset met Mosaic, of CGI-scripts in perl schrijft die communiceren met mSQL op een site gehost op ncsa-httpd. Mozilla, PHP, MySQL en Apache zijn ook maar
heruitgevonden wielen, gemaakt door mensen die er voor kozen om hun energie niet in de eerdere projecten te stoppen.

Los daarvan heeft een groot deel van deze code haar wortels in het jaar 2000. N2 is in die tijd in ontwikkeling geweest bij partijen als Vuurwerk en Scarlet. De eerste versie van nagios stamt uit 2002. De software heeft afwisselende aandacht gehad in de tussenliggende jaren. Het grootste deel van het meest recente werk aan N2 heeft gezeten in de webinterface.

Oorspronkelijk geplaatst door gjtje

Een zabbix omgeving hier zit nu op 6 miljoen records, ik begrijp uit jouw tekst dat de database bestaat uit platte tekst. Hoe wil je dat performant houden?

We hebben op dit moment 122.974.560 samples op onze eigen implementatie van N2 verzameld. Een sample bevat complete statusinformatie, waaronder bandbreedte, network latency, disk-i/o, cpu usage, load average, tot 12 processen uit 'top', geheugen- en swapgebruik, login-sessies, mounted filesystems + disk usage, gebruik van open tcp-poorten en optioneel mod_status-informatie uit apache.

Data wordt uiteraard niet opgeslagen als platte tekst. Voor verdere details over de interne architectuur verwijs ik je graag door naar onze mercurial repository. Use the source, Luke: http://opensource.xlshosting.com/hg/n2

Oorspronkelijk geplaatst door wonko

hoe zit het met het toevoegen van extra checks, zoals bvb een eenvoudige checker voor de status van mysql replicatie, of het uitlezen van de belasting uit een lighttpd of een apache?

Wonko: Echt geweldig is het op dit gebied nog niet. We zijn bezig om het packet-formaat om te bouwen op zo'n manier dat het makkelijker wordt om arbitraire metingen toe te voegen aan de standaarddata.

Oorspronkelijk geplaatst door Martijn Koot

Wonko: Echt geweldig is het op dit gebied nog niet. We zijn bezig om het packet-formaat om te bouwen op zo'n manier dat het makkelijker wordt om arbitraire metingen toe te voegen aan de standaarddata.

Lees ik dat correct als "nee, tenzij je het zelf in C in de agent inhackt?"...

Klopt, in de receive daemon én de interface. De lijst met verzamelde informatie is op dit moment vrij statisch, vandaar dat we daar dingen aan willen aanpassen.

wat met zaken als solaris of bsd? Worden verder alle interfaces uitgelezen (device met 10 ethernet devices)? Alle disks? Alle CPU's? Ik neem aan dat je geen standaard snmp devices zoals switches kan pollen en invoegen?...

Ik vind het leuk dat dit als opensource aangeboden wordt. Zelf hebben we ook wel eens aan dergelijke tooling geprogrammeerd en ik weet uit ervaring dat het een hele klus is om het generiek en toch nuttig te krijgen.

Voor het rijtje alternatieven moet "munin" ook nog even genoemd worden.

Oorspronkelijk geplaatst door wonko

wat met zaken als solaris of bsd? Worden verder alle interfaces uitgelezen (device met 10 ethernet devices)? Alle disks? Alle CPU's? Ik neem aan dat je geen standaard snmp devices zoals switches kan pollen en invoegen?...

BSD-code is al aanwezig en we zijn bezig om daar een fatsoenlijke FreeBSD port voor te bakken. Hier verwachten we de komende twee weken klaar mee te zijn.

Alle interfaces worden uitgelezen maar worden in de grafiek integraal meegenomen, je krijgt uiteindelijk dus nu alleen maar grafieken voor 'network in, network out'. Je kan n2txd wel vertellen om alleen maar een specifieke set poorten te meten. Disks gaan ook integraal op die manier.

Het hele eieren-eten hier is dat het toevoegen van de mogelijkheid tot het aanhouden van 'vrije' velden al dit soort mogelijkheden interessanter zal maken.

Solaris staat nog niet op de kaart, we hebben nog geen idee hoeveel werk het is om de juiste informatie uit die kernel te krijgen. Dit soort metingen verschilt behoorlijk drastisch van OS tot OS. Wellicht is het voor een aantal platformen een idee om te kijken naar bestaande libraries die dit soort metingen wrappen.

Wie commit die meuk ?