---

'Aloha!

Sidder her og kokser lidt rundt med Nagios i et test-lab.

Når jeg kommer op på 5000 hosts med et par services hver,
så går det meget trægt. Det sker selv om jeg bare beder den
om at checke hosts/services en gang i døgnet.

Selve web frontenden bliver træls langsom at danse med.

Jeg har forsøgt at flytte databasefilerne over på en ramdisk,
men det gav ikke rigtig noget.

Nogen der har erfaringer i samme boldgade?

Eller hvad med alternativer til nagios, forslag til noget
jeg skal se på her?



/Morten

---

Morten Guldager wrote:
> Når jeg kommer op på 5000 hosts med et par services hver, så går det
> meget trægt.

Er det Nagios 2 eller 3? Så vidt jeg ved, er én af Nagios 3's mål at gøre
Nagios mere skalérbart.

--
Troels

---

Troels Arvin wrote:
> Morten Guldager wrote:
>> Når jeg kommer op på 5000 hosts med et par services hver, så går det
>> meget trægt.
>
> Er det Nagios 2 eller 3? Så vidt jeg ved, er én af Nagios 3's mål at gøre
> Nagios mere skalérbart.
>
Absolut - Men hvordan checker du alle hostene ???
Er det med aktive checks på alle - så er der absolut noget at tjekke op på.
Jeg ville kigge på mulighederne med NSCA - som er det jeg har erfaringer
med supervision på flere lokationer - eftersom man så "reelt" laver en
lokal install - hver lokation som der så tjekker og sender result til
masterhosten.

Men i nagios3 har de lavet mange extra muligheder omkring hvordan
host/services skal tjekkes. Men hvis du har 5000 hosts - så er det vel
ikke alle på samme lokation!

---

2009-04-14 Per Jørgensen wrote
> Troels Arvin wrote:
>> Morten Guldager wrote:
>>> Når jeg kommer op på 5000 hosts med et par services hver, så går det
>>> meget trægt.
>>
>> Er det Nagios 2 eller 3? Så vidt jeg ved, er én af Nagios 3's mål at gøre
>> Nagios mere skalérbart.

Nagios 3

> Absolut - Men hvordan checker du alle hostene ???

Pt er det aktivt, men som jeg skrev, så er et bare med et dagligt ping.
Langt det meste af tiden står serveren bare og venter.

Det hvor flaskehalsen for alvor bliver kritisk er den centrale web flade,
helt præcist tac.cgi. Den er pt. 3 sekunder om at vise forsiden. Og den del
kan vel ikke splittes op på flere instanser?

> Er det med aktive checks på alle - så er der absolut noget at tjekke op på.
> Jeg ville kigge på mulighederne med NSCA - som er det jeg har erfaringer
> med supervision på flere lokationer - eftersom man så "reelt" laver en
> lokal install - hver lokation som der så tjekker og sender result til
> masterhosten.
>
> Men i nagios3 har de lavet mange extra muligheder omkring hvordan
> host/services skal tjekkes. Men hvis du har 5000 hosts - så er det vel
> ikke alle på samme lokation!

Well, det er i test-lab hvor jeg er ved at undersøge hvordan skidtet skalerer.
Jeg er med på at jeg kan dele test-arbejdet ud på flere maskiner, men de sender
jo så al deres output ind til en central kasse som skal vise mig hvor mange af
mine 5000 noder der er gået ned. Og der er her, inde i min NOC, det går galt.

Jeg gætter på at det bunder i at Nagios ikke bruger en "rigtig" database
til sit husholdning, men bare har et par mega store tekstfiler som tac.cgi
scanner igennem hver gang den skal vise mig et eller andet.


/Morten

---

