Server-Agent

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.

Paket: @sixty-sh/node auf npm
läuft auf: Node 20 oder neuer, jeder Serverprozess, den du ausrollst.
Quellcode: sixty-sh/sixty-node

Installation

A server process you control: functions, HTTP routes and SQL.

Die Installation ist als Prompt für den Coding-Agenten geschrieben, den du ohnehin offen hast, nicht als Checkliste für dich. Das ist Absicht: sie benennt, was am Ende wahr sein muss, statt welche Dateien zu bearbeiten sind — denn wohin der Code gehört, hängt vom Framework ab, und ihn an die falsche Stelle zu setzen scheitert lautlos. Ein Agent kann dein Repository lesen und das herausfinden; ein Absatz auf einer Dokumentationsseite kann es nicht.

Denselben Text liefert install_sixty über den MCP-Server zurück, und den serviert der Collector unter /v1/setup?kind=node. Es gibt genau eine Kopie davon.

die vollständige Node-Installation

Install the @sixty-sh/node agent in this service so its functions, HTTP routes
and database queries report to sixty.

Before editing, inspect whether this service makes LLM or agent calls. If it
does, ask the user: "Do you want LLM monitoring?" Do not enable it without
their answer. Core HTTP, function and database monitoring is installed either
way. If they say yes, also follow the AI wiring in step 3; if no, leave every
AI client and call site untouched.

1. Install @sixty-sh/node as a dependency (not a devDependency — it runs in
   production; that is the entire point).

2. Call init() from "@sixty-sh/node" in the server entry point, BEFORE the
   application imports anything else. It patches the database client at call
   time, so a module that already imported "pg", "mysql2", "postgres" or
   "mongodb" above it is not instrumented. In an ESM entry, imports are
   hoisted above statements — so either put the init in its own module
   imported first, or use --import as in step 4.

   Then check which database client this project actually uses. pg, mysql2,
   postgres.js and mongodb are found and patched by init() with nothing
   further to do — including Mongoose, which drives the mongodb driver.

   PRISMA IS THE EXCEPTION and it is the one worth checking for, because
   getting it wrong is invisible. Prisma does not use pg — it runs queries
   through its own engine, so no patch reaches them — and its extension hook
   returns a NEW client instead of modifying the one it was given. So the
   application has to use the wrapped client:

      import { instrumentPrisma } from "@sixty-sh/node"
      export const prisma = instrumentPrisma(new PrismaClient())

   Replace the project's existing PrismaClient export with that one. Skip this
   and everything still reports except the queries, which is the failure that
   looks like success.

3. If LLM monitoring was requested, instrument only the SDKs the project
   actually uses: instrumentOpenAI(client), instrumentAnthropic(client),
   instrumentAISDK({ generateText, streamText }), or langChainCallbacks().
   For other providers and OpenAI-compatible services such as DeepSeek, wrap
   the call with generation({ provider, model }, () => call()). Never attach
   prompts, generated text, tool arguments or tool results; sixty records
   timing, provider/model, token usage and cost metadata only.

4. Turn on function-level tracing. Work out which of these this project can
   use; do not do both:

   a. It has a build step (Next, Vite, webpack, Rollup, esbuild). Wrap the
      config with withSixty() from "@sixty-sh/node/transform", or add the
      matching bundler plugin from that same module. The transform needs
      @babel/core and unplugin, which are peer dependencies — without them it
      emits nothing and says nothing, so add them if they are not there.

   b. It has no build step — it is started with a plain "node src/server.js"
      or "tsx src/server.ts". Add --import @sixty-sh/node/register to the
      start command, which both installs the transform and calls init() early
      enough that step 2 is already satisfied.

   NEXT.JS, SPECIFICALLY. Use (a) for the transform, and start init() from a
   flag rather than from instrumentation.js:

      // sixty.mjs, beside package.json
      import { init } from "@sixty-sh/node"
      init()

      # the deployed start command
      node --import ./sixty.mjs node_modules/next/dist/bin/next start

   instrumentation.js looks like the right hook and is compiled once per
   runtime. If the app has middleware there is an edge compilation of it, and
   the bundler pulls the agent's node:fs, node:http and node:crypto into a
   bundle that cannot read those schemes — the build fails. A NEXT_RUNTIME
   guard inside register() does not help: it runs at runtime, and the
   bundling already happened.

   Change the command the deployed process actually runs, not only the local
   dev script. A Dockerfile CMD, a Procfile, or a platform start command
   overrides package.json and is the one that matters.

5. Set these environment variables wherever the service is deployed:
      SIXTY_API_KEY  = a secret key starting sixty_sk_ — ask me for it. Do not
                       invent one, and do not commit it.
      SIXTY_SERVICE  = my-app
      SIXTY_ENDPOINT = https://ingest.sixty.sh

   The release identifier is picked up automatically on Vercel, Render,
   Railway, Fly, Heroku and GitHub Actions. If this deploys some other way,
   set SIXTY_RELEASE to the commit SHA — without one, every measurement lands
   in a single nameless bucket and no comparison can ever be made.

Constraints — correctness requirements, not style preferences:

- Do NOT change any application behaviour. This is instrumentation only: no
  refactors, no reordering of business logic, no "while I was in here" fixes.
- Do NOT apply the transform to client bundles. It is for server code; in a
  framework that builds both, restrict it to the server build.
- Do NOT add any analytics library, user id, session id, or cookie to what is
  reported. The agent is deliberately anonymous and must stay that way.
