定期巡检(扁鹊)

扁鹊（定期巡检功能）

• 1 项目概述

  • 1.1 背景介绍及目标

  • 1.2 名词说明

  • 1.3 Roadmap

• 2 需求分析

  • 2.1 功能需求

  • 2.2 非功能需求

  • 2.3 调研

    • 2.3.1 zabbix

    • 2.3.2 openstack ceilometer

    • 2.3.3 小型项目（星络）

    • 2.3.4 shinken

    • 2.3.5 StackStorm

• 3 总体设计

  • 3.1 系统架构

  • 3.2 模块简介

  • 3.3 设计与折衷

    • 3.3.1 规则引擎

  • 3.4 潜在风险

• 4 详细设计

  • 4.1 模块 xx

    • 4.1.1 交互流程

    • 4.1.2 数据库设计

    • 4.1.3 接口形式

• 5 传送门

1 项目概述

1.1 背景介绍及目标

• 对管理的服务进行定期巡检，早期发现隐患

• 巡检服务与监控服务很类似

目标

• 方便添加巡检项

1.2 名词说明

1.3 Roadmap

2 需求分析

需求分析重点是需求

2.1 功能需求

2.2 非功能需求

2.3 调研

2.3.1 zabbix

trigger

{<server>:<key>.<function>(<parameter>)}<operator><constant>


{www.zabbix.com:system.cpu.load[all,avg1].last(0) }> 5
它指定的服务器是'www.zabbix.com'，Items 是'system.cpu.load[all,avg1]'，使用函数'last()'
取最近一次获取到的值，'>5'表示来自 www.zabbix.com 主机最后负载值大于 5 时触发器进入异常状态

2.3.2 openstack ceilometer

https://github.com/openstack/ceilometer

2.3.3 小型项目（星络）

基于 socket 自己封装协议，详细可以看 x-luo（星络）
    +---------------------------+
    | +---------+               |
    | |my_sender|               | alarm
    | +---------+               |
    +------|--------------------+
    +------|--------------------+
    |   +------+     +-----+    |
    |   |filter|     |saver|    |
    |   +------+     +-----+    |
    |        \        /         |  server
    |         +-------+         |
    |         |trans  |         |
    |         +-------+         |
    +---------------------------+
            ^          ^
           /            \
          /              \
    +---------------------------+
    |   +------+     +------+   |
    |   |agent1|     |agent2|   |  agent
    |   +------+     +------+   |
    +---------------------------+

只能由 agent 往 trans 进行发送数据，当监控项需要变更时，需要在 agent 侧进行变更，即监控项的管理缺失

2.3.4 shinken

2.3.4.1 shinken 架构

组件间使用 http 协议


    +--------------------------------------------------------------+
    | +----------------------+   +-------------------------------+ |
    | |Reactionner(Satellite)|   |Broker                         | |
    | |* send notifications  |   |* manage broks                 | |
    | |                      |   |* send check results to backend| |
    | +----------------------+   +-------------------------------+ |         +---------+ * Load configuration
    |                      \           /                           |  server | Arbiter | * Dispath configuration
    |                   +------------------+                       |         +---------+
    |                   |Scheduler         |                       |
    |                   | * schedule checks|                       |
    |                   +------------------+                       |
    +--------------------------------------------------------------+
                            ^          ^
             Active check  /            \ passive check
                          V              \
    +-------------------------------------------------------------+
    |   +------------------------+    +------------------------+  |
    |   |Poller(Satellite)       |    |Receiver(Satellite)     |  |  agent
    |   |* execute check commands|    |* receive passive checks|  |
    |   +------------------------+    +------------------------+  |
    +-------------------------------------------------------------+

2.3.4.2 shinken 组件

• Arbiter（仲裁）: Arbiter 节点读取本地的配置，然后将配置切分之后分发到多个合适的 schedulers 节点。

• Scheduler（调度）: scheduler 节点负责分别管理 poller 和 reactionner 节点的任务调度。

• Poller（轮询）: poller 节点通过各类插件执行 scheduler 节点的任务，获取各种健康指标。

• Reactionner（响应）: reactionner 节点的任务是一旦满足要求将触发 event_handlers 机制（比如发送通知等）。

• Broker（中间人）: broker 节点的任务真的是中间人——导出和管理 scheduler 节点中的数据。

• Receiver （接收人）: 可选节点，在某些特定场景下可以通过 reciver 节点汇总数据（比如汇总私网内部数据，统一转发）

主动监控与被动监控（对象都指的服务端）

Active  check:（主动检查）
--- Scheduler 主动发起命令给 Poller，然后 Poller 回调 Scheduler 写入数据
--- shinken.daemons.pollerdaemon:Poller


Passive check:（被动检查）
--- Receiver 主动将数据上报到 Scheduler
--- shinken.daemons.receiverdaemon.py:Receiver

Reactionner: (动作)
--- shinken.daemons.receiverdaemon.py:reactionnerdaemon.py

