基础平台简介


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

也就是所谓的 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