简单来说,就是如何通过如下的一些平台组合,满足运维的需求。目的:提高自动化、标准化,积累经验,减少人工投入,降低故障率。
也就是所谓的 Build, Config, Launch and Monitor the Infrastructure
。
有时候运维和监控平台的运行是一个矛盾体,如在变更时要求尽量减小对在线服务的影响,那么就要求占用资源尽量少(如网络、CPU、磁盘等);当出现故障需要处理时,
基本功能:日志审计、权限管理;高级功能:高可用、服务降级 (如OSS不可用) 。
单点登陆系统,用于记录用户登陆信息、鉴权信息、分权分域等内容。
保存了各个服务的注册信息,用于服务的自动注册和发现,其后端基于 ETCD 。
注册中心保存的是元数据信息,数据量小,一般以万计,不会超过十万或者几十万;同时提供的是高可用配置,一般会在多个Region中进行部署,提供了跨 Region 的容灾级别。
第一次启动时会连接到注册中心,并获取所依赖服务的配置信息,同时会保存到本地(默认是保存一份历史配置,可以设置保存多份),这样即使注册中心不可用,仍然可以使用本地的历史配置。
当然,这也意味着,第一次启动时必须要能连接到注册中心才可以。
后面启动时,会优先连接到注册中心,获取最新的服务,如果有配置更新,则同时会更新本地的配置文件。
服务的 API 管理,包括了访问权限管理、流量控制、监控数据等。
软件仓库,包括了系统OS、CICD部署、软件包管理等。
这里称之为 BootAgent ,用于 Agent 的安装部署、监控等,只包含了最基本的操作,倾向于小且稳定。
基础运维基础平台,用于提供统一运维工具,提供运维、变更、应急标准化流程,其难点在于如何保证数据一致性。
元数据管理,主机管理、业务拓扑、资源池管理、网络设备。【高可用】
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. 容量资源、资产管理。
提供管道服务,执行命令、文件下发、信息采集、任务调度(服务端)。【稳定】 (开源产品有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 自动扩容,可以直接根据默认获取数据。
作业管理,包括了任务下发、任务调度、并发管理、任务编排、巡检。【可降级】(Airflow)
1. 任务下发用于同时处理多台主机,建议提供【高可用】,在有其它脚本或者可替换工具时【可降级】。
2. 常见任务场景。
2.1 发布变更,服务器分组批量配置(分组规则包括版本、业务、机房等);
2.2 数据库自动备份;
2.3 大文件下发、用户管理;
2.4 巡检(账号扫描、安全扫描)。
3. 特性。超时重试、并发分组控制、密钥管理、
装机服务、软件部署,一般在安装部署时使用。【可降级】
1. 部署标准流程控制,支持蓝绿部署、A/B测试、灰度发布等部署方式。
2. 针对不同的类型配置不同的安装模板,例如HAProxy、MySQL、PostgreSQL、Nginx等。
配置管理,软件配置、主机自发现。【高可用】(Disconf)
监控平台,其目标是提高故障发现率;难点: 存储、告警;关键特性:提供可靠实时告警,故障回溯数据支撑,容量评估基础数据。
上报的指标通常用作告警设置以及数据展示;可以分为主机监控、应用监控(APM)、网络监控、公共组件监控。
按照优先级可以按照如下步骤执行:1. 主机单机监控、告警、通知;2. 组件对比、环比、APM;3. NOC(监控大屏)、故障树;4. 智能监控运维。
Collecting, processing, aggregating, and displaying real-time quantitative data about a system.
简单来说,其基本功能就是收集、处理、汇总和展示系统的实时状态数据。目的就是为了实时了解系统的状态,以保证其稳定性,简言之就是能够回答: A) What’s wrong? B) Why?
监控的核心链路是数据和告警,而难度较大的又属数据存储。监控数据是一个实时连续产生的大数据,几乎不会出现波峰波谷,要求系统有足够大的容量 (capacity)、吞吐量 (Throughput) 以及足够短的时延 (Latency)。
一个监控系统的设计通常需要参考如下的几个方面:
对于 Google 来说,其监控系统主要聚焦四大核心指标:
而 Google 对监控的建设也遵循以下原则:
Google 关于可靠性的原则之一就是 Reliability 不是由 Google 的系统监控和预警系统决定,而是由用户说了算。另外一个原则是,可靠性要达到业界的黄金标准的 99.99%,只靠完善软件本身的设计和实现是不可能达到的,必须结合优秀的 SRE 运维实践。
希望尽量以抽象的方式进行展示,而无需关心其采集方式,例如可以是脚本、StatsD、HTTP、拨测等方式。
监控指标名称分为五层,需要保持唯一,其中 namespace 用于逻辑区分,例如 system、middleware、RDS.Process 等,只用于指标的分类,并不用于上报、告警、查询等用途。
剩余四层用来定义一个指标名称,在同一台主机上,要求指标名称唯一,否则主机上报数据时可能会发生异常。详见如下:
各个层级之间通过 .
分隔,一个指标分类时允许存在两层,不允许出现 .
[
]
分隔。在解析时从后向前,首先通过 ]
判断是否存在 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 作为上下文信息,如果触发了告警则会将此信息同时发送。
监控客户端。【稳定】(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服务不可用,不会影响原有代码逻辑。
日志采集客户端。【稳定】(Logstash)
1. 基于Inotify。
告警,告警规则、告警过滤。【高可用、不降级】(Zabbix)
1. 告警规则。主机名支持前缀匹配,考虑性能不支持全文匹配;通过tag设置规则。
1.1 简单阈值判断。
1.2 移动平均处理。
2. 告警聚合。预告警信息保存,方便回溯。
2.1 迟滞处理,用于过滤掉在阈值范围内的波动情况。
2.2 多次命中,实际就是连续预告警多次后发送告警,用于过滤噪声。
注意事项:
可使用时序数据库 InfluxDB、OpenTSDB 等。
通知,邮件、SMN、手机。【高可用、不降级】
1. 通知确保可达,信息不重复,消息中间件可以采用RabbitMQ。
视图展示,主机视图、服务视图、组件视图。【可降级】
1. 视图。包括了产品树用来选择,标签页中包含了总览、视图、配置、主机视图、服务视图(调用链)、组件视图(数据库)。
1.1 总览。
1.1 主机视图,系统类的指标,包括了CPU、MEM、NET、DISK等基础监控。
1.2 服务视图,业务配置下发的脚本采集数据,也可以包含调用链(太复杂建议单独开个标签页)。
1.3 组件视图,通常是针对一些公用服务的监控,不同类型通常展示的视角也有所不同,例如HAProxy、Nginx、MySQL等。
2. DashBoard 大盘展示,包括了业务大盘(主机数、在线主机数、插件数目等)、报错大盘(最新告警)、核心指标(主站延迟)。
3. 配置中心。
1.1 插件的配置管理,主机绑定(可以允许级联)。
4. 告警中心。可以处理告警回溯、抑制等。
业务调用链,基本都是参考 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