Nagios service unavailable

[mbreet]

De afgelopen weken merk ik dat Nagios bij vlagen onbereikbaar is. Het opvragen van de pagina duurt erg lang, als dit al slaagt.

In de meeste gevallen volgt er een HTTP 503 error (service niet beschikbaar) in een enkel geval krijg ik eerst wel overzicht van hosts maar loopt zaak daarna vast.

Geprobeerd met verschillende devices, browsers, netwerklocaties maar telkens zelfde verschijnselen.

[marc]

Ik kan dit bevestigen.

[ed]

Interface op Unigorn waaraan ook sunny is verbonden is up. Echter geen ping/link naar de server Sunny.
Er zal terplekke gekeken moeten worden bij de server om de verbinding te controleren tussen UnigorN en Sunny.

De backup Sunnysidekick is helaas ook niet bereikbaar omdat NodeHuub en de Nanostations waar deze mee verbonden niet bereikbaar
zijn via het WL netwerk (Vosko2 en Cetim2 zijn wel up)

[marc]

Door dit probleem heb ik al twee weken geen Nagios checks kunnen doen. :-(

[rick]

Ik ben een alternatief op aan het zetten welke via een VPN verbinding bij HybridRick binnenkomt. Je kan deze hier bewonderen:

​http://vmon.vanderzwet.net/nagios/

Ik moet hem nog een beetje fine-tunen zodat alle foutmeldingen weggaan.

[marc]

Whooopie!

[marc]

Dat is aardig gelukt zeg.
De oude Nagios had een lijst van heb ik jou daar met down nodes, deze heeft er nog maar 8. Wel allemaal van vandaag helaas.

[rick]

Grootste deel van de obvious foutmeldingen weggegooid, moet echter nog wel de lvrouted.opt foutmelding weghalen en het gros van de disk warnings. Hiervoor moet ik op alle nodes de snmpd.conf aanpassen, dus dat is denk een leuk klusje voor vanavond.

[rick]

De warnings en errors die over zijn vallen in de categorie: "hier is onderzoek benodigd". mav werk aan de winkel.

[rick]

Ben langzaam begonnen wat grafieken toe te voegen voor de relevante entries, zodat het makkelijker op afstand te zien is wat de history is.

[ed]

Aan de hand van de meldingen op de alternative nagios veel nodes nagelopen en services gestart / herstart etc.
Er zijn een heel aantal meldingen over disk problemen en processes die niet zouden draaien maar daar zit nog
een verbeter puntje in. Waarschijnlijk omdat we met verschillende versies van de node fabriek werken zijn
de disk formaten niet hetzelde en wordt sommige processen die wel draaien op de node niet herkend.

Bij deze nodes staat of een zwart vinkje (ackownledge) en / of een tekst wolkje met commentaar omtrend de storing.

[ed]

Ik heb op de beheer pagina de link en informatie aangepast naar de
nieuwe nagios pagina

[ed]

Ik heb zo goed als alle nodes nagelopen welke voorkwamen in nagios met service meldingen zoals disk sizes
en processen etc dit niet goed waren. Zoals ik het nu kan zien zijn de storingen die nu nog open staat die
daad werkelijk die aandacht nodig hebben.

[mbreet]

Er zijn op dit moment 375 meldingen in tijdelijke Nagios. Deel is wel bevestigd/bekend echter rest dus niet.

Het overzicht wat ik gebruik is dat onder Problems > Services en dan oplopend gesorteerd op duration.

Met huidige resultaat van 375 meldingen raak ik door het aantal zicht kwijt op zaken die echt een ticket verdienen. Hoe staat het met reboot van normale Nagios?

[rick]

Replying to mbreet:

Er zijn op dit moment 375 meldingen in tijdelijke Nagios. Deel is wel bevestigd/bekend echter rest dus niet.

De unknowns komen doordat SNMP niet draait, dit ansich is geen critical issue ik zal deze toevoegen.

Het overzicht wat ik gebruik is dat onder Problems > Services en dan oplopend gesorteerd op duration.

Ik had Problems -> Unhandled gebruikt met je duration filter:

​http://vmon.vanderzwet.net/nagios/cgi-bin/status.cgi?host=all&servicestatustypes=16&hoststatustypes=3&serviceprops=42&sorttype=1&sortoption=6&sorttype=2&sortoption=6

Met huidige resultaat van 375 meldingen raak ik door het aantal zicht kwijt op zaken die echt een ticket verdienen. Hoe staat het met reboot van normale Nagios?

Als je de filter boven gebruik, dan is dit aantal gereduceerd tot 2. Dit lijkt me weer redelijk te behappen.

[huub]

Ik lees nu mijn mail van 1 mei: sunny heeft een harde reboot gehad op 1 mei, maar dat heeft kennelijk niet geholpen. Een mogelijkheid is dat de glasvezelverbinding tussen sunny en zijn nanostation (met utp-glas converters) stuk is.

[huub]

Naast de vmon.vanderzwet.net/nagios/ is nu ook sunnysidekick-nagios weer bereikbaar op wleiden.net (​http://172.16.3.22/nagios/ inloggen met nagiosadmin en nanostation pwd). De portforwarding op mijn internetrouter naar sidekick heb ik nog niet aan de praat gekregen, dus niet bereikbaar helaas vanaf internet. Tenzij je een achterdeurtje gebruikt met socks proxy.

[huub]

Check disk geeft soms een melding en soms niet over te volle disk. Limiet staat kennelijk op 85%, standaard zit /dev/ada0s1a op 87%. Ik zou dus eigenlijk altijd een melding moeten krijgen. Beter natuurlijk om die grens aan te passen. Anderzijds is de check op de flashkaart niet zo zinvol (probleem zijn de md's).

[huub]

Ik mis de internet-check-alive. Dat is eigenlijk voor de gebruikers de meest belangrijke en een beetje 'catch all' check voor routing, dns, gateway. Op dit moment kun je nu bijv. niet zien dat de nodes rond VisitorCentre geen internetverbinding hebben (Geluidsnet, Cope, Lebkov, VisitorCentre, Catwalk,...)

[huub]

De nanostations worden niet meer gecheckt, dat was toch ook wel handig.

[ed]

Replying to huub:

Check disk geeft soms een melding en soms niet over te volle disk. Limiet staat kennelijk op 85%, standaard zit /dev/ada0s1a op 87%. Ik zou dus eigenlijk altijd een melding moeten krijgen. Beter natuurlijk om die grens aan te passen. Anderzijds is de check op de flashkaart niet zo zinvol (probleem zijn de md's).

Ik zal hier vandaag naar kijken door op de betreffende nodes de juiste snmpd.conf uit te rollen.

[ed]

Replying to ed:

Replying to huub:

Check disk geeft soms een melding en soms niet over te volle disk. Limiet staat kennelijk op 85%, standaard zit /dev/ada0s1a op 87%. Ik zou dus eigenlijk altijd een melding moeten krijgen. Beter natuurlijk om die grens aan te passen. Anderzijds is de check op de flashkaart niet zo zinvol (probleem zijn de md's).

Ik zal hier vandaag naar kijken door op de betreffende nodes de juiste snmpd.conf uit te rollen.

Vandaag op de nodes de aangepaste snmpd.conf uitgerold. Sommige met de hand aangepast omdat
deze net iets anders zijn opgebouwd dan de meeste nodes