Langzeitstatistiken aus den Alfred Daten

Technik
1

Fortsetzung der Diskussion von Überblick Alfred Daten:

Momentan bin ich dabei einen Webservice zu schreiben, der periodisch Alfred abfrägt, und Informationen zu den Nodes in eine Datenbank wirft.

Diese Daten kann man dann in sinnvollen Zusammenstellungen auf der Webseite in Tabellen, Auflistungen und als Graphen darstellen, und sollen als json per rest abfragbar sein.

Soll alles so werden, denn momentan scheitert es an mehren Aspekten:

Ich habe drei Tabellen: Eine mit Messpunkten, eine mit allen jemals gesichteten Nodes, deren Daten sind der Hostname und die Mac, und noch eine Status-Tabelle, die als Fremdschlüssel einmal auf einen Messpunkt und einmal auf eine Node zeigt. Darin speichere ich nun die Daten die ich im Laufe der Zeit verfolgen will: Firmware, Uptime, Clients, etc…

Das Problem ist: Gehen wir davon aus, dass durchschnittlich 100 Nodes online sind, dann wächst die Status-Tabelle mit jedem Durchlauf auch um 100 Einträge. Nun, drei/vier Zahlen und ein/zwei Strings sind so 20 bis 100 Bytes, jedoch gemessen auf die Dauer, wie lange das laufen soll wird das schnell sehr viel, vor allem bei kurzen Intervallen.

Zweitens: Ich finde, dass Datenschutz im Freifunk wichtig sein sollte, und leider in vielen Anwendungen zu wenig beachtet wird.

Man muss sich vor Augen halten: Was man hier macht, ist von außen in den persönlichen Lebensbereich von Menschen einzudringen, aus der Sicht der Anwendung sind die Nodes eigentlich nur Sensoren die in den Wohnungen von irgendwelchen Freifunkern stehen.

Das dümmste Beispiel wäre, dass man daraus ablesen kann, ist wann bei jemanden der Strom ausgefallen ist.
Aber anhand der Clients und der längerer Beobachtung dessen Verlaufes, weiss man wann jemand zu Hause ist, oder im Urlaub.

Es interessieren mich nun folgende Fragen:

@stv0g Was in etwa hattest du angedacht?

Wie gehe ich das Problem mit den massiv wachsenden Daten an?
Ich dachte eine Art Vergessen zu Implementieren, die Einträge in der Status-Tabelle sollen nicht älter als 3 Monate werden, jedoch muss man sich um Hand darum kümmern die Relationen innerhalb der Datenbank nicht zu zerstören, jedoch wär damit zumindest ein bisschen Datenschutz gegeben…

Was für Daten sind eigentlich auf lange Sicht überhaupt relevant für eine Community?

Das Projekt kommt leider gar nicht voran, da ich nicht weiß, wie ich das abspeichern soll, und bin erstaunt wie wenig Software es gibt, Daten in Verbindung mit einer Zeitachse verwalten kann.

So klassische Monitoring-Tools sind zwar ganz nett, aber eine RRD-Tool überschreibt sich ja nach einer gewissen Zeitspanne wieder selbst, so dass man immer nur ein Zeitfenster hat, und nicht alle Daten von Anfang an.

Schöne Grüße

1 „Gefällt mir“
2

Time-Series-Daten (Messwerte) in SQL-Datenbanken nicht wirklich Optimal aufgehoben. Klassischer Vertreter für eine geeignete Datenbank ist RRDtool, was allerdings nicht so schön skaliert, u.a. weil die Graphen zur Anzeige vom Backend in png-Dateien gerendert werden müssen, was einen Server ganz schön beschäftigen kann.

Ich habe schonmal überlegt, für exakt diese Baustelle (Alfred-Daten) InfluxDB aufzusetzen, es gibt dafür auch ein nettes Frontend, welches alle Graphen clientseitig rendert. Ähnlich funktioniert auch Graphite, welches es schon etwas länger gibt als InfluxDB.

