基础平台简介

简单来说，就是如何通过如下的一些平台组合，满足运维的需求。目的：提高自动化、标准化，积累经验，减少人工投入，降低故障率。

也就是所谓的 Build, Config, Launch and Monitor the Infrastructure 。

有时候运维和监控平台的运行是一个矛盾体，如在变更时要求尽量减小对在线服务的影响，那么就要求占用资源尽量少（如网络、CPU、磁盘等）；当出现故障需要处理时，

基本功能：日志审计、权限管理；高级功能：高可用、服务降级 (如OSS不可用) 。

公共服务 Common Service

SSO

单点登陆系统，用于记录用户登陆信息、鉴权信息、分权分域等内容。

注册中心 Register Center

保存了各个服务的注册信息，用于服务的自动注册和发现，其后端基于 ETCD 。

注册中心保存的是元数据信息，数据量小，一般以万计，不会超过十万或者几十万；同时提供的是高可用配置，一般会在多个Region中进行部署，提供了跨 Region 的容灾级别。

第一次启动时会连接到注册中心，并获取所依赖服务的配置信息，同时会保存到本地(默认是保存一份历史配置，可以设置保存多份)，这样即使注册中心不可用，仍然可以使用本地的历史配置。

当然，这也意味着，第一次启动时必须要能连接到注册中心才可以。

后面启动时，会优先连接到注册中心，获取最新的服务，如果有配置更新，则同时会更新本地的配置文件。

API Gateway

服务的 API 管理，包括了访问权限管理、流量控制、监控数据等。

软件仓库 Repository

软件仓库，包括了系统OS、CICD部署、软件包管理等。

基础 Agent

这里称之为 BootAgent ，用于 Agent 的安装部署、监控等，只包含了最基本的操作，倾向于小且稳定。

基础平台 Basic Platform

基础运维基础平台，用于提供统一运维工具，提供运维、变更、应急标准化流程，其难点在于如何保证数据一致性。

CMDB +++++

元数据管理，主机管理、业务拓扑、资源池管理、网络设备。【高可用】

1. 元信息。产品、主机、IDC、网络，任务中心(IP扫描、数据同步等任务)  Region->Category->Service->Component
   1.1 主机元信息：
       主机信息。Alias、Tags、SN、采购时间、过保时间、业务分组、备注。
                 业务状态(在线、离线)、物理状态(正常、故障、下架)、保修状态(在保、过保)。
       操作系统。Hostname(主机名 uname -n)、Kernel(内核版本 uname -s + uname -r)、
                 Version(内核版本 uname -v)、Arch(内核平台 uname -m)、OperationSystem(操作系统 uname -o)
       处理器。缓存大小、物理核、逻辑核、主频、型号、厂商。
       内存。物理内存交换区。
       磁盘信息。
       网络。MAC、IP、网卡信息。
   1.2 域名信息
       URL、业务分组、主机地址、TTL、状态、备案情况、CDN类型。
   1.3 公网IP信息
       IP、服务商、业务分组、关联域名。
   1.4 网络设备
       SN、分类、主机名、业务分组。
   1.5 业务信息
       名称、类型、上线时间、资源使用数、服务依赖。

2. 提供REST-API接口供用户访问，例如当前主机的信息。

3. 任务管理。提供常见的基本任务操作，如：
   3.1 网段周期扫描，自动发现未管理主机，通常是在业务已经发展一段时间之后。
   3.2 数据采集。周期更新、校验CMDB数据，可以通过Agent采集，或者从其它服务同步。

4. 容量资源、资产管理。

Agent +++++

提供管道服务，执行命令、文件下发、信息采集、任务调度(服务端)。【稳定】 (开源产品有Ansible、SlatStack等)

1. 自管理，初始化(如通过Ansible安装、安装脚本)、自升级(通过简单稳定子程序监控)、状态、版本。
   1.1 插件管理，支持场景包括：周期执行(命令、脚本)；
   1.2 进程管理，主要是子进程的管理(监控、日志、安全、文件等)，包括启停、状态检测等；
   1.3 数据查询，提供标准查询接口，例如：磁盘、内存、内核等；
   1.4 应急处理，主要是自杀退出。

2. 特性，主要是自身的一些特性设置。
   2.1 资源限制，优先使用cgroup做资源隔离，其次周期检测；
   2.2 任务并发控制、优先级；
   2.3 特殊权限的控制，可以通过Linux中的Capability机制；
   2.4 签名机制、通讯管道密文加密；
   2.5 IP白名单，命令白名单；

3. 状态检测，支撑状态视图(含子进程状态)，一般有PING/AGENT/SUB-MODULES，其状态信息保存在缓存中，在升级时会有频繁更新。

4. 任务类型。
   4.1 命令下发。同步任务、异步任务、标准查询(类似SaltStack的Grain)。
   4.2 管理任务。自身配置管理、插件配置管理。

