InfluxDB / Grafana

[Marha]

Danke Carsten für Deine Ausführungen und den Einblick.

[skyacer]

Ist noch alles im Aufbau, meine influxDB und grafana-Container

Hey, das klingt alles super bei dir. Da du dich ja noch am Anfang befindest wie schaut es den da aus gleich einen Wiki dafür zu schreiben mit Bildern. Würde glabe ich einigen helfen die das später auch einmal vor haben.

Grüße

[Marha]

Das wäre perfekt.

[saegefisch]

Ist zwar OT, aber der Ausflug scheint mir hier schon ok...
Aber wir sollten Installationsthemen abseits edomi nicht ausufern lassen, das Folgende sollte für jeden, der schon gedockert hat, rasch zum Ziel führen: edomi-Daten -> influxdb -> grafana

Habe mich für diese Anwendungen bewusste dafür entschieden, influxDB und grafana nicht in ein compose zu legen, weil ich sie getrennt verwalten bzw. übergreifend nutzen möchte. Aus der strikten Docker-Philosophie heraus könnte man das so als nicht sinnvoll einordnen; muss jeder für sich entscheiden. Da ich aber mehrere influxDB aus unterschiedlichen Quellen bewirtschafte, möchte ich z.B. für den Neustart von telegraf nicht, dass meine influxdb kurz für edomi nicht erreichbar ist. Da grafana nur ein möglicher influxDB-Konsument ist, sehe ich auch hier eine Trennung. Wenn man nur eine influxDB und nur grafana hat, dann würde man es wohl zusammen in ein compose legen.

Das folgende kann man also so machen, aber bestimmt auch ganz anders. Ports macht man, wie man es braucht, man muss grafana also nicht von den üblichen 3000 auf 9903 legen... Die MNT-Pfade muss jeder für sich anpassen, sollte man vorab in der etc/fstab machen (z.B. auf seinen NAS). Oder auch lokal, wenn man denn meint, die Datenablage wäre auf dem Docker-Host hinreichend behütet (Backup-Strategie!)

influxDB: docker-compose.yml

version: '3'
services:
  influxdb_status:
    image: influxdb:alpine
    container_name: influxDB_status
    restart: always
    ports:
      - "8086:8086"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /mnt/data_nfs4/influxdb_status:/var/lib/influxdb
    environment:
      - TZ=Europe/Berlin
      - INFLUXDB_HTTP_AUTH_ENABLED=true
      - INFLUXDB_DB=status
      - INFLUXDB_ADMIN_USER=<wähle Admin-User>
      - INFLUXDB_ADMIN_PASSWORD=${ADMIN_PASSWORD_STATUS}
      - INFLUXDB_USER=<wähle User für schreibene Zugriffe auf genau nur die obige DB "status">
      - INFLUXDB_USER_PASSWORD=${WRITE_PASSWORD_STATUS}
      - INFLUXDB_READ_USER=<wähle User für lesende Zugriffe auf genau nur die obige DB "status">
      - INFLUXDB_READ_USER_PASSWORD=${READ_PASSWORD_STATUS}
  influxdb_haus:
...
  influxdb_pv:
...
wenn Du mehr brauchst...

Dazu im selben Verzeichnis eine ".env"-Datei, in der Du die PW notierst zu den verwendeten Variablen. Im influxDB-LBS aus edomi heraus nutze ich dann den schreibenden User. in Grafana den lesenden User. Admin niemals für andere Zwecke als per SSH. Technisch gesehen könnte man natürlich auch alles über den admin machen, ist aber keine gute IT...

grafana: docker-compose.yml

version: '3'
services:
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: always
    ports:
      - "9903:3000"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /etc/ssl/meineca:/etc/grafana/ssl:ro
      - /mnt/data_nfs4/grafana:/var/lib/grafana
      - /mnt/data_nfs4/grafana/grafana.ini:/etc/grafana/grafana.ini
    user: "0"
    environment:
      - TZ=Europe/Berlin
      - GF_INSTALL_PLUGINS=grafana-piechart-panel,grafana-simple-json-datasource

und vor Installation würde ich die grafana.ini vorbereiten (im Volumes-pfad!) mindestens mit:

