Monitoring von einzelnen Knoten?

Communities Karlsruhe
1

Hi,

ich würde gerne meine eigenen ffka-Knoten mit Check-MK überwachen. Allerdings sind sie von meinem Monitoring-Server aus nicht erreichbar, so daß ich das auf dem Umweg über die Statistikserver machen muß. Die interessanten, zu überwachenden Daten wie Status, Uptime, Teil_des_Netzes_seit, Arbeitsspeicher und Clients werden ja insbesondere in der Infobox zu den Knoten auf der Karte schön dargestellt. Aber ich habe gerade nicht wirklich einen Plan, wie ich da abseits des Browsers rankomme.

Gibt es Erfahrungswerte oder Empfehlungen, wie diese Daten überwacht werden können bzw. auch von welchen Auswertungen besser Abstand genommen werden sollte? Auch gerne bezogen auf andere Monitoring-Lösungen.

Danke!
Bongosmurf

2

Hi @bongosmurf,
Du kannst einfach auf die zugrunde liegenden Daten im JSON Format zugreifen:

https://karlsruhe.freifunk.net/json/nodelist.json und
https://karlsruhe.freifunk.net/json/nodes.json

Hier solltest Du alle benötigten Informationen für ein Monitoring-Script finden können. Ich kann Dir aber nicht sagen, ob jemand schonmal so ein Montoring-Script geschrieben hat :smiley:

Viele Grüße,
Twi

3

Hi @Twi
danke, da ist in der Tat alles drin. :slight_smile:

Ich nehme an, es gibt keine API, über die nur die Daten von einzelnen Knoten abfragbar sind? Das wäre etwas weniger unhandlich, besonders da die Community ja auch wachsen kann.

Wie dem auch sei, das kriege ich geparsed.

LG,
bongosmurf

4

Hey @bongosmurf,

was genau willst du denn monitoren und warum? Geht es dir nur um eine Aufzeichnung der Daten? Dann gibt es die bereits für alle Knoten unter http://graph.ffka.net/#/dashboard/file/pernode.json. Einfach oben wo der Entropia-Knoten ausgewählt ist den Namen deines Knotens eintippen. Außerdem loggt der Bot im IRC einige Daten und announced neue Knoten sowie Änderungen an bestehenden Knoten (ersteres im “Hauptchannel”, letzteres in einem seperaten Channel um weniger zu spammen). Notifications oder Überwachung für einzelne Knoten kann er noch nicht, wäre aber ein nachrüstbares Feature.

Bzgl der Erreichbarkeit der Daten von deinem Monitoringserver: Sofern selbiger IPv6 spricht solltest du jeden Knoten über seine IPv6 Adresse erreichen können. Dort kannst du die Daten entweder von der Statusseite parsen oder dir die Daten in beliebigem Format (JSON und XML kann das Skript iirc out-of-the-box, alle anderen Formate müsste man konvertieren) irgendwo ins Webroot legen.

Grüße
psy

5

Moin @psy ,

warum sollte man per IPV6 besser durch eine FW kommen als per IPV4?

Grafana ist mir schon bekannt, aber da weiß ich nicht, wie ich einfach geskriptet Daten abziehen kann. Das anzuschauen ist nett im Sinne von Reporting, aber für Monitoring und Alerting taugt das nicht.

Da ich die Knoten selbst nicht oder wenig nutze, sondern meine Gäste, möchte ich mitbekommen, wenn etwas ausfällt und ich ggf. Hand anlegen muß.

Anhand von Kriterien wie online, lastcontact, uptime, clients, die ich aus https://karlsruhe.freifunk.net/json/nodes.json ziehen kann, lässt sich da schon ein gutes Bild machen. Was noch mehr helfen würde, wäre der Trafficdurchschnitt der letzten 5 Minuten, aber der lässt sich auch am Monitoringserver errechnen.

Was mich an der Lösung stört, ist der große Overhead. Die Datenmenge in dem JSON-File ist im Verhältnis zu den benötigten Infos riesig und wächst mit jedem neuen Knoten. Auch das Auswerten auf dem Monitoringserver ist unnötig teuer.

