agente de servidor

Node

El único agente que instrumenta tus propias funciones sin que se lo pidas: una transformación de compilación abre un span por cada función asíncrona exportada, así que una consulta tiene a quién acreditarse.

paquete: @sixty-sh/node en npm
funciona sobre: Node 20 o posterior, cualquier proceso de servidor que despliegues.
código: sixty-sh/sixty-node

Cómo instalarlo

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

La instalación está escrita como un prompt para el agente de código que ya tienes abierto, no como una lista de tareas para ti. Es deliberado: nombra lo que tiene que ser cierto cuando la instalación esté terminada en vez de qué archivos editar, porque dónde va el código depende del framework y ponerlo en el sitio equivocado falla en silencio. Un agente puede leer tu repositorio y deducirlo; un párrafo en una página de documentación no.

El mismo texto es lo que devuelve install_sixty a través de el servidor MCP y lo que el colector sirve en /v1/setup?kind=node. Hay una sola copia.

la instalación de Node, completa

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.

Necesita una clave secreta — empieza por sixty_sk_ y se queda en el servidor. Genera una en la página de Ajustes cuando hayas iniciado sesión.

Qué mide

señal	unidad	qué significa
`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

Dónde se engancha

Cualquier servidor node:http — Express, Fastify, Koa, Hono, los route handlers de Next.js — se parchea el módulo del servidor, no el framework, así que nada necesita un adaptador.
Tus propias funciones — Una transformación de compilación envuelve las funciones asíncronas exportadas. Esto es lo que convierte «el endpoint se volvió lento» en «esta función empezó a emitir catorce consultas».

Bases de datos

pg — Filas, forma de la sentencia y planes de consulta vía EXPLAIN.
mysql2 — Filas y filas afectadas, tanto en query como en execute, incluidos los resultados en streaming.
postgres.js — Las plantillas etiquetadas nunca ponen valores en la sentencia, así que no hay nada que redactar.
mongodb — La forma del comando como identidad, los documentos como filas, y las idas y vueltas del cursor.
Prisma — Explícito: instrumentPrisma(new PrismaClient()).

Qué hace solo este

Spans de función automáticos — Sin decorador, sin include, sin dos líneas al principio de la función. Todos los demás agentes de servidor te piden que marques el código que merece medirse.
Planes de consulta en Postgres — Un EXPLAIN de plan genérico, cacheado por sentencia, ejecutado fuera del span de quien llama para que nunca se mida como su trabajo.
Idas y vueltas del cursor — Lecturas de MongoDB que llegan a plazos — una señal que ningún otro driver expone.

Qué no puede hacer

Los spans concurrentes se distinguen con AsyncLocalStorage, que el pool de conexiones derrota por defecto. Los adaptadores enlazan los callbacks del pool de vuelta al contexto que los creó; un driver que no instrumentemos atribuirá sus consultas a quien haya soltado una conexión.
La CPU y la espera no se pueden separar. process.cpuUsage() es de todo el proceso y muchos contextos asíncronos se entrelazan en un hilo, así que ningún span puede reclamar honestamente una parte.

Configuración

Todos los agentes leen las mismas cuatro variables, y DRIFT_* sigue respondiendo allí donde lo hace SIXTY_* — el producto se renombró y ese nombre no es nuestro para retirarlo de los despliegues de otra gente.

`SIXTY_API_KEY`	Sin ella el agente se queda inerte y lo dice. Nunca adivina, nunca reintenta contra un endpoint desconocido, y nunca lanza una excepción.
`SIXTY_SERVICE`	Cómo llamar a este servicio. Por defecto, el nombre del proyecto donde sea legible.
`SIXTY_RELEASE`	La que más importa. Se recoge automáticamente en Vercel, Render, Railway, Fly, Heroku y GitHub Actions; en cualquier otro sitio, ponla al SHA del commit. Sin ella cada medición cae en un único cubo sin nombre y no se puede hacer ninguna comparación.
`SIXTY_ENDPOINT`	Dónde reportar. Por defecto `http://localhost:4319`, que es correcto en un portátil y erróneo en cuanto la aplicación se sirve a alguien más.

El resto — intervalo de envío, tasa de muestreo, qué instrumentar — está en el propio README del paquete, que es donde puede seguir siendo cierto según cambia el agente.