Freifunk-Node-Clients-stats - Ein Statistik Modul

Hallo zusammen,

einige haben sicherlich schon im Nordwestbereich das Thema neuer Meschviewer gelesen.

Ich habe ein basierend auf den Daten von https://github.com/ffnord/ffmap-backend ein etwas umfangreicheres Statistik Modul erstellt. Es basiert auf PHP und RRD. Mein Ziel war es, das das Modul einfach in der Einrichtung ist.
Server Vorraussetzungen:

  • PHP-cUrl Modul
  • PHP RRD Modul
  • Cron Jobs

Das Modul ließt minütlich per Cron Job die Daten des Backend Moduls ab und speichert die Daten in .rrd Dateien auf dem Server. Folgende Daten werden dabei ausgelsen:

  • Anzahl der Clients
  • Traffic (Rx,Tx,MgmtRx,MgmtTx,Forwarded)
  • Memory Usage
  • RootFS Usage
  • Load Average

Im Gegensatz zum ffmap-backend welches in sofern die Statistiken aktiviert sind die Bild Dateien automatisch generiert, habe ich es so programmiert, dass die Bilder nur bei Bedarf erzeugt werden. Über URL-Parameter kann man die Größe des Bildes und den angezeigten Zeitraum einstellen. Vor der Erzeugung einer Grafik wird geprüft, ob diese schon einmal erzeugt wurde, und wenn ja ob sie älter als 60 Sekunden ist. Ist sie noch keine 60 Sekunden alt wird das Bild nicht neu vom Server erstellt, sondern von der Festplatte direkt gelesen.

Ich würde mich über Verbesserungsvorschläge sehr freuen. Am besten einfach einen Issue schreiben unter: https://github.com/PowerPan/Freifunk-Node-Clients-stats

3 Likes

Kühl!

Mit etwas Trickserei (s. Issue) hab’ ich’s soweit zum Laufen bekommen, einzig das, was mich brennend interessieren würde, nämlich der Traffic je Node, mag nicht funktionieren. Clients werden aufgezeichnet, root-FS-Nutzung, Speicher, Load — aber nix mit Datenverkehr :frowning:

Beim Blick in die Rohdaten fällt auf, daß derlei Daten auch gar nicht vorliegen?!

     "statistics" : {
        "clients" : 3,
        "loadavg" : 0.61,
        "rootfs_usage" : 0.43055555555556,
        "uptime" : 119994.76,
        "memory_usage" : 0.812889812889813,
        "gateway" : "deadbeef0201"
     },

Frage daher: wie erzeugt Ihr diese? Eigentlich nutzen wir Gluon v2015.1.2, und da finde ich in gluon-announce keine Traffic-Daten?

1 Like

Moin
den Issue habe ich gesehen, kümmere ich mich mal drum. Es ist ja auch noch nicht stable :smiley:

Also bei uns in Nordwest sieht es wie folgt aus der abschnitt in den Rohdaten

