Dokumentation
Was sixty misst, und wie man es installiert
Ein Agent in deiner Anwendung misst, was jede Operation tut — zurückgegebene Zeilen, abgesetzte Abfragen, verbrauchte Zeit, gesendete Bytes, geworfene Fehler — und schickt Zusammenfassungen. Der Collector vergleicht jedes Release mit dem davor und sagt dir, welches Deployment was verändert hat.
Zwei Konsequenzen, die man vor allem anderen kennen sollte. Es gibt keine Schwellwerte zu konfigurieren, weil der Vergleich gegen dein eigenes vorheriges Release läuft und nicht gegen eine Zahl, die jemand geraten hat. Und es kann nichts verglichen werden, bevor ein zweites Release gemeldet hat — das erste Deployment nach einer Installation ist also mit Absicht still.
Wähle deine Sprache
Jeder Server-Agent misst dieselben Kernsignale und schreibt dasselbe Übertragungsformat. Was sich unterscheidet, ist das, was die Laufzeitumgebung zulässt: nur Python kann Rechnen von Warten trennen, nur Node instrumentiert deine Funktionen ungefragt, nur PHP muss ohne Hintergrund-Thread auskommen, und Abfragepläne brauchen Postgres.
Node
Der einzige Agent, der deine eigenen Funktionen ungefragt instrumentiert: eine Build-Transformation öffnet einen Span pro exportierter async-Funktion, damit eine Abfrage einen Aufrufer hat, dem sie gutgeschrieben werden kann.
npm install @sixty-sh/nodePython
Der einzige Agent, der Rechnen von Warten unterscheiden kann. Jeder andere meldet, dass dein Code langsamer geworden ist, und hört da auf — dieser sagt, welches von beidem passiert ist, und die beiden brauchen entgegengesetzte Lösungen.
pip install sixty-shGo
Die Installation ist ausdrücklich — eine Middleware, ein Treiber-Wrapper und zwei Zeilen am Anfang der messenswerten Funktionen — weil Go keinen Build-Schritt zum Einhaken hat und keine Möglichkeit, den Kontext des Aufrufers zu erreichen, ohne ihn übergeben zu bekommen.
go get github.com/sixty-sh/sixty-goRuby & Rails
Die einzige Installation ohne zweiten Schritt. Das Railtie fügt die Middleware hinzu, abonniert sql.active_record und umschließt Controller-Actions beim Start — es gibt keinen Initializer zu schreiben.
gem 'sixty'PHP
Der einzige Agent, der ohne Hintergrund-Thread auskommen muss. Ein PHP-Worker kann keinen Timer laufen lassen, und alles, was er gelernt hat, stirbt mit der Anfrage — also werden Fenster im Shared Memory gepoolt und zusammengeführt, verlustfrei, sonst wären die Perzentile Fiktion.
composer require sixty-sh/sixtyVor dem Server
Ein Server-Span endet, wenn die Antwort geschrieben ist, und das ist lange bevor irgendetwas auf dem Bildschirm steht. Diese messen die Hälfte, die danach passiert — und auf einem Telefon oder in einer reinen Supabase-Anwendung die Hälfte, für die es überhaupt keinen Server-Span gibt.
Browser
Was der Server nicht sehen kann: wie lange die Seite für einen echten Menschen tatsächlich gedauert hat, welche Klicks nichts bewirkt haben, und welche Komponente sich vierhundertmal neu gerendert hat.
npm install @sixty-sh/browserReact Native
Eine App hat keinen serverseitigen Span, mit dem sie sich vergleichen könnte — ein abgewiesener Aufruf oder eine leere Antwort ist also nur vom Gerät aus sichtbar. Das ist der Agent, der sie sichtbar macht.
npm install @sixty-sh/react-nativeSupabase
Der einzige Agent, der weiß, was der Endpunkt *ist*, statt was er gekostet hat — er kann also eine langsame Abfrage von einer Regel unterscheiden, die eine abgelehnt hat.
npm install @sixty-sh/supabaseDer Rest
- OpenTelemetry — sende OTLP-Traces und -Metriken aus deinem Collector und behalte Grafana, Prometheus, Elastic, Vercel, AWS oder ein anderes Backend.
- Was jeder Agent erfasst — eine Tabelle, 8 Agenten, jedes Signal. Die Seite zum Lesen, wenn du zwischen zweien wählst oder dich fragst, warum ein Befund nie auftaucht.
- Alle Signale — was jede Art von Befund bedeutet, in welcher Einheit, und welche Art von Code-Änderung sie verursacht.
- Wie es funktioniert — Verankerung an Deployments, Quantil-Sketches, wie eine Abfrage der Funktion zugeordnet wird, die sie abgesetzt hat, und was der Agent die Anwendung kostet.
- MCP-Server — wie dein Editor Befunde liest, einen übernimmt, ihn behebt und festhält, was er getan hat.
- GitHub — verbinde ein Repository, und ein Befund benennt den Pull Request in diesem Deployment, der die Datei angefasst hat, in der er steckt. Nur lesend, und Dateiinhalte werden nicht gespeichert.
Zwei Regeln, an die sich jeder Agent hält
Er kann deine Anwendung nicht kaputtmachen. Jeder Messpfad ist so umschlossen, dass ein Fehler innerhalb des Agenten nicht als Anwendungsfehler an die Oberfläche kommen kann. Ist der Collector nicht erreichbar, misst der Agent weiter in einen begrenzten Puffer und verwirft das älteste Fenster, statt zu wachsen; nichts blockiert, nichts wiederholt sich ewig, und die Anwendung erfährt nichts davon.
Er erfährt nie, wer deine Nutzer sind. Keine Nutzer-ID, keine Session-ID, kein Cookie, keine IP-Adresse und kein Wert aus irgendeiner Abfrage — Statements werden auf ihre Form normalisiert, bevor irgendetwas den Prozess verlässt. Eindeutige Besucher werden über einen täglich wechselnden Code gezählt, den dein eigener Server ableitet und den wir nicht umkehren können; er wird in eine Zählung gefaltet und verworfen statt gespeichert. Das ist eine Eigenschaft des Codes und keine Einstellung — und damit auch eine Frage, die dieses Produkt niemandem beantworten kann, uns eingeschlossen.