documentation

Ce que sixty mesure, et comment l’installer

Un agent dans votre application mesure ce que fait chaque opération — lignes renvoyées, requêtes émises, temps passé, octets envoyés, erreurs levées — et envoie des résumés. Le collecteur compare chaque version à la précédente et vous dit quel déploiement a changé quoi.

Deux conséquences à connaître avant tout le reste. Il n’y a aucun seuil à configurer, parce que la comparaison se fait contre votre propre version précédente et non contre un chiffre que quelqu’un a deviné. Et rien ne peut être comparé tant qu’une deuxième version n’a pas remonté de données : le premier déploiement après une installation est donc silencieux par conception.

Choisissez votre langage

Chaque agent serveur mesure les mêmes signaux de base et écrit le même format. Ce qui diffère, c’est ce que permet l’environnement d’exécution : seul Python sait séparer le calcul de l’attente, seul Node instrumente vos fonctions sans qu’on le lui demande, seul PHP doit fonctionner sans thread de fond, et les plans de requête réclament Postgres.

Node

Le seul agent qui instrumente vos propres fonctions sans qu’on le lui demande : une transformation au build ouvre un span par fonction asynchrone exportée, si bien qu’une requête a un appelant à qui être attribuée.

npm install @sixty-sh/node

Python

Le seul agent capable de distinguer le calcul de l’attente. Tous les autres signalent que votre code a ralenti et s’arrêtent là — celui-ci dit laquelle des deux choses s’est produite, et elles appellent des correctifs opposés.

pip install sixty-sh

Go

L’installation est explicite — un middleware, une enveloppe de pilote, et deux lignes en tête des fonctions qui méritent d’être mesurées — parce que Go n’a pas d’étape de build où s’accrocher ni de moyen d’atteindre le contexte de l’appelant sans qu’on le lui passe.

go get github.com/sixty-sh/sixty-go

Ruby & Rails

La seule installation sans étape deux. Le railtie ajoute le middleware, s’abonne à sql.active_record et enveloppe les actions de contrôleur au démarrage — il n’y a aucun initializer à écrire.

gem 'sixty'

PHP

Le seul agent qui doit fonctionner sans thread de fond. Un worker PHP ne peut pas faire tourner de minuterie et tout ce qu’il a appris meurt avec la requête : les fenêtres sont donc mises en commun en mémoire partagée et fusionnées — sans perte, sinon les percentiles seraient de la fiction.

composer require sixty-sh/sixty

Devant le serveur

Un span serveur se termine quand la réponse est écrite, bien avant que quoi que ce soit soit à l’écran. Ceux-ci mesurent la moitié qui se passe après — et, sur un téléphone ou dans une application uniquement Supabase, la moitié qui n’a aucun span serveur du tout.

Browser

Ce que le serveur ne peut pas voir : combien de temps la page a réellement pris pour une vraie personne, quels clics n’ont rien fait, et quel composant s’est re-rendu quatre cents fois.

npm install @sixty-sh/browser

React Native

Une application n’a pas de span côté serveur auquel se comparer : un appel refusé ou une réponse vide n’est donc visible que depuis l’appareil. C’est l’agent qui les rend visibles.

npm install @sixty-sh/react-native

Supabase

Le seul agent qui sait ce qu’*est* le point d’entrée plutôt que ce qu’il a coûté — il peut donc distinguer une requête lente d’une règle qui en a refusé une.

npm install @sixty-sh/supabase

Le reste

OpenTelemetry — envoyez les traces et métriques OTLP depuis votre collector tout en gardant Grafana, Prometheus, Elastic, Vercel, AWS ou un autre backend.
Ce que suit chaque agent — un tableau, 8 agents, chaque signal. La page à lire si vous hésitez entre deux d’entre eux ou si vous vous demandez pourquoi un constat n’apparaît jamais.
Tous les signaux — ce que veut dire chaque type de constat, dans quelle unité, et quel genre de changement de code le provoque.
Comment ça marche — l’ancrage aux déploiements, les sketches de quantiles, comment une requête est attribuée à la fonction qui l’a émise, et ce que l’agent coûte à l’application.
Serveur MCP — comment votre éditeur lit les constats, en prend un, le corrige et consigne ce qu’il a fait.
GitHub — reliez un dépôt et un constat nomme la pull request de ce déploiement qui a touché le fichier où il se produit. En lecture seule, et aucun contenu de fichier n’est stocké.

Deux règles que tient chaque agent

Il ne peut pas casser votre application. Chaque chemin de mesure est enveloppé pour qu’une défaillance à l’intérieur de l’agent ne puisse pas remonter comme une erreur applicative. Quand le collecteur est injoignable, l’agent continue de mesurer dans un tampon borné et jette la fenêtre la plus ancienne plutôt que de grossir ; rien ne bloque, rien ne réessaie indéfiniment, et l’application n’en sait rien.

Il n’apprend jamais qui sont vos utilisateurs. Pas d’identifiant utilisateur, pas d’identifiant de session, pas de cookie, pas d’adresse IP, et aucune valeur issue d’une requête — les requêtes sont normalisées à leur forme avant que quoi que ce soit ne quitte le processus. Les visiteurs uniques sont comptés à partir d’un code qui tourne chaque jour, dérivé par votre propre serveur et que nous ne pouvons pas inverser, puis replié dans un total et jeté plutôt que stocké. C’est une propriété du code et non un réglage, ce qui en fait aussi une question à laquelle ce produit ne peut répondre pour personne, nous compris.