"statistics":{
"uptime":97455.22,
"loadavg":0.52,
"rootfs_usage":0.46875,
"clients":5,
"memory_usage":0.68662508662509,
"traffic":{
    "forward":{"packets":7467,"bytes":883384},
    "rx":{"packets":8132782,"bytes":649379247},
    "mgmt_rx":{"packets":4025672,"bytes":1533882740},
    "mgmt_tx":{"packets":3373134,"bytes":1358202228},
    "tx":{"packets":13348,"dropped":17,"bytes":3000051}
}

[quote=„PowerPan, post:3, topic:9095“]
Also bei uns in Nordwest sieht es wie folgt aus der abschnitt in den Rohdaten[/quote]

Bei den GWs oder auch bei den Knoten? GitHub - ffnord/mesh-announce: Discussion at #mesh-announce:irc.hackint.org and (separately) at liefert diese Daten bei GWs, aber bei den Knoten?

EDIT: Nevermind. ffhh-packages/traffic_fastd at master · freifunkhamburg/ffhh-packages · GitHub liefert wohl diese Info für die Knoten aus dem fastd-Socket. Testversion für FFGT braut grade :wink:

EDIT2: Hmm. Nun sendet der Knoten:

{
   "node_id" : "e894f6524b54",
       "gateway" : "52:31:bd:f2:70:1f",
       "mesh_vpn" : {
            […]
       },
       "clients" : {
          "wifi" : 0,
          "total" : 1
       },
       "processes" : {
          "running" : 1,
          "total" : 44
       },
       "traffic" : {
          "rx" : {
             "bytes" : 981147,
             "packets" : 12231
          },
          "forward" : {
             "bytes" : 18840,
             "packets" : 116
          },
          "tx" : {
            "bytes" : 65186,
            "packets" : 396,
            "dropped" : 9
          },
          "mgmt_rx" : {
             "packets" : 28936,
             "bytes" : 4522686
          },
          "mgmt_tx" : {
             "bytes" : 1111229,
             "packets" : 6314
          }
       },
       "rootfs_usage" : 0.45833333333333,
       "memory" : {
          "total" : 28860,
          "free" : 3004,
          "cached" : 5948,
         "buffers" : 1600
       },
       "loadavg" : 0.11,
       "traffic_fastd" : {
          "rx_packets" : 16212,
          "tx_packets" : 8923,
          "rx_bytes" : 1824856,
          "tx_bytes" : 1151275
       },
       "uptime" : 375.23,
       "idletime" : 244.21
    }

Aber hinter’m ffmap-backend bleibt es bei:

  "e894f6524b54" : {
     "lastseen" : "2015-11-13T23:59:02",
[…]
     "statistics" : {
        "memory_usage" : 0.839362439362439,
        "loadavg" : 0.54,
        "rootfs_usage" : 0.45833333333333,
        "gateway" : "deadbeef0201",
        "uptime" : 769.62,
        "clients" : 1
     },
     "flags" : {
        "gateway" : false,
        "online" : true
     }
  },

Braucht man auch ein neue(re)s ffmap-backend dafür?!

EDIT3: Ja. GitHub - ffnord/ffmap-backend: THIS PROJECT DOESN'T HAVE A MAINTAINER! braucht’s, dann tut’s auch mit den Traffic-Graphen …

Moin zusammen,

heute gab es ein größeres Update:

hier zu sehen: Freifunk Nordwest Statistics jetzt nit Firmware und Hardware Statistiken

1 Like

Bei aller Liebe, aber nicht alles an Daten macht in einem Graphen Sinn. Ich pushe bei uns zwar auch die Informationen über verwendete Hardware und Firmware-Version ins Prometheus, aber die im Grafana als Graph anzuzeigen macht einfach keinen Sinn. Da bietet sich eher ein Kreis- oder Balkendiagram an.

Moin
Das kann ja jeder handhaben wie er möchte
Die Anzeige so ermöglicht eine Übersicht über einen Zeitlichenverlauf.

Wenn man nur lediglich eine Momentaufnahme zeigen möchte dann gebe ich jedem Recht der sagt ein Kreis oder Balkendiagramm ist besser geignet.

Und man muss ja insofern jemand anderes es gerne nutzen möchte nicht alle Graphen anzeigen

Nach dem heutigen Firmware Release kann man nun schön sehen wie schnell der „umstieg“ von statten geht.

Live anschauen: Freifunk Nordwest Statistics

Das LUA-Skript stammt von mir, die Daten werden in Hamburg aus der alfred.json ausgelesen.
Hintergrund war dass die „normalen“ Trafficwerte die ich vorher aus der alfred.json ausgelesen hatte nicht korrekt sein konnten. Ich hatte Testweise eine 1 GB Datei heruntergeladen, die Trafficwerte gingen aber nur um ca. ein fünftel davon hoch. Bei einem kurzen Test mit meinem Knoten schien aber fastd brauchbare Werte zu liefern.

Ah. Naja, ich habe damit einerseits das Problem, daß gelegentlich TB/sec oder PB/sec als Peak angezeigt werden, andererseits komme ich nicht ganz auf die Zahlen, die wiederholte wgets auswerfen (Werte hier sind etwas niedriger). Aber da es weniger um Accounting denn um Richtwerte zur Auslastung der Leitung geht - uns jedenfalls -, ist das schon mal super. Das ‚Spitzen-Problem‘ kaschiere ich durch Graphenkappung bei 20 MBit/sec …

Also anstatt RRD zu verwenden würde ich eher auf Grafana setzen :smile:

Siehe:
https://grafana.lambdacore.de/dashboard/db/freifunk-nodes-dusseldorf

Im Backend sitzt InfluxDB, das lässt sich allerdings auch einfach mit Prometheus oder OpenTSDB realisieren.
Den Import mache ich mit dem folgenden Script:

Dies Peaks habe ich in Hamburg auch gesehen, allerdings nie bei einzelnen Knoten, sondern immer nur bei Gruppen von Knoten bzw. in der Gesamtübersicht mit allen Knoten.
fastd liefert IIRC das Gesamtvolumen das über die Tunnel geht, seit letztem Tunnelaufbau.
Falsch:
Alle Gesamtvolumina zusammenzählen, dann Differenz zum jeweils vorherigen Wert berechnen und als bytes/sec nehmen. Das ist falsch und sorgt für solche falschen Peaks, auch wenn die Werte zwischen den Peaks normal aussehen.

Die korrekte Methode ist für jeden einzelnen Knoten erst die Differenz zu bestimmen, dabei evtl. fehlende Werte zu beachten und erst dann die Werte zusammenzurechnen.
Für grafana nutze ich in Hamburg zur Zeit das hier:

alias(sumSeries(scaleToSeconds(nonNegativeDerivative(freifunk.$region.nodeids.*.traffic.fastd_rx_bytes), 1)), 'Summe aller Knoten mit Werten')

Ergebnis ist ein Graph wie z.B. http://statistik.hamburg.freifunk.net/dashboard/db/freifunk-ubersicht (ganz unten).
Die Werte liegen deutlich unter den Werten die die Gateways messen, ich vermute das aus irgendeinem Grund einige Knoten die Werte nicht liefern im Hamburger Netz, hatte bisher aber noch nicht soviel Zeit mich damit genauer zu beschäftigen.

IIRC speichert grafana (noch) keine Daten selbst, das ist noch in Entwicklung. :wink:

Ich nutze in Hamburg carbons mit whisper-Datenbanken. Ist allerdings ziemlich IO intensiv, weshalb die 15 GB an Datenbanken in einem tmpfs, also quasi im RAM liegt. Theoretisch könnte mein Server die ca. 19.000 Werte pro Minute wohl locker wegschreiben, praktisch merke ich das btrfs für sowas keine gute Idee ist, ich hatte teilweise Kernel-Warnungen im Log das Prozesse die auf die Festplatte zugreifen für über 2 Minuten hingen, weil btrfs damit beschäftigt war, die Daten zu verdauen und transactions zu schreiben und in der Zeit andere Schreibzugriffe komplett blockiert hat.
Der Vorteil eines tmpfs liegt natürlich eindeutig bei der Performance… mal eben die letzten 3 Monate anzuzeigen mit allen Knoten ist kein Thema, solange der Browser die Daten schnell genug schlucken kann. Der Nachteil bei der Datensicherheit, ich lasse die Daten derzeit nur einmal pro Tag auf die Festplatte schreiben.
Influx oder andere wollte ich mir auch schonmal ansehen, aber bisher ist der Leidensdruck nicht groß genug :wink:

Siehe z. B. http://map.4830.org/nodestats/getNodeGraph.php?type=traffic&interval=1D&width=800&mac=c4e984c84d18

Knoten war durchgehend online, daher dürfte das eigentlich nicht passieren.

Was da passiert ist ist ziemlich klar, aus irgendeinem Grund wurden für einige Stunden keine neuen Werte gemeldet und beim nächsten Update scheint der bei dir davon auszugehen, dass der gesamte Datentransfer seit dem letzten Wert binnen einer Minute (oder was auch immer deine Update-Zeit ist) passiert ist.
Grafana bzw. carbons scheint da schlauer zu sein:
http://statistik.hamburg.freifunk.net/render/dashboard-solo/db/freifunk-knoteninfo?panelId=5&fullscreen&from=1448790594730&to=1449395274731&var-region=ffhh&var-knoten=CCCHH&width=1000&height=500

Bleibt also die Frage warum die Daten nicht aktualisiert werden.