CNCF 全景图简介1-可观测性可分析

931 阅读9分钟

简介

云原生的风潮越刮越热,并且涌现出了非常多优秀的云原生组件。有必要对这些组件有个大概的了解,这对我们拓宽视野以及做技术选型会有所帮助。

我们参照 CNCF全景图 的分类依次对其中 开源 的组件进行探索。文中主观的观点可能较多,如有错误处欢迎探讨指正。

可观测性和分析

可观察性:一种系统特性,通过CPU、内存、磁盘空间、延迟、错误等度量,可以观察到系统的运行状况。通过收集日志、链路、监控指标从而观察系统的方方面面。

分析:通过可观察收集到的信息分析系统,使其有意义。

全景图中相关的组件如下,又细分为监控、日志、链路追踪、混沌引擎、持续优化 5 个部分。

  • 监控、日志、链路追踪主要用于构建可观察性
  • 混沌引擎其实属于可靠性、正确性验证,勉强算分析工具吧
  • 持续优化是个比较新的专题目前主要是关注成本控制分析

下面会对 5 部分中开源的组件进行简单介绍

image.png

image.png

1 监控

监控通过收集系统运行指标,进行可视化以及报警,帮助研发人员分析了解系统状况、处理线上问题。

推荐 Opentelemetry(采集) + Prometheus(存储) + Thanos(联邦|可选)+ Grafana(展示) 的组合。

image.png

Prometheus 功能完善,CNCF 第二个毕业项目,是云原生监控领域的事实标准,几乎所有较为成熟的云原生的组件都会提供 Prometheus 指标。基于 k8s 的环境,监控方面可以无脑选 Prometheus。

image.png

Cortex 意在解决 Prometheus 多租户、高可用集群部署、数据长期存储等方面的问题。但目前来看同类型产品 thanos 更为流行。

image.png

OpenMetrics 是一个监控指标的规范项目,旨在统一指标的采集标准,并且提出了 trace 和 metrics 融合的方式。后来推行的 Opentelemetry 规范是可观测性相关的一站式解决方案,指标规范方面几乎完全涵盖了 OpenMetrics,新项目使用 Opentelemetry 即可。

image.png

Thanos(灭霸)主要是做 Prometheus 的高可用和长期存储。Thanos 和 Cortex 的功能非常非常相似,但 Thanos 的活跃度更高,如果指标需要长期保存推荐使用。

image.png

Beats 是 elastic 生态中一系列轻量级的数据采集工具的集合,其中用的比较多的是 Filebeat 日志采集。 可以方便的对接 Elasticsearch 和 Logstash。监控指标相关的 Metricbeat 用的比较少,如果不是选择 Elastic APM 全家桶的话不建议使用。

image.png

Centreon 是产品名也是公司名,成立于 2005 年的法国公司,主要基于 Nagios 实现,其开源版本相对商业版本功能上少了很多,且社区不活跃,不推荐使用

image.png

DeepFlow 是一个国产产品,旨在基于 eBPF、Opentelemetry 等较新的技术实现自动化高质量的可观测性,减少研发成本,此前是 saas 形态,目前刚刚开源,适当观望。

image.png

Checkmk 也是商业软件刚推出开源版本,目前活跃度不高。

image.png

Falcon 小米开源,主要关注机器监控,对标 Zabbix 多了很多功能,但已经很久不维护了。一般云原生架构的项目 Prometheus 提供的机器监控功能已经足够了。

image.png

Fonio 是个 Rust 项目,想基于 eBPF 做安全监控代理,有段时间不维护了,不建议使用。

image.png

Grafana 是目前监控大盘领域的事实标准,可以轻松的对接 Prometheus、ES 等多种数据源,自定义图表绘制,非常方便,无脑选。

image.png

Grafana Mimir 是 Grafana 和 Cortex 的扩展,主要是提供 Prometheus 的长期存储、多租户等功能。和 Cortex 无本质区别,依然推荐 Thanos。

image.png

Graphite 是一个简单易用的监控数据绘图工具,其功能 Grafana 几乎都能干,如果有 Grafana 就不推荐引入了。

image.png

Hubble 是最近比较流行的 CNI Cilium 项目提供的可观测工具,Cilium 未来可期,目前观望。

image.png

Icinga 主要特点是多集群网络监控,主要还是针对机器环境非容器环境,其功能 Prometheus 可以覆盖,不建议使用。

image.png

InfluxDB 是一个时序型数据库,在监控场景下性能强于目前市场同类型产品,如果资源允许且对监控性能有要求的话推荐使用 InfluxDB 代替 Prometheus 自身的时序数据库。不建议产品初期就使用,如果使用的话直接使用 InfluxDB 2。

image.png

Kiali 是 Istio 服务网格的默认控制台页面

image.png

Kuberhealthy 是对 k8s 中 pod 等资源进行持续测试的工具,测试结果可以方便的集成到 Prometheus 中。目前 Prometheus 对于 k8s 核心组件以及业务容器的健康已经很完善了,不推荐再使用 Kuberhealthy 了。

image.png

M3DB 和 InfluxDB 类似,是个时序型数据库,如果数据量真的很大,可靠性要求很高,有精力更换 Prometheus 的时序数据库的话,还是推荐 InfluxDB。

image.png

Nagios 也是个监控引擎,上文中的 Centreon 就是基于它实现的。不推荐使用。

image.png

Netdata 是一款指标丰富性能好的机器性能指标采集工具,可以很好的与 Prometheus 结合,但目前 Prometheus 对于机器的监控也比较完善了,新项目不推荐使用。

image.png