Gruß, Markus

3

Hallo :smile:

Momentan bin ich dabei einen Webservice zu schreiben, der periodisch Alfred abfrägt, und Informationen zu den Nodes in eine Datenbank wirft.

Genau das gleiche habe ich auch vor. Vielleicht wollen wir unsere Anstrengungen bündeln? Ich könnte gerade etwas gegenseitige Motivation ganz gut gebrauchen ;D

Das Problem ist: Gehen wir davon aus, dass durchschnittlich 100 Nodes online sind, dann wächst die Status-Tabelle mit jedem Durchlauf auch um 100 Einträge. Nun, drei/vier Zahlen und ein/zwei Strings sind so 20 bis 100 Bytes, jedoch gemessen auf die Dauer, wie lange das laufen soll wird das schnell sehr viel, vor allem bei kurzen Intervallen.

Ja, ich speichere zur Zeit noch direkt die Ausgaben von Batman-viz und Alfred auf meinem Server ab, um sie später mal importieren zu können. Und das sind jetzt nach ein paar Wochen auch schon >4GB.

Zweitens: Ich finde, dass Datenschutz im Freifunk wichtig sein sollte, und leider in vielen Anwendungen zu wenig beachtet wird.

Da gebe ich dir zu 100% recht. Und wenn man das ganze mal genauer betrachtet, bin ich etwas geschockt wie viele Daten hier öffentlich verfügbar sind.
Hat sich denn noch niemand mal genau angesehen was Batman-Adv für Daten durchs Mesh verteilt?

Da stehen unter anderem auch die MAC Adressen der Clients drin und mit welcher Node sie gerade verbunden sind.
Man könnte also detaillierte Bewegungsprofile erstellen. Dazu kommt noch, dass wir ja auch von den meisten Nodes eine genaue geographische Position kennen.
Weiterhin kann man über die "Betreiber-Adresse, die beim Aufsetzen der Node angegeben wird, einen Rückschluss auf die Person ziehen, die diese Node betreibt.

Ich finde das allein schon besorgniserregend genug, so dass wir das in einem getrennten Thread diskutieren sollten.

Was für Daten sind eigentlich auf lange Sicht überhaupt relevant für eine Community?

Für mich wären das unter anderem:

  • Anzahl der aktiven Nodes
  • Anzahl der aktiven Clients
  • Traffic pro Node
  • Durchschnittliche Vermaschung im Mesh
  • Größe der Community:
    • Wie viele Personen sind aktiv?
    • Wie viele Funkzellen gibt es?
4

…kann man in dem Zusammenhang dann nicht sofort alle Daten erfassen?

Mich würden folgende Datenquellen interessieren:

  • batadv-vis / alfred
  • fastd
  • Traffic auf den Supernodes
  • IP-Vergabe auf den Supernodes
5

Ich glaube das stimmt nicht ganz.
RRDtool kann sehr wohl auch direkt auf die Daten zugreifen, um sie bspw. als JSON zu exportieren.

Aber ich RRDtool eignet sich hier nicht für alle Messgrößen.

In dem Zusammenhang werde ich mal collectd in den Raum.
Das kann wirklich Statistiken über alles mögliche sammeln und in verschiedenen Backends abspeichern. Unter anderem auch RRDtool.
Collectd, kümmert sich jedoch nur um das Sammeln und Abspeichern von Statistiken.
Es gibt eine Reihe von Frontends, die aber leider alle nicht wirklich sehr schön sind.

Wenn ich mir das so recht überlege, wäre das eigentlich die eleganteste und einfachste Möglichkeit.
Wir nutzen einfach CollectD zum Absspeichern und füttern es mit allerhand aus der Community.

  • Alfred
  • Batman-adv
  • Supernode Traffic
  • FastD Verbindungen
  • Forum Posts / Stunde :smiley:

Dann bräuchte man nur noch ein paar schöne Frontends, die die Daten visualisieren können.

Ich glaube dazu gabs beim Geekend auch eine Gruppe.
Auch die Admins, betreiben wohl Collectd für die Supernodes.
Jedoch ist das wohl nur aus dem FF Netz erreichbar und zurzeit wohl auch nicht in Betrieb.
Hat dazu wer mehr Informationen?

6

fastd liefert hervorragende Infos, nachfolgend ein gekürztes Sample vom ffrg004.freifunk.ruhr. Wenn man entsprechend der Daten dann noch mitspeichert von welcher Supernode die Daten sind, hat man sogar im Rückbezug auf die Node die Informationen über welche Server die Tunnel einer Node aktuell konnektiert sind, über welchen der beiden Server der Traffic gerade läuft und wieviel usw.:

{
  "statistics": {
    "tx_dropped": {
      "bytes": 41470,
      "packets": 361
    },
    "tx": {
      "bytes": 25960199104,
      "packets": 149003026
    },
    "tx_error": {
      "bytes": 0,
      "packets": 0
    },
    "rx_reordered": {
      "bytes": 8577262,
      "packets": 30201
    },
    "rx": {
      "bytes": 9706503564,
      "packets": 47790417
    }
  },
  "uptime": 59079006
  "peers": {
    "5eeb7f344763d116b0c31e13299453348e312442073afa05bf0032ac21bd": {
      "connection": {
        "mac_addresses": [
          "66:70:02:d2:f9:e0"
        ],
        "statistics": {
          "tx_dropped": {
            "bytes": 1720,
            "packets": 15
          },
          "tx": {
            "bytes": 459199878,
            "packets": 2982378
          },
          "tx_error": {
            "bytes": 0,
            "packets": 0
          },
          "rx_reordered": {
            "bytes": 1920560,
            "packets": 6346
          },
          "rx": {
            "bytes": 139712545,
            "packets": 790383
          }
        },
        "established": 59077516,
        "method": "salsa2012+gmac"
      },
      "name": "FF-OB-LAB-01",
    }
}
7

Das ganze periodisch in CollectD einzulegen sollte recht easy mit einem Python Skript machbar sein.

Jedoch ist CollectD nicht in der Lage ein Liste mit allen Nodes und ihrem Online-Status zu speichern.
Ich denke, dafür sollte man auf relationale Datenbanken setzen, die dann wie spky es vorgeschlagen hat, einfach alles was älter als 3 Monate ist, vergisst.

Dadurch verliert man ja dann nicht wirklich viele Infos.
Durchschnittliche Uptime usw. kann man ja weiterhin (redundant) in CollectD speichern.

8

Eigentlich sammelt collecd hauptsächlich Systemdaten und hat zufällig auch ein RRD-Backend, welches RRD-Datenbankdateien updaten kann. Jetzt die Daten von Alfred noch durch CollectD zu schubsen erscheint mir auf den ersten Blick umwegig. :slight_smile:

CollectD kann auch im Graphite-Protokoll ausgeben, InfluxDB kann z.B. Daten im Graphite-Protokoll und nativ im CollectD-Protokoll entgegennehmen.

Da InfluxDB und Graphite nativ von Grafana als Web-Frontend unterstützt werden ist das für ein modernes Frontend sicher einfacher als mit den (alten) RRD-Dateien zu arbeiten.

Letztendlich gibt’s noch StatsD, was das füttern von InfluxDB oder Graphite noch einfacher macht. Warum man das nicht direkt submitten sollte erschließt sich mir noch nicht ganz. Muss das alles mal ausprobieren. Gibt aber 'nen netten Blogpost der Entwickler über StatsD.

Gruß, Markus

1 „Gefällt mir“
9

Stop!

Wie bereits geschrieben: RRD-Tool ist ungeeignet, da es das Round-Robin-Database-Tool ist. Das heißt, wenn hinten voll, wird vorne überschrieben.

Was wir hier wollen ist Langzeit, dh. wir wollen wissen, wie viele Nodes vor 25 Jahren online sind.

Zweitens: Collectd kümmert sich nur, um die Übertragung von Informationen von einem Device zum nächsten.
Jemand hat mir mal erzählt die Frankfurter würden dies machen, das machen die aber schon länger als es Alfred gibt.
Du erzeugst also mit Collectd nur zusätzlicher Traffic, der mit Alfred ohnehin anfällt.

Drittens: Graphite. Kenne ich, ist schlimm.
Es hat sich womöglich aus Gründen von „Schmerzen im Hintern“ eine große Anzahl an Tools um Statsd und Graphite gebildet, weil man die eigentlichen Tools Graphite und Statsd eigentlich nicht betreiben möchte. Sind sehr Hardwarehungrig, schwierig zu administrieren, und nerven auch sonst so.
Ich hab da keine Lust mich drum zu kümmern, wie gesagt, Langzeit, das sollte auch so lange wie möglich ohne Probleme laufen. Je mehr Tools man da ranflanscht, desto mehr kann auch kaputt gehen, und sorgt später für Stress.

Und ja, InfluxDB ist das einzige was einen Zeitaspekt hervorhebt. Sehr schade.

Zum Datenschutz:
Ich denke mir manchmal ich bin zu kleinlich mit diesem Thema, jedoch finde ich es z.B. nicht korrekt, dass die Karten die MAC-Adressen preisgeben, bzw. wie viel da in der nodes.json drin steht, die man zum eigentlichen Kartenbetrieb nicht bräuchte.
Ich habe für den Hackerspace vor Ort mal eine Statistik für den Türsensor, Stromverbrauch und vergebene DHCP-Leases geschrieben, alles für sich relativ unbedenkliche Werte, doch musste ich im Verlauf dessen feststellen, dass man anhand der Zusammenstellung der drei Werte in einer Grafik recht eindeutige Muster ablesen kann, bis dahin, dass ich Leute eindeutig zuordnen konnte („Kai war gestern Abend im Space, denn dieses Muster taucht immer auf, wenn Kai da ist“).

Also - Das alles muss bedacht werden, wenn sich irgendwelche Desaster im Vorfeld verhindern lassen - gerne.

10

Also da stimme ich dir nur teils zu. Ich denke die Art der Speicherung ist immer davon abhängig welche Größe wir erfassen wollen:

  • Zeit-Wert Paare kann RRDTool gut ablegen.
  • Um jetzt eine Liste aller MACs und ihren Status zu erfassen ist es aber ungeeignet.

RRDTool wird die auch sagen können wir viele Nodes 25 Jahren online waren.
Es wird nur die zeitliche Auflösung verringert.
Wir brauchen nicht zu wissen wie viele Nodes vor 25 Jahren am 1. Februar um 20 nach zehn online waren. Grob 25 Jahre ist da vollkommen genügend.

Das ist richtig. CollectD hat einen schicken Netzwerksupport.
Aber ich hatte nicht geplant diese Funktion zwischen den Nodes zu nutzen.
Dafür haben wir ja Alfred und Batman.
Höchstens zwischen den Supernodes und dem CollectD Server.

Sehe ich genauso. Ich ziehe hier eher alte bewährte Tools vor.

Zum Datenschutz hab ich ja mal nen parallel Thread aufgemacht.

11

Exakt darum halte ich es für ausgesprochen wirchtig rrd oder ähnliches zu verwenden.

Hier werden die Daten in der Regel bereits nach 24h Stunden ungenauer. Aus Gründen des Datenschutzes ist das stark zu befürworten.

Schließlich haben wir uns selber Datenarmut auferlegt!

1 „Gefällt mir“
12

Alfred ist eine dusselige Scriptsammlung und nicht besonders zuverlässig.
Von daher sollte collectd den alfred mittelfristig in Frankfurt komplett ersetzen.
Die Auswertung bleibt dann bei MRTG&Co.

Der Netmon von NordWest ist älter, aber eigentlich nur ein aufgebohrter Alfred.
Über seinen traffic wird zwar geschimpft, aber im Vergleich zu Broadcast-Trafic des Batman ist das noch ein Waisenknabe.

13

Du Musst dabei bedenken, dass eine Freifunk-Wolke im ständigen Fluss ist. Sie wird allein wegen Batman in 10 Jahren ganz anders aussehen (die Entwickler haben den Kompatibilitätsmodus 16 in 10 Jahren in Aussicht gestellt [Important changes]). Es kann sein, dass die Metadaten anders übermittelt, erweitert oder nicht mehr gesendet werden. Du musst Deine Datensammlung ständig anpassen können und kannst Dich da nicht zurück lehnen

Analysiere nodes.json in Wuppertal, daraus kannst Du kein Nutzerverhalten eines besonderen Nutzers ableiten. Es sind deutlich weniger Daten verfügbar, die aber dennoch im Mesh-Protokoll existieren. In der alten nodes.json sind sie ein wenig undeutlich, aber ewig gleich. Die Daten hätten alle 5 min mit einem Zufallswert geXORt werden müssen.

Ich hoffe, Du hast Verständnis, dass ich Dir zu deinem Thema nicht helfen mag, da ich nicht möchte, dass so was dabei rauskommt, ohne dass wir Freifunker unsere Nutzer nicht zuvor mit Text darüber aufgeklärt haben, dass „so etwas“ und all die anderen „bösen“ Möglichkeiten im Freifunk existieren. Früher oder später wirst Du natürlich selbst herausfinden, wie einfach man an die Daten gelangen kann, da Freifunk ja ein freies Netz ist. Es würde allerdings richtige Größe zeigen, wenn Du zuvor im Wiki oder im Pad diese Möglichkeiten im Freifunk niederschreibst, damit Freifunk-Nutzer eine Wahl haben Freifunk zu Nutzen oder nicht zu Nutzen oder über ihre Möglichkeiten deiner oder der anderen Datenerfassung ein Strich durch die Rechnung zu machen.

14

Ich halte einfach das Ziel „Stats über 10 Jahre“ für unglücklich gewählt.

Es würde ja für die meisten „ff-map-communities“ schon ein Tages/Wochen/Monats-Trend für diverse Kennzahlen vollkommen ausreichen, um daraus die eine oder andere Motivation zu schöpfen.
(Oder Probleme konkret adressieren.)

Dass es Generationswechsel gibt, die zu Datenbankmigration zwingen und evtl. chimärenhafte Meta-Formate gebieren: Nunja… die praxisrelevanten Containerformate real existierender Middleware ist bis unters Dach voll mit solchen Monstern. Softwarekrise halt.

15

Alle Daten, die Alfred rausrückt könnte man auch „bedenkenlos“ auswerten, denn jeder andere mit ggf. dubiosem Interesse kann das auch. Wenn es Bedenken gibt sollten wir versuchen, den Zugang zu diesen Daten zu erschweren.

2 „Gefällt mir“
16

Provider sind in der Regel aus diversen Beweggründen bemüht, Informationen über ihr Core-Netz unterm Decke zu halten. Sowohl den aktuellen CPE-status, wie auch der Router, wie auch überhaupt Informationen zur Struktur.
Und das sind nicht nur primär kommerzielle Motive.
Wenn man weiss, dass man in einem Kartenhaus sitzt, dann möchte man da nicht ständig „Tag der offenen Tür“.

Und ich behaupte mal, dass bei uns beim Freifunk die möglichen Schwachstellen nicht weniger sind. Es braucht gar keine Cyberwarfare-Einheiten (gleich welchen Landes), ein paar hormonpegelauffällige Scriptkiddies würden reichen, FF zuverlässig aus dem Netz zu kegeln.