Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
laiwei #adc2013# #taobao adc#
Search
laiwei
July 16, 2013
Technology
5
3.8k
laiwei #adc2013# #taobao adc#
xiaomi @ taobao adc 2013
laiwei
July 16, 2013
Tweet
Share
More Decks by laiwei
See All by laiwei
小米-企业安全实践
laiwei
1
5.3k
小米运维自动化
laiwei
0
5.6k
小米自动化运维实践 qcon 2014 Beijing
laiwei
2
12k
小米运维基础设施
laiwei
2
1.3k
noops in xiaomi @ Velocity 2013 beijing
laiwei
1
1.4k
Other Decks in Technology
See All in Technology
Witchcraft for Memory
pocke
1
740
FOSS4G 2025 KANSAI QGISで点群データをいろいろしてみた
kou_kita
0
380
ドメイン特化なCLIPモデルとデータセットの紹介
tattaka
2
570
20250625 Snowflake Summit 2025活用事例 レポート / Nowcast Snowflake Summit 2025 Case Study Report
kkuv
1
410
SmartNewsにおける 1000+ノード規模 K8s基盤 でのコスト最適化 – Spot・Gravitonの大規模導入への挑戦
vsanna2
0
120
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
3
6k
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
130
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
260
OPENLOGI Company Profile
hr01
0
67k
怖くない!はじめてのClaude Code
shinya337
0
360
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
410
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
270
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Practical Orchestrator
shlominoach
188
11k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Writing Fast Ruby
sferik
628
62k
Building an army of robots
kneath
306
45k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Building Adaptive Systems
keathley
43
2.6k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
950
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Code Reviewing Like a Champion
maltzj
524
40k
Transcript
小米 运维平台和监控 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-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
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 期待你的线下交流