laiwei #adc2013# #taobao adc#

Transcript

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-web host-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 期待你的线下交流