Hoe bereken je de uptime van de laatste 24 uur?

[gepebril]

Hallo,

Ik heb een ontwerp uitdaging. Ik heb een x aantal machines welke zich elke minuut melden door een record in een centrale Database te updaten. Éen van die velden van dat record is een timestamp.

Nu zijn er natuurlijk af en toe netwerkstoringen en dan krijgt dat record van die machine geen nieuwe timestamp. Nu heb ik al een script dat elke minuut kijken of die timestamp wordt geupdate en indien dat te lang niet wordt gedaan dan wordt er een warning mail gegenereerd.

Nu blijkt echter dat er machines zijn die veel Internet drops hebben, echter welke minder lang zijn dan mijn alarm threshold. Om die "te detecteren" denk ik aan uptime registratie. Elke keer als een machine zich per minuut meldt krijgt hij een '1' erbij in een soort lange binaire string. Zo zou je eenvoudig het percentage uptime kunnen berekenen en ook zien wanneer er drops geweest zijn. Alleen is het niet makkelijk te werken met een binaire string van 1440 bits (bitwise operations enzo)

Is dit een slimme methode, om dit zo te doen, of zijn er veel makkelijkere methodieken om dit aan te pakken? Wie weet raad?


Alvast bedankt.

[Woy]

Je kan toch gewoon elke check een record in een tabel wegschrijven en dan aan het eind van de dag een Count doen?

Of als de tijden niet van belang zijn, gewoon elke keer een counter ophogen?

[ Voor 26% gewijzigd door Woy op 05-10-2012 13:24 ]

[Rmg]

Voeg je toch een timestamp toe waarin je de vorige update tijd inzet. Dan kan je als je de tabel update gelijk meesturen hoelang er tussen zat.

[gepebril]

Woy schreef op vrijdag 05 oktober 2012 @ 13:24:
Je kan toch gewoon elke check een record in een tabel wegschrijven en dan aan het eind van de dag een Count doen?

Of als de tijden niet van belang zijn, gewoon elke keer een counter ophogen?

Inderdaad, zo had ik het nog niet gezien. Dus voor minuut een record aanmaken, en die na x dagen weer verwijderen. En dan in het veld van het status record per machine ene uptime percentage bijhouden dat je door een ander proces elke x minuten laat berekenen. Eventueel als je wilt kun je dan ook nog een grafiek maken van de laatste 24 uur indien zinvol.

Top!

[ Voor 7% gewijzigd door gepebril op 05-10-2012 14:04 ]

[__fred__]

Dat is wel een hele grote tabel voor een uptime berekening.

Denk erover als een state machine met twee states. Online of Offline. Schrijf een record weg indien je van state verandert (offline -> onlline, online -> offline) en de einddatumtijd in het vorige.

Ik zou in die records serverID, starttijd, eindtijd en state (online, offline) wegschrijven. Dat is wellicht wat redundant want eindtijd vorige record = starttijd nieuw record, maar het is verschrikkelijk handig met rekenen.

[ Voor 3% gewijzigd door __fred__ op 06-10-2012 11:34 . Reden: verduidelijkt ]

[ACM]

__fred__ schreef op zaterdag 06 oktober 2012 @ 11:21:
Dat is wel een hele grote tabel voor een uptime berekening.

Dan groepeer je 'm op voorhand per dag of per uur:
Uptime registratie wordt dan zoiets (even in mysql-syntax omdat die zowaar hier een aardige oplossing voor heeft):

code:

INSERT INTO uptimetabel
SET serverid = X, ..., daystamp = CURRENT_DATE, 
     lastupdate = CURRENT_TIMESTAMP, counter = 1
ON DUPLICATE KEY
UPDATE
lastupdate = CURRENT_TIMESTAMP,
counter = counter + 1

In bovenstaande voorbeeld zit er dan een unique/primary key op de serverid+daystamp. Als die counter niet gelijk is aan het aantal minuten tot nu toe, dan weet je dat er een stukje uptime mist (als er uberhaupt geen record is uiteraard ook ).

[Verwijderd]