Netis 是一款抓包工具,帮助定位容器网络问题,有时间可以试试。

image.png

NexClipper 想做指标收集的管道,并且提供企业级的 Prometheus 封装。新项目推荐使用 Opentelemetry 做可观测性数据的统一管道,Thanos + Prometheus 的组合也比较完善了。因此不推荐使用。

image.png

Nightingale 是个新项目对标 Prometheus 做云原生监控,目前 Prometheus 地位稳固,不推荐。

image.png

OpenTSDB 是一个基于 HBase 实现的时序型数据库,如果数据量真的很大,可靠性要求很高,有精力更换 Prometheus 的时序数据库的话,还是推荐 InfluxDB。

image.png

Opstrace 是 Datadog 的开源平替,被 gitlab 收购,融入到 gitlab devops 工具集中了,如果对监控要求不高,不想投入任何研发成本,可以尝试。

image.png

Pixie 是一个基于 eBPF 的可观测性一站式解决方案,目前更看好 Cilium 体系,不推荐使用。

image.png

Promscale 是基于 PostgreSQL 和 TimescaleDB 的可观测性后端,使得架构多了一层且没有发展起来,不推荐使用。

image.png

Sensu 一款较为简单的云监控工具,功能太少,不推荐使用。

image.png

Skooner 一款 k8s 大盘,已经有 k8s dashboard 等很多大盘了,没有亮眼的功能且扩展性不强,不推荐使用。

image.png

sysdig 同样是机器监控为主,有 Prometheus 了,不推荐使用。

image.png

Trickster 是一个指标后端存储到前端大盘之间的 http 反向代理,旨在提高查询速度,多了一层调用且活跃度不高,不推荐使用。

image.png

Vector 是一个高性能可观测性数据管道,主要负责采集数据,可以采集日志和指标,其采集性能比同类型产品例如 filebeat 和 logstash 好不少,可以作为日志采集工具使用。

image.png

VictoriaMetrics 也是一个时序型数据库,同样不推荐使用。

image.png

Weave Scope 是 k8s 的可视化工具,安全权限缺失且扩展性不强,不推荐使用。

image.png

Zabbix 是优秀的老牌机器监控软件,容器环境还是推荐 Prometheus。

2 日志

日志大家都比较熟悉了,日常解决问题几乎全靠它。

目前 Opentelemetry 日志的标准尚不完善,依然推荐 EFK(Elasticsearch + Fluentd + Kibana) 的组合。如果对采集的性能和资源消耗比较敏感,可以把 Fluentd 换成 Fluent Bit 或者 Vector。

image.png

Fluentd 主要用于日志采集和清洗,是 CNCF 毕业项目,拥有相当多的插件,性能相比 logstash 有提升,但对比 Fluent Bit 和 Vector 性能上又差一些,不过仍然推荐使用。

image.png

Grafana Loki 是 Grafana 的日志组件,对于日志存储成本限制很高,对于日志内容搜索要求不高的场景可以使用。

image.png

Logstash 是老牌日志采集工具了,但是资源消耗和性能都比较一般,逐渐被其他工具取代了。

image.png

OpenSearch 是亚马逊丛 Kibana 老版本 fork 出来自己适配的一个版本,大家对 Kibana 使用已经习惯,不推荐使用。

image.png

Parseable 一个新的一站式日志平台,目前刚刚起步,观望。

2 链路追踪

通过链路追踪可以快速定位问题部位,并熟悉系统依赖拓扑。

目前推荐 Opentelemetry + Jaeger + Elasticsearch 的组合。 如果不想投入太多研发成本且需要开箱即用 APM 能力的话也可以使用 Skywalking 一步到位。

image.png

Jaeger 是一个链路追踪平台,提供了丰富的页面,并且支持对接各种后端,作为毕业项目,成熟度非常高。但随着 Opentelemetry 规范的推动,链路采集已经不推荐使用 Jaeger 项目自身提供的采集器了,后端存储方面推荐 Elasticsearch。此外 Jaeger 正在和 Opentelemetry 共同构建目标丛一个链路追踪系统发展成为 APM,总之推荐使用。

image.png

OpenTelemetry 是云原生可观测性标准,上文已经多次提到,推荐新项目都要使用。

image.png

EaseAgent 是一个 java 的 javaagent 用于采集指标和链路,OpenTelemetry 已经有相关功能了,不推荐使用。

image.png

Elastic APM 是 Elastic 技术栈的一员,对于 OpenTelemetry 支持的不好,不推荐使用。

image.png

Grafana Tempo 是一个链路追踪展示大盘,展示效果目前略好于 Jaeger,如果基于 Grafana 构建一站式可观测平台推荐使用。

image.png

OpenTracing 是链路追踪规范,已经合并到 OpenTelemetry 中了

image.png

Pinpoint 是页面非常丰富的 APM 工具,但是不支持 OpenTelemetry,且性能消化大,且基于 Hbase 存储无法很好的支持搜索,因此不推荐使用。

image.png

SkyWalking 是一个 APM 工具,可以和 OpenTelemetry 结合,页面丰富度较好,目前优于 Jaeger,推荐使用。

image.png

SOFATracer 是蚂蚁金服的链路追踪系统,不兼容 OpenTelemetry,不推荐使用。

image.png

Spring Cloud Sleuth 是 spring cloud 体系中用于链路采集上报,官方对 Zipkin 支持好,对 OpenTelemetry 支持的一般,可以参考不推荐使用。

image.png

Tracetest 基于 OpenTelemetry 做端到端测试,新项目,观望。

image.png

Zipkin 老牌链路追踪系统,但页面丰富度不够,不推荐使用。