网站开发创业,上海网站建设信息网,网络课程教学平台,关于网站及新媒体平台建设的规划很多研发人员在日常工作中经常回遇到以下两个问题#xff1a;竟然不可以运行#xff0c;为什么#xff1f;竟然可以运行#xff0c;为什么#xff1f;
因此#xff0c;他们非常期望可观测能够提供解决问题的思路。
引言 2017 年#xff0c;推特工程师 Cindy 发表了一篇…很多研发人员在日常工作中经常回遇到以下两个问题竟然不可以运行为什么竟然可以运行为什么
因此他们非常期望可观测能够提供解决问题的思路。
引言 2017 年推特工程师 Cindy 发表了一篇名为《Monitoring and Observability》的文章首次将可观测性这一词汇带入开发者视野通过半开玩笑的方式调侃了关于可观测性和监控的区别。在软件产品和服务领域监控能够告知我们服务究竟是否能正常运行而可观测性可以告诉我们为为什么服务没有正常运行。
从谷歌趋势图中可以看到可观测性的普及率呈现逐年上升的态势它也被视为系统的属性将逐步成为系统在做开发设计过程中就需要具备的特性。 可观测发展趋势
2020 年后可观测的搜索趋势出现井喷很大一部分原因是 SRE 站点可靠性工程逐步普及国内大厂纷纷设立相关岗位和对应招聘指标使得可观测性在国内也得到了较多关注。这也意味着越来越多的基础服务面临了稳定性挑战而破解稳定性挑战的重要手段就在于提供可观测性。
上图左下角为可观测性的全球搜索趋势其中中国的搜索热度颇高。 可观测性定义
可观测性是由匈牙利工程师提出的一个数学概念指系统可以由外部输出推断其内部状态的程度。换句话说可观测性应当可以从数据产出中分析出其内部的具体运转细节。
难点与挑战
业务蓬勃发展 稳定性诉求激增 F6 汽车科技是一家专注于汽车后市场信息化建设的互联网平台公司目前处于行业内头部位置。随着业务蓬勃发展F6 支持的商户数目短时间内暴增数十倍同时也逐步开展了面向技师等 C 端场景的业务比如 Vin 码解析、数据查询等对于稳定性的要求显著提高。
康威定律的作用 康威定律是 IT 史上对整个组织架构进行微服务拆分的指导性定律。任何组织在设计系统过程中都是组织架构的翻版随着业务膨胀康威定律作用会导致设计微服务时拆分方式趋同于组织架构业务增长会导致部门拆分后续设计微服务时也会十分靠近组织架构。哪怕前期组织架构和微服务拆分不一致后面微服务也会逐步妥协于组织架构。
虽然微服务和组织架构趋同使得系统沟通效率较高但是这也带来了很多分布式的系统问题。比如微服务之间的交互没有人能够对服务有整体性、全局性的了解研发人员最直接的期望就是在分布式系统中也能有单机系统的排查效率这促使我们需要将系统以服务器为中心的思路转变为以调用链为中心的思路。
稳定性诉求激增 F6 最早进行业务开发时采用烟囱式的建设。单体应用比较简单但是它在扩展性和可维护性上存在很多问题。比如所有研发都在系统上进行代码冲突较多什么时间点能发布发布会造成多少业务量损失等皆难以明确。因此越来越多情况导致我们需要进行微服务拆分而微服务拆分和调用又会导致调用链十分复杂繁琐如上图右所示几乎无法人为分析出调用链路。
那么怎么样才能尽可能降低线上排查故障的难度
可观测演进
传统监控微应用日志收集
ELKStack 获取日志和查询 ElastAlert 完成日志告警传统的监控和微服务日志收集一般采用 ELKStack 进行日志收集。ELK 是三个开源项目的首字母缩写分别是 Elasticsearch、Logstash 和 Kibana。
我们重度依赖 ELK 进行微服务日志的收集与此同时还使用了开源的基于 ES 的报警系统 ElastAlert 组件主要功能是从 ES 中查询出匹配规则对相关类型数据进行报警。 上图描述了通过日志收集进行日常查询的思路。比如研发人员会通过 pipeling 查询线上日志ElastAlert 通过匹配规则告警获取到 ES 日志中发掘出来异常数据kibana 可以进行查询也可以优先定位出系统中发生的异常。
架构升级可观测性引入
Grafana 看板Zorka 支持 jvm 监控随着业务发展系统对日志的要求也逐步增加比如团队非常多需要配置各种各样的告警规则因此我们引入了 Grafana 逐步替代 kibana 和 Zabbix 的查询功能。可以通过 Grafana 的 ES 插件查询对日志进行告警然后通过 alert 功能完成原先 ElastAlert 的排除同时可以使用 Grafana 做出更直观的可视化大屏进行展示。
除了日志外我们也期望收集到 Java 应用指标因此又引入了 Zorka 开源组件。Zorka 和 Zabbix 可以简单地进行结合可以通过 Zorka 将收集到的信息上报给 Zabbix 进行展示。而 Zabbix 又可以通过 Grafana Zabbix 插件直接输出数据最终将整个应用大屏和看板信息都收集到 Grafana 界面。 Zorka 的工作机制类似于通过 Zabbix Java gateway 的方式通过 Java Agent 自动挂载到 Java 进程中用于统计常见应用容器和请求数指标等初步解决了我们对于 Java 进程的观测需求。
云原生改造
K8s 的编排能力和微服务相辅相成迫切需要 trace 组件的支持随着微服务程度不断提升传统方式的运维成本越来越高因此我们启动了云原生化改造。
首先云原生化的改造是 K8s 侧就绪探针和存活探针的编写。存活探针的编写提升了服务的自愈能力出现了 OOM 后服务能够自动恢复、启动新节点保证数据服务正常提供。除了 K8s 外我们还引入了 Prometheus 和 ARMS 应用监控。
Prometheus 作为 CNCF 仅次于 K8s 的 2 号项目在整个 metrics 领域形成了足够的话语权ARMS 应用监控作为阿里云商业 APM 的拳头产品使我们能够结合云原生的方式实现研发无感无需进行任何代码改动即可拥有 trace 功能。更重要的是阿里云团队能够保持持续迭代支持越来越多中间件因此我们认为它必定会成为诊断利器。
JmxExporter 快速支持云原生 Java 组件的 jvm 信息展示进行云原生化改造后监控模型也发生了改变。最早的监控模型是 pushZorka 每次发布都在同一台机器上因此它有固定的 host而上云后容器化改造导致 Pod 不再固定且可能会出现新的应用扩缩容等问题。因此我们将监控模型逐步从 push 转换成 pull 模式也更加契合 Prometheus 的收集模型并逐步将 Zorka 从可观测体系中剥离。
没有使用 ARMS 直接收集 JMX 指标是因为 ARMS 不会覆盖线上和线下所有 java 应用没有被覆盖的应用也期望有 JVM 数据收集功能而 ARMS 成本略高。因此出于成本的考虑我们没有将 ARMS 作为完整接入而是选择了 JMX Exporter 组件。
JMX Export 也是 Prometheus 官方社区提供的 exporter 之一。它通过 Java Agent 利用 Java JMX 机制读取 JVM 信息可以将数据直接转化成为 Prometheus 可以辨识的 metrics 格式使 Prometheus 能够对其进行监控和采集并通过 Prometheus Operator 注册对应的 Service Moninor 完成指标收集。
利用配置中心完成应用到 owner 的精准告警随着公司业务蓬勃发展人员激增微服务暴增研发人数和告警也剧烈增长。为了提升告警触达率和响应率我们重新使用了 Apollo 配置中心的多语言 SDK通过 Go 自研了一套基于 Apollo 业务的应用提醒整体流程如下
通过 Grafana 收集到 ES 告警或其他场景下的告警再通过 metrics 应用关联到 alert 告警时会转发到前文提到的 Go 语言编写的精准告警服务上。精准告警服务解析到对应应用根据应用从 Apollo 配置中心中获取到 owner 姓名、手机号等信息再基于此信息通过钉钉进行告警极大提升了消息阅读率。
ARMS无侵入支持 Trace此外我们还引入了阿里云的应用实时监控服务 ARMS 能够在没有任何代码改造的前提下支持绝大部分中间件和框架比如 Kafka、MySQL、Dubbo 等。云原生化后仅需要在 deployment 里添加注解即可支持相关探针的加载微服务的可维护性极为友好。同时还提供了较为完整的 trace 视图可以查看线上应用节点调用日志的整个 trace 链路也提供了甘特图的查看方式和依赖拓扑图、上下游耗时图等数据。
可观测升级
Log Trace Metrics 理念升级可观测在国内微服务领域已遍地开花。因此F6 公司也升级了可观测思路。业界广泛推行的可观测性包含三大支柱分别是日志事件、分布式链路追踪以及指标监控。任何时代都需要监控但是它已经不再是核心需求。上图可以看出监控仅包含告警和应用概览而事实上可观测性还需包括排错剖析以及依赖分析。
最早的监控功能使用主体是运维人员但运维人员大多只能处理系统服务告警。而上升到整个微服务领域更多问题可能出现在应用之间需要进行问题排障。比如服务出现了慢请求有可能是因为代码问题也可能因为锁或线程池不足或连接数不够等以上种种问题最终表现出来的特征是慢和服务无法响应。而如此多的可能性需要通过可观测性才能定位到真正根因。然而定位根因并非真实需求真实需求更多的是利用可观测性分析出问题所处节点然后通过替换对应组件、进行熔断或限流等措施尽可能提升整体 SLA 。
可观测性还可以很好的剖析问题比如线上服务慢可以观测其每个节点的耗时、每个请求中的耗时等。依赖分析也可以得到解决比如服务依赖是否合理、服务依赖调用链路是否正常等。
随着应用越来越多对于可观测性和稳定性的诉求也越来越多。因此我们自研了一套简单的根因分析系统通过文本相似度算法将当前服务日志进行归类聚类分析。
简版根因分析上线上图为典型 ONS 故障依赖服务进行服务升级。如果这是通过日志抓取智能分析出来的日志做了很长时间 SRE 后变更也会对于线上稳定性造成很大破坏。如果能将变更等也收集到可观测体系中将会带来很大好处。同理如果能将 ONS 要升级的信息收集到可观测体系统中通过种种事件关联能够分析出根因对于系统稳定性和问题排查将极为有益。
ARMS 支持 traceId 透出 responseHeaderF6 公司和 ARMS 团队也进行了深入合作探索了可观测的最佳实践。ARMS 近期退出了一项新功能将 traceID 直接透出到 HTTP 头可以在接入层日志中将它输出到对应日志通过 Kibana 进行检索。
客户在发生故障时将日志信息和 traceID 一起上报给技术支持人员最后研发人员可通过 traceID 快速定位到问题原因、上下游链路因为 traceID 在整个调用链路中是唯一的非常适合作为检索条件。
同时ARMS 支持直接通过 MDC 透传 traceID 支持 Java 主流日志框架包括 Logback、Log4j、Log4j2 等也可以将 traceID 作为标准 Python 输出。
上图展示了典型的日志输出场景下 ARMS 的后台配置可以打开关联业务日志和 traceID 支持各种各样的组件只需在日志系统中定义 eagleeye_traceid 即可输出 traceID。
上述方案较为简单研发的修改也很少甚至可以做到免修改且对于 Loggin 和 Trace 的关联程度做到了较大提升减少了数据孤岛。
ARMS 支持运维告警平台ARMS 为进一步降低 MTTR 提供了很多数据但是数据如何到达 SRE 、DevOps 或研发运维人员手里依然需要花费一些心思。
因此ARMS 上线了运维告警平台通过可视化方式完成了告警转发、分流等事件处理可以通过静默功能、分组等支持多种集成方式。目前 F6 在用的包括 Prometheus、buffalo、ARMS 以及云监控其中云监控包含了包括 ONS、Redis 在内的很多数据研发人员或 SRE 人员在钉钉群里认领对应的响应事件即可。同时还支持报表、定时提醒、事件升级等功能便于事后复盘和改善。 上图为线上处理问题的界面截图。比如钉钉群里的告警会提示上一次相似告警由谁处理、告警列表以及对应事件处理流程等。同时还提供了过滤功能可以分割内容通过字段丰富或匹配更新等方式替换内容填充模板用于精准告警比如识别到应用名称后可以关联到对应应用的 owner 或告警人员。此功能后续也将逐步替代前文用 Go 语言写的 Apollo SDK 应用。
Java 生态免修改注入 agent 方式-JAVA_TOOL_OPTIONS同时我们也借鉴了 ARMS 免修改注入 Agent 的方式。ARMS 通过one point initContainer 的方式注入了很多 ARMS 信息也挂载了一个名为 home/admin/.opt 的 mount 用于存储日志。正因为有 initContainer 它才能够实现自动升级。
在 initContainer 中可以通过调用 ARMS 接口获取到当前 ARMS Agent 最新版本然后下载 Java Agent 最新版本放到 mount 目录下与目录下对应的数组 Pod 进行通信通过共享 volume 的方式完成 Java Agent 共享。过程中最核心的点在于通过 JAVA_TOOL_OPTIONS 实现了 Java Agent 挂载。
通过上述方式我们模拟了一套流程通过openkruise 组件 workspread 使用 patch 方式修改 deployment。最简单的实践是利用 openkruise workspread给对应的 deployment 打注解从而使得无需由研发或 SRE 团队进行处理只要编写对应 CRD 即可CRD 过程直接注入 JAVA_TOOL_OPTIONS见上图右下角代码。其应用场景也较为丰富可以做应用流量回放、自动化测试等。
Prometheus Exporter除了 ARMS 等商业化产品外我们也积极开源拥抱 Prometheus 社区接入了较多 Exporter 组件包括 SSLExport 和 BlackBoxExporter极大提升了整个系统的可观测性。Exporter 可以用于黑盒探针比如探测 HTTP 请求是否正常、HTTPS 请求是否正、DNS 是否正常、TCP 是否正常等典型的使用场景是探测当前服务入口地址是否正常。SSL 证书异常更为常见通过 SSLExporter 可以定期轮询证书是否过期进一步提升可观测性。
成本观测除了日常服务可观测我们还实践了成本可观测等优化项目。对于云原生环境可以利用 kubecost 开源组件进行成本优化直接输出资源使用率以及报表等反馈给研发人员进行优化甚至可以用来发现 CPU 和内存是否呈正常比例尽可能实现资源合理分配。
未来畅想
基于 eBPF 的 Kuberneters 一站式可观测性 eBPF 云原生组件愈发进入到深水区很多问题不再只停留于应用层面更多地会出现在系统层面和网络层面需要更加底层的数据进行追踪和排障。利用 eBPF 可以更好地回答 Google SRE 提出的比如延迟、流量、错误率、饱和度等黄金指标出现的问题。
比如 Redis 进行闪断切换的过程中可能会形成 TCP 半开连接从而对业务产生影响再比如 TCP 连接刚建立时backlog 是否合理等都可以通过数据得到相应结论。
Chaos-engineering Chaos-engineering 混沌工程鼓励和利用可观测性试图帮助用户先发制人地发现和克服系统弱点。2020 年 6 月CNCF 针对可观测性提出了特别兴趣小组。除了三大支柱外CNCF 还提出了混沌工程和持续优化。
对于混沌工程是否能划分在可观测性里当前社区依然存在疑议而 CNCF 的可观测性特别兴趣小组里已包含了 chaos-engineering 和持续优化。我们认为CNCF 的做法有一定道理混沌工程可以被认为是一种可观测性的分析工具但其重要前提是可观测性。试想如果在实施混沌工程过程中发生故障我们甚至都无法确定它是否由混沌工程引起这也将带来极大麻烦。
因此可以利用可观测性尽可能缩小爆炸半径、定位问题通过 chaos-engineering 持续优化系统提前发现系统薄弱点更好地为系统稳定性保驾护航。
OpenTelemetry OpenTelemetry 是一个通过多个项目合并而来的开源框架。我们需要更加面向终端研发统一的可观测性视图比如期望将 logging、metrics 和 tracing 数据进行互相关联打标尽可能减少数据孤岛通过多数据源的关联提升整体可观测性。并利用可观测性尽可能缩短线上故障排查时间为业务服务恢复争取时间。
原文链接
本文为阿里云原创内容未经允许不得转载。
