申请试用
HOT
登录
注册
 
Go如何帮滴滴支撑海量运维场景
0 点赞
0 收藏
0下载
无厘头
/
发布于
/
156
人观看

⼤纲
• 海量运维问题域是什么样的
• 为什么选择 Go
• 构筑了什么样的运维平台体系
• 如何开始体系化平台的构建

展开查看详情

1.Go如何帮滴滴支撑海量运维场景 秦晓辉

2.个⼈简介 秦晓辉 18612185520,qinxiaohui@didiglobal.com 先后履职于百度、小米、⾦⼭云,开源互联⽹监控解决⽅案 Open-Falcon主程,Nightingale开源发起⼈之⼀,现在在滴 滴负责产业云技术中⼼,推动滴滴中后台能⼒商业化输出

3.⼤纲 • 海量运维问题域是什么样的 • 为什么选择 Go • 构筑了什么样的运维平台体系 • 如何开始体系化平台的构建

4.海量运维问题域是什么样的

5.海量运维问题域 典型特点 ⼤量不同语⾔的服务 ⼤规模机器 异地多个机房 有物理机虚拟机容器多种运⾏环境 ⽹络分区多样 各类开源中间件 各类自研⼯具 各种安全要求 ⼤量不同厂商的硬件⼤量过保更迭 对接的⼈多角⾊分⼯细

6.海量运维问题域 典型问题 统⼀服务治理困难 机器环境各异 ⽹络抖动带宽争抢 不同的运⾏环境如何提供统⼀的使用体验 各种⽹络分区隔离 各类中间件、自研平台均需构建运维体系 完备的权限审计诉求 每天都有各种硬件故障 每天各种⼈追着你答疑提需求

7.海量运维问题域 典型解法 在流量转发层做⽂章 统⼀机器初始化、整包或镜像部署、静态编译 页面和流程层面统⼀,底层驱动式设计 ⽹络分区代理、防⽕墙友好设计 运维体系是平台核⼼+扩展共建的思路 统⼀权限、统⼀日志、统⼀审计 让业务能漂起来不依赖底层硬件 自动化⼯单、知识库构建、答疑机器⼈ 能统⼀的统⼀、能规范的规范、再不济就是统⼀核⼼+周边扩展;分层⼤法;⼯具⽂化

8.为什么选择 Go

9.为什么选择 Go Go 自身特点 Go 周边⽣态 资源占用少,适合开发agent 并发元语⽅便 静态编译依赖少 上⼿简单、风格统⼀

10.构筑了什么样的运维平台体系

11.运维平台体系构筑⽅向 稳定性体系建设 变更体系建设 效率体系建设 成本体系建设 安全体系建设

12. 稳定性体系建设 构建⽅向 标准 规范 落地 ⼿段 评价 体系

13.稳定性体系建设 相关平台⼯具举例 风险 预防 量化 监控健康分 预案健康分 变更信用分 数据库信用分 监控 发现 报警 业务监控 应用监控 服务监控 基础设施监控 故障 定位 下钻 全局灭⽕图 事件墙 容量⽔位 接⼊层⼤盘 预案 ⽌损 故障自愈 911预案平台 域名切流 变更回滚 管理 问题 复盘 跟进 可用性统计 遗留项管理 故障原因统计 红⿊榜单

14.变更体系建设 构建⽅向和平台⼯具举例 环境管理 编译打包 变更发布 服务治理 流量接⼊ 状态监控 装机带外管 编译构建 服务部署 名字服务 四层接⼊ 指标采集 理 堡垒机跳板 代码检测 配置管理 统⼀框架 七层接⼊ 日志采集 机权限分配 机器初始化 ⼯作流管理 数据配送 调用链追踪 域名管理 告警策略 制品镜像库 编排调度 限流熔断 应用防⽕墙 监控⼤盘

15. 效率体系建设 构建⽅向 日常⼯作平台化 如果还是找不到⽅向 重复⼯作自动化 问⼀下自⼰如下问题 • 固化的问题自动排查 • 哪些⼯作比较多? • 固化的预案自动执⾏ • 哪些⼯作比较痛? • 需求类⼯作自助执⾏ • 哪些⼯作可以做个平台让自⼰更快的完成? • 巡检类⼯作周期执⾏ • 哪些⼯作可以做个平台让需求⽅自助完成? • ⼯作流自动执⾏环节 • 哪些⼯作可以固化为脚本让上游自动触发?

16.效率体系建设 相关平台⼯具举例 ChatOps(各类聊天机器⼈) 知识库(有⼈⼀年写2000多篇wiki) 专 业 接 客 运维准⼊ 软件安装 接⼊层变更 服务下线 区 服务器重装 服务器改名 域名申请 出⽹申请 自 监控告警相关 服务治理相关 PaaS类资源操作:数据库、MQ、NoSQL 助 区 日志查询分析 变更发布相关 IaaS类资源操作:虚机、云盘、对象存储 基 命令通道 ⽂件分发 定时任务 任务⼯作流 座

17.如何开始体系化平台的构建

18.为你的运维平台化之路开个头

