Freifunk-Gateway aufsetzen/Alfred: Unterschied zwischen den Versionen
SebaBe (Diskussion | Beiträge) |
K (→Konfiguration) |
||
| Zeile 38: | Zeile 38: | ||
Anschliesend den neuen Service registrieren und starten: | Anschliesend den neuen Service registrieren und starten: | ||
< | <pre> | ||
systemctl enable alfred-bayreuth.service | systemctl enable alfred-bayreuth.service | ||
systemctl start alfred-bayreuth.service | systemctl start alfred-bayreuth.service | ||
</ | </pre> | ||
=== Testen der Konfigration === | === Testen der Konfigration === | ||
Version vom 4. März 2019, 11:03 Uhr
Alfred Master
Funktion
Die Nodewatcher Daten aus dem Alfred werden nicht mehr von einer zentralen VM (früher die Netmon VM) ans Monitoring geschickt. Das übernehmen jetzt die Gateways. Daher muss auf den Gateways Alfred installiert werden und die Daten ans Monitoring übertragen werden
Installation
Das Gateway muss die Daten zuerst als sogenannter Alfred-Master sammeln. Dazu muss "alfred" installiert werden. (Entweder aus den Distributionsquellen oder selbst kompilieren, funktioniert analog zum batman-adv https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/Batman-adv
Konfiguration
Dann muss pro bedienter Hood (also für jedes batX Interface) ein Alfred master gestartet werden (beispielsweise mit in die Interfacekonfiguration oder wie unten als systemd-Service ...):
~# cat /etc/systemd/system/alfred-bayreuth.service [Unit] Description=Alfred Master After=network-online.target [Service] Type=simple ExecStart=/usr/sbin/alfred -m -i br-bayreuth -b bat2 -u /var/run/alfred-bayreuth.sock WorkingDirectory=/tmp RestartSec=10 Restart=always [Install] WantedBy=multi-user.target
bitte die Parameter -i und -b entsprechend anpassen
-i, --interface specify the interface (or comma separated list of interfaces) to listen on
-b specify the batman-adv interface
configured on the system (default: bat0)
use 'none' to disable the batman-adv
based best server selection
Hinweis: Wenn in der eigenen Konfiguration keine separate Bridge verwendet wird, muss beim Parameter -i das bat-Interface angegeben werden; also bei -i und -b das selbe Interface.
Anschliesend den neuen Service registrieren und starten:
systemctl enable alfred-bayreuth.service systemctl start alfred-bayreuth.service
Testen der Konfigration
Wenn bereits ein Router in der Hood ist, kann mit
alfred -r 64 -u /var/run/xx.sock
der Datensatz des Routers angezeigt werden. Auch kann ein eigener Datensatz ins Batman gesteckt werden z.b.
echo "asdf" | alfred -s 66 -u /var/run/xx.sock
diese können dann mit
alfred -r 66 -u /var/run/xx.sock
wieder ausgelesen werden
Bitte den Data-type 64 für das Monitoring frei halten und dort keine eigenen Daten hinein stecken.
Alfred Monitoring Proxy
Die gesammelten Daten müssen nun noch periodisch an das Monitoring gesendet werden.
alfred-json
Dazu kann alfred-json von kratz00 (https://github.com/kratz00/alfred-json) in Kombination mit einem passenden curl-Skript verwenden werden. Zunächst muss alfred-json kompiliert werden (siehe README).
Alfred-Monitoring-Proxy (via /api/alfred2)
Diese Implementierung vom Nov. 2018 verzichtet auf das einschließende {"64":"<data>"} und sollte daher einfacher sein. Die bisherige Lösung folgt unten.
Danach noch das curl-Script anlegen (auf eigenes Zeug anpassen! Pfade der inneren for-loop über die Sockets prüfen!):
~# cat /usr/local/sbin/alfred-monitoring-proxy
#!/bin/bash api_url="https://monitoring.freifunk-franken.de/api/alfred2" fetchid=64 alfredjson=/usr/local/bin/alfred-json header="Content-type: application/json; charset=UTF-8" gziphead="Content-Encoding: gzip" verbose=-v for socket in /var/run/alfred-*.sock do sleep 1 if [ "$zip" = "1" ]; then $alfredjson -r "$fetchid" -s "$socket" | gzip | curl $verbose -H "$header" -H "$gziphead" --compressed --data-binary @- "$api_url" else $alfredjson -r "$fetchid" -s "$socket" | curl $verbose -H "$header" --data-binary @- "$api_url" fi done
Multi-Target
Für den seltenen Fall, dass man selbst ein Monitoring unterhält oder die Daten aus einem anderen Grund an mehrere Adressen versendet werden sollen, kann man folgende Variante verwenden:
~# cat /usr/local/sbin/alfred-monitoring-proxy
#!/bin/bash api_urls="https://monitoring.freifunk-franken.de/api/alfred2 https://anderes.monitoring/api/alfred2" fetchid=64 alfredjson=/usr/local/bin/alfred-json header="Content-type: application/json; charset=UTF-8" gziphead="Content-Encoding: gzip" verbose=-v for socket in /var/run/alfred-*.sock do for api_url in $api_urls do sleep 1 if [ "$zip" = "1" ]; then $alfredjson -r "$fetchid" -s "$socket" | gzip | curl $verbose -H "$header" -H "$gziphead" --compressed --data-binary @- "$api_url" else $alfredjson -r "$fetchid" -s "$socket" | curl $verbose -H "$header" --data-binary @- "$api_url" fi done done
Alfred-Monitoring-Proxy (via /api/alfred, veraltet)
Diese Implementierung benötigt ein einschließendes {"64":"<data>"} für die Daten und wird daher von der oben beschriebenen Variante abgelöst. Beide Varianten können jedoch ohne Ablaufdatum verwendet werden.
Danach noch das curl-Script anlegen (auf eigenes Zeug anpassen! Pfade der inneren for-loop über die Sockets prüfen!):
~# cat /usr/local/sbin/alfred-monitoring-proxy
#!/bin/bash
api_url="https://monitoring.freifunk-franken.de/api/alfred"
fetch_ids="64"
for fetch_id in $fetch_ids
do
for socket in /var/run/alfred-*.sock
do
tmp=$(mktemp)
echo "{\"$fetch_id\": " > $tmp
/usr/local/bin/alfred-json -r "$fetch_id" -s "$socket" >> $tmp
echo "}" >> $tmp
if [ "$zip" = "1" ]; then
gzip $tmp
tmp="$tmp.gz"
HEADER='-H "Content-Encoding: gzip" --compressed'
fi
curl -v -H "Content-type: application/json; charset=UTF-8" $HEADER --data-binary @$tmp $api_url
rm "$tmp"
done
done
Cron-Job
Und einen passenden Cronjob dafür anlegen:
1-59/5 * * * * sleep 9; /usr/local/sbin/alfred-monitoring-proxy
WICHTIG: Bitte im nächsten Abschnitt den optimalen Zeitpunkt für das senden bestimmen!
Wahl des korrekten Delays (sleep)
Das Zusammenspiel zwischen nodewatcher, Alfred und Monitoring ist komplex. Entsprechend gibt es mehr und weniger sinnvolle Zeiten, wann der Alfred Master seine Daten an das Monitoring sendet. Die folgende Tabelle soll bei der Wahl eines geeigneten Delays behilflich sein.
Anstatt eines fixen Delays ist auch eine Variante mit random möglich. Die Grenzen sollten dabei die angegebenen Bereiche nicht verlassen!
WICHTIG: Sind mehrere Alfred Master in einer Hood sollten diese ihre Daten nie gleichzeitig schicken! (Empfohlener Abstand min. 5 sec.)
| Wartezeit nach Erreichen von */5 | Kommentar | |
|---|---|---|
| 0 - 50 sec. | Reservierter Zeitslot (nodewatcher)
| |
| 50 - 85 sec. | Empfohlener Zeitslot
| |
| 85 - 120 sec. | Reservierter Zeitslot (Netmon-VM)
| |
| 120 - 175 sec. | Möglicher Zeitslot
| |
| 175 - 185 sec. | Reservierter Zeitslot (Erstellung der Statistiken)
| |
| 185 - 300 sec. | Freier Zeitslot
|
Tipps:
Handelt es sich um mehr als eine Minute Delay, kann die Cron Syntax ausgenutzt werden:
1-59/5 * * * * Befehl
Das löst dann 00:01, 00:06, 00:11 usw. aus, also im beginnend bei 1 bis 59 in 5-er Schritten
2-59/5 * * * * Befehl
Das löst dann 00:02, 00:07, 00:12 usw. aus, also im beginnend bei 2 bis 59 in 5-er Schritten.
In Kombination mit sleep gibt es also für 130 Sekunden folgende Lösungen:
*/5 * * * * sleep 130; Befehl
oder besser:
2-59/5 * * * * sleep 10; Befehl
Zwei Minuten plus 10 Sekunden sind 130 Sekunden, aber man vermeidet den langen Sleep.
