From 80951bb800d9d0fcf0fa073df7753db99e16ff7b Mon Sep 17 00:00:00 2001 From: Vchanger Date: Tue, 18 Apr 2023 20:52:08 +0800 Subject: [PATCH] Update docs --- README.md | 681 +++++++++++++++++++++--------------------------------- 1 file changed, 264 insertions(+), 417 deletions(-) diff --git a/README.md b/README.md index e8881cd..e198e1d 100644 --- a/README.md +++ b/README.md @@ -1,568 +1,415 @@ -# 背景 +# gala-gopher -​ 云场景中基础软件/业务应用之间的边界逐渐上移，基础软件逐渐成为云场景最重要的组成部分，而操作系统又最重要的基础软件之一。 -​ 从业界公开的数据看，云场景的一些重要故障均是与基础软件密切相关。公开数据显示现有主流云厂商月平均故障150+次数，75%的故障<1H，90%<1.5H，少量故障>5H。 +### 介绍 +gala-gopher一款基于eBPF技术的探针框架，通过协同各种内核观测工具（包括CPU、网络、I/O、内存等）实现将操作系统运行状态白盒化呈现，并通过扩展能力提供系统性能瓶颈分析，应用性能劣化故障诊断等特性。 -云场景的基础设施、业务场景的复杂性，导致这些故障现象大量集中基础软件（尤其是操作系统）层面，为此openEuler社区规划&孵化A-Ops项目，该项目包括基础设施监控、应用性能监控、应用安全、自动化及监控四大块功能。 +### 软件架构 +gala-gopher集成了常用的native探针以及知名中间件探针；gala-gopher有良好的扩展性，能方便的集成各种类型的探针程序，发挥社区的力量丰富探针框架的能力；gala-gopher中的几个主要部件： -![](./png/a-ops-arch.png) +- gala-gopher框架 -# 介绍 + gala-gopher的基础框架，负责配置文件解析、native探针/extend探针的管理、探针数据收集管理、探针数据上报对接、集成测试等； -​ 针对云场景的故障特点，根据故障发展阶段划分成：系统隐患、灰度故障、故障 三个阶段，A-Ops规划应用性能监控解决方案，该解决方案包括多个关键组件，本文用于介绍相关gala-ops系列组件。 +- native探针 -​ gala-ops系列组件定位：云基础设施场景中，针对基础设施**灰度故障**导致的**应用性能劣化**、卡顿系统级故障**在线诊断**。提供包括**应用性能诊断、系统性能瓶颈诊断、系统参数修复、系统实时拓扑**等特性。 + 原生探针，主要是基于linux的proc文件系统收集的系统观测指标； -# 原理 +- extend探针 -通过eBPF技术实现系统白盒化智能观测，实时在线完成系统架构拓扑化，在此基础完成从基础软硬件至应用现象的根因推导过程，且过程可视化。 + 支持shell/java/python/c等不同语言的第三方探针程序，仅需满足轻量的数据上报格式即可集成到gala-gopher框架中；方便满足各种应用场景下的观测诉求；目前已实现知名中间件程序的探针观测及指标上报，如：lvs、nginx、haproxy、dnsmasq、dnsbind、kafka、rabbitmq等； -三步骤如下： +- 部署配置文件 -![](./png/Principle.png) + gala-gopher启动配置文件，可自定义具体使能的探针、指定数据上报的对接服务信息（kafka/prometheus等） +### 快速开始 - -# 快速安装 - -## 架构 - -gala-ops是C/S架构，可以集群方式部署，也可以单机部署。整个架构由[gala-gopher](#gala-gopher)、gala-ops两个软件组成，在集群模式下，gala-gopher安装在生产节点内，gala-ops安装在管理面节点内；单机模式两者均安装在生产节点内。 - -其中，gala-ops软件内包括[gala-spider](#gala-spider)、[gala-anteater](#gala-anteater)、[gala-inference](#gala-inference)组件。 - -![](./png/csp_arch.png) - - - -## gala-gopher - -### 定位 - -- **数据采集器**：提供应用粒度low-level的数据采集，包括网络、磁盘I/O、调度、内存、安全等方面的系统指标采集，同时负责应用KPI数据的采集。数据类型包括logging、tracing、metrics。 -- **系统异常检测**：提供系统异常检测能力，覆盖网络、磁盘I/O、调度、内存等方面的场景系统异常，用户可以通过阈值设置异常上下限范围。 -- **性能热点分析**：提供CPU、内存、IO火焰图。 - -### 原理及术语 - -gala-gopher软件架构参考[这里](https://gitee.com/openeuler/gala-gopher/tree/master#%E8%BF%90%E8%A1%8C%E6%9E%B6%E6%9E%84)，其是一款基于eBPF技术的低负载探针框架，除了其自身采集的数据外，用户可以自由扩展第三方探针。 - -**术语** - -- **探针**：gala-gopher内执行具体数据采集任务的程序，包括native、extend 两类探针，前者以线程方式单独启动数据采集任务，后者以子进程方式启动数据采集任务。gala-gopher可以通过配置修改的方式启动部分或全部探针。 -- **观测实体（entity_name）**：用来定义系统内的观测对象，所有探针采集的数据均会归属到具体的某个观测实体。每种观测实体均有key、label（可选）、metrics组成，比如tcp_link观测实体的key包括进程号、IP五元组、协议族等信息，metrics则包括tx、rx、rtt等运行状态指标。除原生支持的[观测实体](#观测实体)，gala-gopher也可以扩展观测实体。 -- **数据表（table_name）**：观测实体由1张或更多数据表组合而成，通常1张数据表由1个采集任务完成，由此可知单个观测实体可以由多个采集任务共同完成。 -- **meta文件**：通过文件定义观测实体（包括内部的数据表），系统内meta文件必须保证唯一，定义不可冲突。规范参考[这里](https://gitee.com/openeuler/gala-gopher/blob/master/doc/how_to_add_probe.md#meta%E6%96%87%E4%BB%B6%E5%AE%9A%E4%B9%89%E8%A7%84%E8%8C%83)。 - -### 支持的技术 - -采集范围：参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech.md)。覆盖网络、I/O、内存、网卡、调度、Redis、kafka、Nginx等内核及基础软件的RED（Request、Error、Delay）数据观测。 - -系统异常范围：参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech_abnormal.md)。覆盖包括TCP、Socket、进程/线程、I/O、调度等超过60个系统隐患点自动巡检及上报能力。 - -### 安装及使用 - -参考[这里](https://gitee.com/openeuler/gala-gopher#%E5%BF%AB%E9%80%9F%E5%BC%80%E5%A7%8B) - -### 扩展数据采集范围 - -用户如果希望扩展数据采集范围，只需执行2步：定义观测实体，集成数据探针。 - -- **定义观测实体** - -通过定义观测实体（或者更新原观测实体）用于承载新增采集metrics数据。用户通过meta文件（参考[这里](https://gitee.com/openeuler/gala-gopher/blob/master/doc/how_to_add_probe.md#2-%E5%AE%9A%E4%B9%89meta%E6%96%87%E4%BB%B6)）定义观测实体的key、label（可选）、metrics，定义完成后，将meta文件归档在[探针目录](https://gitee.com/openeuler/gala-gopher/blob/master/doc/how_to_add_probe.md#%E5%BC%80%E5%8F%91%E8%A7%86%E5%9B%BE)。 - -- **集成数据探针** - -用户可以通过各种编程语言（shell、python、java等）包装数据采集软件，并在脚本中按照meta文件定义格式将采集到的数据通过linux管道符形式输出，参考[这里](https://gitee.com/openeuler/gala-gopher/blob/master/doc/how_to_add_probe.md#3-%E8%BE%93%E5%87%BA%E6%8E%A2%E9%92%88%E6%8C%87%E6%A0%87-1)。 - -参考[cAdvisor第三方探针集成案例](https://gitee.com/openeuler/gala-gopher/blob/master/doc/how_to_add_probe.md#%E5%A6%82%E4%BD%95%E6%96%B0%E5%A2%9Eextends%E6%8E%A2%E9%92%88)。 - - - -## gala-spider - -### 定位 - -- **拓扑图构建**：提供 OS 级别的拓扑图构建功能，它将定期获取从 gala-gopher 采集的所有观测对象实例的数据，并计算它们之间的拓扑关系，最终将生成的拓扑图保存到图数据库 arangodb 中。 - -### 原理及术语 - -参考[这里](https://gitee.com/openeuler/gala-spider/blob/master/docs/devel/zh-CN/spider_design.md)。 - -### 支持的技术 - -**支持的拓扑关系类型** - -OS 观测实体之间往往存在物理上或逻辑上的关系，比如线程和进程之间具有从属关系，进程和进程之间往往会有连接关系。因此，gala-spider 定义了一些通用的拓扑关系类型，详情参见 gala-spider 设计文档：[关系类型定义](https://gitee.com/openeuler/gala-spider/blob/master/docs/devel/zh-CN/how_to_add_new_observe_object.md#%E5%85%B3%E7%B3%BB%E7%B1%BB%E5%9E%8B%E5%AE%9A%E4%B9%89)。定义好了拓扑关系类型后，接下来就可以定义观测实体之间的拓扑关系，进而构建拓扑图。 - -**支持的实体关系列表** - -gala-spider 默认定义了一些观测实体之间的拓扑关系，这些拓扑关系是可配置和可扩展的，详情参见 gala-spider 设计文档：[支持的拓扑关系](https://gitee.com/openeuler/gala-spider/blob/master/docs/devel/zh-CN/how_to_add_new_observe_object.md#%E6%94%AF%E6%8C%81%E7%9A%84%E6%8B%93%E6%89%91%E5%85%B3%E7%B3%BB)。 - -### 安装及使用 - -参考[这里](https://gitee.com/openeuler/gala-spider/blob/master/README.md)。 - -### 扩展观测实体及关系 - -参考[这里](https://gitee.com/openeuler/gala-spider/blob/master/docs/devel/zh-CN/how_to_add_new_observe_object.md)。 - - - -## gala-anteater - -### 定位 -* **异常检测**：针对操作系统，提供分钟级别的异常检测能力，能够及时发现潜在影响客户端时延的系统级异常，辅助运维人员，快速跟踪并解决问题。 -* **异常上报**：当发现异常行为，平台能够实时上报至Kafka，运维人员只需订阅Kafka消息队列，即可了解当前系统是否潜在风险。 - - -### 原理及术语 - -gala-anteater是一款基于AI的操作系统异常检测平台。主要涵盖时序数据预处理、异常点发现、以及异常上报等功能。基于线下预训练、线上模型的增量学习与模型更新，能够很好地适应于多维多模态数据故障诊断。 - -* 基本原理 - - 通过线上线下相结合，利用**在线学习**技术，实现模型的线下学习，线上更新，并应用于线上异常检测。 - - **Offline**: 首先，利用线下历史KPI数据集，经过数据预处理、特征选择，得到训练集；然后，利用得到的训练集，对无监督神经网络模型（例如Variational Autoencoder）进行训练调优。最后，利用人工标注的测试集，选择最优模型。 - - **Online**: 将线下训练好的模型，部署到线上，然后利用线上真实的数据集，对模型进行在线训练以及参数调优，然后利用训练好的模型，进行线上环境的实时异常检测。 - - ![](./png/anteater_arch.png) - -### 安装及使用 -参考[这里](https://gitee.com/openeuler/gala-anteater/blob/master/README.md) - - - -## gala-inference - -### 定位 - -- **根因定位**：提供异常 KPI 的根因定位能力，它基于异常检测的结果和拓扑图作为输入，并将根因定位的结果输出到 kafka 中。 - -### 原理及术语 - -参考[这里](https://gitee.com/openeuler/gala-spider/blob/master/docs/devel/zh-CN/infer-design.md)。 - -### 支持的技术 - -**专家规则** - -为了提升根因定位结果的准确性和可解释性，我们对操作系统领域内观测实体之间实际存在的一些因果关系进行了分析，并总结出一些通用的专家规则，用于指导后续的根因定位算法。这些通用专家规则的详细内容参见 gala-inference 设计文档：[专家规则](https://gitee.com/openeuler/gala-spider/blob/master/docs/devel/zh-CN/infer-design.md#%E4%B8%93%E5%AE%B6%E8%A7%84%E5%88%99)。 - -### 安装及使用 - -参考[这里](https://gitee.com/openeuler/gala-spider/blob/master/README.md)。 - -## gala-ops系统集成 - -gala-ops还依赖一些开源软件，包括kafka、arangodb、prometheus等。下图介绍gala-ops系统集成关系，kafka用于传输logs/tracing类数据至ES/logstash/jaeger，prometheus用于存储Metrics数据，Arangodb用于存储实时拓扑数据，grafana用于前端页面展示。 - -![](./png/system_integration.png) - -## gala-ops系统安装 - -A-Ops提供了集成式部署工具A-Ops-Tools以便用户快速部署gala-ops以及其依赖的开源中间件，部署工具的使用约束说明与所有支持选项详细说明可参照[A-Ops-Tools部署工具手册](https://gitee.com/Vchanger/a-ops-tools#a-ops-tools)。 +#### 使用部署工具安装运行 - 获取部署工具 - 1. 下载部署工具压缩包：wget https://gitee.com/Vchanger/a-ops-tools/repository/archive/master.zip --no-check-certificate + 1. 下载部署工具压缩包：wget https://gitee.com/Vchanger/a-ops-tools/repository/archive/master.zip --no-check-certificate (内网用户需要配置代理) 2. 使用unzip解压压缩包后进入对应目录即可使用 -- 部署中间件：kafka/prometheus/arangodb/elasticsearch/logstash - - 执行如下命令安装、配置、启动kafka/prometheus/arangodb/elasticsearch/logstash服务，-K/-P/-A/-E选项支持分开使用单独部署对应组件，其中-P用于配置prometheus服务端抓取消息的来源地址（即部署gala-gopher的生产节点）列表，每个地址之间用英文逗号分隔；elasticsearch/logstash由于存在依赖关系，通过-E选项统一控制、绑定安装。 - - ``` - # sh deploy.sh middleware -K -P -E -A - ``` - -- 部署gala-ops - - gala-ops组件支持rpm、容器镜像两种部署方式，部署时需要指定kafka、prometheus、arangodb服务器地址，当不指定时，这些中间件的地址默认使用localhost。 +- 执行工具脚本进行部署 - rpm方式（仅支持openEuler 22.03 LTS/openEuler 22.03 LTS SP1) ``` - # sh deploy.sh ops -K -P -A + sh deploy.sh gopher -K ``` - 容器镜像方式： ``` - # sh deploy.sh ops -K -P -A --docker + sh deploy.sh gopher -K --docker --tag <容器镜像tag> ``` -- 部署grafana + 注:目前支持的镜像版本tag有：euleros-v2r9（仅支持x86），20.03-lts，20.03-lts-sp1，22.03-lts，22.03-lts-sp1 - 执行如下命令完成部署，grafana会以容器实例方式运行。 + 完成上述两步后gala-gopher即可进入运行状态。部署工具的使用约束说明与所有选项详细说明可参照[A-Ops-Tools部署工具手册](https://gitee.com/Vchanger/a-ops-tools#部署gala-gopher) - ``` - # sh deploy.sh grafana - ``` +#### 基于rpm包安装运行 + +- 获取rpm包 -[gala-ops部署演示视频](https://gitee.com/openeuler/gala-docs/blob/master/demo/5.%20A-Ops%E7%BB%84%E4%BB%B6%E9%83%A8%E7%BD%B2.mp4)中以openEuler 22.03 LTS版本为例演示了使用部署工具完成在生成节点上的gala-gopher以及在管理节点上的gala-ops组件部署的过程。 + gala-gopher目前已在openEuler 21.09（已停止维护）/openEuler 22.09（已停止维护）/openEuler 22.03-LTS-SP1发布，可以通过配置以上发布版本的正式repo源来获取rpm包；对于其他发布版本我们提供了以下方式来获取rpm包： -完成上述部署动作后，即可通过浏览器访问“http://[部署节点IP]:3000” 登录grafana来使用A-Ops，登录用户名、密码默认均为admin。[A-Ops 总体介绍视频](https://gitee.com/openeuler/gala-docs/blob/master/demo/0.%20A-Ops%20%E6%80%BB%E4%BD%93%E4%BB%8B%E7%BB%8D.mp4)中结合grafana前端展示页面对A-Ops整体功能进行了演示。 + - OBS 链接：网页手动下载对应架构的rpm包 -# 项目路线图 + ```basic + openEuler-20.03-LTS : https://117.78.1.88/package/show/home:zpublic:branches:openEuler:20.03:LTS:SP1/gala-gopher-20.03lts + openEuler-20.03-LTS-SP1 : https://117.78.1.88/package/show/home:zpublic:branches:openEuler:20.03:LTS:SP1/gala-gopher + EulerOS-V2R9 : https://117.78.1.88/package/show/home:zpublic:branches:openEuler:20.03:LTS:SP1/gala-gopher-v2r9 + ``` -A-Ops主要选择了8个主力场景，阶段性的落地相关解决方案。gala-ops遵从其场景规划路线图，定义自身特性落地计划，相关场景路线图及落地特性参考下图： + - 每日构建repo源：配置为yum源后安装 -![](./png/roadmap.png) + ```basic + openEuler 22.03-LTS: http://121.36.84.172/dailybuild/openEuler-22.03-LTS/openEuler-22.03-LTS/EPOL/main/ + ``` +- rpm安装 + ```bash + yum install gala-gopher + ``` -# 特性介绍 +- 运行 -## 在线应用性能诊断 + 按照[配置文件介绍](./doc/conf_introduction.md)自定义修改配置文件后，执行如下命令在前台运行： -### 特性背景 + ```bash + gala-gopher + ``` -在云环境中，应用性能受负载、资源等环境因素影响最大，这类因素无法在实验室中模拟，所以在线定位能力显得尤其重要，应用性能诊断存在两个难点：1）[无法识别应用性能劣化](#无法识别应用性能劣化)；2）[无法确定问题根因](#无法确定问题根因)。 + 或者通过 systemd 启动后台服务（推荐）： -- 无法识别应用性能劣化 + ```bash + systemctl start gala-gopher.service + ``` - 对于CSP厂商，该问题重要性不亚于问题根因定位，因为CSP厂商对外提供的服务都有SLA的承诺，主动识别云服务SLI性能劣化，对CSP厂商而言可以提前发现问题，避免客户投诉，被动运维改为主动运维。 +#### 基于容器镜像安装运行 - 我们以CSP厂商常见的DCS场景案例，介绍CSP厂商为什么难以发现云服务SLI性能劣化。 - > 分布式缓存服务（Distributed Cache Service，简称DCS）为租户提供在线分布式缓存能力，常见应用包括Redis、Memcached等，通常用于满足用户高并发及快速数据访问的业务诉求，常见使用场景包括电商、视频直播、游戏应用、社交APP等。 +- 获取容器镜像 - 当前CSP厂商常见的DCS SLI性能监控手段有2种：1）拨测方式模拟租户访问；2）DCS应用软件内性能打点； + 用户可以选择直接[获取官方容器镜像](#docker1)或自行[构建容器镜像](#docker2) - - [ ] 拨测方式模拟租户访问 + - ![](./png/DCS-1.png) + - 获取官方容器镜像 - 拨测获取的DCS的SLI与真实租户访问DCS体验的SLI实际上并不相同，其中差异包括 服务访问的网络路径、访问方式、访问频率均存在差异，这种差异导致该方式存在DCS性能监控失真问题。 + 在docker配置文件/etc/docker/daemon.json（文件不存在则需要新建）中追加如下内容来添加hub.oepkgs.net镜像仓库 - - [ ] DCS应用软件内性能打点 + ``` + { + "insecure-registries" : [ "hub.oepkgs.net" ] + } + ``` - ![](./png/DCS-2.png) + 完成后通过如下命令重启docker服务使配置生效： + + ``` + systemctl daemon-reload + systemctl restart docker + ``` + + + 根据系统架构从对应仓库拉取指定版本的gala-gopher官方容器镜像（以openEuler 20.03 LTS SP1为例）： + + ``` + # x86 + docker pull hub.oepkgs.net/a-ops/gala-gopher-x86_64:20.03-lts-sp1 + + # aarch64 + docker pull hub.oepkgs.net/a-ops/gala-gopher-aarch64:20.03-lts-sp1 + ``` + + 目前支持的镜像版本tag有：euleros-v2r9（仅支持x86），20.03-lts，20.03-lts-sp1，22.03-lts，22.03-lts-sp1 - 在DCS服务应用内（比如Redis）直接性能打点获取应用性能看上去是个不错的选择，但实际情况出乎意料，经常出现租户已经投诉DCS服务SLA未达标，但是应用层监控依然不能发现问题。分析其原因，是因为应用层的性能统计，未覆盖系统层面对应用性能影响的因素，比如TCP丢包/拥塞、网络时延、块设备I/O时延、进度调度时延等。 + -- 无法确定问题根因 - 依旧以DCS场景为例，所有CSP厂商提供的云服务都需要通过网络供租户访问，网络因素对云服务性能影响至关重要。除了网络因素，对应用影响最大包括I/O时延、调度时延、内存申请时延等。这些问题目前主要依赖OS诊断工具来实现问题的定界/定位。但是OS诊断工具存在一些问题： + - 构建容器镜像 - - [ ] 工具碎片化 + 获取gala-gopher的rpm包，获取方式详见第一小节[基于rpm包安装运行](#基于rpm包安装运行)。 - OS诊断工具七国八制，新工具层出不穷（BCC、Blktrace、iostat、netstat等），工具的使用依赖运维人员经验的判断在何时、何地、何种方式使用工具，运维效率取决于人员经验。 + 用于生成容器镜像的Dockerfile文件归档在[build目录](./build)，生成方法详见[如何生成gala-gopher容器镜像](doc/how_to_build_docker_image.md)。 - - [ ] 线上环境使用受限 +- 创建并运行容器 - 大部分OS诊断工具都无法常驻系统，依赖故障现场抓取诊断数据，面对随机性故障时，诊断工具就无从下手；另外在面临短暂性sys CPU冲高场景时，系统会出现短暂性无法登陆、命令无法执行等情况，诊断工具也会无用武之地。除此以外，还有些工具存在需额外提权、安装受限等线上环境使用的问题。 + gala-gopher涉及两个配置文件：gala-gopher.conf和gala-gopher-app.conf。gala-gopher.conf主要用于配置探针的数据上报开关、探针参数、探针是否开启等；gala-gopher-app.conf是观测白名单，可以把用户感兴趣的进程名加入白名单，gala-gopher就会观测这个进程了。 -### 解决方案 + 容器启动前需要用户自定义配置这两个配置文件，请在宿主机创建配置文件目录，并将[config目录](./config)下两个配置文件保存到该目录，示例如下： -#### 高保真采集应用性能SLI + ```shell + [root@localhost ~]# mkdir gopher_user_conf + [root@localhost gopher_user_conf]# ll + total 8.0K + -rw-r--r--. 1 root root 3.2K Jun 28 09:43 gala-gopher.conf + -rw-r--r--. 1 root root 108 Jun 27 21:45 gala-gopher-app.conf + ``` -Google针对云服务SLI的评估提出VALET方法，从5个维度综合评估应用性能。我们借鉴其思路，从吞吐量（容量）、时延2个角度评估应用性能（其他维度后续也可能会纳入评估范围）。 + 请按照[配置文件介绍](./doc/conf_introduction.md)自定义修改配置文件。在执行docker run命令时，需要将宿主机上自定义的配置文件目录和容器内/gala-gopher/user_conf目录映射，从而将自定义的配置信息同步到容器内。 -![](./png/VALET.png) + 最后按照如下示例命令启动容器： -为了提升通用性（避免语言强相关性、避免应用适配SDK修改等），[gala-gopher](#gala-gopher)提供一种相对通用的应用性能SLI采集方法，我们采取从OS内核TCP视角采集应用性能数据（即理论上该方法适用所有基于TCP的应用）。 + ```shell + docker run -d --name xxx -p 8888:8888 --privileged -v /etc/machine-id:/etc/machine-id -v /lib/modules:/lib/modules:ro -v /usr/src:/usr/src:ro -v /boot:/boot:ro -v /sys/kernel/debug:/sys/kernel/debug -v /sys/fs/bpf:/sys/fs/bpf -v /root/gopher_user_conf:/gala-gopher/user_conf/ -v /etc/localtime:/etc/localtime:ro -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/overlay2:/var/lib/docker/overlay2 --pid=host gala-gopher:1.0.1 + ``` -- TCP层采集应用时延性能 + 成功启动容器后，通过docker ps可以看到正在运行的容器： - 时延性能采集的难点在如何降低网络重传、中断时延、调度时延等因素对时延统计带来的误差影响。参考下图，[gala-gopher](#gala-gopher)会内核软中断处会记录业务Request（访问请求[3]）到来的时间戳（TS1），并在系统调用处记录应用读取业务Request的时间戳（TS2），待云服务应用Response时会执行系统调用Write（TS3），Response会产生TCP数据流并且该TCP数据流达到Request请求端后会产生TCP_ACK（TS4）。 - 通过上述四个时间戳，我们分别得到： + ```shell + [root@localhost build]# docker ps + CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES + eaxxxxxxxx02 gala-gopher:1.0.1 "/bin/sh -c 'cp -f /…" About a minute ago Up About a minute 0.0.0.0:8888->8888/tcp xxx + ``` - 应用时延性能SLI：TS4 - TS1 [1] +- 获取数据 - 应用处理时延：TS3 - TS2 [2] + 如上步骤docker run命令中所示，我们映射了宿主机8888端口和容器的8888端口，因而可以通过8888端口获取数据来验证gala-gopher是否运行成功： - 应用调度时延：TS2 - TS1 [2] + ```shell + [root@localhost build]# curl http://localhost:8888 + ... + gala_gopher_udp_que_rcv_drops{tgid="1234",s_addr="192.168.12.34",machine_id="xxxxx",hostname="eaxxxxxxxx02"} 0 1656383357000 + ... + ``` - 发送方向TCP时延：TS4 - TS3 [2] + 如上有指标数据输出则证明gala-gopher运行成功。 - 通过该方法，我们可以实现大部分应用时延性能SLI以及处理过程中不同阶段的时延（便于问题定界）。 +#### 基于源码编译、安装、运行 - ![](./png/tcp-1.png) +##### 仅编译二进制 - [^1]: openEuler 22.03 SP1版本已发布。 - [^2]: openEuler 23.09版本待发布。 - [^3]: 假设云服务应用在处理访问请求时，单个TCP连接内，是按照先进先出顺序处理。如果这个假设不成立，上述时延采集可能有误差. +​ 建议在最低openEuler-20.03-LTS-SP1的环境执行编译动作，这是因为gala-gopher中ebpf探针编译依赖clang和llvm，大多数的bpf功能需要clang 10或者更高版本才可以正常工作，而20.03-SP1以下的发布版本中clang版本较低(低于10)。 -- TCP层采集应用吞吐量性能 +如下编译安装脚本在[build目录](./build)。 - 吞吐量性能采集的难点在于识别短时吞吐量下降，比如有些场景TCP传输数据过程中出现20ms周期性的滑窗不移动现象，导致平常1~3s完成的数据传输，性能劣化至10s以上才能完成。 +- 安装依赖 - 举个形象的例子，TCP吞吐量监控犹如高速公路监控，需要持续的监控高速路上单位时间内是否存在公路资源空闲的情况，单位时间越小监控精度越高。 + 该步骤会检查安装架构感知框架所有的依赖包，涉及三方探针编译、运行的依赖包会在编译构建中检查安装。 - 这种监控的数据观测底噪、精度带来了挑战，这部分能力规划在openEuler 23.09创新版本上线。 + ```bash + # sh build.sh --check + ``` - 备注：openEuler 22.03 LTS SP1版本gala-gopher采集的应用吞吐量依然来自于应用自身而非OS系统层面。 +- 构建 -#### 基础软件low-level分析 + ```bash + # sh build.sh --clean + # sh build.sh --release # RELEASE模式 + # 或者 + # sh build.sh --debug # DEBUG模式 + ``` -根据前面介绍[问题根因](#无法确定问题根因)的定位离不开OS系统层面的观测，鉴于现有工具的局限性，[gala-gopher](#gala-gopher)定位OS系统后台服务，提供基础软件全方位的观测能力，基于eBPF技术，持续性、低底噪的方式为采集基础软件运行时数据（主要是Metrics类型数据）。所有采集的性能Metrics数据，均会携带应用（即进程/线程）标签，实现以应用视角下钻式观测系统运行状态。 + 注：在编译过程中出现如下信息，表示bpf探针编译需要的vmlinux.h文件缺失； -举例： + ![build_err](doc/pic/build_err.png) -``` - { - table_name: "tcp_abn", -- tcp 异常统计表名 - entity_name: "tcp_link", -- tcp 对象名 - fields: - ( - { - description: "id of process", - type: "key", - name: "tgid", --> tcp所属进程号 - }, - { - description: "role", - type: "key", - name: "role", --> tcp类型（客户端/服务端） - }, - { - description: "client ip", - type: "key", - name: "client_ip", --> tcp client IP - }, - { - description: "server ip", - type: "key", - name: "server_ip", --> tcp server IP - }, - { - description: "client port", --> 以下均是tcp五元组其他标签 - type: "key", - name: "client_port", - }, - { - description: "server port", - type: "key", - name: "server_port", - }, - { - description: "protocol", - type: "key", - name: "protocol", - }, - { - description: "comm", - type: "label", - name: "comm", --> tcp所属进程名 - }, - { - description: "retrans packets", - type: "gauge", - name: "retran_packets", --> 以下均是tcp异常统计Metrics - }, - { - description: "drops caused by backlog queue full", - type: "gauge", - name: "backlog_drops", - }, - { - description: "sock drop counter", - type: "gauge", - name: "sk_drops", - }, - { - description: "tcp lost counter", - type: "gauge", - name: "lost_out", - }, - { - description: "tcp sacked out counter", - type: "gauge", - name: "sacked_out", - }, - { - description: "drops caused by socket filter", - type: "gauge", - name: "filter_drops", - }, - { - description: "counter of tcp link timeout", - type: "gauge", - name: "tmout_count", - }, - ..... - ) - } -``` + ​ vmlinux.h文件包含了系统运行Linux内核源码中使用的所有类型定义，可以利用bpftool工具生成；我们已经预生成了几个openEuler发布版本的vmlinux.h文件在`src\probes\extends\ebpf.probe\src\include`目录，请根据内核版本、CPU架构选择相应的文件，并手动软链接到vmlinux.h；例如： -数据观测范围包括网络、I/O、内存、调度等，具体可以参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech.md)。 + ```shell + [root@master ~]# uname -r + 4.19.90-2012.5.0.0054.oe1.x86_64 + [root@master ~]# ln -s linux_4.19.90-2012.5.0.0053.oe1.x86_64.h vmlinux.h + ``` -![](./png/basic-analysis.png) + 生成vmlinux.h文件后再次执行编译命令。 -结合应用性能SLI、基础软件low-level数据观测，建立应用性能大模型，以前者为KPI，后者为特征量，通过gala-ops内相关组件完成线上问题分析，找到对应用性能劣化贡献值最大的特征量（即某个基础软件low-level Metrics） +- 安装 -### 案例演示 + ```bash + # sh install.sh + ``` -数据库与DCS类似，经常也会遇到I/O、网络类因素干扰，造成应用性能波动，下面我们使用openGauss作为演示案例。 +- 运行 -[应用性能诊断视频](https://gitee.com/openeuler/gala-docs/blob/master/demo/1.%20A-Ops%20%E6%95%B0%E6%8D%AE%E5%BA%93%E5%9C%BA%E6%99%AF%20-%20%E5%9C%A8%E7%BA%BF%E5%BA%94%E7%94%A8%E6%80%A7%E8%83%BD%E6%8A%96%E5%8A%A8%E8%AF%8A%E6%96%AD.mp4) + ```bash + # gala-gopher + ``` +##### 编译rpm包 -## 系统性能诊断 +​ 我们提供了OBS地址，用于用户编译最新的rpm包。当用户需要最新的rpm包时，可以按照如下步骤自行编译出最新版本的rpm包。 -### 特性背景 +- OBS路径如下： -系统性能诊断主要用于提供给系统维护SRE日常巡检，提供包括网络（TCP）、I/O等性能劣化的诊断能力。适用于随机性问题追溯，比如网络、I/O性能波动、Socket队列溢出、DNS访问失败、系统调用失败、系统调用超时、进程调度超时等等。 +```sh +EulerOS-V2R9C00 : https://117.78.1.88/package/show/home:zpublic:branches:openEuler:20.03:LTS:SP1/gala-gopher-v2r9 +openEuler-20.03-LTS : https://117.78.1.88/package/show/home:zpublic:branches:openEuler:20.03:LTS:SP1/gala-gopher-20.03lts +openEuler-20.03-LTS-SP1 : https://117.78.1.88/package/show/home:zpublic:branches:openEuler:20.03:LTS:SP1/gala-gopher +openEuler-22.03-LTS : https://117.78.1.88/package/show/home:zpublic:branches:openEuler:22.03:LTS/gala-gopher +openEuler-22.09 : https://117.78.1.88/package/show/home:zpublic:branches:openEuler:22.09:Epol/gala-gopher +``` -支持的系统性能诊断类型参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech_abnormal.md#%E7%B3%BB%E7%BB%9F%E7%BA%A7)。 +编译前需要选择对应版本的路径，并通过 `Branch package` 按钮拉出个人分支包，如下图所示： -### 解决方案 +![1667461889396](doc/pic/obs编译-branch_package.png) -系统性能诊断分两类： +> 注：branch操作仅需在第一次编包的时候执行一次，后续可以直接在 **个人已有项目** 处找到，直接执行后续的打包、上传编译等步骤。 -- 系统错误/资源不足类 +- 源码打包 - 这类问题通常是依赖一些专家经验规则、用户配置阈值来识别系统问题。 +```shell +# 需要先将gala-gopher文件夹名重命名为gala-gopher-1.0.0 +# 然后打成tar包 +[root@master code]# tar zcvf gala-gopher-1.0.0.tar.gz gala-gopher-1.0.0/ +``` - 具体支持范围如下： +- tar包上传并触发编译 - - [ ] TCP相关的异常事件：参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech_abnormal.md#tcp_link)。具体内容包括：tcp OOM、TCP丢包/重传、TCP 0窗口、TCP建链超时等。 - - [ ] Socket相关的异常事件：参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech_abnormal.md#endpoint)。具体内容包括：侦听队列溢出、Accept队列溢出、Syn队列溢出、主动/被动建链失败、SYNACK重传等。 - - [ ] 进程相关的异常事件：参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech_abnormal.md#proc)。具体内容包括：系统调用失败、DNS访问失败、iowait超时、BIO错误、调度超时等。 - - [ ] I/O相关的异常事件：参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech_abnormal.md#block)。具体内容包括：Request超时、Request错误、磁盘空间不足、inode资源不足等 + 还是以编译能够在openEuler-20.03-LTS环境运行的rpm包为例，需要在**外网操作**。参考如下视频： -- 系统性能波动类 +![obs编译-操作指南](doc/pic/obs编译-操作指南.gif) - 这类问题通常不能简单的通过一些规则、阈值来判断是否出现性能波动。所以需要通过一些AI算法来实时检测。gala-ops建立系统性能KPI以及相应的特征量，对采集到的数据进行离线训练+在线学习，实现在线异常检测，具体原理参考[这里](#gala-anteater-1)。 +​ 右侧 `Build Results` 框会显示编译结果，`building`表示还在编译中，`failed`表示编译失败，`succeeded`表示编译成功，编译成功则可以点击获取最新的rpm包。 - 系统性能波动类异常事件：参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech_abnormal.md#%E7%B3%BB%E7%BB%9F%E7%BA%A7)。具体包括 TCP建链性能波动、TCP传输时延性能波动、系统I/O时延性能波动、进程I/O时延性能波动、磁盘读写时延性能波动。 +![1667461827079](doc/pic/obs编译-获取rpm包.png) -### 案例演示 +- 安装 -[系统性能诊断视频](https://gitee.com/openeuler/gala-docs/blob/master/demo/2.%20A-Ops%20%E8%99%9A%E6%8B%9F%E5%8C%96%E5%9C%BA%E6%99%AF%20-%20%E5%9C%A8%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%80%A7%E8%83%BD%E7%93%B6%E9%A2%88%E8%AF%8A%E6%96%AD.mp4) +```shell +[root@master ~]# yum localinstall gala-gopher-1.0.0-2.oe1.x86_64.rpm +``` -### 接口介绍 +- 运行 -系统性能诊断结果也可以通过kafka topic形式对外通知，诊断结果内标识出具体的观测实体，以及异常原因。 +```shell +# 前台运行 +[root@master ~]# gala-gopher +# 通过systemd启动（推荐） +[root@master ~]# systemctl start gala-gopher.service +``` -- 样例1：主机对象内block观测实体异常： +### 运行架构 - ``` - { - "Timestamp": 1586960586000000000, // 异常事件时间戳 - "event_id": "1586xxx_xxxx" // 异常事件ID - "Attributes": { - "entity_id": "xx", // 发生异常的观测实体ID（集群内唯一） - "event_id": "1586xxx_xxxx", // 异常事件ID（同上） - "event_type": "sys", // 异常事件类型（sys: 系统异常，app：应用异常） - "data": [....], // optional - "duration": 30, // optional - "occurred count": 6,// optional - }, - "Resource": { - "metrics": "gala_gopher_block_err_code", // 产生异常的metrics - }, - "SeverityText": "WARN", // 异常级别 - "SeverityNumber": 13, // 异常级别编号 - "Body": "20200415T072306-0700 WARN Entity(xx) IO errors occured. (Block %d:%d, COMM %s, PID %u, op: %s, datalen %u, err_code %d, scsi_err %d, scsi_tmout %d)." // 异常事件描述 - } - ``` +技术特征 - 用户通过kafka订阅到异常事件后，可以表格化管理，以时间段形式呈现管理，如下： +•**统一观测标准**：支持对接prometheus、kafka、openTelemetry标准。 - | 时间 | 异常事件ID | 观测实体ID | Metrics | 描述 | - | ----------------- | ------------ | ---------- | -------------------------- | ------------------------------------------------------------ | - | 11:23:54 CST 2022 | 1586xxx_xxxx | xxx_xxxx | gala_gopher_block_err_code | 20200415T072306-0700 WARN Entity(xx) IO errors occured. (Block %d:%d, COMM %s, PID %u, op: %s, datalen %u, err_code %d, scsi_err %d, scsi_tmout %d). | +•**低底噪**：提供eBPF观测技术，通过优化eBPF运行时性能、动态装卸载等技术降低观测底噪。 +•**协同观测**：提供探针框架，根据场景协同各探针调整观测范围，避免观测碎片化。 +•**对象式**：定义（且可扩展）系统观测实体以及实体间关系，实时构建出云服务数据流拓扑。 -## 系统I/O全栈诊断 +![runtime_arch](doc/pic/coe_runtime_arch.JPG) -### 特性背景 +### 探针开发构建流程 -分布式存储（包括块存储、对象存储等）是CSP厂商提供的重要服务，常见的分布式存储服务包括EVS、OBS，几乎所有CSP厂商都有这些云服务，同时这些云服务也是其他云服务的存储后端提供者。所以分布式存储的运维效率会决定CSP厂商整个系统的运维效率。 +![devops](doc/pic/devops.JPG) -同时，分布式存储的系统构成复杂，软件来源多样性，系统集群化分布式部署，这些都给该场景的运维带来挑战。具体表现在： +### 详细介绍 -- 不同业务团队之间使用不同的诊断工具，工具之间数据缺乏衔接，运维效率低下。 -- 缺乏I/O视角集群运行状态的监控平台，集群型I/O故障诊断能力不足。 -- 缺乏历史问题追溯能力，随机性故障诊断能力不足。 +#### 开发指南 -### 解决方案 +[开发指南](doc/how_to_add_probe.md) -从I/O数据流视角实时绘制分布式存储集群拓扑图，全栈I/O视角完成对分布式存储系统的I/O数据流进行观测。 +#### 配置文件介绍 -![](./png/io.png) +[配置文件介绍](doc/conf_introduction.md) -备注： +#### eBPF探针开发指南 -1. 鉴于分布式存储系统软件来源多样性，这里使用ceph作为示例讲解，不同软件解决方案有不同的观测点。但是主要思路基本相同。 -2. openEuler 22.03 SP1发布的系统I/O全栈主要是针对ceph场景（未采用SPDK加速），其分布式存储场景会在后续update版本持续更新。 +[eBPF探针开发指南](src/probes/extends/ebpf.probe/README.md) -### 案例演示 +#### 如何实现探针编译裁剪 -[分布式存储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) +[如何实现探针编译裁剪](doc/how_to_tail_probe.md) -## 系统隐患诊断 +#### API接口文档 -### 特性背景 +[API介绍](doc/api_doc.md) -用户在日常运维过程还经常会遇到僵尸进程、内存泄漏、CPU冲高等问题，这些问题现象表现在系统层面，但是问题根因常见在应用层面。为了能够让系统运维SRE快速定界问题范围，gala-ops提供系统隐患诊断能力（隐患是指应用对系统产生的不利影响），用于监控/诊断非健康应用对系统产生的持续性、随机性的隐患，包括CPU冲高、内存泄漏（或持续增长）、I/O带宽拥塞等。 +#### 测试框架介绍 -### 解决方案 +[测试框架介绍](test/README.md) -通过eBPF + 系统perf事件高频采样系统堆栈数据，高度还原故障现场系统运行状态；也可以根据系统资源操作点Hook采样系统堆栈数据，实时还原系统资源使用情况。 +#### 负载测试 -覆盖大部分编程语言（包括C/C++、GO、Rust、java等），提供在线、持续的全栈堆栈信息采集能力。 +#### 使用示例 -![](./png/stack_trace.png) +[CDN视频直播环境部署运行架构感知](doc/example_CDN_trace.md) -- 采样负载评估：以10ms采样一次数据为例，一次采样逻辑的指令预估 1W条（ CPU 10MS 指令数量大概能够执行 1KW条指令），采样指令数量/CPU单位时间执行数量 = 1W/1KW 0.1%，所以采样负载理论上是 0.1%（每核） -- 数据存储评估：采样数据需保存一段时间用于周期性的转换成函数符号。假设采样频率10ms，转换周期1min，那么最少要保留的采样点：1min/10ms * 单次采样数据。即单核大约 6000个采样点。放大评估，单核大约1.2W个采样点。 +基于CDN简化场景部署架构感知服务做了拓扑绘制的效果演示如下。 -### 案例演示 +![系统演示](doc/pic/demo.gif) -[系统隐患诊断视频](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) +| 特性 | 发布时间 | 发布版本 | +| -------------------------------- | -------- | ------------------------------------ | +| TCP异常巡检 | 22.12 | openEuler 22.03 SP1 | +| Socket异常巡检 | 22.12 | openEuler 22.03 SP1 | +| 系统调用异常巡检 | 22.12 | openEuler 22.03 SP1 | +| 进程I/O异常巡检 | 22.12 | openEuler 22.03 SP1 | +| Block I/O异常巡检 | 22.12 | openEuler 22.03 SP1 | +| 资源泄漏异常巡检 | 22.12 | openEuler 22.03 SP1 | +| 硬件（磁盘/网卡/内存）故障巡检 | 23.09 | openEuler 22.03 SP1, openEuler 23.09 | +| JVM异常巡检 | 23.09 | openEuler 22.03 SP1, openEuler 23.09 | +| 主机网络栈（包括虚拟化）丢包巡检 | 23.09 | openEuler 22.03 SP1, openEuler 23.09 | -### 问题及解决思路 +#### 可观测性 -以云原生常见的java应用为例，常见的java应用性能问题通常要经过四个步骤完成定位。过程（归纳示例）参考如下： +| 特性 | 发布时间 | 发布版本 | +| ------------------------------------------------------------ | -------- | ------------------------------------ | +| 进程级TCP观测能力 | 22.12 | openEuler 22.03 SP1 | +| 进程级Socket观测能力 | 22.12 | openEuler 22.03 SP1 | +| 分布式存储全栈I/O观测能力 | 22.12 | openEuler 22.03 SP1 | +| 虚拟化存储I/O观测能力 | 22.12 | openEuler 22.03 SP1 | +| Block I/O观测能力 | 22.12 | openEuler 22.03 SP1 | +| 容器运行观测能力 | 22.12 | openEuler 22.03 SP1 | +| Redis性能观测能力 | 22.12 | openEuler 22.03 SP1 | +| PG性能观测能力 | 22.12 | openEuler 22.03 SP1 | +| Nginx会话观测能力 | 22.12 | openEuler 22.03 SP1 | +| Haproxy会话观测能力 | 22.12 | openEuler 22.03 SP1 | +| Kafka会话观测能力 | 22.12 | openEuler 22.03 SP1 | +| JVM性能观测能力 | 23.06 | openEuler 22.03 SP1, openEuler 23.09 | +| L7协议观测能力（HTTP1.X/MySQL/PGSQL/Redis/Kafka） | 23.09 | openEuler 22.03 SP1, openEuler 23.09 | +| L7协议观测能力（HTTP1.X/MySQL/PGSQL/Redis/Kafka/MongoDB/DNS/RocketMQ） | 24.03 | openEuler 22.03 SP3，openEuler 24.03 | +| 通用应用性能观测能力 | 24.03 | openEuler 24.03 | +| 全链路协议跟踪能力 | 24.09 | openEuler 24.09 | -![](./png/plan-3.png) +#### 性能profiling +| 特性 | 发布时间 | 发布版本 | +| --------------------------------------- | -------- | ------------------------------------ | +| 系统性能Profiling（OnCPU、Mem） | 23.03 | openEuler 23.09 | +| 系统性能Profiling（OnCPU、Mem、OffCPU） | 23.04 | openEuler 22.03 SP1, openEuler 23.09 | +| 线程级性能Profiling（java、C） | 23.06 | openEuler 22.03 SP1, openEuler 23.09 | +#### 版本兼容性 -详细步骤介绍如下： +| 特性 | 发布时间 | 发布版本 | +| --------------------------- | -------- | ------------------------------------ | +| 支持内核Release版本跨度兼容 | 23.12 | openEuler 22.03 SP3, openEuler 24.03 | +| 支持内核大版本跨度兼容 | 24.09 | openEuler 24.09 | +| | | | -| 步骤 | 过程分析 | 存在问题 | 问题总结 | 解决方案 | -| :--- | ------------------------------------------------------------ | ------------------------------------------------------------ | --------------------------------- | ------------------------------------------------------------ | -| 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属于现有特性针对云原生场景的补充增强。 +| 特性 | 发布时间 | 发布版本 | +| ------------------------------ | -------- | ------------------- | +| 非侵入集成第三方探针 | 22.12 | openEuler 22.03 SP1 | +| 非侵入集成第三方eBPF源码 | 24.03 | openEuler 23.09 | +| 大语言驱动自动生成eBPF观测探针 | 24.09 | openEuler 24.09 | -# 常见问题 -1. 生产环境采集的数据无法送至管理面？ -2. 如何新增数据采集范围？ -3. 如何新增应用场景？ -4. 支持哪些OS -5. 支持哪些内核版本 -6. 支持的软件版本范围 -7. 全栈热点分析调用栈为什么不能准确显示函数名？ +#### 部署&集成能力 -# 用户案例 +| 特性 | 发布时间 | 发布版本 | +| -------------------------------- | -------- | ------------------------------------ | +| 支持Prometheus exporter对接 | 22.12 | openEuler 22.03 SP1 | +| 支持日志文件形式对接 | 22.12 | openEuler 22.03 SP1 | +| 支持kafka client形式对接 | 22.12 | openEuler 22.03 SP1 | +| 支持REST接口动态变更探针监控能力 | 23.06 | openEuler 22.03 SP1, openEuler 23.09 | -# 合作厂商 \ No newline at end of file -- Gitee