5. 提供统一接口查询系统信息。
   5.1 用户信息。
       A) 所用用户信息getpwent()，密码是否过期，用户是否被锁；
       B) 非系统用户信息(默认)；
       C) 指定UID/GID，用户名、分组名查询getpwuid()/getgrgid()。
   5.2 系统版本。
       A) 内核指标信息 uname()；
       B) 主机名 gethostname()。
   5.3 内存信息。A) RAM信息；B) Swap信息。
   5.4 磁盘信息。

6. 测试用例。
   6.1 资源继承，通过lsof；
   6.2 文件描述符是否泄露；
   6.3 命令执行超时、交互命令、返回内容过大、Unicode支持；
   6.4 大批量操作。

7. 高级特性。
   7.1 自动扩容，可以直接根据默认获取数据。

Task ++++

作业管理，包括了任务下发、任务调度、并发管理、任务编排、巡检。【可降级】(Airflow)

1. 任务下发用于同时处理多台主机，建议提供【高可用】，在有其它脚本或者可替换工具时【可降级】。

2. 常见任务场景。
   2.1 发布变更，服务器分组批量配置(分组规则包括版本、业务、机房等)；
   2.2 数据库自动备份；
   2.3 大文件下发、用户管理；
   2.4 巡检(账号扫描、安全扫描)。

3. 特性。超时重试、并发分组控制、密钥管理、

Deploy +++

装机服务、软件部署，一般在安装部署时使用。【可降级】

1. 部署标准流程控制，支持蓝绿部署、A/B测试、灰度发布等部署方式。
2. 针对不同的类型配置不同的安装模板，例如HAProxy、MySQL、PostgreSQL、Nginx等。

Config ++

配置管理，软件配置、主机自发现。【高可用】(Disconf)

Monitor Center

监控平台，其目标是提高故障发现率；难点: 存储、告警；关键特性：提供可靠实时告警，故障回溯数据支撑，容量评估基础数据。

上报的指标通常用作告警设置以及数据展示；可以分为主机监控、应用监控(APM)、网络监控、公共组件监控。

按照优先级可以按照如下步骤执行：1. 主机单机监控、告警、通知；2. 组件对比、环比、APM；3. NOC(监控大屏)、故障树；4. 智能监控运维。

category

简介

Collecting, processing, aggregating, and displaying real-time quantitative data about a system.

简单来说，其基本功能就是收集、处理、汇总和展示系统的实时状态数据。目的就是为了实时了解系统的状态，以保证其稳定性，简言之就是能够回答： A) What’s wrong? B) Why?

监控的核心链路是数据和告警，而难度较大的又属数据存储。监控数据是一个实时连续产生的大数据，几乎不会出现波峰波谷，要求系统有足够大的容量 (capacity)、吞吐量 (Throughput) 以及足够短的时延 (Latency)。

一个监控系统的设计通常需要参考如下的几个方面：

  • Data collecting interval and resolution 采集频率和精度
  • Data storage, as well as retention period and policy 数据存储及其保存策略
  • Alert thresholds and rules 警告筏值和规则
  • Data search and services 监控数据的查询服务
  • Data aggregation and alert noise reduction 数据聚合以及告警去噪

对于 Google 来说，其监控系统主要聚焦四大核心指标：

  • Latency 一个请求的响应时间，包括成功失败
  • Traffic 服务的繁忙度，如每秒请求数
  • Errors 服务请求失败率
  • Saturation 服务的饱和度，如CPU的使用率

而 Google 对监控的建设也遵循以下原则：

  • 保证监控系统简单明了、快速可靠。对于海量的实时数据，不建议做太复杂的实时数据分析，此时采集的数据主要回答 What’s wrong?
  • 完善的事后分析 (post-hoc analysis) 工具，用于做根因分子，用于回答 Why?

Google 关于可靠性的原则之一就是 Reliability 不是由 Google 的系统监控和预警系统决定，而是由用户说了算。另外一个原则是，可靠性要达到业界的黄金标准的 99.99%，只靠完善软件本身的设计和实现是不可能达到的，必须结合优秀的 SRE 运维实践。

指标管理

希望尽量以抽象的方式进行展示，而无需关心其采集方式，例如可以是脚本、StatsD、HTTP、拨测等方式。

监控指标名称分为五层，需要保持唯一，其中 namespace 用于逻辑区分，例如 system、middleware、RDS.Process 等，只用于指标的分类，并不用于上报、告警、查询等用途。

剩余四层用来定义一个指标名称，在同一台主机上，要求指标名称唯一，否则主机上报数据时可能会发生异常。详见如下：

  • namespace 标示业务，例如系统类(system)、中间组件 (middle)、业务。
  • category
  • subcate
  • indicator
  • instance

各个层级之间通过 . 分隔，一个指标分类时允许存在两层，不允许出现 . [ ] 分隔。在解析时从后向前，首先通过 ] 判断是否存在 instance ，然后获取 indicator ，最后判断是否存在 subcate 。

