浅谈云原生可观测性生态的优化和丰富

云原生可观测数据中的时序数据 Metrics，在业务高基数、持久化存储、乱序写入、多租户隔离等场景下，对后端时序数据库底座的能力带来众多挑战。本次分享 OPPO 自研时序数据库在上述场景下的思考及实战演进。同时我们为了构建基于 Opentelemetry 的可观测全链路演进方案，也初探了 Grafana Labs 主推的一套全家桶，看他们是如何玩转 Metrics、Trace、Log 以及 eBPF。
Q1｜OPPO 有自己的可观测性产品 UI 还是 直接使用开源的 Grafana ？
A：目前数据展示包括三个场景：
开源grafana提供的UI给基础运维同学提供看板。
另外公司也有自己的UI内嵌到云平台环境，由各业务方自行查看、调用等。
同时各业务方的业务看板也可以直接调用我们提供的多机房聚合查询接口，对数据进行二次使用。
Q2｜Open Metrics 对比 OTel Metrics， 哪个会更加贴近标准一些？
A：openmetrics是当前prometheus 等生态主流的协议。opentelemetry是目前正在推广并且被社区认可的协议，重要的是，otlp同时也会兼容openmetrics的数据进行导入和导出。在当前一段时间内，应该是openmetric为主，但个人认为随着可观测的推广和普及，otlp会更被大家接受。在实际落地上看，Grafana生态已经在Mimir新版本支持了otlp的支持，cortex/prometheus 等也考虑引入otlp的计划。

Grafana 是一个强大的可观测性数据可视化平台，并且迭代迅速，截止目前已经支持了对指标、追踪、日志、性能剖析等四种观测信号的可视化。此次分享将会对 DeepFlow Grafana 插件做详细解析，介绍如何从零开始开发一个 Grafana 的 Datasource，分享如何利用 Grafana 的强大插件能力构建自己的数据查询插件。同时，我们也会介绍 DeepFlow Grafana 可视化 Panel 组件，解析内置的 DeepFlow 数据可视化系统的框架结构和具体实现，并分享绘制流量拓扑图、分布式调用火焰图的实战经验。
Q1｜为什么不使用echarts的图来制作panel？
A：Echarts图可以用来制作panel。只有在Echarts目前提供的图无法满足准确体现产品意图情况下，我们才会考虑自己开发相关图表。
Q2｜如果想把上面的DeepFlow的火焰图嵌入我们自己开发页面，可以嘛，怎么做？
A：可以。待DeepFlow-vis开源后，可以使用绘图组件自由搭配页面。
Q3｜有计划支持其他可视化平台嘛，比如kibana或者chronograf？
A：暂时没有计划，相对来说kibana和chronograf更加针对自己的es和influxdb。
Q4｜开发完页面性能上怎么保证呢？
A：数据层面通过从查询时限制查询的数据条数，优先使用对数据进行分组聚合来减少数据量。组件层面，需要从代码级别进行性能优化，避免多份数据拷贝或者视窗外的无效渲染。
Q5｜ 公司有在使用Grafana，是否可以直接对接DeepFlow的数据，还需要额外开发吗？或者有什么特别要求？
A：安装DeepFlow社区版时自带打包好的Grafana。独立的Grafana可以通过安装插件，导入模板直接对接DeepFlow的数据。

]]>