ntpd

Sven Orf sven_orf at hotmail.de
Di Aug 21 13:17:05 CEST 2018


Also

kann und wird die Zeit benutzt und über die Ntp Zeit eine einigermaßen genaue Systemzeit zu verteilen und diese kann auch zur sekunden genauen validierung genutzt werden.

Gruß Sven

________________________________
Von: mail at adrianschmutzler.de
Gesendet: 21. August 2018 11:24:24 MESZ
An: 'Dominik Heidler' <dominik at heidler.eu>, 'Freifunk Franken' <franken at freifunk.net>, 'Sven Orf' <sven_orf at hotmail.de>, 'Robert Langhammer' <rlanghammer at web.de>
Betreff: RE: ntpd


Hallo Dominik,

ich verwende die Routerzeit, um einem speziellen Problem zu entgehen:

In V2 haben wir nicht mehr die Netmon-VM als Quelle für die Alfred-Daten, sondern ZWEI Gateways pro Hood, die ihren jeweiligen Stand der Alfred-Daten schicken. Da die GWs nicht verbunden sind, kommt es gelegentlich zu Synchronisationsproblemen.

Hat also ein GW nicht die aktuellen Daten eines Routers bekommen, so schickt es nach fünf Minuten nochmal die ALTEN Daten an das Monitoring. Das führt dann dazu, dass das Monitoring erst einen neuen, und dann einen alten Datensatz bekommt. Das Monitoring tut dann u.U. komische Dinge, z.B. loggt es einen Neustart, weil die uptime dadurch kleiner wird.
Wenn ich mich richtig erinnere war das damals der Grund, warum wir eine Zeit lang bei vielen Geräten dauernd Reboots geloggt hatten.

Zur Lösung des Ganzen überprüfe ich bei jedem neuen Datensatz, ob die Systemzeit eines Routers größer ist als die, die schon in der Datenbank steht. Wenn nicht, wird der alfred-Datensatz verworfen. Um ntp-Probleme zu berücksichtigen, nehme ich zudem jedem Datensatz, wo die neue Zeit mehr als eine Stunde vor der alten Zeit liegt. Im Code steht das hier:

https://github.com/FreifunkFranken/fff-monitoring/blob/master/ffmap/routertools.py#L84

Insgesamt ist es leider so, dass das V2-System am Monitoring einiges "komplexer" gemacht hat. Der Vorteil ist im Gegenzug, dass jetzt nicht mehr alle Daten auf einmal kommen und wir zudem Redundanz haben (früher war Netmon tot=Monitoring tot). Dafür muss(te) ich mir auf der anderen Seite enorm Gedanken machen, dass es keine deadlocks gibt, wenn Daten gleichzeitig ankommen oder die Datenbank mal langsam ist.
Dies war tatsächlich auch meine Hauptbeschäftigung nach dem "Umzug" auf MySQL. Inzwischen sind die entsprechenden Maßnahmen aber ganz gut optimiert (ich habe am Anfang natürlich auch viel schlechte Workarounds gebaut), sodass fast keine Probleme mehr auftauchen.

Wurde jetzt doch ne recht lange Antwort, naja ...

Beste Grüße

Adrian



 -----Original Message-----
 From: Dominik Heidler [mailto:dominik at heidler.eu]
 Sent: Dienstag, 21. August 2018 10:08
 To: Freifunk Franken <franken at freifunk.net>; Adrian Schmutzler
 <mail at adrianschmutzler.de>; 'Sven Orf' <sven_orf at hotmail.de>; 'Robert
 Langhammer' <rlanghammer at web.de>
 Subject: Re: ntpd

 Hi,

 Am 17.08.2018 um 16:11 schrieb Adrian Schmutzler:
 Fürs Monitoring ist es wichtig, dass die Zeit stimmt. Nicht sekundengenau,
 aber auch nicht zu viel Offset.

 Wo verwenden wir denn im Monitoring die Routerzeit? IIRC verwenden wir
 nur die Uptime.

 Grüße,
 Dominik

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20180821/f38e5854/attachment.html>


Mehr Informationen über die Mailingliste franken