常见的示例如下。

系统类型 CPU、Memory、Disk、Load、Process
中间组件 HAProxy、MySQL、PostgreSQL、Nginx
业务数据 登录次数、UV、PV

cpu.usage[total]                  CPU使用率，其中实例标示了那个CPU，或者是总体
load.1min[abs] load.1min[avg]     系统负载，可以是平均负载或者是整体负载
net.tx[eth0]                      eth0网卡的发送字节数
process.nums[nginx]               Nginx的进程数
memory.usage                      内存使用率
mysql.innodb.cache                MySQL InnoDB存储引擎的Cache使用率
mysql.conn.running                MySQL已经建立连接数
haproxy.error.econ                发送失败数
postgre.conn.idle                 PostgreSQL空闲连接数

数据上报

注意如下仅为示例，标示了指标上报的类型，可以用不同的方式上报。

{
	"tags": "srv:EVS,idc:northeast-01,group:az1",  # 可选，全局的tag信息
	"hostname" : "your-host-name",                 # 可选，主机名，为空时会使用本地默认的主机名
	"metrics": [{
		"metric" : "disk.usage[/]",            # 详见指标名称的定义，上报时会做拆解
		"tags": "fstype:ext4",                 # 指标相关的tags信息
		"value": 50.4,
		"timestamp": `date +%s`,               # 时间戳，单位是秒
		"type": "GAUGE",                       # 数据类型
		"step": 60                             # 采集间隔，单位是秒
	}]
}

##srv=EVS,idc=northest-01,group=az1
==disk(mountpoint)
mountpoint=/,tags=fstype:ext4,usage=50.4

告警配置

告警配置信息中会带上 namespace 作为上下文信息，如果触发了告警则会将此信息同时发送。

MonitorAgent +++++

监控客户端。【稳定】(Collectd)

1. 系统监控指标上包。
   1.1 只有一个.so即可，内置types.db以及默认配置；可以通过命令行保存成配置文件。
   1.2 支持参数动态修改。
   1.3 支持插件启停。
   1.4 插件的动态加载。

2. 数据采集异常上报。

3. SuperAgent 内网拨测。Agent(Active/Inactive)、SNMP、JMX、SSH、HTTP、UDP、TCP。

4. StatsD 协议。每次只能上报一个指标，对于类似成功率无法计算。
   4.1 上报是嵌套在代码逻辑中的，通过UDP协议，即使StatsD服务不可用，不会影响原有代码逻辑。

LogAgent ++

日志采集客户端。【稳定】(Logstash)

1. 基于Inotify。

Alert +++++

告警，告警规则、告警过滤。【高可用、不降级】(Zabbix)

1. 告警规则。主机名支持前缀匹配，考虑性能不支持全文匹配；通过tag设置规则。
   1.1 简单阈值判断。
   1.2 移动平均处理。
2. 告警聚合。预告警信息保存，方便回溯。
   2.1 迟滞处理，用于过滤掉在阈值范围内的波动情况。
   2.2 多次命中，实际就是连续预告警多次后发送告警，用于过滤噪声。

注意事项：

  1. 告警只允许屏蔽一段时间，例如最大 12 小时，不允许永久屏蔽，以防止告警失效。

Storage +++++

可使用时序数据库 InfluxDB、OpenTSDB 等。

Notify +++++

通知，邮件、SMN、手机。【高可用、不降级】

1. 通知确保可达，信息不重复，消息中间件可以采用RabbitMQ。

View ++++

视图展示，主机视图、服务视图、组件视图。【可降级】

1. 视图。包括了产品树用来选择，标签页中包含了总览、视图、配置、主机视图、服务视图(调用链)、组件视图(数据库)。
   1.1 总览。
   1.1 主机视图，系统类的指标，包括了CPU、MEM、NET、DISK等基础监控。
   1.2 服务视图，业务配置下发的脚本采集数据，也可以包含调用链(太复杂建议单独开个标签页)。
   1.3 组件视图，通常是针对一些公用服务的监控，不同类型通常展示的视角也有所不同，例如HAProxy、Nginx、MySQL等。
2. DashBoard 大盘展示，包括了业务大盘(主机数、在线主机数、插件数目等)、报错大盘(最新告警)、核心指标(主站延迟)。
3. 配置中心。
   1.1 插件的配置管理，主机绑定(可以允许级联)。
4. 告警中心。可以处理告警回溯、抑制等。

APM ++

业务调用链，基本都是参考 Google 的 Dapper 论文实现，业界按照侵入性排序为 Pinpoint->Zipkin(Java)->CAT，其它的参考 Zipkin 的 Jaeger(Golang)、AppDash(GoLang)。

This Site was built by Jin Yang, generated with Jekyll, and hosted on GitHub Pages
©2013-2019 – Jin Yang