- If a hot function must not be traced, put // @sixty-ignore above it rather
  than turning the transform off for the whole file.

When you are done, tell me which files you changed and what the deployed start
command now is, so I can confirm data is arriving.

Er braucht einen geheimen Schlüssel — er beginnt mit sixty_sk_ und bleibt serverseitig. Erzeuge einen auf der Einstellungsseite, sobald du angemeldet bist.

Was er misst

Signal	Einheit	was es bedeutet
`rows`	rows per call	this query returns more rows than it used to
`fanout`	queries per call	this operation now issues more database calls per invocation — an N+1
`latency`	ms per call	this operation takes longer end to end than it used to
`self_latency`	ms per call	the time spent in this function itself got longer — its children did not
`payload`	bytes per call	the serialized result of this operation got bigger
`errors`	error rate	a larger fraction of calls are throwing
`runaway`	calls per minute	this operation is being called far more often than anything triggers it
`repeated_query`	times per request	the identical query runs several times within one request
`overfetch`	rows per call	far more rows are fetched than the code appears to use
`unbounded`	rows per call	this query has no upper bound on what it can return
`recursion`	levels deep	this operation calls itself, deeper than it should
`new_error`	occurrences	an error that did not occur in the previous release
`missing_tenancy`	—	This reads a table of per-person data without saying whose rows it wants. Unless your database is filtering it for you, everyone gets everyone else's.
`collapse`	—	This is handing back roughly half the data it used to, or less. If that was not deliberate, something is filtering out rows that somebody expects to see.
`vanished`	—	It was being used steadily until this release and has not been used once since. Usually the link, button, or redirect that led here stopped working.
`traffic_drop`	—	This is still being used, but a fraction as often, and its share of your traffic fell too — so it is not just a quiet period.
`round_trips`	round trips per read	one read now waits on the database many times instead of once
`plan`	—	the database chose a different plan for this query

Wo er sich einhängt

Jeder node:http-Server — Express, Fastify, Koa, Hono, Next.js-Route-Handler — gepatcht wird das Servermodul, nicht das Framework, also braucht nichts einen Adapter.
Deine eigenen Funktionen — Eine Build-Transformation umschließt exportierte async-Funktionen. Das ist es, was aus „der Endpunkt wurde langsam“ ein „diese Funktion hat angefangen, vierzehn Abfragen abzusetzen“ macht.

Datenbanken

pg — Zeilen, Statement-Form und Abfragepläne über EXPLAIN.
mysql2 — Zeilen und betroffene Zeilen, sowohl bei query als auch bei execute, gestreamte Ergebnisse eingeschlossen.
postgres.js — Tagged Templates setzen nie Werte ins Statement, es gibt also nichts zu schwärzen.
mongodb — Befehlsform als Identität, Dokumente als Zeilen, und Cursor-Roundtrips.
Prisma — Ausdrücklich: instrumentPrisma(new PrismaClient()).

Was nur dieser kann

Automatische Funktions-Spans — Kein Dekorator, kein include, keine zwei Zeilen am Anfang der Funktion. Jeder andere Server-Agent bittet dich, den messenswerten Code zu markieren.
Abfragepläne auf Postgres — Ein EXPLAIN mit generischem Plan, pro Statement gecacht, außerhalb des Spans des Aufrufers ausgeführt, damit es nie als dessen Arbeit gemessen wird.
Cursor-Roundtrips — MongoDB-Lesevorgänge, die in Raten ankommen — ein Signal, das kein anderer Treiber offenlegt.

Was er nicht kann

Gleichzeitige Spans werden über AsyncLocalStorage auseinandergehalten, was der Connection Pool standardmäßig aushebelt. Die Adapter binden Pool-Callbacks an den Kontext zurück, der sie erzeugt hat; ein Treiber, den wir nicht instrumentieren, schreibt seine Abfragen dem zu, der eine Verbindung freigegeben hat.
CPU und Warten lassen sich nicht trennen. process.cpuUsage() gilt für den ganzen Prozess, und viele asynchrone Kontexte verschränken sich auf einem Thread — kein Span kann ehrlich einen Anteil davon für sich beanspruchen.

Konfiguration

Jeder Agent liest dieselben vier Variablen, und DRIFT_* antwortet weiterhin überall dort, wo SIXTY_* es tut — das Produkt wurde umbenannt, und dieser Name ist nicht unserer, um ihn aus fremden Deployments zu entfernen.

`SIXTY_API_KEY`	Ohne sie bleibt der Agent untätig und sagt das auch. Er rät nie, versucht es nie erneut gegen einen unbekannten Endpunkt, und wirft nie.
`SIXTY_SERVICE`	Wie dieser Dienst heißen soll. Standardmäßig der Projektname, wo einer lesbar ist.
`SIXTY_RELEASE`	Die wichtigste. Wird auf Vercel, Render, Railway, Fly, Heroku und GitHub Actions automatisch abgeholt; überall sonst setze sie auf den Commit-SHA. Ohne sie landet jede Messung in einem einzigen namenlosen Eimer, und kein Vergleich ist je möglich.
`SIXTY_ENDPOINT`	Wohin gemeldet wird. Standardmäßig `http://localhost:4319`, was auf einem Laptop richtig ist und in dem Moment falsch, in dem die Anwendung jemand anderem ausgeliefert wird.

Der Rest — Flush-Intervall, Sample-Rate, was instrumentiert wird — steht im README des Pakets selbst, wo es wahr bleiben kann, während sich der Agent verändert.