Announced statt alfred im Mesh nutzen und der nächste Schritt

Vorgebaute binaries gibt es unter Releases auf der Github-Seite. Die muss man nur runterladen. Brauchst also keinen golang-Compiler o.ä.
An einer Ansible-Rolle arbeite ich gerade, die das ganze automatisiert. Die verwendet aber auch die vorgebauten Binaries.

1 „Gefällt mir“

Moin,

gibt es irgendwo eine Anleitung dazu? Im besonderen zu announced

Gruß
Fabian

Ich glaube es gibt keine komplette Anleitung.
Bis auf die Graphen ist es eigentlich extrem einfach:
GitHub - ffdo/node-informant: Small utility to collect node information in a Freifunk network via announced auf dem Kartenserver installieren wie in der README beschrieben under starten. Dann in der meshviewer config.json als Datenquelle http://dein.mapserver:8080/ eintragen.

Die Graphen sind ein bisschen mehr Arbeit, aber es hält sich in Grenzen. Du brauchst jedenfalls Prometheus und Grafana. Dann musst du in der Prometheus Standardkonfiguration am Ende das http://localhost:9090/ durch ein http://localhost:8080/ austauschen. Zu guter Letzt in Grafana Prometheus als Datenquelle eintragen und nötigen Dashboards anlegen.
Wenn du bei den Graphen Hilfe brauchst schreib mich einfach an.

2 „Gefällt mir“

Derzeit ist das selbstverständlich einfacher.
So wie ich die Gluon-Roadmap verstanden habe ist jedoch alfred zukünftig nur noch optional zu Gunsten von announced.
Daher finde ich den Ansatz gut, dass @PetaByteBoy sich heute schon darum kümmert.

@CyrusFox es geht hier eben hauptsächlich um announced an Stelle von Alfred

1 „Gefällt mir“

Freut mich, dass langsam von Alfred weg migriert wird. Das öffnet auch die Türen für alternative Meshing-Protokolle.
Der gluon-collector ist übrigens tatsächlich dafür ausgelegt aus ganz unterschiedlichen Quellen Infos sammeln zu können. Weitere Listener lassen sich recht einfach implementieren (was auch schon in vorbereitung ist).
Bald gibt es übrigens auch eine recht einfache ansible-Rolle, die die Installation für ansible-nutzende Communities noch einfacher machen sollte.

4 „Gefällt mir“

Wie sieht es aus mit OLSR als Quelle?

Afaik OLSR ist ein Routingprotokoll. Es spricht also nichts dagegen announced (oder einen Nachfolger) darüber laufen zu lassen. Aber Infos selber wird das eher nicht übermitteln. Man könnte aber mit einem passenden Agent Infos wie Linkqualität, Nachbarn etc. aus OLSR rausholen und in den gluon-collector schmeißen.

Doch, bei OLSR hat jeder Knoten eine Gesamtübersicht des Netzes und es werden weitere Informationen z.B. über interne Services vermittelt (wie genau weiß ich auch nicht, könnte auch ein zusätzliches Programm sein). Aus der kann man Daten für den Meshviewer generieren.

@PetaByteBoy:

Hast du die Prometheus anbindung an Grafana geschafft? Ich bekomme den Fehler hier:

Unknown error
Cannot read property ‚message‘ of null

Das ist die Ausgabe:
http://5.9.174.75:8080/metrics

Das was du geschickt hast war der output von node-informant und der input für prometheus. Du musst zuerst Prometheus installieren und in der Konfiguration die http://5.9.174.75:8080/ als Quelle eintragen (standardmäßig hat Prometheus sich selbst als Quelle also http://localhost:9090/)

Ich schreibe bald™ einen Wiki-Artikel oder so

2 „Gefällt mir“

Kannst du mir deine Prometheus Config Datei zukommen lassen?

root@gl1 ~# cat /opt/prometheus-0.16.1.linux-amd64/prometheus.yml 
global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.
  evaluation_interval: 15s # By default, scrape targets every 15 seconds.
  # scrape_timeout is set to the global default (10s).

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: 'codelab-monitor'

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'freifunk'

    # Override the global default and scrape targets from this job every 5 seconds.
    scrape_interval: 20s
    scrape_timeout: 10s

    target_groups:
      - targets: ['localhost:8080']

1 „Gefällt mir“

Funktioniert hier jetzt auch… Danke
http://statistik.freifunk-troisdorf.de/

Eine Kleinigkeit ist mir noch aufgefallen, die Metriken werden nur mit dem Label „nodeid“ bereitgestellt.
Sinnvoller wäre zusätzlich noch der Hostname sowie der Site-Code. Wir nutzen in Düsseldorf Grafana mit templating im Dashboard. Dort kann man seinen Router momentan einfach anhand des Hostnames in einem Drop-Down Menu auswählen.
Die Node-ID merkt sich leider keiner :frowning:

Moin,

über ähnliches hatte ich mit @dereulenspiegel schon mal gesprochen. Derzeit können ja mehrere Instanzen angegeben werden, die dann zusammen verarbeitet werden. Schön wäre jetzt noch das automatische „splitten“ der Daten, um die Daten auch pro Community bereit zu stellen. Da wäre deine Idee mit dem site-code im Prinzip schon die Lösung für die Graphen.

Gruß

Chrisno

Naja der Site-Code ist mir nicht ganz so wichtig wie die Hostnames. Den Split mit eigenem Job hab ich auch schon vorgenommen :slight_smile: Aber so kann halt kein templated Dashboard genutzt werden.
Außerdem habe ich gemerkt das Announced noch schlechter performt als Alfred :(. Aber das mag mit den momentan schlechten Verbindungen zwischen den Gateways zusammenhängen.
Ich überlege gerade den gluon-collector auf beiden Gateways auszuführen und mittels ebtables die Multicast UDP Pakete nur über fastd/l2tp zu den Clients zu schicken. So wird nicht unnötig der Batbone Link zwischen den Supernodes verwendet.

Das „Problem“ bei announced ist tatsächlich, dass es grundsätzlich per multicast läuft. Hat man also Probleme Nutzdaten in seinem Mesh zu transportieren merkt man das recht stark an announced. Das wird mit anderen Lösung, die „routingprotokoll-agnostisch“ sind aber nicht anders werden.
Was multicast-Routing etc. angeht gibt es sicher noch Möglichkeiten die Performance von announced zu verbessern. Im gluon-collector sind die Möglichkeiten leider begrenzt, da ich im Prinzip nicht anderes mache als Pakete auf die Reise zu schicken und auf Antwort zu warten. Ich versuche das multicast-Problem in soweit abzufangen, dass potentiell unerreichbare Nodes (sofern sie einmal bekannt sind), per unicast abgefragt werden. Aber das bringt nur begrenzt viel.

@CyrusFox

Ich habe im Projekt node-informant mal ein Issue für den Wunsch nach Hostnames eröffnet (Export human readable node names to prometheus · Issue #9 · ffdo/node-informant · GitHub). Allerdings gefällt mir die Lösung nicht. Die Hostnames der Nodes müssen nicht zwingend einzigartig sein, was sie zu schlechten Schlüsseln macht und Statistiken für Nodes, die noch nicht in der Datenbank sind, müssen aktuell verworfen werden.
Meiner Meinung macht es eher Sinn das Mapping Node-ID → Hostname auf einer anderen Ebene zu machen. Der gluon-collector sollte sich keine Sorgen um Hostnames machen müssen. Leider weiß ich aktuell auch zu wenig über Grafana und Prometheus um jetzt eine gute Idee zu haben wie man das dort am elegantesten löst.