dotnetcore/mocha

[proposal] mocha : 云原生 APM 和大规模可观测性数据处理平台

liuhaoyang opened this issue · 0 comments

背景

近年来,可观测性概念被提出和逐渐流行,OpenTelemetry 也逐渐成为最流行的可观测性框架,OTel 很好的解决了多语言系统中Metrics\Trace\Log 的收集和标准化问题,但对于如何存储和分析使用收集到的 M.T.L 数据,业界并没有统一的方案,一般来说大家需要

  1. 使用 Jaeger、Prometheus、Loki 等不同的后端系统搭配,但引入了相当的复杂度
  2. 引入 SkyWalking 、ElasticAPM 等 APM 系统
  3. 使用 Datadog、SLS 等 SaaS 可观测性平台,需要支付昂贵的流量和数据存储费用

同时上述提到的开源 APM 后端,除 SkyWalking [Java实现]外,其余无一例外使用 Golang 实现。
而从 .NET 5 以来,到目前的 .NET 8,每一个版本都对 CLR 和 BCL做了大量性能优化和提供了面向高性能场景的新语言特性,.NET 的演进很适合开发高性能的云原生中间件。所以我们发起 mocha 项目,使用 .NET 实现一个面向大规模可观测性数据分析和存储的平台。

Mocha 的定位:基于 OpenTelemetry 的 APM 系统,同时提供可伸缩的可观测性数据分析和存储平台。

平台功能

image
Mocha 将要提供的功能集合:

  • APM 和 分布式追踪
    • 服务概览、R.E.D 指标和可用性监控
    • 服务拓扑
    • 调用监控,包括 HTTP、RPC、Cache、DB、MQ 等
    • 调用链路查询和检索
  • 基础设施监控
    • 主机监控
    • 容器和 Kubernetes 监控
    • 主流中间件监控
  • 日志
    • 日志查询
    • 日志聚合分析
  • 报警
    • 报警规则管理
    • 报警通知
  • M.T.L 数据探索 [Data Explore / Inspect]

技术架构

image

Mocha 由下面的部分组成

  • Mocha Distributor Cluster:作为 mocha 系统的数据入口,负责接收 OTel SDK 和 Collector 上报的数据,并通过一致性Hash 将数据路由到对应的 aggregator 节点上。为了保证数据不丢失,最终 Distributor 应该具备本地 FIFO 队列的能力。
  • Mocha Aggregator Cluster:mocha 的核心组件,通过读取预配置或者用户配置的 aggr rule dsl 生成对应的 streaming data flow 并执行。Aggregator 是具备分布式 shuffle 的能力的有状态组件,需要将自身信息注册到ETCD中。
  • Storage:mocha M.T.L 存储,可以选用开源存储组件,如 ClickHouse、ElasticSearch、victoriametrics 等。
  • Mocha Querier + Grafana: 从存储查询数据并提供给 grafana 做展示。因此要兼容 promql / jeager / loki 等数据源的查询。
  • Mocha Manager : 包括 manager server、dashboard和ETCE组件,集群元数据和 M.T.L 数据分析规则存储。
  • OTel SDK / Collector : 开源 OpenTelemetry 采集套件。