Otel是一个基于OpenTelemetry的监控运维可观测性解决方案，主要由数据采集、数据分析、数据展示三个组件构成。标准化的观测数据在这三个组件中能简单、高效的关联聚合，为可观测性下的各类业务场景提供了更加丰富的接口数据。
数据采集
得益于OpenTelemetry提供的可观测性数据标准化和一系列的工具集，我们能够快速构建一个统一标准下可观测数据的采集、处理、导出服务。
在具体实现方案上，我们采用了Agent + Collector部署的方式。
Agent以daemonset的方式运行在Node上，主要负责该Node上数据的采集(receiver)和处理(processor)工作，包括但不限于应用、主机、集群等资源的可观测数据(Trace、Log、Metric)；
Collector作为一个数据中心服务，主要负责收集Agent处理后的数据，支持在该数据上再做处理工作(数据打标、分组等)，最后将处理后的数据导出到对应的服务即可。Collector服务可独立部署且支持高可用，能与Agent通信即可。
数据的采集架构和实现方案主要由OpenTelemetry提供的工具集完成，通过配置的方式可以很轻松的部署。同时我们对这个方案做了以下优化和改动:
添加processor配置，为所有数据添加用户信息，用于支持数据的多租户功能
Filebeat的outputs插件官方只有(es、kafka、logstash等)，暂不支持OpenTelemetry
基于官方接口，我们实现了一个telemetry outputs插件，用于filebeat将日志数据标准化后直接上传至Agent
至此，OpenTelemetry完成了目前它所期望解决的可观测性标准方案的全部内容，在Collector之后关于数据的分析、存储、展示等功能并不是它所要解决的问题(至少短期内不是)。针对这个问题大家目前都还是依赖各自的Vendor平台去实现，开源界暂时也没有一个成熟统一的解决方案。
尽管Collector很友好的支持导出数据至阿里云SLS，但基于公司内运维可视化需求的定制性和运营成本等多方面因素，我们决定在这基础上自己实现一个完整的可观测性解决方案，用于解决之后数据分析、存储、展示的问题。
数据分析
如何处理Collector上传的海量数据，是该可观测性方案的核心内容。这些数据作为元数据主要用于实现以下两个服务:
业务可视化
应用可视化，包括应用拓扑、应用性能、应用链路、应用资源等
集群可视化，包括集群健康、集群资源、集群状态等
日志可视化，包括日志查询、日志分析等
...
监控告警
这些服务在及时性、关联性上都有较强的需求，那么数据处理的吞吐率、准确性和灵活度也就显示十分重要。基于这些因素，我们采用了Flink作为数据处理分析的基础平台。
同时，为了降低Flink task与业务的耦合，我们采用可配置式的方法，实现一个简单的规则引擎让flink动态获取配置后再执行相应的task。
数据展示
数据经由Flink处理完成后，通过Flink的Sink对外输出并存储。这些数据的存储分为两部分:
Elasticsearch，主要用于存储前端业务可视化常用的聚合数据，起到数据缓存的效果
Cassandra，超高的写性能和高效的压缩策略适合存储元数据，这部分数据使用频率很低，仅支持简单查询即可
Elasticsearch作为一个分布式的搜索引擎，其特有的全文搜索、快速查询、复杂聚合、高可用等优点，让我们选择它作为数据展示的底座，在其上面构建一个OpenAPI服务，用于读取和再聚合Elasticsearch数据提供给各业务前端使用。
总结
Otel作为一个完整的云原生监控运维可观测性方案，采用Opentelemetry作为数据基础设施，利用其提供的丰富工具集快速构建数据采集服务；同时在解决OpenTelemetry的局限性时，充分发挥了其提供的标准化统一数据模型规范的优势。
所有服务组件都实现了容器化部署并提供了相应的helm包，之后我们将提供Otel的完整部署方案以及简单快捷的接入方式。