#################################### Server ####################################
[server]
# Protocol (http or https)
protocol = https
# The ip address to bind to, empty will bind to all interfaces
http_addr = 0.0.0.0
# The http port  to use
http_port = 3000
# https certs & key file
cert_file = /etc/grafana/ssl/certs/<dein öffentliche Schlüssel>.pem
cert_key = /etc/grafana/ssl/private/<Dein privater Schlssel>.pem

Initial User/PW sind admin/admin und man muss das PW bei der Erstanmeldung ändern.

Viel Erfolg!

Mit Daten aus edomi (fritzbox-LBS - erweitert um weitere Werte) sieht das z.B. so aus. Die Daten sind aber sehr gut und wunderbar auch in edomi zu visualiseren und mache ich auch schon - d.h. ich plane nicht, grafana in edomi einzubetten. Für die FB braucht man kein influxDB oder grafana. aber als Mess-Freak (ohne "I"! ... ) habe ich alleine schon so viele Leistungsdaten aus meinem Haus, dass edomi das für längere Zeiträume nicht mehr sinnvoll möchte - und auch nicht braucht, weil es dafür auch nicht gemacht ist. Messen ist für mich auch Hobby - niemand braucht das wirklich und die meisten Menschen sind mit den Boardmitteln (Agggregation von Werten...) von edomi bestens versorgt.
grafana.PNG

[rdeckard]

saegefisch Vielen Dank für deine Infos!
Zufälligerweise befasse ich mich auch heute das erste Mal mit InfluxDB und Grafana. Für mich ist klar, dass ich meine Edomi-Diagramme (bzw. Archive) auslagern möchte, da MySQL nicht unbedingt dafür geeignet ist. InfluxDB scheint ja das richtige System dafür zu sein und erfreut sich steigender Beliebtheit.
Grafana ist cool für Diagramme, auch wenn das Design (noch) nicht so beliebig anpassbar ist. (Mit diesem Plugin könnte es aber gehen.)

Im Moment habe ich InfluxDB und Grafana einfach mal auf meinem Test Edomi CentOS 6.5 (VM) ohne Docker installiert. Sind meine allerersten Versuche. Aber es funktioniert immerhin schon. Telegraf möchte ich auch noch testen, da ich damit evtl. auch meine Systeme monitoren könnte.

Als nächstes möchte ich mal (testhalber) versuchen, meine produktiven Edomi Archidaten von MySQL zu InfluxDB zu kopieren (ca. 10 Mio Records), damit ich schon echte Daten zum Spielen habe. (Ein Tipp, wie man das am besten machen könnte? Kann man den MySQL datetime Timestamp 1:1 nutzen? Die Werte in Edomi sind glaub auf den ersten Blick varchar, müssten also noch während der Migration entsprechend gecastet werden, oder macht das InfluxDB automatisch?)

Nebst diesen technischen Tests kommt dann bald die Frage, wie man InfluxDB korrekt konfiguriert. Welche Measurements zusammenfassen? Was als Fields und was als Tags definieren und dann vorallem das für mich noch nicht ganz verstandene Prinzip der Retention Policies, Continuous Queries und shards. Also ich weiss so ungefähr, dass man damit die Daten automatisch komprimieren kann. Aber wie das im Genauen umgesetzt wird, weiss ich noch nicht. Und es ist sinnvoll, wenn man das vorher testet und versteht, ansonsten sind dann plötzlich nach einem Monat ALLE Daten weg.

[wintermute]

Ein Tipp, wie man das am besten machen könnte?

Ich hab mal irgendwann ein Perl-Skript gepostet um RRD-Daten von einem Wiregate nach Influx zu bekommen. Das koenntest Du evtl als Ansatzpunkt nehmen...
Bin grad aber zu faul zu suchen

[saegefisch]

und wenn du an relevanten Daten arbeitest: https://docs.influxdata.com/influxdb...p_and_restore/

[rdeckard]

Ich habs jetzt mal auf 2 Varianten via CSV File gemacht.

Einerseits mit dem Telegraf, was aber etwas komplizierter zum Konfigurieren ist (und bei mir noch nicht ganz korrekt läuft). Und andererseits über dieses hilfreiche Tool: https://github.com/jpillora/csv-to-influxdb

Zuerst natürlich in der MySQL Datenbank das Export SELECT Query definieren (in meinem Fall mit der MySQL Workbench). Bei meinem Test sah das so aus (Variante für Telegraf):

MySQL_Export.png

