运行环境多种多样：不同的运行环境下，每个系统的工作情况是变化的，我们需要在任何阶段都能有效记录好系统的状态，便于我们分析问题、优化产品。
运行环境多种多样：不同的运行环境下，每个系统的工作情况是变化的，我们需要在任何阶段都能有效记录好系统的状态，便于我们分析问题、优化产品。
在这种多套方案组合的场景下，问题排查需要和多套系统打交道，若这些系统归属不同的团队，还需要和多个团队进行交互才能解决问题，整体的维护和使用代价非常巨大。因此我们希望能够使用一套系统去解决所有类型可观测性数据的采集、存储、分析的功能。
基于上述我们的一些思考，回归到可观测这个问题的本质，我们目标的可观测性方案需要能够满足以下几点：
数据全面覆盖：包括各类的可观测数据以及支持从各个端、系统中采集数据
足够的算力：分布式、可扩展，面对PB级的数据，也能有足够的算力去分析
灵活智能的算法：除了基础的算法外，还应包括AIOps相关的异常检测、预测类的算法，并且支持对这些算法进行编排
可观测数据引擎的整体架构如下图所示，从底到上的四层也基本符合方案落地的指导思想：传感器+数据+算力+算法：
传感器：数据源以OpenTelemetry为核心，并且支持各类数据形态、设备/端、数据格式的采集，覆盖面足够的“广”。
我们可以很大程度上让客户的问题能匹配到当前最适合解决这个问题的坐席身上，缩短解决问题时间的同时，兼顾提升客户满意度，极大释放坐席人员效能。
Node Query Cache：负责缓存 filter 查询结果，基于 lucene 的 segment 构建，缓存在堆内存中，ES 节点默认的 cache 大小为堆内存的10%，采用LRU机制。
Shard Request Cache：针对 ES 的 query 请求，缓存各分片的查询结果，主要用于缓存聚合结果，采用LRU机制，当分片 refresh 后会失效。
对于 lucene 而言，其使用的是堆外内存
• Page Cache：lucene 读写段文件时会依赖操作系统的 page cache 缓存，如果多次查询都涉及到读取某个段文件的同一部分内容，就直接使用 page cache 进行读取，无需再从磁盘获取数据。page cahce 由操作系统管理，淘汰策略类似LRU。
