为什么工程优先团队选择 SigNoz 做可观测性
- 工程优先团队打造的产品中，延迟、可靠性和基础设施本身就是客户体验的一部分。
- 他们需要解答一些在埋点采集时没有预料到的问题。
- SigNoz 让团队可以聚合任意属性、查询嵌套 JSON、直接使用 OpenTelemetry 原始数据、通过 API 自动化工作流，并围绕客户影响设置告警。
工程优先团队不把可观测性当作事故发生后才有人看的仪表盘，而是融入构建、发布和运维产品的整个过程。
对这类团队来说，客户买的就是技术性能。浏览器会话卡顿、sandbox 不稳定、模型响应延迟或工具调用失败，都不只是内部实现细节，而是产品故障。
这改变了团队对可观测性平台的要求。
什么样的团队算工程优先？
工程优先团队打造的产品，其基础设施、可靠性、延迟或系统性能本身就是核心竞争优势。
Kernel 提供面向 Web 自动化的浏览器基础设施，Blaxel 提供运行自主工作负载的基础设施，Black Forest Labs 打造前沿视觉模型，Sail Research 专注技术复杂的 AI 系统。
这些公司做的产品各不相同，但工程团队面临的可观测性问题很相似：
- 系统包含多个相互作用的层级。
- 遥测数据复杂且变化很快。
- 他们关注 tenant、session、model、region、sandbox、operation 等维度。
- 经常需要排查事先没预料到的问题。
- 希望基础设施工具开放、可编程，并能与现有工程工作流兼容。
基础仪表盘有用，但对这种运营模式来说远远不够。
回答你没规划过的问题
大多数可观测性方案都从一组已知指标开始。请求数、错误率、CPU、内存和延迟可以覆盖常见场景。
但棘手的问题往往随后就来了：
- 某个地区和浏览器版本组合的 p95 浏览器启动耗时是多少？
- 每次成功请求中各模型消耗了多少 token？
- 某次部署之后，哪些 tenant 遇到了 sandbox 初始化缓慢？
- 失败任务总共消耗了多少 CPU 时间？
所需数据往往已经存在于 Span 或日志的属性中。问题在于，没有人为那个具体的问题创建过对应的 Metric。
SigNoz 查询构建器支持对通用遥测字段执行求和、平均值、最小值、最大值、百分位数和速率等聚合操作。结果还可以按其他属性进行分组。这意味着无需定义新 Metric 或再次部署，就能将现有的 Span 和日志转化为分析数据源。
例如，浏览器基础设施公司可以计算那些以错误结束的会话中各客户的平均页面加载时间；沙箱提供商可以按租户汇总 CPU 秒数以了解资源使用量；模型公司则可以比较不同模型版本和区域间的 p95 生成耗时。
这一功能在处理高基数维度时尤为有用。团队可以直接按客户或会话等维度进行调查，而无需预先为每个可能的值创建 Metric 序列。
更多详情参阅 SigNoz 查询构建器文档。
将 JSON 查询视为数据，而非无结构数据块
工程优先的产品会产生大量结构化日志。Agent 步骤、浏览器事件、模型响应、Webhook 载荷以及沙箱生命周期事件，通常都以嵌套 JSON 的形式传入。
传统的日志管道要求团队在数据摄入前决定哪些字段重要。这意味着有人需要解析载荷、提取特定键值、在 Schema 变更时更新管道，并等待新数据到达。而用于解释事故原因的关键字段，往往正是之前未被提取的那个。
SigNoz 可以将 JSON 日志体作为原生 JSON 存储，并在查询界面中暴露嵌套字段。团队无需先将每个值展平为独立属性，即可对这些字段进行过滤、分组和聚合。
假设日志正文包含一个下游请求数组，工程师可以筛选出状态码为 500 或更高的日志。SigNoz 会检查数组内部的具体元素，而不是将整个正文视为不透明的字符串。你也可以在日志详情视图中通过可视化方式进行筛选
这意味着更少的管道维护工作量，以及对历史数据更好的访问能力。当载荷中出现新字段时，团队无需先提交插桩工单，即可直接开始调查。
有关筛选和搜索工作流，请参见Logs Explorer 文档。
OpenTelemetry-native 不应仅意味着接受 OTLP
许多可观测性产品都可以摄入 OpenTelemetry 数据。但工程优先的团队还应关注摄入后发生了什么。
后端能否保留 OpenTelemetry 属性名称？它是否理解 SDK 产生的指标时序性（metric temporality）？在查询日志、指标和追踪时，能否使用相同的 resource 和 span 上下文？
SigNoz 支持 OpenTelemetry 风格的点分属性，例如 service.name、deployment.environment.name 和 http.route。团队在查询时无需将这些名称转换为其他厂商特有的命名约定（例如某些厂商将点号转换为下划线）。
指标时序性是另一个例子。OpenTelemetry 计数器可以是累积型（cumulative）或增量型（delta）：
- 累积型数据点报告自进程启动以来的总数。
- 增量型数据点报告自上次采集间隔以来发生的变化。
对于高基数和短生命周期的工作负载，增量时序性非常有用，因为产生进程无需在整個生命周期内保留每个序列。将增量计数器转换为仅累积模型是有状态的，并会将额外的工作转移到遥测管道中。
SigNoz 支持 delta temporality，团队可以直接上报埋点产生的指标格式，而不必把所有数据强行转成仅支持 cumulative 的约定。
OpenTelemetry 指标数据模型详细说明了这两种形式的语义和取舍。
可观测性应该是可编程的
工程优先的团队会自动化基础设施，他们同样期望可观测性也能自动化。
SigNoz 提供了 OpenAPI 参考和用于查询遥测数据的 API。以 Metrics API 为例，它支持范围查询、时间与空间聚合、属性过滤、分组以及公式计算。
这可以支撑以下工作流：
- 从内部工具中查询遥测数据。
- 根据 API 契约生成带类型的客户端。
- 在服务接入流程中自动创建可观测性资源。
- 围绕产品特有的信号构建可复用的排查流程。
- 把生产环境上下文融入现有的工程工作流。
对于可视化构建器无法满足的查询，SigNoz 还支持在仪表盘中直接编写 ClickHouse SQL。团队可以从常见问题顺畅地过渡到高度定制化的分析。
告警应该贴合系统的实际运维方式
一条告警只有同时满足三点才有价值：送达正确的团队、反映真实的用户影响、避免不必要的噪音。
SigNoz 支持基于指标、日志、trace、异常和错误的告警。团队可以针对 p99 span 延迟、日志属性条件、偏离历史基线的异常变化、或遥测数据停止上报等情况设置告警。
告警路由策略支持基于服务、环境、严重程度、Kubernetes 标签和自定义属性进行配置。在计划维护窗口期间，已知停机时段的通知会被抑制，但告警评估仍会持续运行。告警规则还可以通过 Terraform 进行管理，实现可重复且受版本控制的配置配置。我们近期还发布了 SigNoz Operator，以便在 Kubernetes 中更便捷地通过编程方式管理告警。
请参阅 SigNoz 告警文档。
Kernel：面向浏览器基础设施的可观测性
Kernel 在控制平面 API、microVM、代理提供商、裸机服务和浏览器会话中运行浏览器基础设施。故障可能源自这些层中的任意一层，或来自正在访问的外部网站。
正如 Kernel 创始工程师 Hiro Tamada 所言：
“我们的客户非常关注可靠性和延迟，因此我们也同样重视这两点。”
Kernel 使用 SigNoz 进行客户问题分诊、事件响应、上线后监控、仪表盘配置、告警设置及延迟优化。
在一次排查中，团队检查了浏览器获取请求的链路追踪（traces），发现 Temporal 工作流的输入输出位于热点路径上。在添加 Redis 缓存并将 Temporal 从该路径移除后，Kernel 在数周内将浏览器获取延迟从 140 ms 降低至 30 ms。
另一起事件中，Kernel 因请求被路由至失效 Pod 而遭遇 17 分钟 API 中断。SigNoz 中的遥测数据帮助团队确认 API 进程仍然存活，从而将调查方向指向路由层。
我试图说明的重点并非每个工程优先型团队都拥有与 Kernel 相同的架构，而是当故障面超过标准 API 和数据库应用的范围时，可观测性必须达到同等标准。
SigNoz 是否适合你的工程团队？
在以下场景中，SigNoz 的技术深度最具价值：
- 可靠性或延迟是客户购买决策的一部分。
- 你的系统跨越多个服务和基础设施层。
- 你的遥测数据包含丰富、自定义或高基数属性。
- 工程师经常需要进行自定义调查。
- 你希望使用 OpenTelemetry，但不希望依赖专有仪表代码层。
- 需要在可视化界面之外，同时支持 API、SQL 和基础设施即代码（IaC）工作流。
并非每个团队都需要本文提到的所有功能。一个简单的应用，只做基础的可用性和错误率监控，可能永远用不到嵌套 JSON 聚合或 delta 时间模型。但一旦可观测性深度融入工程开发流程，这些细节就不再是边缘场景。
随着越来越多的团队在 AI 优先的时代转向工程驱动，我们认为这些能力将变得越来越重要。
这些描述符合你的情况吗？ 立即使用 SigNoz Cloud，或者自行部署 SigNoz。