小米 运维平台和监控

laiwei@小米

关于

laiwei 小米系统运维

微博：@来炜没睡醒

Github: @laiwei

Blog：http://thepast.me/laiwei

关注

安全

应用运维，服务管理，监控

IaaS/PaaS

引言

从小到大

从粗放到规范

小米运维平台

成长过程中的思考、实践、现状

摘要

运维平台

服务树

监控系统

部署系统

运维平台

服务树

部门

产品线

机房

公司

部门

产品线

服务

模块

分组

机房

状态

服务管理 - 服务树

筛选

想知道某个服务部署在那些机器上

“定位”

Api接口和命令行工具

反筛选

想知道某个机器上有哪些模块(标签)

“自省”

Api接口和命令行工具

权限管理

哪些人对那些机器有什么样的权限

筛选上地机房offline机器

idc.sd, status.offline

筛选米聊产品线第一个分组

pdl.miliao, grp.1

服务管理–服务树设计

标签的定义

一个有特定意义的属性，所有的标签都可以显示在树上

比如：

机房、位置、在线状态、产品线、模块……

标签的运用

机器的“状态”发生变化的时候，伴随着标签的变更

“状态”什么时候会发生变更？

人工操作

周边系统

机器到货 上架 交付线上

部署服务机器故障

idc.sd pdl.miliao mod.nginx

staus.problem

服务管理–服务树设计

公司

部门

产品线

服务

模块

分组

机房

状态

# 组合标签

cop.xiaomi owt.miliao pdl.account mod.fe grp.online

# 全局标签

idc.sd loc.bj status.problem

基于服务树的服务监控

基于服务树的监控管理

基于服务树的监控管理

一组标签的集合，构成了一个“服务”

一个服务，对应着自己的多个模板

每个模板，都是一组数据采集项和一组告警策略的集合

机器的自动加入，触发模板自动应用

问题：模板的维护依赖人工操作，后续会通过部署来解决

监控分类

常规监控

系统资源cpu，memory，disk，network等

服务的qps，latency，response_time等

Perf-counter

程序在运行过程中，内部主动反馈自身运行状态的计数器

包括exception_counter，qps，75th-percentile，访问db时间等

访问质量监控

从多点监控域名的连通性

全国大概有20个点

页面载入速度

监控数据

常规监控

10万 counter

zabbix-server主动获取数据 [proxy]

perf-counter

50万+ counter

trapper模式，批量主动推数据到zabbix-server

监控系统开发

选择

自己开发 或者 开源软件

wikipedia一个关于监控系统的列表

标准

数据采集

告警

数据展示

我们选择以zabbix为基础二次开发

部署结构

Zabbix-server

mysql中间层

Zabbix-webhost-1Zabbix-agent

host-2Zabbix-agent

host-3Zabbix-agent

host-4Zabbix-agent

Zabbix-proxy

Agent主动上报数据

Server定期拉取数据

proxy定期拉取数据

用户配置

告警策略

数据采集项等

1.数据插入

2.判断是否告警

机房2

dbpartition 1

dbpartition 2

dbpartition 3

Zabbix-api

redis

dashboard

Dashboard

每个产品线都会定制自己的dashboard

Dashboard

也可以选择查看更详细的指标

Dashboard

绘图

基于zabbix的api，方便的开发dashboard

同比，环比，求和，最大值，最小值，平均值采样

screen

多个graph展示在一个页面，构成一个screen

每个产品线自行订制多个screen，构成dashboard

提高绘图性能

后端只生成数据，前端js负责渲染 [highcharts]

[缓存]数据插入前，先插入redis

绘图时直接查询redis

Zabbix经验分享

问题

Zabbix的水平扩展较差，zabbix node模式可用性较差

每个counter上报数据都会update一次items表

database的读写基本会把io跑满

解决方案

去除外键约束 – zabbix较多的依赖于数据库的外键约束

取消zabbix的Sql合并

mysql中间层 - amoeba

拆表 – history，trends等

告警合并

告警去重

服务器维度

策略维度

多维度

滑动时间窗口

计算同策略两次连续告警时间间隔+1

最大等待时间小于61秒

监控策略A 监控策略B 监控策略C 监控策略D

服务器A 告警1

服务器B 告警2 告警5

服务器C 告警3 告警4 告警6

服务器D 告警7

服务器E 告警8

告警分级

告警分级

不同级别的告警，给予不同的关注

告警分为P0到P5六个级别

比如P0级别为影响对外服务和用户体验

App帮助更好的提醒，查看，追踪告警

QA

谢谢大家

我们的联系方式

Blog: http://noops.me

Github: @xiaomi-sa

期待你的线下交流