Morten Guldager wrote:
> 2009-04-14 Per Jørgensen wrote
>> Troels Arvin wrote:
>>> Morten Guldager wrote:
>>>> Når jeg kommer op på 5000 hosts med et par services hver, så går det
>>>> meget trægt.
>>> Er det Nagios 2 eller 3? Så vidt jeg ved, er én af Nagios 3's mål at gøre
>>> Nagios mere skalérbart.
>
> Nagios 3
>
>> Absolut - Men hvordan checker du alle hostene ???
>
> Pt er det aktivt, men som jeg skrev, så er et bare med et dagligt ping.
> Langt det meste af tiden står serveren bare og venter.
>
> Det hvor flaskehalsen for alvor bliver kritisk er den centrale web flade,
> helt præcist tac.cgi. Den er pt. 3 sekunder om at vise forsiden. Og den del
> kan vel ikke splittes op på flere instanser?
>
>> Er det med aktive checks på alle - så er der absolut noget at tjekke op på.
>> Jeg ville kigge på mulighederne med NSCA - som er det jeg har erfaringer
>> med supervision på flere lokationer - eftersom man så "reelt" laver en
>> lokal install - hver lokation som der så tjekker og sender result til
>> masterhosten.
>>
>> Men i nagios3 har de lavet mange extra muligheder omkring hvordan
>> host/services skal tjekkes. Men hvis du har 5000 hosts - så er det vel
>> ikke alle på samme lokation!
>
> Well, det er i test-lab hvor jeg er ved at undersøge hvordan skidtet skalerer.
> Jeg er med på at jeg kan dele test-arbejdet ud på flere maskiner, men de sender
> jo så al deres output ind til en central kasse som skal vise mig hvor mange af
> mine 5000 noder der er gået ned. Og der er her, inde i min NOC, det går galt.
>
> Jeg gætter på at det bunder i at Nagios ikke bruger en "rigtig" database
> til sit husholdning, men bare har et par mega store tekstfiler som tac.cgi
> scanner igennem hver gang den skal vise mig et eller andet.
>
>
> /Morten
Jamen hov - hvis du mener det - så er det jo bare at ændre dette . det
understøtter Nagios3 specifikt - at man bruger en database fremfor andet!

Derudover - er det jo generelt hvis den skal sende 5000ping mm og sende
svar - så er det noget omsonst at bruge 1maskine til dette

---

2009-04-14 Per Jørgensen wrote
> Morten Guldager wrote:
>> 2009-04-14 Per Jørgensen wrote
>>> Troels Arvin wrote:
>>>> Morten Guldager wrote:
>>>>> Når jeg kommer op på 5000 hosts med et par services hver, så går det
>>>>> meget trægt.
>> ...
>> Nagios 3
>> ...
>>> Absolut - Men hvordan checker du alle hostene ???
>> ...
>> Pt er det aktivt, men som jeg skrev, så er et bare med et dagligt ping.
>> Langt det meste af tiden står serveren bare og venter.
>> ...
>> Jeg gætter på at det bunder i at Nagios ikke bruger en "rigtig" database
>> til sit husholdning, men bare har et par mega store tekstfiler som tac.cgi
>> scanner igennem hver gang den skal vise mig et eller andet.
>> ...
> Jamen hov - hvis du mener det - så er det jo bare at ændre dette . det
> understøtter Nagios3 specifikt - at man bruger en database fremfor andet!

Jo, jeg kunne kode visnings-delen om så den brugte en database, men
der er jo en grund til at jeg ser på nagios frem for at kode et system
selv. Jeg er bestemt ikke nogen ørn til at kode web baserede bruger interfaces.

> Derudover - er det jo generelt hvis den skal sende 5000ping mm og sende
> svar - så er det noget omsonst at bruge 1maskine til dette

Well, det er ikke noget problem at pinge 5000 objekter hvert minut og
registrere ændringerne i en database. Det vil være en smal sag at kode i
perl med fping som "arbejder".

Med nagios' lidt klodsede ide om at hver test skal klares af en separat
process, så bliver det hurtigt til en enorm masse fork og exec.
Her kunne man jo godt se op en indlejret perl løsning, som da også er min
plan på længere sigt.

Men husk på at jeg i test-lab blot pinger en enkelt gang i døgnet, netop
for at udelukke flaskehalse i den ende af kæden.

Så min bekymring er stadig frontend'en. Den synes jeg hurtigt går i knæ.


/Morten

---

