Monitoring
Jede App ist von Anfang an beobachtbar, mit CPU, Arbeitsspeicher, Traffic und Logs live in der Console und über MCP. Exporter müssen Sie nicht anbinden.
Jede App ist beobachtbar, sobald sie live ist, ohne dass Sie etwas installieren. Sie schauen in die Console, Ihr Coding-Agent liest dieselben Daten über MCP.
Ressourcennutzung beobachten
CPU und Arbeitsspeicher live im Verhältnis zur Zuteilung der App, als Verlauf über 24 Stunden: die Nutzung gegenüber der Untergrenze (Request) und der Obergrenze (Limit). So sehen Sie, ob eine App bequem läuft oder an ihre Obergrenze stößt. Genau das brauchen Sie, um ein Projekt zu dimensionieren. Ihr Agent liest dieselben Zahlen mit nyx_project_state.
Traffic verfolgen
Für jede App, die HTTP ausliefert, erfasst das Traffic-Panel vier Werte:
Traffic-Zahlen gibt es nur in der Console, ein MCP-Tool dafür gibt es noch nicht. Behalten Sie Fehlerquote und p95-Latenz im Blick. Eine steigende Fehlerquote oder eine Latenzspitze ist meist das erste Anzeichen einer Regression. Weil jeder Deploy in der Betriebsakte steht, können Sie eine Spitze neben die Änderung legen, die sie ausgelöst hat.
Logs lesen
Für die Details hinter einer Metrik lesen Sie die Logs der App: in der Console auf der Seite Logs des Projekts (Live-Tail einer App) oder über Ihren Agenten mit nyx_app_logs. Das Tool liefert strukturierte Zeilen mit Zeitstempel und kommt sauber mit einer auf null skalierten App zurecht. Dort prüfen Sie auch, ob ein Job oder Cronjob seine Arbeit erledigt hat. Achten Sie auf Exception, panic, Connection refused, OOMKilled oder eine fehlschlagende Readiness-Probe.
Verfügbarkeit und Betrieb prüfen
nyx_app_get mit view: uptime liefert die Verfügbarkeit pro Tag, bis zu 90 Tage zurück. nyx_ops_events zeigt, was die Plattform im Projekt erkannt hat und was sie daraufhin getan hat. Außerdem wird das Image jeder App automatisch auf CVEs geprüft, siehe Security-Scans.
Agentenläufe nachvollziehen
Laufen Agenten in Ihrem Projekt, listet nyx_runs ihre Läufe, die neuesten zuerst, jeweils mit Status, Dauer, Kosten und dem Ein-Wort-Urteil der Plattform (loop, budget80, baseline:2.1x). Setzen Sie run auf einen dieser Läufe, öffnet das Tool ihn Schritt für Schritt, mit seinen Warnungen und dem typischen Lauf des Projekts zum Vergleich. Beide Ansichten zeigen, wo ein Lauf schiefging. Sie speichern, womit jedes Tool aufgerufen wurde, nicht was es zurückgab. Den Fehler selbst lesen Sie deshalb mit nyx_app_logs.