Summary report - XLab-Tongji/RCAToolbox GitHub Wiki

Author: 周涵嵩

Last-modified: 2021.10.14

云平台的三种服务类型

Iaas(Infrastructure-as-a-Service):基础设施建设即服务

通过软件平台将大量硬件资源集中管理，根据用户请求按需分配存储空间、计算能力、内存大小、防火墙、操作系统、网络环境等基础设施，以满足用户需求。

即提供硬件，不包括环境配置

Paas(Platform-as-a-Service):平台即服务

把服务器平台作为一种服务提供的商业模式，通过网络进行程序提供的服务。

提供部分开发环境

Saas(Software-as-a-Service):软件即服务

厂商将应用软件统一部署在自己的服务器上，客户根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务。

提供完整应用，有网络就能用

云原生(Cloud Native)

感觉定义很宽泛，没有具体的例子

定义

  • 应用容器化
  • 面向微服务架构
  • 应用支持容器的编排调度

重定义

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

凡是能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。

设计理念

  • 面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
  • 面向配置设计（Configuration）：一个镜像，多个环境配置；
  • 面向韧性设计（Resistancy）：故障容忍和自愈；
  • 面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
  • 面向交付设计（Delivery）：自动拉起，缩短交付时间；
  • 面向性能设计（Performance）：响应式，并发和资源高效利用；
  • 面向自动化设计（Automation）：自动化的 DevOps；
  • 面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
  • 面向安全性设计（Security）：安全端点、API Gateway、端到端加密；

Kubernetes概述

简介

  • K8s是容器集群管理系统，可以实现容器集群的自动化部署、扩缩容、维护等
  • 着重于不间断的服务状态
  • 所有容器均在Pod中运行，一个Pod可以承载一个或者多个相关容器
  • 创建了一个地址空间，不动态地分配端口，为每个Pod分配IP地址
  • 所有资源如Pod都通过URI来区分，URI包括对象类型、名字、命名空间等

Kubernetes设计架构

Kubernetes节点

有运行应用容器必须的服务，每个节点上都要运行Docker来负责所有具体映像的下载和容器运行。

分层架构

  • 核心层：对外提供API构建高层的应用，对内提供插件式应用执行环境
  • 应用层：部署和路由
  • 管理层：系统度量、自动化以及策略管理
  • 接口层：kubectl命令行工具、客户端SDK以及集群联邦
  • 生态系统
  • 外部：
  • 内部：

TODO

使用Kubernetes可以

  • 多个进程（作为容器运行）协同工作
  • 存储系统挂载
  • DIstributing secrets
  • 应用健康检测
  • 应用实例的复制
  • Pod自动伸缩/扩展
  • Naming and discovering
  • 负载均衡
  • 滚动更新
  • 资源监控
  • 日志访问
  • 调试应用程序
  • 提供认证和授权

Kubernetes不是什么

K8s并不是传统的PaaS系统

大量的PaaS系统都可以运行在K8s上

Kubernetes运行在应用级别而不是硬件级，因此提供了普通PaaS平台提供的一些通用功能，如部署等

从实践的眼光来看

  • 所有云应用群策群力来解决问题
  • 盲人摸象
    • 每个应用程序只能获得它们从直接请求中调用的内核服务的状态
    • 多对一的黑盒异常诊断
    • 数据驱动的方法，重建传播过程
  • 微服务架构中服务的相关性是动态的

DyCause优点

  • 部署在app端，快速并且轻量化，没有对内核的结构或功能要求，不需前置知识
  • 新型统计算法，更深入
  • 动态因果区间检测的优化算法，更快速

SPOT(Stream Peak-Over-Threshold)算法

基于极值理论(EVT, Extreme Value Theory)检测流单变量时间序列中的异常值，该理论不需要手动设置阈值，也不对分布进行假设

EVT

EVD

TDOO

DyCause

框架

不依赖内核功能，而是通过收集user space下的API logs来建立服务相关性

分为五个模块

  • 众包指标收集 DyCause在每个应用中以API代理的方式工作，将内核API调用记录为本地日志，然后每个代理之间共享。之后，DyCause对日志进行聚合、差值成为许多1Hz的时间序列

  • 异常区间检测 在检测到异常情况的应用程序上，有义务发起一项众包诊断。

SPOT算法

代码中包含spot文件，但项目并没有引用

  • 时间动态因果关系发现 使用滑动窗口进行因果关系测试，生成一系列动态因果关系曲线。通过结合这些曲线，可以得到一个局部相关图，该图描述了内核服务如何影响应用程序以及它们如何相互影响。

  • 众包图融合 DyCause的另一个原理是联合决策。图形融合模块体现了这一思想。在此步骤中，提出诊断的应用程序将汇集其他应用程序的智慧。为此，它通过考虑其他应用程序内核的相关性并聚合它们的优势，将其相关性图与其他应用程序内核的相关性图融合在一起。

  • 回溯根因分析 通过遵循融合的相关图，DyCause执行回溯搜索以构建异常传播路径，并生成根因服务的排序列表。该列表建议应用程序和云运营商以更高的优先级调查这些服务。

众包指标收集

设计API log 储存不同的信息指标(表格的第一列，导出为data_head in main_dycause.py)

预处理阶段，把表格除data_head的部分进行聚合操作，每相邻aggre_delta个数进行求和，得到数组data (loaddata.py）

异常区间检测

从发现到传播的时间通常只有短短几分钟，针对这一特定时期使用SPOT异常检测算法进行初步检测。对于时间序列中的每个时间戳，根据极值分布(EVD)生成一个阈值，每个内核服务，其当前时间戳的度量值高于高阈值或低于低阈值，将被视为异常。（start_time_list in anomaly_detect.py）然后，在每个应用程序中，计算检测到的异常服务的数量，并在统计数据超过$\theta_{ab}N$，$\theta_{ab}\in(0,1)$ 时启动诊断，其中N是该应用程序请求的服务数量。

对anomaly_detect()中的start_time不是很理解，看代码是将所有滑动窗口的标准差列表data_std每一行进行权重阈值筛选，得到dither_proportion，然后获取排序index的最后一位，即最后一个值满足大于等于$\theta_{ab}N$的index

只考虑在这个异常间隔期间的度量（由检测到的异常时间戳的两个周期组成：长度的前一段$L_{pre}$，后一段的长度$L_{post}$）。（local_data in main_dycause.py）

时间动态因果关系发现

DyCause重点分析检测到的异常间隔期间的度量$M^{ab}(t)$。

使用滑动窗口检查Granger因果区间，为每对服务生成动态因果关系曲线$C_{i,j}(t)$。(thread_results in main_dycause.py)

动态因果关系曲线$C_{i,j}(t)$描述了从服务vi到服务vj的相关性随时间变化的强度

因果关系的动态性

  • F分布
  • Granger因果关系测试

优化动态因果关系发现

众包图融合

绘图参数太多太杂，暂时没看

回溯根因分析

  • 从应用中异常的前端服务$v_{fe}$开始向后BFS，输出候选根因列表(analyze_root()in ranknode.py)

总结

大致了解了云平台的概念，K8s的作用（理解为Docker容器统一管理平台），粗略看了论文及代码，还未阅读SPOT等引用文献