Leider scheint wieder was nicht zu funktionieren. Hier im Dashboard Open Hive: Die BeeKloppten fehlen sämtliche Daten ab 05.07.2018, ca. 23 h, Die nodes liefern aber Daten, wie man hier sehen kann: http://open-hive.org/apiary/clemens/node002.html
Andere nodes liefern Daten, z.B. MUC-MH-B99 plus Wetter, daher würde ich vermuten, dass an der CSV-Annahme was nicht (mehr) stimmt?! @Andreas hast du eine Idee?
Vielen Dank für Eure Meldung. Die Symptome deuten u.U. auch auf Imkerliche Daten nicht im Grafana sichtbar hin, nicht?
Wir müssen da später mal unter die Haube schauen: Dass es ausschließlich nur die CSV Datenannahme betrifft, kann ich mir zwar grade nicht vorstellen, kann es aber auch nicht ausschließen. An den Systemen haben wir im fraglichen Zeitraum nur geringfügige Änderungen gemacht, es wurden keine neuen Releases eingespielt oder dergleichen.
Später wissen wir bestimmt mehr.
Hallo in die Runde,
danke nochmals an @clemens für die Meldung. Wir sehen uns das nun einmal an und vermuten und hoffen, dass auch diesmal wieder nur der Datenbankindex kaputt ist.
Ein erster Versuch auf Anfrageebene bringt die gleichen Ergebnisse wie Clemens’ Beobachtung:
$ influx -precision rfc3339
> select * from hiveeyes_open_hive_test01..default_1_sensors order by time desc limit 1;
time Outside Humid Outside Temp Voltage Weight
---- ------------- ------------ ------- ------
2018-07-05T20:12:15Z 1 27.3 3.51 8.185
Die letzten aufgezeichneten Daten zeigen leider, dass tatsächlich nur bis zum fraglichen Zeitpunkt Meßwerte in der Datenbank vorliegen:
influx_inspect dumptsm /var/lib/influxdb/data/hiveeyes_open_hive_test01/autogen/3780/000000097-000000002.tsm
Summary:
File: /var/lib/influxdb/data/hiveeyes_open_hive_test01/autogen/3780/000000097-000000002.tsm
Time Range: 2018-07-02T00:26:34Z - 2018-07-05T20:12:15Z
Duration: 91h45m41s Series: 4 File Size: 2755
Alle Time Series Dateien scheinen in Ordnung zu sein:
influx_inspect verify -dir /var/lib/influxdb | grep -v healthy
Broken Blocks: 0 / 41991, in 1.9390382050000001s
Auch "influx_inspect report /var/lib/influxdb" berichtet nichts Auffälliges.
Wir müssen also in den Schichten “darüber” nachsehen, die Timeseries Datenbank scheint jedenfalls in Ordnung zu sein.
Vermutlich liegt es - wie immer ;] - am Kabel: In diesem Fall dem Datenkanal, der die Meßwerte von Open Hive per PHP entgegennimmt und an swarm.hiveeyes.org übermittelt, wie hier beschrieben:
Bei dieser Variante der Datenübermittlung spielen verschiedene Komponenten eine Rolle:
Auf Seite des Gateway Servers von Open Hive tut eine kleine PHP Maschinerie ihren Dienst, welche die Meßwerte per HTTP im CSV Format an die Hiveeyes Plattform weiterleitet, siehe auch data acquisition with PHP.
Die Python Maschinerie dekodiert die Daten aus dem CSV Format und leitet sie intern auf den MQTT Bus, siehe auch data acquisition with HTTP/CSV.
Irgendwo dort müsste der Wurm sein. Wir können auf jeden Fall bestätigen, dass schon eine zeitlang keine Daten mehr auf dem MQTT Bus ankommen:
mosquitto_sub -h swarm.hiveeyes.org -p 1883 -t '#' -v | grep open_hive
<void>Auf dem dafür vorgesehenen HTTP Kanal scheinen wirklich keine CSV Daten von Open Hive anzukommen:
root@elbanco:~# ngrep -Wbyline -d lo "host localhost and port 24642"
######
<void>
Schade! Wir können jedoch bestätigen, dass der Kanal “frei” ist, es gehen also Daten durch und werden durch nichts daran gehindert.
Der Grund für den Abriss der Datenübertragung ist also höchstwarscheinlich die Datenquelle, in dem Fall betrifft es den Gateway Server von Open Hive oder die darauf laufende Software. Also raus mit dem Wagen und den anderen auf die Hebebühne…
Danke @Andreas für die ausführliche Analyse! Beim testweise Abschicken von Daten liefert das skript schon die richtigen Hinweise
Warning: SSL: certificate subject name 'luftdaten.hiveeyes.org' does not match
target host name 'swarm.hiveeyes.org' ...
und damit wird es mit dem Abschicken der Daten nix:
Fatal error: Could not submit telemetry data to 'https://swarm.hiveeyes.org ...Danke! Ja, das geht auf meine Kappe: Ich habe neulich die Luftdaten nach https://luftdaten.hiveeyes.org/ umgezogen und dabei anscheinend einen Fehler bei den HTTPS Zertifikaten gemacht:
$ echo "Q" | openssl s_client -connect swarm.hiveeyes.org:443 -showcerts | openssl x509 -text | grep -E '(Subject:|DNS)'
Subject: CN=luftdaten.hiveeyes.org
DNS:luftdaten.getkotori.org, DNS:luftdaten.hiveeyes.org
Sorry vielmals.
@Andreas, du hast mich ja noch am Wochenende gefragt, was mit meinem Test-Node test01 los ist. Da die Batterien um die 3,5 V runter waren, dachte ich der senden nicht und das sei das Problem. Hmm, ist aber nicht so, der node hat noch Daten geschickt, die auf http://open-hive.org/apiary/test01/node001.html angekommen sind, was mir erst heute bewußt wurde.
Also, aufgefallen ist es uns, auch das Monitoring hat uns benachtichtig, nur meine Schlüsse waren vor 5 Tagen falsch. Sorry!
Doch nicht ganz:
$ echo "Q" | openssl s_client -connect swarm.hiveeyes.org:443 -servername swarm.hiveeyes.org -showcerts | openssl x509 -text | grep -E '(Subject:|DNS)'
Subject: CN=swarm.hiveeyes.org
DNS:luftdaten.getkotori.org, DNS:swarm.hiveeyes.org, DNS:telemeta.hiveeyes.org
Alles richtig: “swarm.hiveeyes.org” steht hier sogar direkt im “Common Name” Attribut des Zertifikats:
Subject: CN=swarm.hiveeyes.org
Ich hatte den Parameter "-servername swarm.hiveeyes.org" vergessen, der das richtige (und wichtige!) für SNI (Server Name Indication – Wikipedia) tut, nämlich den Hostnamen zu übermitteln, damit die Kommunikation mit multi-homed HTTP/SSL Web Servern gut klappt.
An dieses Thema denkt heutzutage kaum jemand mehr, aber früher musste man in der Tat mal HTTPS Web Server auf dedizierten IP Adressen betreiben. Mittlerweile ist SNI schon lange überall angekommen (Server, Browser, Whatever), kann aber natürlich nicht per Zeitmaschine in die Steinzeit zurückgeschickt werden.
Das Problem haben wir uns also (auch) eingehandelt, weil das Gateway noch auf PHP4 läuft, PHP aber erst ab Version 5.3 SNI unterstützt. Schade!
Wir werden sehen, was wir am Server tun können - vielleicht bekommen wir ihn wieder non-SNI kompatibel.
Falls es akzeptabel ist, an dieser Stelle auf HTTPS zu verzichten, könnten wir das jederzeit tun:
As sensor node hardware like the GPRSbee doesn’t do TLS, there’s an additional endpoint for unencrypted communication. In this case, just use:
export HTTPURI=http://swarm.hiveeyes.org/api-notls– See also: Hiveeyes data acquisition using HTTP
Ja, das klappt. Folgendermaßen bekommt man den konfigurierten virtuellen Server für “swarm.hiveeyes.org” an die erste Position,
root@elbanco:~# ls -1 /etc/nginx/sites-enabled/
01-swarm.hiveeyes.org
luftdaten.hiveeyes.org
was den Webserver veranlasst, genau diesen virtuellen Host anzusteuern und dessen Zertifikat auszuspielen, wenn ein non-SNI client anfrägt.
Hier nun nochmal - diesmal absichtlich ohne "-servername" Parameter:
$ echo "Q" | openssl s_client -connect swarm.hiveeyes.org:443 -showcerts | openssl x509 -text | grep -E '(Subject:|DNS)'
Subject: CN=swarm.hiveeyes.org
DNS:luftdaten.getkotori.org, DNS:swarm.hiveeyes.org, DNS:telemeta.hiveeyes.org
@clemens: Mit "CN=swarm.hiveeyes.org" an erster Stelle im Zertifikat sollte Deine Gateway Software den o.g. Fehler
Warning: SSL: certificate subject name 'luftdaten.hiveeyes.org'
does not match target host name 'swarm.hiveeyes.org'
nun nicht mehr ausgeben, sondern stattdessen wieder ordentlich kommunizieren. Kannst Du das überprüfen?
Klappt schon, der Sensor meldete gerade:
[RECOVERY] Grafana datasource freshness for Open Hive Teststand on
elbanco.hiveeyes.org is OK!
Wenn der Sensor nur mal kurz anschlägt, denke ich normalerweise, dass Du daran arbeitest ;]. Nach ein paar Tagen wollte ich dann doch mal nachhaken.
Ich hab das im Kopf auch nicht mit meinen Änderungen an den SSL Zertifikaten zusammengebracht und - weil es ja “augenscheinlich” nur Deinen Teststand betraf, als “nicht so wichtig” eingestuft. Very sorry meinerseits!
Zur Verbesserung der Einschätzbarkeit Gesamtsituation nehmen wir nun auch einen Deiner produktiven Meßknoten mit in die Überwachung dazu:
Prüfung
./check-grafana-datasource-stale.sh \
--uri https://swarm.hiveeyes.org/grafana/api/datasources/proxy/63/query \
--database hiveeyes_open_hive_clemens \
--table default_2_sensors \
--warning 1h \
--critical 2d \
--verbose
Ausgabe
INFO: check-grafana-datasource-stale 0.2.0
INFO: Checking hiveeyes_open_hive_clemens:default_2_sensors for data not older than 1h
OK - Data in hiveeyes_open_hive_clemens:default_2_sensors is more recent than 1h
Einen entsprechenden Konfigurationseintrag gibt es nun auch im Monitoring System, wie unter Monitoring in-flight data and the whole database for freshness - #6 by Andreas beschrieben und per GitHub - cicerops/monitoring-check-grafana: Monitor a Grafana datasource against data becoming stale to detect data loss or other dropout conditions. implementiert.
[NEW] Grafana datasource freshness for Open Hive Clemens #2 on elbanco.hiveeyes.org is OK!
Falls jemand von Euch ebenfalls solch einen Sensor auf seinem Datenkanal konfiguriert haben will: Gebt uns gerne Bescheid!