Overweeg even de mogelijkheid om een RRD te gebruiken. Zo kun je ook netjes bijhouden wanneer er een onderbreking was.

[Gomez12]

ACM schreef op zaterdag 06 oktober 2012 @ 18:32:
[...]
Uptime registratie wordt dan zoiets (even in mysql-syntax omdat die zowaar hier een aardige oplossing voor heeft):

code:

INSERT INTO uptimetabel
SET serverid = X, ..., daystamp = CURRENT_DATE, 
     lastupdate = CURRENT_TIMESTAMP, counter = 1
ON DUPLICATE KEY
UPDATE
lastupdate = CURRENT_TIMESTAMP,
counter = counter + 1

In bovenstaande voorbeeld zit er dan een unique/primary key op de serverid+daystamp. Als die counter niet gelijk is aan het aantal minuten tot nu toe, dan weet je dat er een stukje uptime mist (als er uberhaupt geen record is uiteraard ook ).

Toch zou ik er voor kiezen om per dag alle metingen te behouden en dan 's nachts het geheel te archiveren naar een online-offline tabel . 1440 records per dag per server is geen probleem voor een db-server (zolang je maar tijdig archiveert).
En een online-offline tabel kost je per server per dag max 1 record als hij 100% up is terwijl je toch 100% van je scanningsresolutie behoud.

Met jouw oplossing wordt je resolutie opeens nog maar 1 dag.terwijl je eigenlijk wil weten waar op de dag het fout ging als je 3 weken lang 10 counts mist.
Die 10 missende counts zijn een luxe-probleem als ze optreden om 06:00 (en je bedrijf van 08:00 tot 17:00 werkt en je backup om 03:00 klaar is etc) maar zijn een major probleem als ze om 16:00 optreden en er daardoor simpelweg orders kwijtraken.

[gepebril]

Verwijderd schreef op zaterdag 06 oktober 2012 @ 18:39:
Overweeg even de mogelijkheid om een RRD te gebruiken. Zo kun je ook netjes bijhouden wanneer er een onderbreking was.

Wat is een RRD als ik vragen mag?

[gepebril]

Wat een interessante ingevingen allemaal. Hartelijk dank daarvoor!

Ik heb er voor gekozen per systeem elke minuut een record aan te maken (1440 pdag) en deze na 48 uur weg te gooien. Daarnaast bereken ik elke 15 minuten de uptime per machine en sla deze waarde op in het status record per machine, wat een andere tabel is. Doordat ik alle records opsla kan ik eventueel later een grafiek produceren en gericht onderzoek doen naar de problemen bij de Internetverbindingen vanaf één centraal punt dan alle loggingen van de individuele machines door te spitten.

De routines zijn inmiddels met Perl (berekenen en storage) /PHP (weergave op website) gemaakt en draaien al bijna 24hr probleemloos

[ Voor 4% gewijzigd door gepebril op 09-10-2012 13:36 ]

[geforce5_guy]

Is het niet handig om te weten wanneer het er uit ligt? Dat je dus alleen de tijden bewaarde wanneer je storing hebt .
Dan kan je ook eenvoudig zien wanneer op de dag het er uit ligt en is het misschien eenvoudiger de reden te achterhalen.

[gepebril]

@geforce5_guy

Indien ik elke minuut een record aanmaak dan registreer ik toch als het goed gaat en als het niet goed gaat. Dus indien er de afgelopen minuut een update is geweest, schrijf ik een True weg, is die er niet geweest een false. En dat met timestamp

[DrClaw]

Wikipedia: RRDtool

RRD staat voor round-robin database, en wordt ontzettend vaak gebruikt om servermonitoring te doen. rrdtool maakt dan weer mooie plaatjes van die rrd's.

[DiedX]

Zabbix maakt hierbij gebruik van RRD voor graphs, en een database voor opslag.

Ze schrijven niet *ELKE* check weg in de database, alleen updaten ze het laatste record als de check succesvol was. Indien niet, dan komt er een regel bij, en daarvanuit genereren ze de RRD.