1. 小米 运维平台和监控
laiwei@小米

2. 关于
laiwei 小米系统运维
微博：@来炜没睡醒
Github: @laiwei
Blog：http://thepast.me/laiwei
关注
安全
应用运维，服务管理，监控
IaaS/PaaS

3. 引言
从小到大
从粗放到规范
小米运维平台
成长过程中的思考、实践、现状

4. 摘要
运维平台
服务树
监控系统
部署系统

5. 运维平台

6. 服务树
部门
产品线
机房
公司
部门
产品线
服务
模块
分组
机房
状态

7. 服务管理 - 服务树
筛选
 想知道某个服务部署在那些机器上
 “定位”
 Api接口和命令行工具
反筛选
 想知道某个机器上有哪些模块(标签)
 “自省”
 Api接口和命令行工具
权限管理
 哪些人对那些机器有什么样的权限
筛选上地机房offline机器
idc.sd, status.offline
筛选米聊产品线第一个分组
pdl.miliao, grp.1

8. 服务管理–服务树设计
标签的定义
 一个有特定意义的属性，所有的标签都可以显示在树上
 比如：
 机房、位置、在线状态、产品线、模块……
标签的运用
 机器的“状态”发生变化的时候，伴随着标签的变更
 “状态”什么时候会发生变更？
 人工操作
 周边系统
机器到货 上架 交付线上
部署服务机器故障
idc.sd pdl.miliao mod.nginx
staus.problem

9. 服务管理–服务树设计
公司
部门
产品线
服务
模块
分组
机房
状态
# 组合标签
 cop.xiaomi
 owt.miliao
 pdl.account
 mod.fe
 grp.online
# 全局标签
 idc.sd
 loc.bj
 status.problem

10. 基于服务树的服务监控

11. 基于服务树的监控管理

12. 基于服务树的监控管理
一组标签的集合，构成了一个“服务”
一个服务，对应着自己的多个模板
每个模板，都是一组数据采集项和一组告警策略的集合
机器的自动加入，触发模板自动应用
问题：模板的维护依赖人工操作，后续会通过部署来解决

13. 监控分类
常规监控
系统资源cpu，memory，disk，network等
服务的qps，latency，response_time等
Perf-counter
程序在运行过程中，内部主动反馈自身运行状态的计数器
包括exception_counter，qps，75th-percentile，访问db时间等
访问质量监控
从多点监控域名的连通性
全国大概有20个点
页面载入速度

14. 监控数据
常规监控
10万 counter
zabbix-server主动获取数据 [proxy]
perf-counter
50万+ counter
trapper模式，批量主动推数据到zabbix-server

15. 监控系统开发
选择
 自己开发 或者 开源软件
 wikipedia一个关于监控系统的列表
标准
数据采集
告警
数据展示
我们选择以zabbix为基础二次开发

16. 部署结构
Zabbix-server
mysql中间层
Zabbix-webhost-1
Zabbix-agent
host-2
Zabbix-agent
host-3
Zabbix-agent
host-4
Zabbix-agent
Zabbix-proxy
Agent主动上报数据
Server定期拉取数据
proxy定期拉取数据
用户配置
告警策略
数据采集项等
1.数据插入
2.判断是否告警
机房2
db
partition 1
db
partition 2
db
partition 3
Zabbix-api
redis
dashboard

17. Dashboard
每个产品线都会定制自己的dashboard

18. Dashboard
也可以选择查看更详细的指标

19. Dashboard
绘图
基于zabbix的api，方便的开发dashboard
同比，环比，求和，最大值，最小值，平均值采样
screen
多个graph展示在一个页面，构成一个screen
每个产品线自行订制多个screen，构成dashboard
提高绘图性能
后端只生成数据，前端js负责渲染 [highcharts]
[缓存]数据插入前，先插入redis
绘图时直接查询redis

20. Zabbix经验分享
问题
Zabbix的水平扩展较差，zabbix node模式可用性较差
每个counter上报数据都会update一次items表
database的读写基本会把io跑满
解决方案
去除外键约束 – zabbix较多的依赖于数据库的外键约束
取消zabbix的Sql合并
mysql中间层 - amoeba
拆表 – history，trends等

21. 告警合并
告警去重
 服务器维度
 策略维度
 多维度
滑动时间窗口
计算同策略两次连续告警时间间隔+1
最大等待时间小于61秒
监控策略A 监控策略B 监控策略C 监控策略D
服务器A 告警1
服务器B 告警2 告警5
服务器C 告警3 告警4 告警6
服务器D 告警7
服务器E 告警8

22. 告警分级
告警分级
不同级别的告警，给予不同的关注
告警分为P0到P5六个级别
比如P0级别为影响对外服务和用户体验
App帮助更好的提醒，查看，追踪告警

23. QA
谢谢大家
我们的联系方式
Blog: http://noops.me
Github: @xiaomi-sa
期待你的线下交流