CNCF云原生生态版图-分类指南（一）- 观测和分析
CNCF云原生生态版图-分类指南（一）- 观测和分析
CNCF云原生生态版图-分类指南
云原生生态版图按照功能类型，将项目和产品组织在一起，方便架构设计人员查找所需的技术。本文将对这个庞大的版图进行分解，从全局角度介绍各个类型，及各类项目能够解决的问题、作用方式及使用的技术。并对每种分类下的项目和产品进行整体介绍。
先对可观测性和分析进行定义：
- 可观测性：可观测性是一种系统特征，描述可以从系统的外部输出中理解系统的程度。以 CPU 时间、内存、磁盘空间、延迟、错误等来衡量，计算机系统或多或少是可观察的。
- 分析：分析是一种活动，在活动中查看和理解可观察数据。
为确保服务持续运行不中断，需要全面观察和分析应用程序，以便在应用程序发生异常时能够快速发现并矫正。这就是观测和分析类别中的所有项目和产品的主要职责。该类别位于整个云原生生态版图的侧面，能够观测左侧的所有类别层级。
下文主要介绍了可观测性和混沌工程，其中，混沌工程也可以划分为可靠性工具类别。
一、观测和分析（Observability and Analysis）
（一）可观测性（Observablility）
1. 是什么？
可观测性是从系统外部输出来理解系统的一种实践和能力。观测框架提交遥测数据给查询和可视化工具使用。遥测数据来自应用程序代码、底层节点基础设施和编排系统中采集的日志、指标和跟踪信息。这些数据，简单的有从本地节点统计的磁盘空间，复杂的有客户端到服务端往返的端到端用户事务。
2. 解决什么问题？
复杂系统的故障发生和性能下降通常会以多种形式出现，通过可观测性框架，可以掌握系统中各个服务或基础设施组建的运行状况，跟踪时间段内的重要统计指标，调试生产中的问题等。
3. 如何解决问题？
大规模运维云原生系统要求运维人员和开发人员通过访问高质量的系统状态遥测数据，来对事件作出响应并就如何改进系统做出最优的决策。可观测性可以帮助运维人员快速响应事件，帮助开发人员在生产环境调试应用程序，同时也能帮助团队分析用户行为，平衡系统性能与业务目标的关系。
4. 使用的技术
云原生可观测性在概念上与传统应用程序监控非常相似，但有几个关键区别。被检测的对象生命周期往往是短暂的，系统复杂性往往会随着部署的服务数量呈指数级的增长。这使得通过结构化数据和模式来诊断系统变得非常有意义，同时更加重视数据存储。云原生生态版图中这一部分的许多项目在设计时就考虑到了这些特征，例如 OpenTelemetry 和 Prometheus。
5. 项目和产品整体介绍
属于可观测性分类的项目和产品共有 148 个，其中 CNCF 项目有 19 个。这些项目和产品的关键字有：
- Monitoring 监测
- Time series 时间序列
- Alerting 警告
- Metrics 指标
- Logging 日志
- Tracing 跟踪
CNCF 项目如下表所示：
| 项目 | CNCF 项目阶段 | 说明 |
|---|---|---|
| Fluentd | 已毕业 | 用于统一日志记录层的开源数据收集器 |
| Jaeger | 已毕业 | 一个分布式跟踪平台，由 Uber Technologies 于 2016 年以开源形式发布并捐赠给云原生计算基金会 |
| Prometheus | 已毕业 | 一个开源的系统监控和警报工具套件 |
| Cortex | 孵化中 | 一个水平可扩展的、高度可用的、多租户的 Prometheus 即服务（Prometheus-as-a-Service）解决方案 |
| OpenTelemetry | 孵化中 | 提供了一组标准的 API、SDK 和工具，用于生成、收集、处理和导出分布式系统中的追踪（Tracing）、指标（Metrics）和日志（Logs）数据 |
| Thanos | 孵化中 | 一个专为高可用的 Prometheus 设置而设计的开源项目 |
| Fonio | 已存档 | 为云而生的安全监控代理 |
| Headlamp | 沙盒 | 是一个用户友好的 Kubernetes UI，专注于可扩展性 |
| Inspekto Gadget | 沙盒 | 使用eBPF对 Kubernetes 集群和 Linux 主机进行数据采集和系统检查的工具和框架 |
| K8sGPT | 沙盒 | 一种用于扫描 kubernetes 集群、用简单的英语诊断和分类问题的工具 |
| Kepler | 沙盒 | 一个 Prometheus 导出器，使用 eBPF 来探测 CPU 性能计数器和 Linux 内核跟踪点 |
| Kuberhealthy | 沙盒 | 一个 Kubernetes 运维工具，用于综合监控和持续流程验证 |
| Logging Operator (Kube Logging) | 沙盒 | 通过自动部署和配置 Kubernetes 日志记录管道来解决 Kubernetes 环境中与日志记录相关的问题 |
| OpenMetrics | 已存档 | 大规模传输云原生指标的事实标准 |
| OpenTracing | 已存档 | 一个开放的分布式追踪标准，用于在不同的分布式系统和编程语言之间提供一种统一的追踪方式 |
| Perses | 沙盒 | 一个开源的、可扩展的、云原生的时间序列数据库和可视化工具 |
| Pixie | 沙盒 | 面向开发人员的 K8S 可观察性工具 |
| Skooner | 已存档 | 一个开源 Kubernetes 控制面板 |
| Trickster | 沙盒 | 一个开源的 HTTP 代理缓存和加速层 |
（二）混沌工程（Chaos Engineering）
1. 是什么？
Chaos Engineering（混沌工程）是一种通过实验来验证系统在面对不确定性和故障时的健壮性的方法。它的核心思想是主动地向系统中引入故障或异常情况，以此来观察系统的反应，发现潜在的风险和脆弱点，从而提高系统的可靠性和韧性。混沌工程工具将提供一种受控的方式来引入故障并针对应用程序的特定实例运行特定实验。
2. 解决什么问题？
引起复杂系统失败的原因有很多，在分布式系统中，其后果往往难以理解。使用混沌工程的组织相信失败会发生，不试图阻止失败，而是练习如何快速从失败中恢复，或称为 MTTR1 。
3. 如何解决问题？
在云原生世界中，应用程序必须动态地适应故障，这是一个相对较新的概念。这意味着，当出现问题时，系统不会完全宕机，而是会正常降级或恢复。混沌工程工具能够在软件系统生产中进行实验，以确保它们在发生实际故障时能够正常执行。
4. 使用的技术
混沌工程工具和实践对于实现应用程序的高可用性至关重要。分布式系统通常过于复杂，任何一个工程师都无法完全理解，而且任何变更流程都无法完全预先确定变更对环境的影响。通过引入混沌工程实践，团队能够练习和自动化故障恢复。Chaos Mesh 和 Litmus Chaos 是该领域的两个 CNCF 工具。
5. 项目和产品整体介绍
属于可观测性分类的项目和产品共有 11 个，其中 CNCF 项目有 4 个。这些项目和产品的关键字有：
- Chaos Engineering 混沌工程
CNCF 项目如下表所示：
| 项目 | CNCF 项目阶段 | 说明 |
|---|---|---|
| Chaos Mesh | 孵化中 | 一个云原生的混沌工程平台，用于在 Kubernetes 环境中进行系统可靠性测试 |
| Litmus | 孵化中 | 一个开源的混沌工程框架，主要用于云原生应用和分布式系统的可靠性测试 |
| Chaosblade | 沙盒 | 一个云原生混沌工程平台，支持多种环境、集群和语言 |
| Krkn | 沙盒 | 结合了 Terraform（一种基础设施即代码的工具）的优势，帮助用户在复杂的云基础设施上自动化地构建和执行混沌实验场景 |
（三）小结
可观察性和分析旨在了解系统的运行状况，并确保系统在恶劣的条件下也能保持运行。日志记录工具捕获应用程序发出的事件消息，监控监视日志和指标，跟踪跟踪单个请求的路径。这些工具组合在一起时，理想情况下可以 360 度全方位了解系统内的情况。混沌工程略有不同。它提供了一种安全的方式来验证系统是否可以承受意外事件，从而确保其保持正常运行。
链接
MTTR 是 “Mean Time To Repair” 的缩写，即平均修复时间。它是一个用于衡量系统故障后恢复正常运行所需时间的关键指标。在运维管理、系统可靠性工程等众多领域被广泛应用。计算 MTTR 通常是统计一段时间内（如一个月、一个季度或一年）所有故障修复时间的总和，然后除以故障次数。例如，在一个数据中心，如果在过去一个季度内发生了 10 次系统故障，这些故障的修复时间分别为 1 小时、2 小时、1.5 小时、0.5 小时等，将所有修复时间相加（假设总和为 15 小时），再除以故障次数 10，得到 MTTR 为 1.5 小时。 ↩︎
原文地址：https://blog.csdn.net/qichengzong_right/article/details/144406118
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！