• 除了 Arbiter 节点之外，任何的节点都可以不是唯一的。节点之间的关系也都是多对多的。

• 每一个节点都支持 / 依赖插件，或者说 Shinken 本身只是一个插件的框架而已。

• 保障性能和可靠性——根据 CAP 法则，放弃了一致性。

2.3.4.3 shinken 代码

Satellite（shinken/satellite.py）--卫星

2.3.5 StackStorm

st2

• 主要角色

  • 传感器（Sensors）是用于分别接收或监视事件的入站或出站集成的 Python 插件。 当来自外部系统的事件发生并由传感器处理时，StackStorm 触发器将发射到系统中。

  • 触发器（Triggers）是外部事件的 StackStorm 表示形式。 有通用触发器（例如定时器，webhooks）和集成触发器（例如，Sensu 告警，JIRA 问题更新）。 通过编写传感器插件可以定义新的触发器类型。

  • 动作（Actions）是 StackStorm 出站集成。 有通用动作（ssh，REST 调用），集成（OpenStack，Docker，Puppet）或自定义操作。 动作是 Python 插件或任何脚本，通过添加几行元数据将其消耗到 StackStorm 中。 动作可以由用户通过 CLI 或 API 直接调用，或者作为规则和工作流程的一部分使用和调用。

  • 规则（Rules）将触发器映射到动作（或工作流），应用匹配条件并将触发器加载到动作输入中。

  • 工作流（Workflows）将动作拼接成“超级动作”，定义顺序，转换条件以及传递数据。 大多数自动化不止一步，因此需要多个动作。 工作流就像“原子”动作一样，可在 Action 库中使用，并且可以手动调用或由规则触发。

  • 包 (Packs) 是内容部署的单位。 它们通过对集成（触发器和动作）和自动化（规则和工作流）进行分组，简化了 StackStorm 可插拔内容的管理和共享。 StackStorm Exchange 上有越来越多的包可用。 用户可以创建自己的包，在 Github 上共享它们，或者提交给 StackStorm Exchange.

  • 审计跟踪（Audit Trail）记录并存储手动或自动操作执行的审计跟踪，并存储触发上下文和执行结果的全部细节。 它还被记录在审计日志中，用于集成外部日志记录和分析工具：LogStash，Splunk，statsd，syslog

• 大概执行流程

  • 从各个服务系统通过 push 或 pull 的方式把 event 传给 sensors， sensors 会产生一个 trigger

  • 到规则配置中查询该 trigger 对应的动作或者工作流

  • 将来自工作流的 Action 发送到消息队列（内置 rabbitmq）中

  • Actions 到达外部的系统后就执行相应的动作

  • 日志和审计历史被推送到数据库进行存储（Mongodb）

  • 处理后的结果被发送回规则引擎进行进一步处理

3 总体设计

总体设计重点是设计与折衷

3.1 系统架构

一般来说会有个简单的架构图，并配以文字对架构进行简要说明；

3.2 模块简介

架构图中如果有很多模块，需要对各个模块的功能进行简要介绍；

3.3 设计与折衷

设计与折衷是总体设计中最重要的部分；

3.3.1 规则引擎

https://github.com/zeroSteiner/rule-engine

• 需要 Python3 支持

import rule_engine
# match a literal first name and applying a regex to the email
rule = rule_engine.Rule(
    'first_name == "Luke" and email =~ ".*@rebels.org$"'
) # => <Rule text='first_name == "Luke" and email =~ ".*@rebels.org$"' >
rule.matches({
    'first_name': 'Luke', 'last_name': 'Skywalker', 'email': '[e-mail]'
}) # => True
rule.matches({
   'first_name': 'Darth', 'last_name': 'Vader', 'email': '[e-mail]'
}) # => False

import rule_engine
# define the custom context with two symbols
context = rule_engine.Context(type_resolver=rule_engine.type_resolver_from_dict({
    'first_name': rule_engine.DataType.STRING,
    'age': rule_engine.DataType.FLOAT
}))

# receive an error when an unknown symbol is used
rule = rule_engine.Rule('last_name == "Vader"', context=context)
# => SymbolResolutionError: last_name

# receive an error when an invalid operation is used
rule = rule_engine.Rule('first_name + 1', context=context)
# => EvaluationError: data type mismatch

3.4 潜在风险

4 详细设计

// 详细设计重点在“详细”

4.1 模块 xx

（有了数据库 + 接口 + 流程，别的同学拿到详设文档，基本也能够搞定了）

4.1.1 交互流程

简要的交互可用文字说明，复杂的交互建议使用流程图，交互图或其他图形进行说明

4.1.2 数据库设计

4.1.3 接口形式

5 传送门

• yzhao062/pyod --- 异常检测算法库
• redis
• graphite(Python)

• o/simmetrica
• cloud-custodian/cloud-custodian 适配了 AWS