Hier ist eine Szene, die mir immer wieder begegnet — und ich wette, du kennst eine Variante davon.
Ein Roboter bleibt in einer Lagerhalle stehen. Die Flotte hat Dashboards — gute! Grafana-Panels, Traces, Metriken, Logs in einem Index, der jeden Monat echtes Geld kostet. Das Team hat seine Observability-Hausaufgaben gemacht. Und was passiert als Nächstes? Jemand öffnet ein Terminal, verbindet sich per SSH mit dem Roboter und fängt an zu greppen.
Ich finde das endlos faszinierend. Wir haben all dieses Tooling gebaut, und in dem Moment, in dem wirklich etwas kaputtgeht, sind wir zurück bei grep -r "ERROR", als wäre es 2009. Warum?
Ich habe eine ganze Weile darauf herumgekaut, und ich glaube, ich habe endlich die Antwort: Observability und Diagnose sind zwei verschiedene Disziplinen, die sich aus der Ferne nur ähnlich sehen. Wir kaufen hartnäckig die erste und erwarten, dass sie den Job der zweiten erledigt.
Zwei Fragen, nicht eine
Observability beantwortet die Frage: Was tut das System gerade? Sie ist gebaut für einen Engineer am Schreibtisch, mit Kontext im Kopf, beim Explorieren. Traces, Metriken, strukturierte Logs — das sind Erkundungswerkzeuge. Sie sind wunderbar, wenn man ungefähr weiß, wonach man sucht.
Diagnose beantwortet eine andere Frage: Was ist kaputt, warum, und was tue ich jetzt? Und hier kommt der Teil, den zu begreifen ich beschämend lange gebraucht habe — sie ist gebaut für den Moment, in dem der Kontext weg ist. Vor der kaputten Maschine steht ein Techniker, der deine Codebasis noch nie gesehen hat. Oder du selbst, drei Monate später — was im Grunde dasselbe ist.
Eine Logzeile ist ein Satz, den jemand zum Schreibzeitpunkt für sich selbst formuliert hat. Ein Fehler ist eine Datenstruktur, entworfen für einen Fremden zum Fehlerzeitpunkt. Das sind nicht dieselben Artefakte, und kein Log-Shipping der Welt macht aus dem einen das andere.
Das Auto in deiner Einfahrt hat das längst gelöst
Das ist der Teil, den ich wirklich liebe — denn die Antwort stand die ganze Zeit auf dem Parkplatz.
Wenn dein Auto kaputtgeht, liest der Mechaniker keine Logs. Es gibt keine, jedenfalls nicht wirklich. Stattdessen speichert das Auto einen Fehlercode — einen DTC — und jetzt kommt das Schöne: Neben dem Code speichert es einen Freeze Frame. Motordrehzahl, Kühlmitteltemperatur, Geschwindigkeit, Drosselklappenstellung — der Zustand der Welt in exakt dem Moment, in dem der Fehler auftrat. Automatisch erfasst, aufbewahrt, bis ihn jemand ausliest.
Und Fehler haben einen Lebenszyklus. Pending. Confirmed. Healed. Ein Fehler, der einmal an einem kalten Dienstag auftrat, ist etwas anderes als einer, der alle vier Minuten feuert — und das System kennt den Unterschied. Es gibt ein Standardprotokoll, um all das abzufragen (UDS, und heute seinen HTTP-sprechenden Nachfolger SOVD). Das heißt: Ein Mechaniker in jeder Werkstatt der Welt kann ein generisches Gerät anstecken und bekommt Antworten von einem Auto, das er noch nie gesehen hat.
Über dreißig Jahre davon. Deterministisch, langweilig, spektakulär wirksam. Ich habe Jahre im Automotive-Umfeld verbracht und gebe zu: Ich habe das komplett für selbstverständlich gehalten — bis ich anfing, mit Robotern zu arbeiten, und feststellte, dass es dort nichts davon gibt.
ROS 2 hat es nicht gelöst — und nicht aus Mangel an Versuchen
ROS 2 hat einen Diagnose-Stack. Es gibt ein /diagnostics-Topic, eine DiagnosticArray-Message, diagnostic_updater, diagnostic_aggregator. Ich will fair sein: Das ist wirklich nützlich, und es steckt viel Sorgfalt darin.
Aber schau dir an, was es tatsächlich ist: ein Live-Statusfeed. Key-Value-Paare aus Strings, periodisch publiziert, aggregiert zu einem Baum aus OK/WARN/ERROR. Wenn du in dem Moment subscribed warst, in dem etwas schiefging — wunderbar. Wenn nicht? Ist die Message weg. Es gibt keinen Fehlerspeicher. Keinen Lebenszyklus. Keinen Freeze Frame. Keinen Standardweg, einen Roboter von außen zu fragen: “Was ist dir letzte Nacht passiert?”
Und viele haben versucht, die Lücke zu füllen. Alles mit rosbag aufzeichnen und später durchwühlen (jetzt hast du ein Storage-Problem, plus das Durchwühlen). /rosout nach Elasticsearch schicken (herzlichen Glückwunsch, du hast schon wieder Observability gebaut). Nach Prometheus exportieren, in Foxglove zuschauen — alles gute Werkzeuge, und jedes einzelne beantwortet “Was tut das System gerade?” Wir bauen immer wieder das Erkundungswerkzeug und wundern uns, warum der Techniker in der Halle noch immer keine Antwort bekommt.
Das Muster ist, wenn man es einmal gesehen hat, überall: Die Robotik erfindet immer wieder Observability neu, weil die Softwarewelt genau das verkauft — während eine Maschine auf einem Betonboden das braucht, was die Automobilwelt vor Jahrzehnten herausgefunden hat.
Jemand hat das fehlende Stück endlich gebaut
Stell dir also meine Freude vor, als ich über ein Projekt stolperte, das genau die Transplantation ist, die ich hier beschreibe. Volle Transparenz: Es ist nicht meins, ich habe keinerlei Anteil daran. Ich habe es nur gefunden — und dieses seltene Gefühl gehabt: Endlich versteht es jemand.
ros2_medkit ist ein Open-Source-Diagnose-Gateway (Apache 2.0) für ROS 2. Es nimmt die Ideen, die Autos seit dreißig Jahren haben, und gibt sie Robotern: Deine Nodes werden in einen SOVD-artigen Entity-Baum organisiert, und Ausfälle werden zu strukturierten Fehlern — ein Fehlercode an einer Entity, mit Lebenszyklus, Historie und einem Freeze Frame des Systemzustands, erfasst in dem Moment, in dem es passiert ist. Alles abfragbar über eine schlichte REST-API. Kein SSH. Kein Spezial-Tooling auf dem Laptop.
Mein Lieblingsteil ist, wie die Daten hineinkommen: Drop-in-Bridges. Richte sie auf das, was dein System ohnehin schon emittiert — /diagnostics, /rosout, abgebrochene Actions — und aus Logzeilen werden Fehler mit Kontext. Null Codeänderungen. Du kannst einen Container auf einen bereits laufenden Roboter richten und ihm ein paar Minuten später Fragen stellen. (Fast DDS und CycloneDDS sind beide eingebaut — weil das natürlich das Erste ist, woran es sonst gescheitert wäre.)
Und der Teil, der mich wirklich gepackt hat: ros2_medkit ist das Open-Source-Fundament von selfpatch.ai, das dieselbe Idee über den ganzen Hallenboden zieht — ROS-2-Roboter, SPSen über OPC UA, Automotive-Steuergeräte. Eine Diagnoseschicht über Branchen hinweg, die nie dieselbe Sprache gesprochen haben, deterministische Fehlerkorrelation gegen vergangene Vorfälle, signierte Over-the-Air-Fixes mit Rollback, ein Mensch, der jeden Schritt freigibt. On-Premise, auf Wunsch air-gapped. Genau auf diese Kreuzbestäubung habe ich seit Jahren gewartet: die hart erarbeitete Diagnose-Disziplin der Automobilwelt, die endlich in jede Maschine durchsickert, die auf einem Hallenboden steht.
Wie sehr ich diese Idee liebe? Genug, um das zu tun, was ich am Ende immer tue, wenn mich eine Idee nicht mehr loslässt: Ich habe sie nachgebaut. Die taktora-medkit-Crates sind mein Rust-Port des Medkit-Konzepts, Teil von taktora, meinem Execution-Framework auf Basis von iceoryx2. Derselbe SOVD-Entity-Baum, dasselbe Fehlermodell mit Freeze Frames, derselbe REST-Contract — ros2_medkit-kompatibel, dasselbe Tooling spricht also mit beiden. Es gibt keinen besseren Weg herauszufinden, ob eine Idee trägt, als sie ein zweites Mal zu bauen — in einer anderen Sprache, auf einem anderen Stack. Ich kann berichten: Die Idee übersteht den Port. So gut ist sie.
Stell bessere Fragen
Nichts davon heißt, dass du deine Dashboards rauswerfen sollst. Behalte OpenTelemetry. Behalte die Metriken. Observability ist großartig in dem, was sie kann.
Achte nur darauf, welche Frage dein Tooling beantwortet. “Was tut das System gerade?” ist für Engineers beim Explorieren. “Was ist kaputt, warum, und was tue ich jetzt?” ist für den Moment, der dich tatsächlich Geld kostet — und der verdient eine eigene Disziplin, eigene Datenstrukturen und, ja, eigenen Spaß.
Denn genau dahin komme ich immer wieder zurück: Dieses Problem macht Spaß. Freeze Frames, Fehler-Lebenszyklen, Entity-Bäume — echte Mechanismen, dreißig Jahre erprobter Ideen, die darauf warten, zu Maschinen gebracht zu werden, die sie dringend brauchen. Wenn das auch nach deiner Sorte Spaß klingt: Der Code liegt genau hier. Richte ihn auf einen Roboter. Frag ihn, was kaputt ist. Schau, was er antwortet.
