Pinterest 孟晓桥-一个硅谷独角兽公司监控系统的七年衍变

2020-02-27 58浏览

1.GOPS 全球运维大会2017·北京站
2.Pinterest 的监控系统孟晓桥， Pinterest监控部经理 GOPS 全球运维大会2017·北京站
3.目录 1 Pinterest公司 2 监控系统组成和衍变 3 监控，日志搜索和分布式跟踪 4 搭建监控系统的经验和下一步 GOPS 全球运维大会2017·北京站
4.世界上最大的图片探索引擎 ² 1亿9千万月活跃用户 ² 1000亿个图片收藏 ² 20亿个收藏夹 ² 每月20亿搜索 GOPS 全球运维大会2017·北京站
5.后台架构和运维后台架构运维 ²搭建在三万多台亚马逊云的虚拟机上 ²专职SRE团队负责第一线运维 ²少量亚马逊云服务 + 一百多个自开 ²少量SRE嵌入产品部门充当开发和发的微服务 + 自开发的数据存储平台运维间的桥梁 ²搜索平台 + 内容平台+ 广告平台 ²运维指标：可靠性 > 99.9% ²运维使用来自于监控组的各种实时监控系统 GOPS 全球运维大会2017·北京站
6.目录 1 Pinterest公司 2 监控系统组成和衍变 3 监控，日志搜索和分布式跟踪 4 监控系统的挑战和展望 GOPS 全球运维大会2017·北京站
7.成为⼀个10倍影响⼒⼯程师的诀窍，就是帮助10个⼯程师更好地完成他(她)们的⼯作 - 引用于互联⽹ GOPS 全球运维大会2017·北京站
8.组成基于时序数据的监控和警报 ² 实时了解所有系统和应用指标 ² 实时报警日志搜索 ² 实时了解所有重要系统输出的日志 ² 实时报警分布式跟踪系统 ² 理解用户请求对后台服务的调用 ² 标示对用户延迟影响最大的瓶颈服务 GOPS 全球运维大会2017·北京站
9.衍变从运维队伍划分出一个监控小组，开发监控工具 Graphite 收集应用程序指标 Pinterest 上线 Ganglia 收集操作系统指标日志搜索 openTSDB 时序数据数据库分布式跟踪系统 2010 2011 2012 2013 2014 2015 2016 2017 GOPS 全球运维大会2017·北京站
10.目录 1 Pinterest公司 2 监控系统组成和衍变 3 监控，日志搜索和分布式跟踪 4 搭建监控系统的经验和下一步 GOPS 全球运维大会2017·北京站
11.基于时序数据的监控系统 • 架构 • 基于Kafka和 openTSDB/Hbase。其他部分均自开发 • 规模 • 每秒250万个数据点 • 每秒3万5千个查询请求（90% 是用于报警系统）指标数据的整合和采样报警系统 openTSDB集群虚拟机 Kafka 数据查询 GOPS 全球运维大会2017·北京站
12.应用场景一：数据搜索和可视化 GOPS 全球运维大会2017·北京站
13.应用场景二：仪表板 GOPS 全球运维大会2017·北京站
14.应用场景三：警报 GOPS 全球运维大会2017·北京站
15.痛点和对策数据量大每天～100Terabyte数据可靠性要高 > 99.9% 查询速度要快打开图表的延迟在1秒内 ² 对长期数据降维，调低分辨率 ² 冷数据挪到成本低的存储上 ² 多个监控系统，交叉监控 ² 主动和被动式监控相结合 ² 多维度数据分片 ² 按数据类型 ² 按时间 ² 热数据置于内存（开发中） ² 参见Facebook的Gorilla GOPS 全球运维大会2017·北京站
16.日志搜索 • 架构 • 日志的索引，存储。其他部分均自开发 • 规模 • 每秒采集250万个数据点 • 每秒3万5千个查询请求（90% 是用于报警系统） GOPS 全球运维大会2017·北京站
17.日志的标准化 • 对每个编程语言，定制输出日志的函数库 • 统一格式为JSON • 强制输出丰富的上下文信息 GOPS 全球运维大会2017·北京站id:string // mandatory; globally unique to identify a log record. It can be a structure with timestamp.timestamp:date // mandatory; when the log records are created.service:string // uniquely identify a service which generates the log record.project:string // or organization so that we can teams can be associated withhost:string // name of the host creating the logenv:string // deployment envstage:string // deployment stageversion:string // git commit numbertags:{ } // labels consisting of key value pair assuming both key and values are strings for expansion by clients. This can include locale or organization and so on. payload_encoding:string // can be either string, JSON, base64 encoded binary format and so on. string by default payload : // mandatory
18.微服务的体系结构，怎样监测服务间的调用？ GOPS 全球运维大会2017·北京站
19.分布式跟踪系统 • 标准化的数据结构，可以描述用户请求在分布式系统中的所有事件 GOPS 全球运维大会2017·北京站
20.架构我们已经开源了后台的Spark处理逻辑: github.com/openzipkin/zipkin-sparkstreaming GOPS 全球运维大会2017·北京站
21.用途实例 • 理解服务之间的调用关系 • 已成为整个公司所有与性能有关的数据的格式标准 • 发现最影响用户请求的瓶颈服务 • 帮助发现代码里的错误。例如：同一个API被调用多次 • 建立模型来计算服务对资源消耗 GOPS 全球运维大会2017·北京站
22.服务间的调用关系 GOPS 全球运维大会2017·北京站
23.基于服务调用关系的一站式仪表板（开发中） GOPS 全球运维大会2017·北京站
24.目录 1 Pinterest公司 2 监控系统组成和衍变 3 监控，日志搜索和分布式跟踪 4 搭建监控系统的经验和下一步 GOPS 全球运维大会2017·北京站
25.最大的挑战来自工具的使用者 • 监控系统本身的产能规划困难 • 工程师对数据的读写规律难以预测 • 对策：自动阔缩，冗余产能以保障高可用性 • 90%的数据从未没读取 • 根源：冗余代码，采样率过大，非关键点的没必要的测量 • 对策：教育 • 工具新性能的推广困难 • 对策：重视用户界面设计，借用专业图表提供商的解决方案 GOPS 全球运维大会2017·北京站
26.GOPS 全球运维大会2017·北京站
27.三种监测工具，三种数据时序指标数据日志 GOPS 全球运维大会2017·北京站分布式跟踪数据
28.时序指标数据对系统总的数值化描述，一般是计数器，延迟，测量值等成本低缺乏服务间关系的描述缺乏对单一用户请求的描述 GOPS 全球运维大会2017·北京站
29.日志对单一事件，尤其是错误事件的记录事件记录里有丰富的上下文描述缺乏对服务总体和服务间关系的描述日志索引的成本较高 GOPS 全球运维大会2017·北京站
30.用户请求的跟踪数据记录每个服务API的调用把跨服务，跨设备的记录串联起来事件记录里有准确的时间信息和丰富的上下文描述对用户请求性能有影响，只能少量抽样 (例如0.1%) GOPS 全球运维大会2017·北京站
31.监控系统下一步：集成化 • 串联起三种数据类型，营造功能更强大的集成化的监控工具 • 实例： • 前端工具上，把来自于同一服务的时序指标和日志放在一起，提高查错速度 • 利用用户请求ID的独一性，串联起日志和跟踪数据，可以快速确定响应慢的用户请求的来源 • 大量监控系统提供商的共识 GOPS 全球运维大会2017·北京站时序指标数据日志分布式跟踪
32.监控系统下一步：智能化 • 运维数据的深度挖掘和智能分析 • 自动搜索关联数据以快速发现问题根源 • 智能报警系统 • 冗余警报的自动过滤 • 自我调整的阈值设定 • 警报的智能推送 GOPS 全球运维大会2017·北京站
33.会议培训咨询 • 8月18日 DevOpsDays 上海 • 全年 DevOps China 巡回沙龙 • 11月17日 DevOps金融上海 GOPS 全球运维大会2017·北京站 • EXIN DevOps Master 认证培训 • DevOps 企业内训 • DevOps 公开课 • 互联网运维培训 • 企业DevOps 实践咨询 • 企业运维咨询商务经理：刘静女士电话 / 微信：13021082989 邮箱：liujing@greatops.com
34.Thanks 高效运维社区开放运维联盟荣誉出品 GOPS 全球运维大会2017·北京站
35.想第一时间看到高效运维社区公众号的好文章吗？请打开高效运维社区公众号，点击右上角小人，如右侧所示设置就好 GOPS 全球运维大会2017·北京站