关于Observability数据模型和存储模型思考

[laziobird]

1、Trace、Metric、Log要不要一起传输，如何串联
Trace、Metric 绝大部分场景会一起使用，做关联一同传递
Log 数据量比Span 大一个数量级，一起传递，传输量压力太大。 业界Log 异步上报，异步存储，只需要记录下TraceId映射关系，做串联索引查询还是比较容易。

Observability 系统数据使用频率：Trace和Metric 几乎高 Log 一个数量级，
Log 查询场景：A、Id 查询，关联trace B、模糊查询 C、Tag 查询，比如看全局异常

[laziobird]

携程例子

日志
Clog是一个应用日志不落本地磁盘，实时传输的日志系统，每天处理约2PB的日志数据，机器规模约40台物理机（32C128G）

Trace
Tracing，携程使用CAT。由140台物理机（32C128G）每天处理近2PB的数据。

Metric
VictorialMetrics时序数据库和ClickHouse列存数据库

目前的VictorialMetrics系统规模是200台物理机（40C256G，4T SSD）。
当基数（Tag维度组合）较多时，VictorialMetrics的性能会急剧下降，这是因为Metric到ID的映射关系缓存在内存中，当Miss后，将从索引文件中读取，大量文件解码将导致CPU持续高位，影响性能，因此内存决定了VM支持的基数有限。

对于高基数的数据，我们引入了ClickHouse，当前规模600台物理机（32C128G）。

频率 Metric 》 Trace 》 Logs

[laziobird]

场景 ： A、报警，异常诊断，监控系统使用
B、大数据分析
C、实时用户行为分析

离线搜索、实时搜索，完全两种架构和性能

1、时效性：实时、10s、1分钟，性能差异，架构设计最大，所需服务器资源差异巨大 PB
2、高频聚合维度查询：分片
3、模糊查询：分片

C、特殊的索引处理

[laziobird]

从上面的文章中成本启发，我来提个讨论话题吧：关于Metric、Trace、Log

场景：有多种数据格式的原始日志信息，量级PB级别，每种格式有各自维度列信息，以及一些数组列，以及一些纯文本的text信息
需求：用户既要根据这些维度列做高频的维度聚合查询，也要做明细查询

从成本最低的角度来思考一个方案

我先来提一种方案：Metric、Trace、Log3者之中，存储成本最高的还是Log，减少Log的使用
1 高频的维度聚合查询，还是需要TSDB之类的来满足，clickhouse在量级大并且高频查询上优势没有TSDB大
2 明细查询，有2类：A类是根据维度列来查询明细，B类是根据纯文本text信息来查询明细
这块还是自己append文件的代价最低，始终根据id来点查完整的Log信息
接下来要解决如何根据用户查询需求来查询符合要求的id列表了
对于A类，在TSDB聚合每种维度时，也可以自动聚合出数值列大的一些id，基本就可以满足A类
对于B类，这种可以写入Log系统，建立id和纯文本的关联，可以满足B类
这种方案，最大化减少对Log使用，让PB级别的全量明细存储代价最低化