Ich betreibe auch ein paar RIPE Atlas Probes und monitore die über den zentralen RIPE Atlas Server. Dort habe ich die Möglichkeit, die gewünschten Attribute nodespezifisch abzurufen, was eine sehr überschaubare Datenmenge und -struktur liefert z.B. https://atlas.ripe.net/api/v1/probe/39/?format=json&fields=status_name,status_since,id
Sowas wäre toll. Die Feldselektion wäre gar nicht so wichtig, aber ein Datenabruf pro Knoten, das wär’s!

Im Grafana ist ja auch die Gesamtstatistik verfügbar http://graph.ffka.net/#/dashboard/file/ffka.json in der man zufällig just im Augenblick auch einen Ausfall zu erkennen scheint. Gibt es die zugrundeliegenden Daten auch irgendwo zum Abruf? Für die Beurteilung im Monitoring, ob es sich um einen lokalen oder zentralen Ausfall handelt wären die hilfreich.

Wie kommt eigentlich die Node-ID zustande und wie persistent ist sie? Ist klar, dass der Knotenname serverseitig als Primärschlüssel nicht taugt, aber da ich den (besser) kenne, ist das aktuell mein Selektionskriterium.

Grüßle,
bongosmurf

6

Hi @bongosmurf,

Beim IPv6, IPv4 Thema geht es nicht um irgendeine Firewall. Die Knoten haben schlichtweg keine v4 Adresse, dafür hat jeder Koten seine eigene öffentliche v6 Adresse unter der das Webinterface erreichbar ist.

Zum Ausfall heute Morgen. Zur Zeit hat unser Monitoring Server nur eine Verbindung zu Albufer6. Albufer6 hatte mal wieder einen Kernel-Panic, habe die Kiste neu gestartet und damit stehen auch wieder alle Daten zur verfügung.

Die Node-ID wird über die Physikalische MAC-Adresse des WAN-Interfaces berechnet und sollte daher immer eindeutig sein.

Ich werde mir die Tage mal anschauen wie man am besten Daten von einzelnen Knoten ausließt. Kann da aber noch nichts versprechen.

Grüße,
Simon

7

Hey @bongosmurf,

Von einer Firewall war im Ausgangsposting nie die Rede. Du erreichst die Knoten aber generell von extern nur per IPv6, da sie keine öffentliche IPv4 Adresse besitzen.

Über die IPv6 Adresse und das Webinterface kannst du bereits jetzt schon die Daten eines einzelnen Knoten abholen, dafür braucht es eigentlich nichts zusätzliches. Außerdem lässt sich dadurch auch super prüfen, ob der Knoten noch erreichbar ist.

Ich halte es für unnötig Daten für einzelne Knoten bereitzustellen, da diese Daten einerseits bereits direkt an den Knoten abgeholt werden können und andererseits in den meisten Fällen eh nur insgesamt (also mit den anderen Knoten zusammen) betrachtet werden. Sinvoller fände ich es, Dienste die potentiell mehrere Freifunker interessieren und nutzen könnten direkt global fürs ganze Netz zu bauen und anderen anzubieten diese mitzunutzen.

Die Gesamtstatistik wird vom Grafana berechnet, die zugrunde liegenden Daten stammen aus der nodes.json

Grüße
psy

PS: Ich hab gerade mal das mit dem Mailinglisten-Modus ausprobiert. Lesen funktioniert super, aber man kann nicht auf Beiträge antworten. :confused:

8

Hallo psy, Simon,

achso, es war mir nicht bewusst, dass der Knoten sich ja über seinen eigenen Tunnel erreichbar macht.

Ok, die Node ID ist dann persistent, solange die HW nicht getauscht wird.

Wie ist es mit der IPV6-Adresse des Knotens? Die ist doch davon abhängig, an welchem Ufer gerade festgemacht ist und das kann sich doch jederzeit ändern, oder?

Grüße,
Michael

