Remote-Logging zur Ferndiagnose für den Terkin-Datenlogger

Einleitung

wollen wir die fehlenden Lücken bei der aktuell in Arbeit befindlichen Firmware schließen.

Bei Developing Terkin for MicroPython haben wir geschaut, dass die Firmware ordentliches Logging bekommt, worauf wir nun aufbauen wollen.

Plan

Wir sehen hier zwei drei Dinge.
a) Remote logging.
b) Log record buffering on local storage, see Zwischenpufferung von Daten und Log-Informationen auf SD-Karte.
c) Use annotations to support highlevel signalling of system events and operator interactions à la energy budget testbench.

Backlog

Danke für den Impuls via Zwischenpufferung von Daten und Log-Informationen auf SD-Karte. Ich hab das Thema mal auf Prio 1.5 bei [Backlog] Terkin-Datenlogger für BOB - #2 by Andreas gesetzt.

Datenstruktur » Adressierung

Diese Gedanken zu Aspekten der akkuraten Adressierbarkeit beziehen sich auf die Zwischenspeicherung (buffering) von log records auf einem Flash-Speicher.

Einerseits: Warum nicht. Andererseits: Schaumamal. Folgende Überlegungen gibt es dabei:

  • Vielleicht kann oder sollte der Identifizierer auch in den Dateinamen selbst kodiert werden.
  • Vielleicht kann oder sollte das identifizierte Problem an anderer Stelle gelöst werden. Auf anderen attached storages kodiert man die Maschinennamen schließlich auch nicht in die Verzeichnis- oder Dateinamen selbst.
  • Auf jeden Fall sollten im Daten- und Logverzeichnis aber entsprechende Metadaten(-dateien) Rückschlüsse über die Herkunft der angefallenen Daten und Logeinträge zulassen.

Datenstruktur » Nachrichtenformat

For protocol references, see also…

Syslog

Some spots from the world of syslog.

Seitenblicke

Loki API

Other NIHs

Eine Blaupause eines für den Embedded Einsatz ausgelegten Logging-Systems.

Auch der Logger von Jumper spielt im gleichen Umfeld.

https://medium.com/jumperiot/how-to-build-a-monitoring-and-analytics-system-for-your-iot-embedded-devices-87f73eda3497

Wissenschaftlicher, dafür einen Tick zu Lowlevel (trace recording) und mittlerweile schon ein paar Jahre auf dem Buckel.


Request for comments

Ich will hier kein riesen Faß aufmachen, aber bei der Gelegenheit vielleicht kurz in die Runde fragen, ob jemand unter uns ist, die mit solchen Dingen mindestens im semiprofessionellen Praxiseinsatz schon einmal zu tun hatte und vielleicht ihre Erfahrungen oder Ratschläge teilen will.

syslog ist ‘industriestandard’ und kann ‘jeder’… openwrt, plasterouter, auch all die kommerziellen devices ob fuer homegamer oder teures gear von cisco oder juniper, ich denke auch die fritzbox.

da es fuers debugging bestimmt ist muss es ja nicht alle fancy features haben, sondern zuerst vor allem andren zuverlaessig und simpel sein, sonst hat man gleich wieder mehr der dinge die man debuggen muss ;)

aus der perspektive ist syslog ein guter kandidat…
das ist nix andres als ‘strings auf udp ip/port ziele werfen. zeilenbasiert.’

rsyslog/syslog-ng ist dann eher ne featurefrage im detail… ich seh da aber nix das da komplexitaet wert waere. (und die verbreitung ist kleiner)

die meisten andren dinge kenn ich nicht aus dem maschinenraum. das ist alles zu hip/speziell.

1 Like

Dafür wäre ich auch. Siehe “Seitenblicke” und “Datenstruktur » Nachrichtenformat” – vielleicht besser “direktgradeaus”.

Logging machinery for MicroPython applications

Momentan haben wir das klassische logging-Modul aus der MicroPython-Standarbibliothek mit ein paar Erweiterungen eingebaut.

Folgende Fundstücke gibt es unabhängig davon.

MicroPython

Allgemein

Lowlevel ESP-IDF

1 Like

RFC5424 FTW

Einleitung

und wird daher angestrebt.

Wir haben uns die von Rainer Gerhards (Adiscon) überarbeitete Version des Syslog Protokolls in Form des RFC 5424 - The Syslog Protocol reingezogen und finden im Besonderen die STRUCTURED-DATA Erweiterungen sinnvoll.

Beispielnachrichten

Ein paar Beispiele

Example 1 - with no STRUCTURED-DATA

   <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
   - 'su root' failed for lonvick on /dev/pts/8

Example 3 - with STRUCTURED-DATA

   <165>1 2003-10-11T22:14:15.003Z mymachine.example.com
   evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
   "Application" eventID="1011"] An application
   event log entry...

Example 4 - STRUCTURED-DATA Only

   <165>1 2003-10-11T22:14:15.003Z mymachine.example.com
   evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
   "Application" eventID="1011"][examplePriority@32473
   class="high"]

Ausblick

Es wäre praktisch, dieses Nachrichtenformat sowohl an eine UDP-Datensenke (rsyslogd) senden zu können als auch im gleichen Format ggf. auf der SD-Karte zwischenzupuffern, um Konnektivitätslücken auszugleichen, wie bei Zwischenpufferung von Daten und Log-Informationen auf SD-Karte gewünscht.

Zufällig lief uns gerade ein passendes Python-Modul über den Weg, wie man strukturierte Informationen in Log-Nachrichten überhaupt sinnvoll auf den Weg bringen könnte.

Diagnostics with Tracing

Auch hier geht es um die Übermittlung von strukturierten Log-Informationen.

About

Effectively developing systems and operating them in production requires visibility into their behavior at runtime. While conventional logging can provide some of this visibility, asynchronous software — like applications using the Tokio runtime — introduces new challenges.

tracing is a collection of libraries that provide a framework for instrumenting Rust programs to collect structured, context-aware, event driven diagnostics. Note that tracing was originally released under the name tokio-trace ; the name was changed to reflect that, although it is part of the Tokio project, the tokio runtime is not required to use tracing .

Resources

https://tokio.rs/blog/2019-08-tracing/
– via: Diagnostics with Tracing, a Unified Instrumentation System for Rust | Hacker News

Ich denk auch; das ist gut abgehangen, ausreichend und es gibt diverse Tools aus dem System-/Netzwerk-Administrationsbereich, um die Messages einzufangen und aufzubereiten.