Morten Guldager wrote:
> 2009-04-14 Per Jørgensen wrote
>> Morten Guldager wrote:
>>> 2009-04-14 Per Jørgensen wrote
>>>> Troels Arvin wrote:
>>>>> Morten Guldager wrote:
>>>>>> Når jeg kommer op på 5000 hosts med et par services hver, så går det
>>>>>> meget trægt.
>>> ...
>>> Nagios 3
>>> ...
>>>> Absolut - Men hvordan checker du alle hostene ???
>>> ...
>>> Pt er det aktivt, men som jeg skrev, så er et bare med et dagligt ping.
>>> Langt det meste af tiden står serveren bare og venter.
>>> ...
>>> Jeg gætter på at det bunder i at Nagios ikke bruger en "rigtig" database
>>> til sit husholdning, men bare har et par mega store tekstfiler som tac.cgi
>>> scanner igennem hver gang den skal vise mig et eller andet.
>>> ...
>> Jamen hov - hvis du mener det - så er det jo bare at ændre dette . det
>> understøtter Nagios3 specifikt - at man bruger en database fremfor andet!
>
> Jo, jeg kunne kode visnings-delen om så den brugte en database, men
> der er jo en grund til at jeg ser på nagios frem for at kode et system
> selv. Jeg er bestemt ikke nogen ørn til at kode web baserede bruger interfaces.
>
>> Derudover - er det jo generelt hvis den skal sende 5000ping mm og sende
>> svar - så er det noget omsonst at bruge 1maskine til dette
>
> Well, det er ikke noget problem at pinge 5000 objekter hvert minut og
> registrere ændringerne i en database. Det vil være en smal sag at kode i
> perl med fping som "arbejder".
>
> Med nagios' lidt klodsede ide om at hver test skal klares af en separat
> process, så bliver det hurtigt til en enorm masse fork og exec.
> Her kunne man jo godt se op en indlejret perl løsning, som da også er min
> plan på længere sigt.
>
> Men husk på at jeg i test-lab blot pinger en enkelt gang i døgnet, netop
> for at udelukke flaskehalse i den ende af kæden.
>
> Så min bekymring er stadig frontend'en. Den synes jeg hurtigt går i knæ.
>
>
> /Morten
OK.
Jeg har max været oppe på 1000host - men hvor jeg tjekkede disc,RAM og
load - plus diverse services som SSH,web,tfp,tomcat mm. og der har jeg
nu ikke haft problemer. Men tja kunne man evt tveake Apache til at holde
til det det? For tja - Det må så også være et stort netværk på
webinterfacet. Normalt syntes jeg det tager da lidt tid - men også at
den generer hver for sig.

Normalt har jeg ikke brugt det's videre indtastningsmuligheder via
Webinterfacet - men altid redigeret opsat det i hånden. MEN kan da godt
se det må tage lidt tid.
Nu tænker du så kun på webdelen, og der må jo kunne lege med apache på
nogle måder - men det er jeg ikke inde i.

P

---

Hej,

Morten Guldager <spamtrap@mogul.dk> writes:
> Sidder her og kokser lidt rundt med Nagios i et test-lab.
>
> Når jeg kommer op på 5000 hosts med et par services hver,
> så går det meget trægt. Det sker selv om jeg bare beder den
> om at checke hosts/services en gang i døgnet.
>
> Selve web frontenden bliver træls langsom at danse med.
>
> Jeg har forsøgt at flytte databasefilerne over på en ramdisk,
> men det gav ikke rigtig noget.
>
> Nogen der har erfaringer i samme boldgade?
>
> Eller hvad med alternativer til nagios, forslag til noget
> jeg skal se på her?


Jeg har gode erfaringer med Opsview¹, der integrerer Nagios, RRDTool,
Net-SNMP mf. i et samlet framework, hvor konfiguration, status og
historik gemmes i MySQL.

¹) http://www.opsview.org/


/Claus A

---

2009-04-14 Claus Albøge wrote
> Hej,
>
> Morten Guldager <spamtrap@mogul.dk> writes:
>> Sidder her og kokser lidt rundt med Nagios i et test-lab.
>>
>> Når jeg kommer op på 5000 hosts med et par services hver,
>> så går det meget trægt. Det sker selv om jeg bare beder den
>> om at checke hosts/services en gang i døgnet.
>>
>> Selve web frontenden bliver træls langsom at danse med.
>
> Jeg har gode erfaringer med Opsview¹, der integrerer Nagios, RRDTool,
> Net-SNMP mf. i et samlet framework, hvor konfiguration, status og
> historik gemmes i MySQL.

