sixty

文档

sixty 测量什么,以及怎么安装

你应用里的 agent 会测量每个操作做了什么 —— 返回多少行、发出多少查询、花了多少时间、发出多少字节、抛了多少错 —— 然后把汇总发出去。收集端把每个版本和上一个作比较,并告诉你是哪次部署改变了什么。

有两个后果值得先知道。这里没有阈值要配置,因为比较的对象是你自己上一个版本,而不是某个人拍脑袋定的数字。而且在第二个版本上报之前什么都比不了,所以安装之后的第一次部署按设计就是安静的。

选择你的语言

每个服务端 agent 测量同样的核心信号,写同样的传输格式。不同的是运行时允许什么:只有 Python 能把计算和等待分开,只有 Node 不用你开口就给你的函数埋点,只有 PHP 必须在没有后台线程的情况下工作,而查询计划需要 Postgres。

在服务器前面

服务端的 span 在响应写完时就结束了,而那远远早于屏幕上出现任何东西。这些测量的是之后发生的那一半 —— 而在手机上,或者在只有 Supabase 的应用里,是那压根没有服务端 span 的一半。

其余部分

  • OpenTelemetry — 从现有 Collector 发送 OTLP 链路和指标,同时保留 Grafana、Prometheus、Elastic、Vercel、AWS 或其他后端。
  • 每个 agent 分别追踪什么 —— 一张表,8 个 agent,所有信号。如果你在两个之间做选择,或者想知道某条发现为什么一直不出现,就该读这一页。
  • 所有信号 —— 每一类发现是什么意思、单位是什么,以及什么样的代码改动会造成它。
  • 它怎么工作 —— 以部署为锚、分位数 sketch、一条查询是怎么被归到发出它的那个函数上的,以及 agent 会给应用带来多少开销。
  • MCP 服务器 —— 你的编辑器怎么读取发现、认领一条、修好它,并记录自己做了什么。
  • GitHub —— 接上一个仓库,一条发现就会点名那次部署里动过它所在文件的那个 pull request。只读,而且不保存任何文件内容。

每个 agent 都遵守的两条规矩

它不能把你的应用弄坏。 每一条测量路径都被包了起来,所以 agent 内部的失败不会以应用错误的形式冒出来。当收集端联系不上时,agent 会继续往一个有上限的缓冲里测量,并丢掉最旧的窗口而不是一直变大;没有任何东西会阻塞,没有任何东西会永远重试,而应用对此毫不知情。

它永远不会知道你的用户是谁。 没有用户 id、没有会话 id、没有 cookie、没有 IP 地址,也没有任何来自查询的值 —— 语句在离开进程之前就已经被规范化成它的形状。独立访客是从一个每天轮换的编码里数出来的,那个编码由你自己的服务器推导、我们无法反推,而且它被折进一个计数之后就被丢掉,不做存储。这是代码的性质而不是一个开关,也就是说,这同样是一个这个产品对任何人都答不出来的问题,包括我们自己。

sixty 文档 —— 每个 agent 测量什么,以及怎么安装