2 刘征 elastic 破解云原生应用的可观测性

2020-03-01 413浏览

  • 1.分层次构建应⽤用系统的可观测性 刘征 2019-9, 社区布道师, elastic, @martinliu
  • 2.关于我 刘征，elastic 社区布道师 Ops背景 云计算 ⼯具链 中国DevOps社区组织者 译者： • DevOps Handbook • The Reliability Workbook 【翻译中】 2
  • 3.关于Elasticsearch项⽬目 创始⼈人/CEO Shay Banon • ⼀一位码农带着妻⼦子去伦敦打⼯工，妻⼦子想从事厨师 ⼯工作，他⽤用Lucene开发⻝⾷食谱 • 他对Lucene封装后，发布了了⾸首个开源项⽬目 Compass • 找到⼀一份和⾼高性能分布式系统相关的⼯工作，激发 他编写⼀一个实时、分布式搜索引擎 • 后来Compass重命名为Elasticsearch，成为 Github上的⽕火热项⽬目 • 许可证有开源Apache2.0、商业两种 3
  • 4.议程 破解云原⽣生应⽤用的可观测性 4 1 云原⽣生应⽤用的主要特征，它在系统可运维⽅方⾯面的挑战 2 可观测性的定义和本质，这是新⽣生事物还是⽼老老⽣生常谈 3 分层次的构建云原⽣生应⽤用系统的可观测性，⽤用四步法破解这个难题 4 构建可观测性的难点和挑战，准备的越充分，就能⾛走的越远 5 演示，Q&A
  • 5.云原⽣生应⽤用的三个特点 应⽤用架构 5 基础设施 ⽣生命周期 • 从单体应⽤用向微服务过渡 • 容器器化、应⽤用⾃自身快、轻、微 • DevOps流⽔水线持续部署 • 应⽤用架构过渡为松耦合系统 • Kubernetes成为默认的平台 • 服务变更更低成本和低⻛风险 • 应⽤用版本迭代更更快、周期更更短 • IaaS、PaaS和CaaS平台底层 • 呈现⾼高频率和全⾃自动变更更
  • 6.Monolith at scale 互联⽹网应⽤用 基于延迟的路路由 多区部署 负载均衡 多应⽤用副本 ⾃自动扩容 数据库读写分离副本 6
  • 7.服务间通讯 Micro service at Scale Wheel of Doom This diagram, taken from late 2014, illustrates the interactions between services running on Hailo’s platform. 7
  • 8.微服务应⽤用和传统单体的对⽐比 在重要运维事件⽅方⾯面的差异 8 运维部署的复杂度 扩展性 回滚/故障隔离 服务期限承诺 必须借助⾃自动化配置管理理 ⼯工具和Docker 速度更更快、按需扩展 更更快、更更⽅方便便 服务周期短 更更⾼高的复杂度 更更⾼高的资源利利⽤用率 实现更更好的故障隔离 船⼩小好调头 正常⽔水平 复制整个虚拟机或技术栈 速度慢 速度慢、难度⼤大 成本⾼高、⻛风险⾼高 周期⻓长、不不靠谱 没有回头路路、⽆无后悔悔药
  • 9.Rethink Service Monitoring
  • 10.议程 破解云原⽣生应⽤用的可观测性 10 1 云原⽣生应⽤用的主要特征，它在服务监控⽅方⾯面的挑战 2 可观测性是新⽣生事物还是⽼老老⽣生常谈，它的真实本质 3 分层次的构建云原⽣生应⽤用系统的可观测性，⽤用四步法破解这个难题 4 构建可观测性的难点和挑战，准备的越充分，就能⾛走的越远 5 演示，Q&A
  • 11.应⽤用部署到⽣生产 环境只是刚刚开 始。 11
  • 12.天下没有不不宕机 的系统，时刻做 好恢复系统的准 备。 12
  • 13.如果系统是分布 式的，那么它的 故障也可能在哪 ⾥里里都存在。 13
  • 14.Baron SchSchwarz CTO of VividCortex 14 监控告诉我们系统的那 些部分是⼯工作的。可观 测性告诉我们那⾥里里为何 不不⼯工作了了。
  • 15.监控和可观测性之间的关系 从上往下是逐层递进的现象和原因 告警 Alerting 概况 Overview 排错 Debugging 信号总量量 剖析 Profilling 依赖分析 dependency 15 监控 Monitoring Ops 可观测性 Observability Dev
  • 16.可观测性的三根⽀支柱 16 Log Metric Tracing ⽇日志 指标 应⽤用追踪
  • 17.议程 破解云原⽣生应⽤用的可观测性 17 1 云原⽣生应⽤用的主要特征，它在系统可运维⽅方⾯面的挑战 2 可观测性的定义和本质，这是新⽣生事物还是⽼老老⽣生常谈 3 分层构建云原⽣生应⽤用系统的可观测性，四步法破解难题 4 构建可观测性的难点和挑战，准备的越充分，就能⾛走的越远 5 演示，Q&A
  • 18.分层级构建可观测性 适⽤用于云原⽣生应⽤用的可观测性建设四步法 18 0 1 2 3 健康检查 指标 ⽇日志 应⽤用追踪
  • 19.提供服务运⾏行行状态的红绿灯系统 Level 0 : 健康检查 是否在运⾏行行中？ 能处理理更更多⼯工作量量么？ 能处理理它的⼯工作么？ 19
  • 20.实施健康检查的三种模式 Level 0 : 健康检查 ⼴广播 注册表 暴暴露露 • 将状态信息封包 • 服务的ip/域名的端⼝口信息 • 利利⽤用服务默认的服务端⼝口 • 发送到⽹网络上 • 写⼊入/更更新到etcd或Zk • 编写应⽤用特有的健康服务 • 更更新⾃自⼰己和邻居的状态 • 最新服务清单 • 等待外部⼯工具的轮询
  • 21.实施向外暴暴露露健康状态的接⼝口 Level 0 ：健康检查 21
  • 22.⽤用Heatbeat实施健康检查的系统架构 Level 0 ：健康检查 22 1 部署Heatbeat采集点 2 配置也运⾏行行每⼀一个采集点 3 加载集中分析仪表板 4 定义告警规则
  • 23.Elastic Heatbeat监控服务健康检查的效果 Level 0 : 健康检查 可能的问题和挑战 • 定义何谓健康？ • 扫描互相依赖的复杂系统 并不不⼀一定能识别出问题？ • 过度的检查导致资源浪 费，甚⾄至DDos⾃自⼰己！
  • 24.指标是在许多个连续的时间周期⾥里里度量量的KPI数值 Level 1：指标 07/Jan/2019 16:10:00 all 2.58 0.00 0.70 1.12 0.05 95.55 server1 containerX regionA 07/Jan/2019 16:20:00 all 2.56 0.00 0.69 1.05 0.04 95.66 server2 containerY regionB 07/Jan/2019 16:30:00 all 2.64 0.00 0.65 1.15 0.05 95.50 server2 containerZ regionC 在每10分钟⾥里里，度量量CPU load指标，显示这个数值，并附加相关的元数据 24
  • 25.监控指标的三种来源/类型 Level 1：指标 1 2 3 系统指标 应⽤用指标 业务指标 • CPU使⽤用率 • 磁盘使⽤用率 • ⽹网络带宽 25 • 出错率 • 延迟 • 饱和度 • ⽤用户会话 • 订单数量量 • 营业额
  • 26.实施指标监控的部署模式 Level 1：指标 监控对象 业务服务 应⽤用/Infra 服务器器/vm 26 采集点/代理理 集中处理理 展示/告警 /metrics Agent /metrics Agent /metrics 指标采 指标查 集器器 询引擎 仪表板 告警引擎
  • 27.实施指标监控的部署模式 Level 1：指标 监控对象 27 采集点/代理理 业务服务 /metrics 应⽤用/Infra /metrics 服务器器/vm /metrics 集中处理理 展示/告警
  • 28.谨防对指标的过度依赖，它的挑战和不不⾜足 Level 1：指标 28 现实的情况 局限性和挑战 不不是每⼀一个指标都值得告警 缺乏针对影响⽤用户端征兆的告警 每个信息点的维度有限 对细粒度排错帮助有限，例例如：缺少CustomerID 实时查询意味着数据⽆无法⻓长期保留留 实时的短期数据查询和⻓长期的趋势分析之间存在⽭矛盾 传统的静态阈值管理理正在失效 业务⾼高峰期的最低阈值⼤大于平时最⾼高值， 动态基线和可能性预测功能匮乏 数据的聚合、统计、分析和展示花费⼤大量量成本 需要耗费⼀一定开发⼈人⼒力力成本， 运算消耗⼤大量量时间和存储空间成本
  • 29.⼀一种优化的指标监控部署模式 Level 1：指标 监控对象 代理理 业务服务 Beat 应⽤用/Infra Beat 服务器器/vm Beat 集中处理理 Logstash Kibana Elasticsearch + 机器器学习 Beat 29 展示/告警 发送告警
  • 30.破局指标监控窘境的可能性 Level 1 : 指标 局限性和挑战 需要的能⼒力力和⼯工具 缺乏针对影响⽤用户端征兆的告警 参考SRE的⽅方法，定义基于SLO的告警 梳理理有价值的指标与SLI的对应关系 对细粒度排错帮助有限，例例如：缺少 CustomerID 在指标数据⽣生成的地⽅方/监控代理理上，或者指标发送到集中存储的中转站 ⾥里里丰富元数据，beats和logstash可⽅方便便的增加必要的键值型指标元数据 实时的短期数据查询和⻓长期的趋势分析之 将冷热和密度不不同的指标数据放置在不不同存储集群上进⾏行行统⼀一查询和数据 间存在⽭矛盾 管理理，elasticsearch可以设计实施温热数据架构，⽀支持多集群查询 业务⾼高峰期的最低阈值⼤大于平时最⾼高值， 对关照的监控指标进⾏行行动态基线管理理，Elastic Stack的机器器学习功能可以 动态基线和可能性预测功能匮乏 在⽆无督导的模式下进⾏行行指标的动态阈值运算，并做异常⾏行行为检测和告警 分析能⼒力力需要耗费⼀一定开发⼈人⼒力力成本， 运算消耗⼤大量量时间和存储空间成本 中央数据存储内置数据的聚合、分析和统计等功能，elasticsearch在索引 存储了了指标数据后就能提供以上分析能⼒力力，数据上卷功能可节省⼤大量量空间
  • 31.⽇日志是那些⻓长时间累积的事件记录 Level 2 : ⽇日志 64.242.88.10 - - [07/Jan/2019:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" 200 6291 64.242.88.10 - - [07/Jan/2019:16:11:58 -0800] "POST /twiki/bin/view/TWiki/WikiSyntax HTTP/1.1" 404 7352 64.242.88.10 - - [07/Jan/2019:16:20:55 -0800] "GET /twiki/bin/view/Main/DCCAndPostFix HTTP/1.1" 200 5253 每⼀一条事件记录，都证明那⾥里里曾经发⽣生过什什么事 31
  • 32.⽇日志类型-请求⽇日志 Level 2: ⽇日志 32
  • 33.⽇日志类型-排错⽇日志 Level 2: ⽇日志 33
  • 34.打下管理理⼤大数据量量⽇日志的三个前提条件 Level 2 : ⽇日志 可集中化 Centralised 可全⽂文搜索 Searchable 可关联 Correlated
  • 35.构建可进⾏行行关联分析的⽇日志信息流 Level 2 : ⽇日志 C B D A ERROR [svc=A] [trace=x5y6z7] Failed to process orderCause:'>Cause: