Grafana gcx bringt Observability in die CLI und gibt Agenten Zugang zu Produktionskontexten. Dies reduziert MTTR und schließt die Lücke zwischen Code und dem tatsächlichen Verhalten des Systems.
Das Problem zeigt sich nicht sofort — bis das Team die Entwicklung mit agentenbasierten Werkzeugen beschleunigt. Die Codegenerierung wird schneller, aber die Observability bleibt außerhalb dieses Rahmens. Ein Ingenieur oder Agent schreibt Code, ohne zu sehen, was in der Produktion passiert: es gibt keine Daten zur Latenz, kein Verständnis für SLO, kein Signal für eine Degradierung. Es entsteht eine Lücke: Entscheidungen werden auf Annahmen und nicht auf Fakten getroffen. Jeder Wechsel zu einem separaten Observability-Tool verstärkt das Context Switching und erhöht die Reaktionszeit auf Vorfälle.
Als Antwort wurde der pragmatische Weg gewählt — die Observability über Grafana gcx in die CLI zu verlagern. Dies bietet eine einheitliche Schnittstelle, in der der Agent nicht nur Code schreiben, sondern auch den Zustand des Systems lesen kann. Der entscheidende Trade-off: der Verzicht auf eine GUI-orientierte Interaktion zugunsten einer textbasierten Schnittstelle. Aber für agentenbasierte Umgebungen ist das natürlich: Modelle arbeiten nach dem Schema text in / text out, mit vorhersehbaren Rückgabecodes. Infolgedessen wird gcx zur gleichen Klasse von Werkzeugen wie git oder kubectl, jedoch für Aufgaben der Observability und SRE.
Die Implementierung basiert auf dem vollständigen Zyklus der Observability: von der Abwesenheit von Metriken und Alerts bis hin zu deren automatischer Erstellung und Analyse. gcx erfordert keine vorherige Konfiguration als zwingende Voraussetzung. Dies ist wichtig, da die meisten Dienste ohne Instrumentierung und SLO starten. Der Agent erhält primitive Werkzeuge zur Arbeit mit Metriken, Logs und Alerts direkt im Terminal. Das Werkzeug ist für den agentenbasierten Modus angepasst: es entfernt visuelle Ablenkungen, bietet ein maschinenlesbares Verzeichnis von Befehlen und erfordert eine ausdrückliche Bestätigung für destruktive Operationen. Die Unterstützung von Kontexten, ähnlich wie bei kubectl, ermöglicht die Arbeit mit mehreren Umgebungen, ohne den globalen Zustand zu verändern.
Eine separate Schicht sind die Agent Skills. Dies ist eine Sammlung von Anweisungen für typische Aufgaben: Einrichtung der Observability, Untersuchung von Alerts, Arbeit mit SLO, synthetische Prüfungen. Sie verringern die Unsicherheit und reduzieren die Abhängigkeit vom „Raten“ der Möglichkeiten der CLI. Wichtig ist, dass der Agent nun nicht mehr auf statisches Wissen aus dem Training angewiesen ist, sondern auf den aktuellen Zustand des Systems. Dies verändert die Form der Interaktion: Fragen werden an reale Metriken und Ereignisse gebunden.
Das Ergebnis ist eine Verkürzung der Reaktionszeit auf Vorfälle und eine Verringerung des operationellen Rauschens. Aufgaben, die früher in mehrtägige Tickets umgewandelt wurden, passen nun in eine Sitzung des Agents. Auch die Kosten für die Durchführung von Aufgaben sinken durch eine effizientere Interaktion mit der CLI und eine Verringerung des Token-Burns. Konkrete Metriken werden nicht angegeben, aber der Effekt wird in Form einer beschleunigten Diagnose und Problemlösung behauptet. Die entscheidende Veränderung ist, dass der Agent, der Code schreibt, das gleiche Maß an Sichtbarkeit erhält wie der On-Call-Ingenieur.
Dieser Ansatz fügt sich in den allgemeinen Trend ein: Observability als Code (observability as code) und die Verschiebung der Werkzeuge hin zu CLI-first. In der agentenbasierten Entwicklung ist dies nicht nur ein Komfort, sondern eine Anforderung an die Architektur der Werkzeuge.