SELECT UNIX_TIMESTAMP(STR_TO_DATE(datetime, '%Y-%m-%d %T')) AS unixtime, gavalue, 'Innen' AS Raum, 'Temperaturen' AS Measurement FROM edomiLive.archivKoData WHERE targetid=14 ORDER BY datetime DESC LIMIT 0,20;

Hier habe ich bereits den MySQL Timestamp zu einem Unix-Timestamp umgewandelt und eine Tag-Spalte und eine Measurement-Spalte hinzugefügt, weil dies offenbar der Telegraf erwartet.

Das Telegraf config.file sah so aus:

# Telegraf Configuration
[global_tags]

[agent]
  interval = "10s"
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_interval = "10s"
  flush_jitter = "0s"
  precision = ""
  debug = true
  quiet = false
  logfile = ""
  hostname = ""
  omit_hostname = true

[[outputs.influxdb]]
  database = "csv"

[[inputs.file]]
  files = ["/root/test_export_mysql.csv"]
  data_format = "csv"
  csv_header_row_count = 1
  csv_comment = "#"
  csv_measurement_column = "Measurement"
  csv_tag_columns = ["Raum"]
  csv_timestamp_column = "unixtime"
  csv_timestamp_format = "unix"

Wie gesagt, das hat noch nicht ganz funktioniert. Irgendwie loopt der Telegraf das CSV endlos beim Importieren. Daten scheinen aber korrekt in Influx anzukommen.
Hab den Fehler noch nicht gesucht, da ich zufällig auf das oben erwähnte Hilfstool gekommen bin, was auf den ersten Blick viel einfach ist und auch zu funktionieren scheint.

Hier musst ich dann das MySQL Export Query auch nicht so stark anpassen, da man den Original Timestamp verwenden kann und auch keine Measurements-Spalte benötigt. Einzig eine Tag-Spalte habe ich noch hinzugefügt. Das Query sieht dann in diesem Fall so aus:

SELECT datetime AS timestamp, gavalue, 'Innen' AS Raum FROM edomiLive.archivKoData WHERE targetid=14;

Aufruf des Tools war so:

./csv-to-influxdb_linux_amd64 -t Raum -b 200000 test_export_mysql3.csv

Obwohl knapp 170'000 Datensätze exportiert wurden und ich eine Batch-Size von 200000 angegeben habe, hat er aber nur ca. 80'000 Datensätze wirklich in Influx importiert. Entweder diese Batch-Size sind nicht Records oder ein anderer Buffer greift hier noch ein. Aber zumindest diese 80'000 Datensätze sind in InfluxDB drin und sehen korrekt aus (inkl. Original Timestamp). Die 80'000 Datensätze waren in 5-10 Sek. drin. Also geht sauschnell. (Gut, sind ja nur Timestamps und paar Zahlen)

Scheint also grundsätzlich zu klappen.

[saegefisch]

Danke, Hansjörg für's Teilen Deiner Lösung! Habe aus anderer Quelle ähnliches vor, wenn meine inlfuxDB komplett steht. Dann wird mir das sehr helfen.

Wegen der Differenz in den Satzzahlen eine reine Vermutung, ohne zu wissen, ob telegraf und/oder influxDB bei Dateien dies tun: Kann es sein, dass Deine Messungen zum Teil so nah beieinander lagen (z.B. innerhalb einer Sekunde), dass sie entweder aggregiert oder überschrieben (letzter gewinnt) wurden?

[saegefisch]

Frage zu grafana bei bei folgender Datenkonstellation:

> select * from "ping" where "url" = 'pv.sma.homemanager' ORDER BY time DESC LIMIT 5
name: ping
time                average_response_ms host maximum_response_ms minimum_response_ms packets_received packets_transmitted percent_packet_loss result_code standard_deviation_ms sys type   url
----                ------------------- ---- ------------------- ------------------- ---------------- ------------------- ------------------- ----------- --------------------- --- ----   ---
1557134650000000000                     HAL                                          0                10                  100                 1                                 sma server pv.sma.homemanager
1557134587000000000 0.562               HAL  0.848               0.438               4                8                   50                  0           0.166                 sma server pv.sma.homemanager
1557134527000000000 0.497               HAL  0.594               0.315               4                8                   50                  0           0.11                  sma server pv.sma.homemanager
1557134470000000000                     HAL                                          0                10                  100                 1                                 sma server pv.sma.homemanager
1557134409000000000 0.579               HAL  0.648               0.542               4                10                  60                  0           0.044                 sma server pv.sma.homemanager