Perfekt. den må jeg da prøve så. Min mistanke er dog at det går præcis
lige så galt, da den del jeg har problemer med, nemlig nagios's .cgi'er
formodentlig er de samme. Men det er dog ikke lige til at se ud fra
de screenshots der er tilgængelige, så en test skal der til.

Har du prøvet en opsview installation med 5000+ objekter i datbasen?


/Morten

---

Morten Guldager skrev:
> 2009-04-14 Claus Albøge wrote
>> Hej,
>>
>> Morten Guldager <spamtrap@mogul.dk> writes:
>>> Sidder her og kokser lidt rundt med Nagios i et test-lab.
>>>
>>> Når jeg kommer op på 5000 hosts med et par services hver,
>>> så går det meget trægt. Det sker selv om jeg bare beder den
>>> om at checke hosts/services en gang i døgnet.
>>>
>>> Selve web frontenden bliver træls langsom at danse med.
>> Jeg har gode erfaringer med Opsview¹, der integrerer Nagios, RRDTool,
>> Net-SNMP mf. i et samlet framework, hvor konfiguration, status og
>> historik gemmes i MySQL.
>
> Perfekt. den må jeg da prøve så. Min mistanke er dog at det går præcis
> lige så galt, da den del jeg har problemer med, nemlig nagios's .cgi'er
> formodentlig er de samme. Men det er dog ikke lige til at se ud fra
> de screenshots der er tilgængelige, så en test skal der til.
>
Det er vel også tungt for en browser at vise en tabel med 5000 rækker.
For ikke at tale om uoverskuelighed for en bruger.

Big Brother, som jeg ikke har set på i lang tid, har mulighed for
undersider.

Så man starter med en hovedside, der viser rød, hvis der er something
rotten in the state of Denmark.

Så kan man klikke sig videre på undersider for Sjælland, Helsingør,
indtil man ser at fejlen er et utæt nedløbsrør i kælderen ved siden af
Holger

Så hvis det er størrelsen af tabeller, der er et problem, så skal man
måske tænke på at at bryde det ned i overskuelige størrelser.


Ikke at det lyder som problemet her, men man kan jo have flere servere,
der hver checkker en del af serverne, og blot rapporterer opad om der er
et problem eller ej på de servere, de overvåger.

Leif

---

Hej,

Morten Guldager <spamtrap@mogul.dk> writes:
> 2009-04-14 Claus Albøge wrote
>> Morten Guldager <spamtrap@mogul.dk> writes:
>>> Sidder her og kokser lidt rundt med Nagios i et test-lab.
>>>
>>> Når jeg kommer op på 5000 hosts med et par services hver,
>>> så går det meget trægt. Det sker selv om jeg bare beder den
>>> om at checke hosts/services en gang i døgnet.
>>>
>>> Selve web frontenden bliver træls langsom at danse med.
>>
>> Jeg har gode erfaringer med Opsview¹, der integrerer Nagios, RRDTool,
>> Net-SNMP mf. i et samlet framework, hvor konfiguration, status og
>> historik gemmes i MySQL.
>
> Perfekt. den må jeg da prøve så. Min mistanke er dog at det går præcis
> lige så galt, da den del jeg har problemer med, nemlig nagios's .cgi'er
> formodentlig er de samme. Men det er dog ikke lige til at se ud fra
> de screenshots der er tilgængelige, så en test skal der til.

Opsview kommer med sin egen web-application-server, som man normalt
gemmer bag Apache. Der er eksempler¹ på at smidde lighttpd+FastCGI
imellem, for hurtigere UI respons - det har jeg dog ikke haft brug for
(endnu).

> Har du prøvet en opsview installation med 5000+ objekter i datbasen?

Nej, pt er der lige under 1000 (hosts+services). Men lad endelig høre
hvad du kommer frem til.

¹) http://docs.opsview.org/doku.php?id=opsview3.0:fastcgi


/Claus A