Il n’y a pas d’étape deux.

Ce qu’il mesure

Chaque action de contrôleur

Nommée par contrôleur#action, donc le fil se lit comme votre fichier de routes. Le railtie les enveloppe au démarrage — il n’y a rien à inclure et rien à se rappeler au prochain contrôleur.

Chaque requête émise par ActiveRecord

Abonné via sql.active_record, le bus sur lequel Rails publie déjà. Les lignes, la requête normalisée, la taille de la réponse, et quelle action l’a émise.

Trois bases, chacune selon ses règles

pg avec les plans de requête via EXPLAIN ; mysql2 et trilogy lus selon les règles de citation de MySQL plutôt que celles de Postgres, parce qu’une chaîne entre guillemets doubles est un littéral dans l’une et un identifiant dans l’autre ; et mongo, ce qu’utilise Mongoid, avec la forme de la commande comme identité.

Ce que la base a fait pour répondre

On demande à Postgres le plan de chaque requête — un EXPLAIN à plan générique, mis en cache par requête, émis en dehors du span de l’appelant pour qu’il ne soit jamais mesuré comme son travail, et sans jamais lier un paramètre, donc aucune de vos valeurs n’est impliquée.

Vos propres classes, quand vous le voulez

include Sixty::Instrumented transforme chaque méthode d’instance publique en opération et laisse les méthodes privées et les accesseurs tranquilles. Ou Sixty.instrument(Stripe::Charge, :create) pour une méthode sur la classe de quelqu’un d’autre.

Ce qu’il trouve

Chacune de ces choses est comparée à la version précédente : le constat nomme donc le changement plutôt que le jour.

Ce qui arrive dans votre fil

Pas un tableau de bord à lire. Une carte par constat, avec les chiffres, la version qui les a changés, et les preuves dont votre agent de code a besoin pour écrire le correctif.

Comment ça s’installe

Sur Rails, c’est toute l’installation : la gem, et deux variables d’environnement. Le railtie ajoute le middleware, s’abonne au bus de requêtes et enveloppe les actions de contrôleur au démarrage, donc il n’y a pas d’initializer à écrire et rien à appeler.

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

L’identifiant de version est récupéré tout seul chez Vercel, Render, Railway, Fly, Heroku ou GitHub Actions, et SIXTY_RELEASE le fixe partout ailleurs. La première comparaison arrive après votre prochain déploiement, parce qu’il n’y a rien à quoi comparer une version isolée.

Ce qu’il ne fait pas

• Les plans de requête ne concernent que Postgres. MySQL n’a pas d’EXPLAIN à plan générique et MongoDB n’a pas de requête à expliquer — et expliquer l’une ou l’autre voudrait dire conserver les valeurs de requête de quelqu’un pour les renvoyer à sa propre base dans une commande que nous aurions composée, ce que cet agent ne fera pas.
• Le CPU et l’attente ne sont pas séparés. Cela demande une horloge par thread et un span qui possède son thread, ce que seul l’agent Python a.
• Sous Puma avec des workers, ou Sidekiq, chaque processus remonte indépendamment et le collecteur les fusionne. C’est correct, et bon à savoir quand vous lisez un chiffre par processus.
• include Sixty::Instrumented mesure les méthodes d’instance publiques. Une méthode privée qui fait le vrai travail est invisible tant que vous n’en faites pas une opération autrement, ce qui est le prix à payer pour ne pas deviner ce qui mérite d’être mesuré.

Si vous êtes ici pour l’une de ces raisons