9

Nein. Die IPv6-Adresse wird aus der MAC-Adresse des Knotens berechnet und bleibt gleich, auch wenn er über ein anderes Gateway zum Freifunknetz verbindet.

10

Danke, das war alles schon mal sehr hilfreich!

Da mein DSL-Provider noch keine IPv6-Connectivity bereitstellt, habe ich auf einem externen Server 4-to-6-Port-Forwarding eingerichtet:

# grep 8888 /etc/services
socat_8888    8888/tcp  # ffka 4-to-6 http

# cat /etc/xinetd.d/socat
service socat_8888
{
        disable         = no
        socket_type     = stream
        protocol        = tcp
        user            = nobody
        wait            = no
        bind            = NNN.NNN.NNN.NNN
        only_from       = MEIN.MONITORING.HOST.example.com
        server          = /usr/bin/socat
        server_args     = - TCP6:[2a03:22MM:a:b:62MM:MMff:feMM:MMMM]:80
}

Was standardmäßig über die Startseite des Knotens abrufbar ist, reicht als Lebenszeichen aus, ist mir aber zu wenig. Da muß ich in Puncto Inhalt und Format noch etwas nachlegen. @psy Du hattest angedeutet, das sei ein Kinderspiel. Könntest Du mich bitte in die richtige Richtung steuern?

Bzgl. Ausfall des Albufer6: Machen die Router einen Fallback auf andere Gateways? Mein Eindruck ist, dass meine es nicht tun, aber ich tue mich gerade schwer, das zu überprüfen.

11

Auf deinem Router:
gluon-neighbour-info -i lo -p 1001 -d ::1 -r nodeinfo
bzw:
gluon-neighbour-info -i lo -p 1001 -d ::1 -r statistics

Ja, die sollten automatisch auf ein anderes Gateway wechseln.

12

Ah, danke. Gerade hatte ich auch
http://gluon.readthedocs.io/en/v2016.1.5/features/monitoring.html#format-of-collected-data
gefunden und mich gefragt, ob man alfred auch dazu bewegen kann, direkt auf Fragen von meinem Monitoring-Proxy zu antworten, statt nur im Mesh. Aber lokal über ssh geht natürlich auch. Da muss ich dem Monitoring aber beibringen, mit deutlich erhöhter Latenz zu rechnen.

Jetzt fürchte ich nur, ich muss die Router physisch einsammeln und über den Config-Mode meinen RSA-Key bekannt machen. Die kennen nur meinen alten DSA-Key von vor zu vielen openssh-Updates.:frowning:

13

So, vom ersten Router kriege ich immerhin schon mal die Daten (auch wenn jede Abfrage inkl. ssh-Verbindungsaufbau über 6 Sek. braucht.).

Ist irgendwo beschrieben, welche Maßeinheiten zu den jeweiligen Attributen im gluon gehören? Ich rate mal:

tx_dropped: [packets] ?
tx_bytes: [bytes]
tx_packets: [packets]
rx_packets: [packets]
rx_bytes: [bytes]
procs_running: [processes]
procs_total: [processes]
rootfs_usage: [1/1] ?
loadavg: [1/1] ?
idletime: [s] ? since boot ?
uptime: [s] ? since boot
mem_total: [bytes] ?
mem_free: [bytes] ?
mem_buffers: [bytes] ?

14

Dazu hab ich mir jetzt was handgedrexelt. Node-ID (=MAC) aus der IPv6-Adresse:

$ cat slaac2mac
#!/usr/bin/perl -w
use strict;
use Net::IP qw(:PROC);

my $ip='';
while(<>){
        $ip=$_;
        last;
}
unless(defined $ip and $ip ){exit 1} # no input on STDIN
unless(ip_is_ipv6($ip)){exit 2}; # not an IPv6 address

my $expanded = ip_expand_address($ip,6);

