当前对可观测性数据的查询状态是否存在问题？
大家好！我是一名SigNoz的维护者，SigNoz是一个开源的可观察性平台。
我想听听大家对我在查询可观察性（o11y）方面观察到的内容的反馈，看看是否有更多的人对此有共鸣。
我觉得目前的可观察性工具在用户期望方面显著滞后，主要是因为它们未能支持一个关键功能：跨不同遥测信号的查询。
这种局限性使得本应强大的关联能力变成了“关联戏剧”，这只是一种表面的洞察模拟，而非真正的分析能力。
以下是我看到的当前缺口：
1. 假设我想检索在过去13分钟内CPU使用率最高的主机的日志。今天几乎不可能无缝地查询到这一点，除非先查询指标，然后将结果粘贴到日志查询构建器中以获取结果。如今，跨信号查询的无缝关联几乎是不可能的。
2. 在多个列上进行唯一计数（COUNT distinct）在今天是不可行的。大多数平台允许你对一个列进行唯一计数，比如对源进行唯一计数，或者对主机进行唯一计数，或者对服务进行唯一计数等。添加多个维度并深入挖掘也是一个严重的痛点。
关于我们在SigNoz如何考虑解决这些缺口的一些想法：
1. 子查询支持：能够将一个查询的结果作为另一个查询的输入，主要用于获取过滤后的输出。
2. 跨信号连接：支持跨不同遥测信号连接数据，以便并排查看信号以及其他一些内容。
在这篇博客中有早期的想法，你觉得怎么样？这是否与您的情况相符，还是说这似乎是一个并不太多人有的用例？
[0] https://github.com/signoz/signoz
[1] https://signoz.io/blog/observability-requires-querying-across-signals/
查看原文
Hey folks! I’m a maintainer at SigNoz[0], an open-source observability platform<p>Looking to get some feedback on my observations on querying for o11y and if this resonates with more folks here<p>I feel that current observability tooling significantly lags behind user expectations by failing to support a critical capability: querying across different telemetry signals.<p>This limitation turns what should be powerful correlation capabilities into mere “correlation theater”, a superficial simulation of insights rather than true analytical power.<p>Here’s the current gaps I see<p>1/ Suppose I want to retrieve logs from the host which have the highest CPU in the last 13 minutes. It’s not possible to query this seamlessly today unless you query the metrics first and paste the results into logs query builder and retrieve your results. Seamless correlation across signal querying is nearly impossible today.<p>2/ COUNT distinct on multiple columns is not possible today. Most platforms let you perform a count distinct on one col, say count unique of source OR count unique of host OR count unique of service etc. Adding multiple dimensions and drilling down deeper into this is also a serious pain-point.<p>and some points on how we at SigNoz are thinking these gaps can be addressed,<p>1/ Sub-query support: The ability to use the results of one query as input to another, mainly for getting filtered output<p>2/ Cross-signal joins: Support for joining data across different telemetry signals, for seeing signals side-by-side along with a couple of more stuff.<p>Early thoughts in this blog[1], what do you think? does it resonate or seems like a use case not many ppl have?<p>[0] https://github.com/signoz/signoz
[1] https://signoz.io/blog/observability-requires-querying-across-signals/