diff --git a/README.md b/README.md index cd407879c2bab11d3684b60307b8d39037293f9b..6fb89a649a5a3ba8105d6e8e8d400a548a2b8060 100644 --- a/README.md +++ b/README.md @@ -1,25 +1,56 @@ +# 介绍 + +gala-ops是一款C/S架构、基于AI的操作系统亚健康诊断工具。其基于eBPF + java agent无侵入观测技术，并以AI技术辅助，实现亚健康故障（比如性能抖动、错误率提升、系统卡顿等问题现象）分钟级诊断，简化IT基础设施的运维过程。 + # 背景 -​ 云场景中基础软件/业务应用之间的边界逐渐上移，基础软件逐渐成为云场景最重要的组成部分，而操作系统又最重要的基础软件之一。 -​ 从业界公开的数据看，云场景的一些重要故障均是与基础软件密切相关。公开数据显示现有主流云厂商月平均故障150+次数，75%的故障<1H，90%<1.5H，少量故障>5H。 +云基础设施在近几年随着云原生、无服务化等技术的实施，其运维的复杂性变得越来越有挑战性，尤其是亚健康问题特点（间歇性出现、持续时间短、问题种类多、涉及范围广等）给云基础设施故障诊断带来重要挑战。亚健康故障诊断的挑战（包括可观测能力、海量数据管理能力、AI算法的泛化能力等）在Linux场景中变的尤为突出。在openEuler开源操作系统中，现有的运维手段不足以及时发现、定位亚健康问题，存在包括：缺乏在线、持续性监控能力；缺乏应用视角精细化的观测能力；缺乏基于全栈观测数据的自动化、AI分析能力等问题。然而，针对亚健康故障的诊断能力其难点包括： -云场景的基础设施、业务场景的复杂性，导致这些故障现象大量集中基础软件（尤其是操作系统）层面，为此openEuler社区规划&孵化A-Ops项目，该项目包括基础设施监控、应用性能监控、应用安全、自动化及监控四大块功能。 +- 全栈的无侵入可观测观测能力。 +- 持续、精细化、低负载的监控能力。 +- 自适应不同应用场景的异常检测、可视化故障推导能力。 -![](./png/a-ops-arch.png) +# 项目简介 -# 介绍 +gala-ops的整体架构如图所示，其整体上是一个C/S架构。在生产节点gala-gopher是一个Linux后台程序，其负责提供全场景、全栈（包括Metrics、Events、Tracing等）的数据采集，其支持通过OpenTelemetry开放生态接口（支持prometheus exporter、kafka client等）将数据传递给管理节点。管理节点部署gala-spider、gala-anteater组件，分别负责集群拓扑计算、可视化根因推导； + +gala-ops架构上依赖一些开源中间件（包括prometheus、kafka、Elastic等），但亦可对接至客户IT系统现有的中间件。gala-ops架构设计提供被集成能力，可以由行业客户IT运维系统集成。其提供两类被集成方式： + +- 软件生态集成方式：可以只使用gala-gopher可观测能力（OpenTelemetry方式获取数据），亦可以使用全部能力，通过prometheus、Elastic、kafka等中间件获取观测数据、异常检测结果、可视化推导结果。 +- 工具集成方式：将gala-ops提供的能力以Grafana形式集成至客户IT运维系统内。 + +![](./png/gala-arch.png) + + + +gala-ops可以给客户提供如下运维能力： + +- 在线应用性能抖动诊断：提供数据库类应用性能在线诊断能力，包括网络类（丢包、重传、时延、TCP零窗等）问题、I/O类（磁盘慢盘、I/O性能下降等）问题，调度类（包括sysCPU冲高、死锁等）问题、内存类（OOM、泄漏等）问题等。 +- 系统性能瓶颈诊断：提供通用场景的TCP、I/O性能抖动问题诊断能力。 +- 系统隐患巡检：提供内核协议栈丢包、虚拟化网络丢包、TCP异常、I/O时延异常、系统调用异常、资源泄漏、JVM异常、应用RPC异常（包括8种常见协议的错误率、时延等）硬件故障（UCE、磁盘介质错误等）等秒级巡检能力。 +- 系统全栈I/O可观测：提供面向分布式存储场景的I/O全栈观测能力，包括GuestOS 进程级、Block层的I/O观测能力，以及虚拟化层存储前端I/O观测能力，分布式存储后端I/O观测能力。 +- 精细化性能Profiling：提供多维度（包括系统、进程、容器、Pod等多个维度）、高精度（10ms采样周期）的性能（包括CPU性能、内存占用、资源占用、系统调用等类型）火焰图、时间线图，可实时在线持续性采集。 +- K8S Pod全栈可观测及诊断：提供K8S视角的Pod集群业务流实时拓扑能力，Pod性能观测能力、DNS观测能力、SQL观测能力等。 + + + +gala-ops涉及的关键技术包括如下： + +- 融合型非侵入观测技术：融合eBPF、Java agent等不同观测技术优点，实现多语言（支持C/C++、Java、Go等主流语言）、全软件栈（包括内核、系统调用、基础库Glibc、运行时jvm、基础中间件Nginx/Haproxy等）的观测能力。 +- 流程拓扑：基于时序化数据（L4/L7层流量等），实时计算生成时序化拓扑结构，动态展现业务集群拓扑变化。 +- 可视化根因定位：统计推理模型结合全流程拓扑，实现可视化&分钟级的问题根因诊断。 -​ 针对云场景的故障特点，根据故障发展阶段划分成：系统隐患、灰度故障、故障 三个阶段，A-Ops规划应用性能监控解决方案，该解决方案包括多个关键组件，本文用于介绍相关gala-ops系列组件。 +# 应用场景 -​ gala-ops系列组件定位：云基础设施场景中，针对基础设施**灰度故障**导致的**应用性能劣化**、卡顿系统级故障**在线诊断**。提供包括**应用性能诊断、系统性能瓶颈诊断、系统参数修复、系统实时拓扑**等特性。 +​ gala-ops在openEuler等Linux环境主要面向场景包括数据库、分布式存储、虚拟化、云原生等场景。助力金融、电信、互联网等行业客户在全栈可观测的基础上实现亚健康故障分钟级诊断。 -# 原理 +# 项目代码仓 -通过eBPF技术实现系统白盒化智能观测，实时在线完成系统架构拓扑化，在此基础完成从基础软硬件至应用现象的根因推导过程，且过程可视化。 +https://gitee.com/openeuler/gala-gopher -三步骤如下： +https://gitee.com/openeuler/gala-spider -![](./png/Principle.png) +https://gitee.com/openeuler/gala-anteater @@ -646,7 +677,7 @@ Google针对云服务SLI的评估提出VALET方法，从5个维度综合评估 -## 系统I/O全栈诊断 +## 系统I/O全栈观测 ### 特性背景 @@ -673,11 +704,11 @@ Google针对云服务SLI的评估提出VALET方法，从5个维度综合评估 [分布式存储I/O全栈诊断视频](https://gitee.com/openeuler/gala-docs/blob/master/demo/3.%20A-Ops%20%E5%88%86%E5%B8%83%E5%BC%8F%E5%AD%98%E5%82%A8%E5%9C%BA%E6%99%AF%20%E2%80%93%20%E5%9C%A8%E7%BA%BF%E7%B3%BB%E7%BB%9FIO%E8%AF%8A%E6%96%AD.mp4) -## 系统隐患诊断 +## 精细化性能Profiling ### 特性背景 -用户在日常运维过程还经常会遇到僵尸进程、内存泄漏、CPU冲高等问题，这些问题现象表现在系统层面，但是问题根因常见在应用层面。为了能够让系统运维SRE快速定界问题范围，gala-ops提供系统隐患诊断能力（隐患是指应用对系统产生的不利影响），用于监控/诊断非健康应用对系统产生的持续性、随机性的隐患，包括CPU冲高、内存泄漏（或持续增长）、I/O带宽拥塞等。 +用户在日常运维过程还经常会遇到僵尸进程、内存泄漏、CPU冲高等问题，这些问题现象表现在系统层面，但是问题根因常见在应用层面。为了能够让系统运维SRE快速定界问题范围，gala-ops提供精细化性能Profiling能力，其支持长期、在线采集系统/应用性能数据，可以快速诊断包括CPU冲高、内存泄漏（或持续增长）、系统调用异常、资源不足等问题。 ### 解决方案 @@ -690,43 +721,16 @@ Google针对云服务SLI的评估提出VALET方法，从5个维度综合评估 - 采样负载评估：以10ms采样一次数据为例，一次采样逻辑的指令预估 1W条（ CPU 10MS 指令数量大概能够执行 1KW条指令），采样指令数量/CPU单位时间执行数量 = 1W/1KW 0.1%，所以采样负载理论上是 0.1%（每核） - 数据存储评估：采样数据需保存一段时间用于周期性的转换成函数符号。假设采样频率10ms，转换周期1min，那么最少要保留的采样点：1min/10ms * 单次采样数据。即单核大约 6000个采样点。放大评估，单核大约1.2W个采样点。 -### 案例演示 - -[系统隐患诊断视频](https://gitee.com/openeuler/gala-docs/blob/master/demo/4.%20A-Ops%20%E6%95%B0%E6%8D%AE%E5%BA%93%E5%9C%BA%E6%99%AF%20-%20%E7%B3%BB%E7%BB%9F%E9%9A%90%E6%82%A3%E8%AF%8A%E6%96%AD%EF%BC%88%E7%81%AB%E7%84%B0%E5%9B%BE%EF%BC%89.mp4) - -# 未来规划 - -### 背景介绍 - -云原生是云场景的发展趋势，越来越多的场景采取云原生方式部署业务。在云原生场景的运维软件目前也非常丰富，但是系统层面的运维在云原生场景依然存在一些问题。具体表现在： - -- 在云原生领域，现有成熟监控工具：cAdvisor、Atop、Ganglia等只能看到kernel暴露的数据，无法高保真的监控应用运行状态。 -- 传统监控APM在面临云原生基础设施厚重的背景下，存在无法深入基础软件内部、无法弹性/动态插桩、语言强依赖等问题。 -- 基础软件相关的观测工具也存在架构开放性不足（强依赖某种技术，比如istio），引入系统底噪（skywalk引起JVM savepoint）等问题。 -- 云原生应用的运行状态更多停留在内核中，观测离不开对kernel内运行状态洞察，虽然kernel有cgroup、namespace等抽象，但与云原生应用视角依然存在GAP。 - -总结：现有云原生观测技术存在语言依赖性、底噪高、弹性能力不足、全栈观测能力不足等问题。 - -![](./png/plan-1.png) - -### 问题及解决思路 - -以云原生常见的java应用为例，常见的java应用性能问题通常要经过四个步骤完成定位。过程（归纳示例）参考如下： - -![](./png/plan-3.png) - +gala-ops支持使用Grafana图形界面用来帮助客户更好的理解性能Profiling结果，包括火焰图、时间线图两种形式。 +### 案例演示 -详细步骤介绍如下： +[精细化性能Profiling视频](https://gitee.com/openeuler/gala-docs/blob/master/demo/4.%20A-Ops%20%E6%95%B0%E6%8D%AE%E5%BA%93%E5%9C%BA%E6%99%AF%20-%20%E7%B3%BB%E7%BB%9F%E9%9A%90%E6%82%A3%E8%AF%8A%E6%96%AD%EF%BC%88%E7%81%AB%E7%84%B0%E5%9B%BE%EF%BC%89.mp4) -| 步骤 | 过程分析 | 存在问题 | 问题总结 | 解决方案 | -| :--- | ------------------------------------------------------------ | ------------------------------------------------------------ | --------------------------------- | ------------------------------------------------------------ | -| 1 | 通过APM进行集群内分布式跟踪，实现业务实例级定界（定位到某个容器实例） | 1. skywalking等传统apm存在底噪问题（影响应用吞吐量约10%）;
2. 语言强相关性。 | 底噪大，侵入式修改。 | 无侵入分布式Tracing | -| 2 | 通过perf + AsyncProfier等工具实现容器实例内性能热点抓取，定位至某业务流程。 | 1. linux 、jvm性能数据分开采集，无法统筹分析；
2. perf等工具无法细粒度采集单个容器实例性能热点数据； |缺乏全栈细粒度性能数据采集能力|**全栈细粒度性能火焰图**：低底噪、实时全栈(覆盖Linux、JVM) OnCPU、OffCPU、内存热点火焰图| -| 3 | 通过业务专家分析业务流程，辅助日志、插桩等方式定位至具体函数。 | 1. 日志、插桩等方式存在效率低的问题（需要重新出版本）；
2. 业务流程中的系统性能事件无法观测到（比如线程切换，锁操作，文件操作、网络时延等）； |缺乏业务Request级性能Profling能力|**Request级性能Profiling**：提供在线的Request级性能事件观测能力（包括文件操作、网络访问、锁操作等）| -| 4 | 如果问题是出现在底层（比如慢I/O），则依赖业务/系统专家会诊，辅助各类工具。 | 1. 依赖人力会诊，效率低；
2. 随机性故障无法追溯； |缺乏下钻式全栈观测能力|细粒度下钻式全栈观测能力：提供全栈的应用（进程/线程）粒度系统性能数据，并提供应用/系统性能瓶颈分析能力。| +# 待发布特性 -备注：2/3解决方案是gala-ops在云原生场景未来规划的特性，4属于现有特性针对云原生场景的补充增强。 +1. 系统隐患巡检 +2. K8S Pod全栈可观测及诊断 # 常见问题 @@ -741,4 +745,6 @@ Google针对云服务SLI的评估提出VALET方法，从5个维度综合评估 # 用户案例 -# 合作厂商 \ No newline at end of file +# 合作厂商 + +![](./png/partner.png) \ No newline at end of file diff --git a/png/gala-arch.png b/png/gala-arch.png new file mode 100644 index 0000000000000000000000000000000000000000..7f71718008dce4bd2c358a2af19a0b472ff04e40 Binary files /dev/null and b/png/gala-arch.png differ diff --git a/png/partner.png b/png/partner.png new file mode 100644 index 0000000000000000000000000000000000000000..28a1ec5c7254309917807e88eaf6a6a7980390e9 Binary files /dev/null and b/png/partner.png differ