中年|一文聊聊监控，可观测性与数据存储( 二 ) |数据存储|聊聊|

【中年|一文聊聊监控，可观测性与数据存储】

集中存储/检索。使得工程师免于分别登陆机器查看日志之苦，日志被统一采集，集中存储于日志服务，并提供统一的检索服务。这个过程牵扯到例如日志格式统一，解析，结构化等等问题。
日志的监控。
从日志中提取的 metrics ，例如 access log 中携带的大量数据，都可以被提取成有用的信息。至于提取的手段，有的通过客户端在日志本地进行解析，有的在集中存储过程中进行解析。

tracing 随着互联网工程日渐复杂，尤其是微服务的风潮下，分布式 tracing 通常是理解系统，定位系统故障的最重要手段。
在存储层面， tracing 已经有相对明确的方案，无论是 OpenZipkin ，还是 CNCF 的 Jaeger，都提供几乎开箱即用的后端软件，其中当然包括存储。
Tracing 的存储设计主要考虑

稀疏数据：tracing 数据通常是稀疏的，这通常有几个原因

不同业务的 trace 路径通常不同，也就是 span 不同，因而稀疏
同种业务的 trace，在不同内外部条件下，路径也不同。例如访问数据库，是否命中缓存，都会产生不同的 span 链
访问正常/异常的 trace，产生不同 span

多维度查询：通常的解决思路

二级索引：在以 HBase, Cassandra 为基础的方案中比较常见
引入倒排索引，在二级索引方案无法满足全部查询请求时，可能会引入 Elasticsearch 辅助索引，提升查询灵活性

Events 同样是一个难以定义，但是很容易描述的术语。我们把，一次部署，一次配置变更，一次dns 切换，诸如此类的变更，称为事件。
它们通常意味着生产环境的变更。而故障，通常因为不恰当的变更引起。
对 events 的处理主要包括

集中存储：事件种类很多，较难归纳共同的查询纬度，所以倒排索引在这种无法事先确定查询纬度的场景下，是非常合适的存储结构
Dashboard：以恰当的方式，把事件查询 /展示出来。上文提到 Etsy 的博客中，展示了很好的实践方法，使得工程师能够通过 dashboard，非常轻松确认网站登陆失败，与登录模块部署事件之间的关系。

总结现代的监控，或者可观测性工程，通常是对不同类型数据的采集/存储/分析。这些数据各有特点，因而存储也不存在银弹。通常是根据各自特点，独立设计存储方案，上层提供一个统一、综合的存储系统。