if( $expanded =~ /^([[:xdigit:]]{4}:){4}([[:xdigit:]]{2})([[:xdigit:]]{2}):([[:xdigit:]]{2})ff:fe([[:xdigit:]]{2}):([[:xdigit:]]{2})([[:xdigit:]]{2})\
b/){
        printf("%02x%s%s%s%s%s\n",(hex $2)^0x02,$3,$4,$5,$6,$7);

}else{
        exit 3; # extraction not possible
}

$ dig +short aaaa ffka-entropia-neu.nodes.karlsruhe.freifunk.net | slaac2mac
f81a675a7165

15

Vielleicht interessant, kam neulich via Freifunk Stuttgart Mailingliste: Die haben dort Monitoring der Knoten als netzinternen Dienst aufgezogen, sodass man als Knotenbetreiber ne Mail bekommt wenn der Knoten offline ist. @bongosmurf, eventuell was davon für dich interessant?

Online gibt’s das hier an Details:
https://wiki.freifunk-stuttgart.net/technik:netzinterne_dienste#ffs_nodealarm
…da das aktuel noch eher dürftig ist, hier mal noch die Ankündigungsmail:

Hallo zusammen,

eines der Ergebnisse des Mesh Wochenende ist die Rückkehr des
NodeAlarms. Der NodeAlarm prüft ob Freifunk Stuttgart Nodes online sind.
Für jeden zu überwachenden Node muss ein Task angelegt werden, welcher
dann prüft, ob ein Node eine festzulegende Zeit nicht Online ist. Sollte
ein entsprechender Node offline sein, wird der Benutzer via E-Mail
benachrichtigt. Der NodeAlarm aktualisiert seine Datenbasis alle fünf
Minuten.

Der NodeAlarm ist unter https://nodealarm.freifunk-stuttgart.de/ nun
erreichbar.

ps: Wenn du früher bereits mal einen Account hattest, musst du dich
trotzdem neu anmelden. Die alte Datenbank wurde nach dem Einstellen des
früheren Dienstes natürlich gelöscht.

pps Neuerungen für Bastler:

Infos einzelner Nodes sind dort nun auch per HTTP GET request abrufbar,
ohne eine ganze json parsen zu müssen:

https://nodealarm.freifunk-stuttgart.de/{mac adresse}

bzw ganz spezifisch:

https://nodealarm.freifunk-stuttgart.de/{mac adresse}/clients
,https://nodealarm.freifunk-stuttgart.de/{mac adresse}/isonline

Doku hierzu muss ich auf Github in der Readme noch nachreichen. Wenn
jemand noch andere Daten braucht, kann das erweitert werden.

Grüße

Flip
16

Stichwort Monitoring einzelner Knoten:

Um einzelne Werte aus der großen json-Datei für meine Knoten zu extrahieren nutze ich übrigens den json-parser jq. Für einen schnellen Blick einfach und effektiv.

# hier für alle Knoten mit 'test' im Namen: last-seen und network-Infos
$ SEARCH="test" URL="https://api.karlsruhe.freifunk.net/hopglass/nodes.json" wget -q -O - ${URL} |  jq -c ' .nodes[] |  [ .nodeinfo.hostname, .lastseen, .nodeinfo.network.addresses[] ] ' | grep "${SEARCH}" | column -xts ','
["ffka-Haltestelle-Poststr."  "2017-05-03T19:27:21.944Z"  "2a03:2260:a:b:f6f2:6dff:fe40:43f6"  "fe80::f6f2:6dff:fe40:43f6"]
["ffka-buntestr5dg"           "2017-05-03T19:27:21.967Z"  "fe80::6670:2ff:fe84:e478"           "2a03:2260:a:b:6670:2ff:fe84:e478"]
["ffka-Forcheimtest"          "2017-05-03T19:27:21.812Z"  "2a03:2260:a:b:9ade:d0ff:fed6:2668"  "fe80::9ade:d0ff:fed6:2668"]
["freifunk-Bauplatz-test"     "2017-05-03T19:27:21.844Z"  "fe80::8616:f9ff:fe9b:d162"          "2a03:2260:a:b:8616:f9ff:fe9b:d162"]
$

JT