Bei Verwendung von Singelstat (=Einzelwert anzeigen) würde ich erwarten, dass wenn ich field(average_response_ms) wähle, aktuell "no value" erschient - das wäre zumindest mein Wunsch, den faktisch gibt es ja auch keinen Wert in der letzten Messung. Doch liefert mir grafana stets den letzten verfügbaren, hier "0.562" aus einer früheren Messung. Das ist in anderen Fällen sicher prima, aber wenn der ping fehl schlägt, will ich nicht den letzten funktionierenden sehen, sondern das gerade nix geht.
Hab' schon vieles versucht (last, mean, ohne/mit GROUP_BY time mit unterschiedlichen Intervalen, irgendwie steh' ich auf dem Schlauch...

Wie muss ich die Query gestalten, damit bei fehlendem Wert bei einer Messung auch tatsächlich no value kommt?

--------------
Nachtrag: Hatte schon eine Weile viel versucht; nach dem ich das obige schrieb, versuchte ich das Folgende und es scheint so zu gehen: bei GROUP_BY hinzufügen z.B. fill(99999) und dann Value Mapping von 99999 auf no value. Wenn man dann noch Coloring verwendet, wird no value auch rot.
Wenn jemand einen anderen Weg kennt: gerne!

[rdeckard]

Wegen der Differenz in den Satzzahlen eine reine Vermutung, ohne zu wissen, ob telegraf und/oder influxDB bei Dateien dies tun: Kann es sein, dass Deine Messungen zum Teil so nah beieinander lagen (z.B. innerhalb einer Sekunde), dass sie entweder aggregiert oder überschrieben (letzter gewinnt) wurden?

Die Temperatur-Werte habe ich minütlich ins Edomi-Archiv geschrieben. Das sollte also nicht zu "eng" sein.
Hab mir aber am Wochenende mein (Test) Host zerschossen und muss nochmals von vorne beginnen. Deshalb bin ich noch nicht viel weiter.
Zudem habe ich bereits ein weiteres "Problem" entdeckt. Obwohl ich die 1:1 Datumswerte von Edomi (MySQL) für die Migration verwendet habe, zeigt mir dann Grafana bei meinen ersten Tests offenbar 2 Std. Versatz an. Da muss man höllisch aufpassen mit diesen ganzen Datumswirrwarr. Vorallem wenn die Daten migriert werden. (Ob Grafana oder InfluxDB die Ursache sind, muss ich noch prüfen.)

Und wenn man tausende Temperaturwerte mit einem Timestamp hat, dann sieht das schnell mal "korrekt" aus und man hinterfrägt das gar nicht.
Mir ist es nur zufällig aufgefallen, weil ich mal den max. Wert (39.9°C) wissen wollte und dann etwas staunte, dass das im Juli 2018 um 21:30 gewesen sein sollte. Fand ich doch etwas hoch für die Zeit. Im Excelsheet stand dann 19:30 drin, was eher passt. Also bei solchen Sachen immer konzentriert arbeiten und wenn möglich querchecken. (Wenn mal alles korrekt läuft, sollte es ja nichts mehr zu ändern geben...)

[Uwe!]

2 Std Versatz klingt sehr nach einmal UTC und einmal MESZ.

[gulp2k]

Hallo Michael,
klasse LBS, danke!

4 Dinge schlage für eine Update vor:

• Dein Baustein lässt derzeit kein Schreiben von Null-Werten zu. Korrektur
  if ($E[$i]['value'] && $E[$i+1]['value']!='' && $E[$i+3]['value']){
  in dem code-Block

...
$data="";
for($i = 10; $i < 45; $i=$i+4) {
if ($E[$i]['value'] && $E[$i+1]['value'] && $E[$i+3]['value']){
... 

• String-Werte (z.B. aus der Fritzbox "Connected") kann der LBS nicht schreiben, weil influxDB die delimitted erwartet. Natürlich kann man das mit einem vorgelagerten LBS machen Doch schlage ich Dir folgende Automatik vor, die bei mir bislang wunderbar funktioniert und sauber unterscheidet. Man könnte das auch noch auf einen zusätzlichen EIngang schaltbar machen, z.B. "Auto-Delimiter String". Direkt anschließend zum obigen Code-Block funktioniert bei mir:

...
$switch = 1; // könnte man auf einen E legen für "Auto-Delimiter String"
if ($switch==1 && is_numeric($E[$i+1]['value'])==false) {
$data.=$E[$i]['value'] . ($E[$i+2]['value'] ? ",".$E[$i+2]['value'] : "") . " ". $E[$i+3]['value']."=".'"'.$E[$i+1]['value'].'"'."\n";
} else {
$data.=$E[$i]['value'] . ($E[$i+2]['value'] ? ",".$E[$i+2]['value'] : "") . " ". $E[$i+3]['value']."=".$E[$i+1]['value']."\n";
}
... 

• Es wäre sinnvoll, die precision mit setzen zu können. Ich hab' mir das mal hart codiert, aber noch besser wär's auf einem weiteren Eingang; entweder genau nur für precision (dann würde man z.B. den Eingang mit "s" belegen für sekündlich) oder als freier URL-Append (dann würde man den Eingang z.B. mit "&precision=s") (vor-)belegen und könnte das auch für andere Parameter flexibel nutzen.

...
$url = $protocol."://$host:$port/write?db=$db_name&precision=s";
... 

• Nur Wunsch, kein echtes Thema: Îrgendwie habe ich mehrerer Fälle, wo ich 11 Werte schreiben wollte, nicht nur die verfügbaren 10 - vermutlich weil ich stets als erstes einen Status des "Device OK" voranstelle mit 0 oer 1, um in grafana auf einen Blick zu sehen, wenn ein Gerät down ist und dann meist dazu eine gerade Anzahl Werte. Also wenn Du ohnehin dran wärst gelegentlich und erweitern magst...kann ich aber für mich auch selbe rmachen...

Viele Grüße,
Carsten

Hi Carsten,

hat zwar etwas länger gedauert aber ich hab jetzt mal die meisten deiner Wünsche übernommen.
Viel getestet habe ich noch nicht aber bei mir läufts.
Was den 11. Wert angeht muss ich dich aber enttäuschen. Krumme Werte widerstreben mir da einfach und dafür hatte ich ja sowieso den Trigger Ausgang vorgesehen.
Meine WP z.B. hat 4 davon kaskadiert !

Wenn noch was sein sollte immer her damit.

LBS ist im Download Portal.

[saegefisch]

gulp2k : Läuft seit dem klasse und problemlos. Danke!

ABER...
Hallo allerseits,
habe jetzt meine InfluxDB mal auf https umgestellt. Meine telegraf-Lieferanten machen das auch ganz wunderbar mit

## Use TLS but skip chain & host verification
insecure_skip_verify = true

war die Umstellung quasi nahtlos. Grundsätzlich geht also die InfluxDB mit https.

Aber aus edomi kommen aus dem LBS keine Daten in influxDB an mehr an. Habe an E8 auf "https" umgestellt. Auch bei Debug=8 liefert das Log keine Hinweise, dass da was schief liefe.

=> Hat jemand schon erfolgreich den LBS 19001034 mit https verwendet?

Nachtrag:
Im Log von InfluxDB finde ich

http: TLS handshake error from <edomi-IP>:41777: remote error: tls: unknown certificate authority

InfluxDB liegt auf einem anderen Server und dort habe ich natürlich die cert/key des Linux-Servers verwendet. Kann es sein, dass ich bei https nicht Daten aus unterschiedlichen IP-Quellen sammeln kann in eine influxDB?

Nachtrag2:
Kann nicht sein, weil ich von meinem RevProxy-Server (mit anderer IP natürlich) ebenfalls in die selbe DB schreibe und das auch ankommt - mit dem Parameter siehe oben bzw. wie es auch hier (ganz unten) steht. Hm, aber warum funktioniert's dann nicht aus dem LBS heraus...?

[gulp2k]

Ich nutzte aktuell nur http, bin mit aber ziemlich sicher das ich auch schon mal https am laufen hatte, das war ursprünglich ein Grund für diesen LBS.

Spontan hört sich das danach an das du entweder in deinem Zertifikat von Influx einen anderen hostnamen drin hast die URL muss den gleichen FQDN haben wie im Cert.
Oder du hast ein eigenes Zertifikat gebaut, dann musst du im Edomi System deine CA bekannt machen.