19.滴滴夜莺简介 Github地址:https://github.com/didi/nightingale Nightingale(滴滴夜莺),衍⽣自Open-Falcon,融⼊了滴滴的最佳实践, 如今是v3版本,已经从⼀款运维监控系统,演化为⼀款运维平台,除了具 备监控告警的能⼒,也融⼊了部分CMDB、资产管理、命令执⾏、告警自 愈的能⼒。运维平台体系化之路,可以用夜莺开个头 :-)

20.

21.

22.

23.

24.夜莺当前产品能⼒ 运维⼯单系统 变更管理 稳定性体系 其他⽅向 机器环境初始化 应用打包编译 监控告警系统 故障定位系统 备份恢复系统 应用变更发布 日常维护类操作 预案管理系统 故障跟踪系统 成本管理系统 配置管理 资产管理 运维安全体系 组织元信息 资源元信息 主机设备 ⽹络设备 容量⽔位系统 权限元信息 服务元信息 机柜机架位 配件耗材 ⽹络访问质量 统⼀底座:统⼀框架、统⼀用户、统⼀角⾊、统⼀审计 下划线部分是当前夜莺已经具备的能⼒

25.夜莺系统架构

26.夜莺与Open-Falcon的对比 对比项 Open-Falcon Nightingale • 部分模块存在单点问题,比如告警模块 • 所有模块全部⾼可用,挂掉⼀台机器服务⽆影响 • 使用数据库存储索引⽆法应对海量索引情况 • 自研索引或采用M3DB⽅案可以应对海量索引 架构 • 只有rrd⼀种落盘存储机制,扩展能⼒较弱 • 使用驱动式设计,支持多种后端存储:M3、RRD、InfluxDB • 是个纯粹的监控,体系化考虑较少,缺少完备的 • 体系化程度⾼,以监控告警为核⼼主打能⼒,围绕着建立了部 用户权限体系、资产管理、运维自动化、告警自 分CMDB能⼒、完备的用户权限体系、命令通道和告警自愈等 体系化 愈等 • 整体设计较为简单,除了模板继承机制稍难理解, • 单就监控⽅面易用性更好⼀些,但是因为功能模块较多,学习 整体容易上⼿ 起来确实有⼀定成本 易用性 • 只有RRD⼀种落盘存储机制,存储⽅面扩展能⼒ • 使用驱动式设计,支持多种后端存储:M3、RRD、InfluxDB 较弱 • 可以复用Open-Falcon社区采集插件和Prometheus社区各类 扩展性 • 社区贡献了部分监控采集插件,囊括各类常见对 Exporter,也提供Java、Go的埋点SDK,内置日志监控能⼒ 象的监控采集

27. 夜莺与Zabbix的对比 对比项 Zabbix Nightingale • 基于数据库来存储时序数据,容量上限较为明 • 使用驱动式设计,支持多种后端存储:M3、RRD、InfluxDB, 显,TimescaleDB有待⽣产验证;拉取监控数据 ⽣产环境建议M3DB;近期数据在内存拉取监控数据比较快 架构 也比较慢 • 是个纯粹的监控,如果要做CMDB、运维自动化 • 体系化程度⾼,以监控告警为核⼼主打能⼒,围绕着建立了部 相关支持,就需要和其他产品搭配使用了 分CMDB能⼒、完备的用户权限体系、命令通道和告警自愈等 体系化 • 对各类设备的监控支持较好,甚⾄AIX、BSD等 • 设备层面支持常规Linux、Windows、交换机、容器的监控 都有支持 • 对应用业务侧监控支持较好,提供日志提取⽅式和SDK⽅式 监控能⼒ • 对应用业务侧监控支持较差,主要是受限于数据 结构 • 服务端和客户端采用C语⾔,研发⼈员较为难招 • 全部使用Go语⾔开发,和Kubernetes、Prometheus⼀个语⾔, • WEB端采用PHP语⾔,没啥说的,毕竟,这是世 单语⾔系统⼆开难度小⼀些 ⼆开难度 界上最好的语⾔

28. 夜莺与Prometheus的对比 对比项 Prometheus Nightingale • 设计上偏⼯具⼀些,采集策略、告警策略都是 • 产品化程度更⾼⼀些,所有操作都可以通过页面完成,使用复 编辑yaml⽂件,对于多⼈同时使用的场景不够 杂度上相对简单⼀些 易用性 友好 • 与Kubernetes结合紧密,比较容易采集容器相关 • 可以采集容器相关指标,对Kubernetes自身组件,需要借助监 指标,比较容易制作集群监控⼤盘 控插件实现采集,略微麻烦 容器监控 • 对传统物理机、虚机的监控管理不够友好,特别 • 特别适合传统物理机、虚机的监控,树状机器分组机制非常灵 是服务混部情况下,缺少易用的机器分组机制 活,直观易用 设备监控 • 是⼀个纯粹的监控告警系统,不处理其他运维场 • 体系化程度⾼,以监控告警为核⼼主打能⼒,围绕着建立了部 景 分CMDB能⼒、完备的用户权限体系、命令通道和告警自愈等 体系化

29.夜莺用户案例

0 点赞
0 收藏
0下载