# gala-docs **Repository Path**: dowzyx/gala-docs ## Basic Information - **Project Name**: gala-docs - **Description**: Handbook and requirements documentation - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 24 - **Created**: 2022-09-13 - **Last Updated**: 2023-05-09 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 背景云场景中基础软件/业务应用之间的边界逐渐上移，基础软件逐渐成为云场景最重要的组成部分，而操作系统又最重要的基础软件之一。从业界公开的数据看，云场景的一些重要故障均是与基础软件密切相关。公开数据显示现有主流云厂商月平均故障150+次数，75%的故障<1H，90%<1.5H，少量故障>5H。云场景的基础设施、业务场景的复杂性，导致这些故障现象大量集中基础软件（尤其是操作系统）层面，为此openEuler社区规划&孵化A-Ops项目，该项目包括基础设施监控、应用性能监控、应用安全、自动化及监控四大块功能。 ![](./png/a-ops-arch.png) # 介绍针对云场景的故障特点，根据故障发展阶段划分成：系统隐患、灰度故障、故障三个阶段，A-Ops规划应用性能监控解决方案，该解决方案包括多个关键组件，本文用于介绍相关gala-ops系列组件。 gala-ops系列组件定位：云基础设施场景中，针对基础设施**灰度故障**导致的**应用性能劣化**、卡顿系统级故障**在线诊断**。提供包括**应用性能诊断、系统性能瓶颈诊断、系统参数修复、系统实时拓扑**等特性。 # 原理通过eBPF技术实现系统白盒化智能观测，实时在线完成系统架构拓扑化，在此基础完成从基础软硬件至应用现象的根因推导过程，且过程可视化。三步骤如下： ![](./png/Principle.png) # 快速安装 ## 架构 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 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 ops -K -P -A --docker ``` - 部署grafana 执行如下命令完成部署，grafana会以容器实例方式运行。 ``` # sh deploy.sh grafana ``` [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组件部署的过程。完成上述部署动作后，即可通过浏览器访问“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整体功能进行了演示。 # 项目路线图 A-Ops主要选择了8个主力场景，阶段性的落地相关解决方案。gala-ops遵从其场景规划路线图，定义自身特性落地计划，相关场景路线图及落地特性参考下图： ![](./png/roadmap.png) # 特性介绍 ## 在线应用性能诊断 ### 特性背景在云环境中，应用性能受负载、资源等环境因素影响最大，这类因素无法在实验室中模拟，所以在线定位能力显得尤其重要，应用性能诊断存在两个难点：1）[无法识别应用性能劣化](#无法识别应用性能劣化)；2）[无法确定问题根因](#无法确定问题根因)。 - 无法识别应用性能劣化对于CSP厂商，该问题重要性不亚于问题根因定位，因为CSP厂商对外提供的服务都有SLA的承诺，主动识别云服务SLI性能劣化，对CSP厂商而言可以提前发现问题，避免客户投诉，被动运维改为主动运维。我们以CSP厂商常见的DCS场景案例，介绍CSP厂商为什么难以发现云服务SLI性能劣化。 > 分布式缓存服务（Distributed Cache Service，简称DCS）为租户提供在线分布式缓存能力，常见应用包括Redis、Memcached等，通常用于满足用户高并发及快速数据访问的业务诉求，常见使用场景包括电商、视频直播、游戏应用、社交APP等。当前CSP厂商常见的DCS SLI性能监控手段有2种：1）拨测方式模拟租户访问；2）DCS应用软件内性能打点； - [ ] 拨测方式模拟租户访问 ![](./png/DCS-1.png) 拨测获取的DCS的SLI与真实租户访问DCS体验的SLI实际上并不相同，其中差异包括服务访问的网络路径、访问方式、访问频率均存在差异，这种差异导致该方式存在DCS性能监控失真问题。 - [ ] DCS应用软件内性能打点 ![](./png/DCS-2.png) 在DCS服务应用内（比如Redis）直接性能打点获取应用性能看上去是个不错的选择，但实际情况出乎意料，经常出现租户已经投诉DCS服务SLA未达标，但是应用层监控依然不能发现问题。分析其原因，是因为应用层的性能统计，未覆盖系统层面对应用性能影响的因素，比如TCP丢包/拥塞、网络时延、块设备I/O时延、进度调度时延等。 - 无法确定问题根因依旧以DCS场景为例，所有CSP厂商提供的云服务都需要通过网络供租户访问，网络因素对云服务性能影响至关重要。除了网络因素，对应用影响最大包括I/O时延、调度时延、内存申请时延等。这些问题目前主要依赖OS诊断工具来实现问题的定界/定位。但是OS诊断工具存在一些问题： - [ ] 工具碎片化 OS诊断工具七国八制，新工具层出不穷（BCC、Blktrace、iostat、netstat等），工具的使用依赖运维人员经验的判断在何时、何地、何种方式使用工具，运维效率取决于人员经验。 - [ ] 线上环境使用受限大部分OS诊断工具都无法常驻系统，依赖故障现场抓取诊断数据，面对随机性故障时，诊断工具就无从下手；另外在面临短暂性sys CPU冲高场景时，系统会出现短暂性无法登陆、命令无法执行等情况，诊断工具也会无用武之地。除此以外，还有些工具存在需额外提权、安装受限等线上环境使用的问题。 ### 解决方案 #### 高保真采集应用性能SLI Google针对云服务SLI的评估提出VALET方法，从5个维度综合评估应用性能。我们借鉴其思路，从吞吐量（容量）、时延2个角度评估应用性能（其他维度后续也可能会纳入评估范围）。 ![](./png/VALET.png) 为了提升通用性（避免语言强相关性、避免应用适配SDK修改等），[gala-gopher](#gala-gopher)提供一种相对通用的应用性能SLI采集方法，我们采取从OS内核TCP视角采集应用性能数据（即理论上该方法适用所有基于TCP的应用）。 - TCP层采集应用时延性能时延性能采集的难点在如何降低网络重传、中断时延、调度时延等因素对时延统计带来的误差影响。参考下图，[gala-gopher](#gala-gopher)会内核软中断处会记录业务Request（访问请求[3]）到来的时间戳（TS1），并在系统调用处记录应用读取业务Request的时间戳（TS2），待云服务应用Response时会执行系统调用Write（TS3），Response会产生TCP数据流并且该TCP数据流达到Request请求端后会产生TCP_ACK（TS4）。通过上述四个时间戳，我们分别得到：应用时延性能SLI：TS4 - TS1 [1] 应用处理时延：TS3 - TS2 [2] 应用调度时延：TS2 - TS1 [2] 发送方向TCP时延：TS4 - TS3 [2] 通过该方法，我们可以实现大部分应用时延性能SLI以及处理过程中不同阶段的时延（便于问题定界）。 ![](./png/tcp-1.png) [^1]: openEuler 22.03 SP1版本已发布。 [^2]: openEuler 23.09版本待发布。 [^3]: 假设云服务应用在处理访问请求时，单个TCP连接内，是按照先进先出顺序处理。如果这个假设不成立，上述时延采集可能有误差. - TCP层采集应用吞吐量性能吞吐量性能采集的难点在于识别短时吞吐量下降，比如有些场景TCP传输数据过程中出现20ms周期性的滑窗不移动现象，导致平常1~3s完成的数据传输，性能劣化至10s以上才能完成。举个形象的例子，TCP吞吐量监控犹如高速公路监控，需要持续的监控高速路上单位时间内是否存在公路资源空闲的情况，单位时间越小监控精度越高。这种监控的数据观测底噪、精度带来了挑战，这部分能力规划在openEuler 23.09创新版本上线。备注：openEuler 22.03 LTS SP1版本gala-gopher采集的应用吞吐量依然来自于应用自身而非OS系统层面。 #### 基础软件low-level分析根据前面介绍[问题根因](#无法确定问题根因)的定位离不开OS系统层面的观测，鉴于现有工具的局限性，[gala-gopher](#gala-gopher)定位OS系统后台服务，提供基础软件全方位的观测能力，基于eBPF技术，持续性、低底噪的方式为采集基础软件运行时数据（主要是Metrics类型数据）。所有采集的性能Metrics数据，均会携带应用（即进程/线程）标签，实现以应用视角下钻式观测系统运行状态。举例： ``` { 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", }, ..... ) } ``` 数据观测范围包括网络、I/O、内存、调度等，具体可以参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech.md)。 ![](./png/basic-analysis.png) 结合应用性能SLI、基础软件low-level数据观测，建立应用性能大模型，以前者为KPI，后者为特征量，通过gala-ops内相关组件完成线上问题分析，找到对应用性能劣化贡献值最大的特征量（即某个基础软件low-level Metrics） ### 案例演示数据库与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) ## 系统性能诊断 ### 特性背景系统性能诊断主要用于提供给系统维护SRE日常巡检，提供包括网络（TCP）、I/O等性能劣化的诊断能力。适用于随机性问题追溯，比如网络、I/O性能波动、Socket队列溢出、DNS访问失败、系统调用失败、系统调用超时、进程调度超时等等。支持的系统性能诊断类型参考[这里](https://gitee.com/openeuler/gala-docs/blob/master/gopher_tech_abnormal.md#%E7%B3%BB%E7%BB%9F%E7%BA%A7)。 ### 解决方案系统性能诊断分两类： - 系统错误/资源不足类这类问题通常是依赖一些专家经验规则、用户配置阈值来识别系统问题。具体支持范围如下： - [ ] 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资源不足等 - 系统性能波动类这类问题通常不能简单的通过一些规则、阈值来判断是否出现性能波动。所以需要通过一些AI算法来实时检测。gala-ops建立系统性能KPI以及相应的特征量，对采集到的数据进行离线训练+在线学习，实现在线异常检测，具体原理参考[这里](#gala-anteater-1)。系统性能波动类异常事件：参考[这里](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时延性能波动、磁盘读写时延性能波动。 ### 案例演示 [系统性能诊断视频](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) ### 接口介绍系统性能诊断结果也可以通过kafka topic形式对外通知，诊断结果内标识出具体的观测实体，以及异常原因。 - 样例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订阅到异常事件后，可以表格化管理，以时间段形式呈现管理，如下： | 时间 | 异常事件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). | ## 系统I/O全栈诊断 ### 特性背景分布式存储（包括块存储、对象存储等）是CSP厂商提供的重要服务，常见的分布式存储服务包括EVS、OBS，几乎所有CSP厂商都有这些云服务，同时这些云服务也是其他云服务的存储后端提供者。所以分布式存储的运维效率会决定CSP厂商整个系统的运维效率。同时，分布式存储的系统构成复杂，软件来源多样性，系统集群化分布式部署，这些都给该场景的运维带来挑战。具体表现在： - 不同业务团队之间使用不同的诊断工具，工具之间数据缺乏衔接，运维效率低下。 - 缺乏I/O视角集群运行状态的监控平台，集群型I/O故障诊断能力不足。 - 缺乏历史问题追溯能力，随机性故障诊断能力不足。 ### 解决方案从I/O数据流视角实时绘制分布式存储集群拓扑图，全栈I/O视角完成对分布式存储系统的I/O数据流进行观测。 ![](./png/io.png) 备注： 1. 鉴于分布式存储系统软件来源多样性，这里使用ceph作为示例讲解，不同软件解决方案有不同的观测点。但是主要思路基本相同。 2. openEuler 22.03 SP1发布的系统I/O全栈主要是针对ceph场景（未采用SPDK加速），其分布式存储场景会在后续update版本持续更新。 ### 案例演示 [分布式存储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) ## 系统隐患诊断 ### 特性背景用户在日常运维过程还经常会遇到僵尸进程、内存泄漏、CPU冲高等问题，这些问题现象表现在系统层面，但是问题根因常见在应用层面。为了能够让系统运维SRE快速定界问题范围，gala-ops提供系统隐患诊断能力（隐患是指应用对系统产生的不利影响），用于监控/诊断非健康应用对系统产生的持续性、随机性的隐患，包括CPU冲高、内存泄漏（或持续增长）、I/O带宽拥塞等。 ### 解决方案通过eBPF + 系统perf事件高频采样系统堆栈数据，高度还原故障现场系统运行状态；也可以根据系统资源操作点Hook采样系统堆栈数据，实时还原系统资源使用情况。覆盖大部分编程语言（包括C/C++、GO、Rust、java等），提供在线、持续的全栈堆栈信息采集能力。 ![](./png/stack_trace.png) - 采样负载评估：以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) 详细步骤介绍如下： | 步骤 | 过程分析 | 存在问题 | 问题总结 | 解决方案 | | :--- | ------------------------------------------------------------ | ------------------------------------------------------------ | --------------------------------- | ------------------------------------------------------------ | | 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. 如何新增数据采集范围？ 3. 如何新增应用场景？ 4. 支持哪些OS 5. 支持哪些内核版本 6. 支持的软件版本范围 7. 全栈热点分析调用栈为什么不能准确显示函数名？ # 用户案例 # 合作厂商