Observability
Du solltest kein zusätzliches Tool installieren müssen, um zu sehen, was dein Projekt gerade tut.
Build-Ausgabe, Runtime-Logs, Ressourcenverbrauch pro Container und aufgeschlüsselte Kosten. Nichts davon ist ein Add-on, das du installierst, ein Sidecar, den du konfigurierst, oder ein Tarif, auf den du upgradest. Es ist aktiv, weil dein Projekt läuft.
Inklusive. Es gibt keinen Observability-Tarif.
An einem Ort
Im Projekt läuft alles zusammen.
Eine Komponente erzählt dir etwas über sich selbst. Ein Projekt erzählt dir, was die Anwendung tut: jede Komponente, die Datenbanken und Buckets, die sie nutzen, die Routen davor, und eine Zahl dafür, was das Ganze diesen Monat kostet. Diese Übersicht stellst du dir nicht selbst zusammen. Es ist die Seite, auf der du ohnehin schon warst.
Eingebaut
Jeder Teil berichtet über sich selbst.
Nichts davon ist ein eigenständiges Produkt. Diese Ansichten gehören zu jedem Projekt, das du deployst.
Build-Ausgabe
Das Protokoll eines Deploys, während er läuft, gestreamt statt abgefragt, und zusammen mit dem Deployment aufbewahrt, damit ein fehlgeschlagener Build auch danach noch lesbar ist.
Runtime-Logs
Was die Komponente gerade ausgibt, filterbar, ohne eine Shell zu öffnen oder einen Agenten anzuhängen.
Ressourcenverbrauch
CPU, Arbeitsspeicher und Speicherplatz pro Container, während er läuft, auf demselben Bildschirm wie die Konsole und die An-/Aus-Schalter.
Kosten, aufgeschlüsselt
Monat bis heute und eine Prognose, aufgeteilt nach Basis-Container, zusätzlichen Replicas, Bandbreite und eigenen Domains, pro Komponente und für das Projekt als Ganzes.
Aktivität
Wer was wann geändert hat. Deploys, Variablen, Mitglieder, Domains. Der Eintrag existiert unabhängig davon, ob die Änderung aus der Konsole, der API oder einem Assistenten kam.
Die Systemkarte
Was mit was verbunden ist, gezeichnet aus dem Projekt, wie es tatsächlich ist, statt aus einem Diagramm, das irgendwann jemand gezeichnet und dann nicht mehr aktualisiert hat.
Mitgeteilt, nicht entdeckt
Niemand muss einen Bildschirm im Blick behalten.
Observability, die nur funktioniert, solange du hinschaust, bringt wenig. Die Ereignisse, die zählen, erreichen dich dort, wo du bist.
- Ein Deploy war erfolgreich.
- Ein Deploy ist fehlgeschlagen.
- Eine Datenbank wurde fertig bereitgestellt oder entfernt.
- Eine Komponente wurde in statisches Hosting umgewandelt.
- Dein Guthaben ist kritisch niedrig.
Sie kommen in der Konsole und per E-Mail an, und dieselben Ereignisse sind es, auf die der Spend Cap reagiert.
Auf der Roadmap
Besucheranalyse kommt, ist aber noch nicht da.
Seitenaufrufe, Referrer und woher deine Nutzer kommen, werden gerade gebaut, und nichts davon existiert heute. Wir schreiben das lieber hier hin, als dich es nach deinem Deploy herausfinden zu lassen.
Der Edge zählt Requests pro App, um zu entscheiden, wann skaliert werden muss, und dieser Zähler wird fünf Minuten aufbewahrt und dann verworfen. Das ist keine Analytics-Pipeline unter anderem Namen.
Wir nennen kein Datum, bevor es fertig ist.
Deploy etwas und sieh es laufen.
Die Logs, die Kostenaufschlüsselung und die Systemkarte sind schon da.