Einen zweiten Schritt gibt es nicht.

Was es misst

Jede Controller-Action

Benannt nach controller#action, der Verlauf liest sich also so wie deine Routendatei. Das Railtie umschließt sie beim Start — es gibt nichts einzubinden und nichts, woran man beim nächsten Controller denken müsste.

Jede Abfrage, die ActiveRecord absetzt

Abonniert über sql.active_record, den Bus, auf dem Rails ohnehin veröffentlicht. Zeilen, das normalisierte Statement, die Antwortgröße, und welche Action sie abgesetzt hat.

Drei Datenbanken, nach ihren eigenen Regeln

pg mit Abfrageplänen über EXPLAIN; mysql2 und trilogy nach MySQLs Quoting-Regeln gelesen statt nach denen von Postgres, weil eine Zeichenkette in doppelten Anführungszeichen im einen ein Literal und im anderen ein Bezeichner ist; und mongo, was Mongoid benutzt, mit der Befehlsform als Identität.

Was die Datenbank getan hat, um zu antworten

Postgres wird nach dem Plan jedes Statements gefragt — ein EXPLAIN mit generischem Plan, pro Statement gecacht, außerhalb des Spans des Aufrufers abgesetzt, damit es nie als dessen Arbeit gemessen wird, und ohne je einen Parameter zu binden, es ist also kein Wert von dir beteiligt.

Deine eigenen Klassen, wenn du willst

include Sixty::Instrumented macht jede öffentliche Instanzmethode zu einer Operation und lässt private Methoden und Accessoren in Ruhe. Oder Sixty.instrument(Stripe::Charge, :create) für eine Methode in der Klasse eines anderen.

Was es findet

Jedes davon wird gegen das Release davor verglichen, der Befund benennt also die Änderung und nicht den Tag.

Was in deinem Verlauf landet

Kein Dashboard zum Lesen. Eine Karte pro Befund, mit den Zahlen, dem Release, das sie verändert hat, und den Belegen, die dein Coding-Agent braucht, um die Lösung zu schreiben.

Wie es installiert wird

Auf Rails ist das die ganze Installation: das Gem und zwei Umgebungsvariablen. Das Railtie fügt die Middleware hinzu, abonniert den Abfrage-Bus und umschließt Controller-Actions beim Start, es gibt also keinen Initializer zu schreiben und nichts aufzurufen.

claude mcp add sixty \
  -e SIXTY_API_KEY=sixty_sk_… \
  -e SIXTY_ENDPOINT=https://ingest.sixty.sh \
  -- npx -y @sixty-sh/mcp

# or by hand:
gem 'sixty'                      # Gemfile

export SIXTY_API_KEY=sixty_sk_…
export SIXTY_SERVICE=checkout-api

# On Rails, that is the install. Outside it:
require 'sixty'
Sixty.init
use Sixty::Instrument::Rack      # config.ru — Sinatra, Hanami, a bare app

# Your own classes, if you want them measured:
class OrdersQuery
  include Sixty::Instrumented
end

Der Release-Bezeichner wird von allein von Vercel, Render, Railway, Fly, Heroku oder GitHub Actions abgeholt, und SIXTY_RELEASE setzt ihn überall sonst. Der erste Vergleich kommt nach deinem nächsten Deployment, weil es nichts gibt, womit man ein Release vergleichen könnte.

Was es nicht tut

• Abfragepläne gibt es nur für Postgres. MySQL hat kein EXPLAIN mit generischem Plan und MongoDB hat kein Statement zum Erklären — und eines von beiden zu erklären hieße, die Abfragewerte von jemandem aufzubewahren, um sie in einem von uns zusammengesetzten Befehl an dessen eigene Datenbank zurückzuschicken, und das wird dieser Agent nicht tun.
• CPU und Warten werden nicht getrennt. Das braucht eine Uhr pro Thread und einen Span, der seinen Thread besitzt, und das hat nur der Python-Agent.
• Unter Puma mit Workern oder unter Sidekiq meldet jeder Prozess eigenständig und der Collector führt sie zusammen. Das ist korrekt, und man sollte es wissen, wenn man eine Zahl pro Prozess liest.
• include Sixty::Instrumented misst öffentliche Instanzmethoden. Eine private Methode, die die eigentliche Arbeit macht, ist unsichtbar, bis du sie auf anderem Weg zu einer Operation machst — der Preis dafür, nicht zu raten, was messenswert ist.

Falls du wegen einer dieser Sachen hier bist