鹰潭建设网站,要看网站是多少,网站建设企业所得税,空间设计说明怎么写背景及现状
系统架构简介 上图为阿里云内部实际使用的系统架构#xff0c;系统主要用途为实时数据流的计算和存储。使用阿里云的容器服务 ACK 作为系统底座#xff0c;容器化的部署、发布、管控等全部基于 K8s 标准。使用自己开发的 Gateway service 作为系统流量入口#…背景及现状
系统架构简介 上图为阿里云内部实际使用的系统架构系统主要用途为实时数据流的计算和存储。使用阿里云的容器服务 ACK 作为系统底座容器化的部署、发布、管控等全部基于 K8s 标准。使用自己开发的 Gateway service 作为系统流量入口并基于 LoadBalancer 类型的 service 部署。
此架构也是应用 K8s 做系统较为常见的做法通过 ACK 提供的 CCM 组件自动将 service 和底层 SLB 实例进行绑定通过此实例承接外部流量。Gateway 收到上报的数据流后将数据放入 Kafka 并在某个 topic 中进行数据缓冲。当 Consumer 感知到数据流的上报后则会从 Kafka 相应的 topic 中对数据进行进一步计算处理并将最终结果写入存储介质。
此处存在两种存储介质其中阿里云块存储 ESSD 相对较快但价格较高文件存储 NAS 主要用于存放性能要求较低的数据。元数据由 ACM 进行管理自研的组件 Consumer 和 Center 负责从存储介质中查询计算结果并返回给用户。
系统现状 系统目前为全球开服部署在全球将近 20 个 region 中从图中也可以间接看出数据读写链路较长需要经过多个组件的处理。监控对象也较为复杂包括基础设施调度、存储、网络等、中间件Kafka、业务组件Gateway、Center、Consumer。
工作内容
可观测数据的收集可观测性主要包含Metrics、Tracing 和 Logging三类数据。三类数据各司其职相辅相成。
Metrics 负责回答系统是否出现问题它也是系统的自监控体系入口。针对 Metrics 做异常的告警或问题的排查可以快速确定系统是否有问题是否需要人为介入处理。
Tracing 负责回答系统问题出现在什么位置它能够提供组件之间的调用关系、每一次请求以及哪两个组件之间的调用过程出现了问题等具体细节。
找到出现问题的组件后需要通过最详细的问题日志即 Logging 来定位问题根因。
数据可视化问题排查收集到三类数据后下一步需要通过大盘将数据用可视化的方式展现能够一眼确定问题所在使问题排查更高效。
告警应急处理确定问题后需要通过告警和应急处理流程来解决问题。
应急处理过程主要有以下几个要点
第一需要分级的告警通知和升级策略能够快速找到相应的人员处理告警。与此同时若原定人员因为某些原因无法及时处理还需将告警升级到其他人员以及时处理。
第二问题认领和处理流程标准化。
第三事后统计及复盘。系统出现故障并解决后还需要事后的统计以及复盘工作让系统通过故障和教训避免后续再出现相同的问题让系统更稳定。
第四运维处理工具化、白屏化尽量减少手动输入命令的工作将整套标准的处理动作用工具进行固化。
实践经验分享
可观测数据收集接入
指标Metrics数据监控的第一步是收集可观测数据这些数据在系统里可以分为三个层面。
最上层为应用层主要关心核心业务接口的健康度通过REDRate、Error、Duration三个黄金指标进行衡量。其中 Rate 指接口的 QPS 或 TPS Error 指错误率或错误数Duration 指接口在多长时间内能够返回。可以通过黄金指标来定义 SLO 并分配 Error Budget 。如果 Error Budget 很快耗尽则应及时调整 SLO直到系统优化到足够完善后再将其调高。也可以通过 Apdex Score 衡量服务的健康度计算公式如上图所示。此外应用层也会关心与业务强相关的指标比如营收、用户数、UV、PV 等。 中间层为中间件和存储主要关心系统里大量应用的 Kafka client 端消费位点的提交状况、生产者缓冲区的占用率、是否会提前将缓冲区占满导致新的消息进不来、消费延迟、平均消息大小等比如 Kafka Broker 端的水位、读写流量、磁盘使用率等再比如云盘 ESSD 的挂载成功率、IOPS、磁盘空余空间等。 最下层是基础设施层关心的指标较为复杂典型的有比如 ECSK8s Node CPU 内存水位、重启次数、定时运维事件等比如 K8s 核心组件的 API server、 ETCD、调度相关指标等比如业务 Pod 的 Pending 状态、是否有资源可供足够的调度、OOMKilled 事件、Error 事件等再比如 VPC/SLB 相关的出口带宽、丢弃连接数等。 监控 ECS 节点需要使用 node-exporter Daemonset 的方式部署K8s 云原生的核心组件可以通过 Metrics 接口将指标暴露供 Prometheus 抓取。Kafka 或存储组件由于使用了阿里云的云产品本身提供了基础监控指标可以直接接入。ACK 对 CSI 存储插件也提供了非常核心的指标比如挂载率、iops、空间占用率等也需要接入。应用层包括 Java 应用和 Go 应用Java 使用 MicroMeter 或 Spring Boot Actuator 做监控Go 应用直接使用 Prometheus 官方 SDK 做埋点。 基于 ACK 和 K8s 体系 Metrics 协议的最佳选型即 Prometheus。开源自建的 Prometheus 与云托管的接入难度不相上下但可靠性、运维成本等方面云托管的 Prometheus 更优于自建。比如使用 ARMS 体系可以直接在集群里安装非常轻量级的探针然后将数据中心化存储在全托管的存储组件并围绕它做监控、告警、可视化等整个过程非常方便不需要自建开源组件。云托管在采集能力和存储能力上也更有优势。 Prometheus 针对 ECS 节点、K8s 核心组件、Kafka 和存储组件都提供了一键接入的能力。 K8s 基础监控和节点状态接入主要通过 ACK 组件管理中心只需简单地安装相关组件即可使用该能力。 Kafka 的接入主要通过 Prometheus 云服务实例云服务实例目前已经接入阿里云非常完整的 PaaS 层云产品。接入 Kafka 时所需填写的指标都为常见指标无需额外学习成本。 云盘 ESSD 监控的接入主要通过 CSI 存储插件监控。ACK 里的 csi-provisioner 组件提供了很有用的可观测性能力可以通过它提供的信息及时查看哪块盘没有挂载上、哪块盘挂在后 iops 达不到要求或配置告警以及时发现云盘的异常状况。
通过 ARMS Prometheus 接入预置采集的 job 比如 K8s cluster 级别、node 级别的 PV 状态都可以很方便地进行监控。 应用层不存在一键接入的便捷方式需要通过应用埋点服务发现的方式将整个应用的 Metrics 接口暴露出来提供给 ARMS Prometheus 的探针抓取。 Java 应用需要使用 MicroMeter 或 Spring Boot Actuator 进行埋点。
以上图代码为例MicroMeter 中很多 JVM 相关信息可以简单地通过几行代码进行暴露其他更有帮助的信息比如进程级别的 memory 或 thread、system 信息等也可以通过很简单的方式将其接入。设置完埋点后需要在内部启动 server 将 Metrics 信息通过 HTTP 接口的方式暴露最后绑定指定的端口。至此埋点流程结束。
此外如果有业务指标只需将自己的指标注册到全局的 Prometheus Registry 即可。 ARMS 探针抓取暴露的端点只需添加 ServiceMonitor 由 ServiceMonitor 直接通过控制台白屏化的方式简单地写几行 YAML 的定义即可完整地将整个监控的采集、存储和可视化跑通。 Go 应用与 Java 大同小异只是埋点方式有所区别主要使用 Prometheus 官方的 SDK 埋点。
以上图为例比如系统里有一个查询组件关心每一条查询的时间分布可以使用 Prometheus 里面直方图类型的指标记录每个请求的时间分布并在埋点的时候指定常用的分统进行统计。再由 ServiceMonitor 将 Go 应用的 endpoint 写入最终在控制台上完成整套应用的接入。 ARMS 还提供了基于 eBPF 的无侵入可观测性实现方案主要适用于不希望修改代码的场景使用无侵入的方式监控系统接口的 RED通过 ARMS Cmonitor 探针结合 eBPF 的方式通过系统内核的 filter 实现信息的抓取和存储。 使用上述方式需要在集群里额外安装 Cmonitor App安装后可在 Daemonset 看到 Cmonitor Agent每个节点都需要启动 Cmonitor Agent作用是通过 eBPF 的方式注册到系统内核中抓取整台机器的网络流量然后过滤出想要的 service 网络的拓扑等信息。如上图它可以监控整个系统的 QPS 、响应时间的分布等信息。
链路Trace和日志Log数据Trace 也使用 Cmonitor 来实现相关能力。日志方面系统组件的日志、K8s 控制面的日志、JVM 的 DCLog 等主要通过 arms-Promtail 采集应用日志的探针将日志投递到 Loki 内做长期存储。
K8s 系统事件的日志主要基于 ARMS 事件中心的功能对 K8s 的关键事件、Pod 调度上的 OOM 、Error 等事件进行监护。
读写链路监控和问题定位上图为部分系统截图。
比如 trace 相关控制台可以查看每个请求经过的组件、接收用时、处理时长、回应耗时等标准信息。
组件运行日志收集和存储日志收集方面通过在 Grafana 里配置 Loki 的数据源即可轻松根据关键字或 Pod 标签快速获取到 Pod 或某个 service 下挂载的 Pod 日志对排查问题提供了极大便利。
K8s 运行事件收集和监控上图为 ARMS 提供的事件中心工作台截图。工作台提供了关键事件列表可以对等级较高的事件进行订阅订阅只需简单几步填写基本规则选择需要匹配事件的模式选择告警发送对象即可对关键事件进行监控实现及时响应的目的。
数据可视化及问题排查
Grafana 大盘配置实践完成数据收集后下一步需要打造高效可用的数据可视化和问题排查工具。
Prometheus 与 Grafana 是一对黄金搭档因此我们也选择了 Grafana 作为数据可视化的工具。上图列举了大盘配置过程中的要点
加载大盘时需要控制每个 panel 上的查询时间线避免在前端展现过多时间线导致浏览器渲染压力大。而且对于问题排查而言一次性显示多时间线并没有帮助。大盘配置了很多灵活的 Variable 可以随意在一张大盘上切换各种数据源和查询条件。使用 Transform 让 Table Panel 灵活展现统计信息。分清 Range 和 Instant 查询开关避免无用的范围查询拖慢大盘显示速度。K8s集群总览
上图为监控节点信息、 K8s 集群 Pod 信息的大盘。整体布局一目了然通过不同颜色对关键信息进行标记通过 Grafana 的动态阈值功能将数字以不同的形式展现提升问题排查效率。 节点水位
上图为节点水位大盘展示了磁盘iops 、读写时间、网络流量、内存使用率、CPU使用率等重要信息。 全局 SLO
上图为全局 SLO 大盘 。通过 Grafana 托管服务配置自定义大盘这也是 ARMS 最新上线的功能在云上托管 Grafana 实例即可通过云账号直接登录到 Grafana 界面其中包含阿里云定制的特有功能。
大盘中包含了全局 latency、QPS、成功率、错误码的分布情况、QPS 的变化趋势以及一些较细粒度的信息比如单分片、负载均衡、Gateway 组件、center 组件等。如遇发版可以通过带上版本号查看前后版本的区别可以在 pannel 中以变量的形式展现 datasource也可以选择全球各个 region 进行切换查看。 Kafka 客户端及服务端监控
集群中依赖 Kafka 客户端和服务端其监控来源于云监控集成。 内部组件强依赖于 Kafka通过指标监控 Kafka 以及它与 broker 之间的连接数、平均消息长度、位点提交速率、消费流量等。Producer 端提供了缓冲区的占用率、活跃的 producer 数等信息。 Java 应用运行情况监控
如果组件使用 Java 编写还需要监控 JVM 相关的 GC 情况大盘能够提供 JVM memory 的情况、GC 相关情况、CPU 使用率、线程数、线程状态等。此外比如发版或有动态加载的类在加载类的统计中可以查看是否存在持续上升的状态等。 Table 格式的错误类型复盘统计表
如果希望使用电子表格统计集群中的安装状态或重点客户状态可以使用 Grafana 的 transform 功能将整个大盘打造成电子表格式的体验。可以用 transform 将字段映射到一张电子表格上打开 filter 后还可通过筛选各种字段得出查询结果。
问题排查案例分享日志信息的展示需要通过在 Grafana 里查询 Loki 的数据比如 center 里有查询日志其中包含很多原始信息比如此次查询的时间、UID 等。通过后处理的方式首先将想要的日志按行的方式进行筛选然后通过模式匹配提取信息后续还可以按照 PromQL 将其中某些字段的做大小关系的匹配最终将匹配出来的日志格式进行二次处理。
告警和分级响应机制 上图为告警和分级响应机制流程依次为告警配置、人员排班、告警触发、应急处理、事后复盘和机制优化最后将机制优化体现在告警配置上形成完整的闭环。 以上流程是自建的告警系统通过依赖自建系统定时跑任务检查指标然后调用钉钉的 webhook 或其他运维系统的 webhook 发出告警流程中存在几点不足
1. 自建系统的稳定性需要自己负责如果告警系统的稳定性比运维系统更差则告警系统的存在无意义。其次随着整个集群开服的 region 越来越多配置越来越复杂自己维护配置并保证配置全球生效难以实现。 2. 依赖手工排班极易出现漏排或 backup 缺失。 3. 告警触发阶段触发条件非常单一难以在告警触发链路上增加额外的业务逻辑如动态阈值、动态打标等。 4. 应急处理阶段信息发送非常频繁无法主动认领和主动关闭。系统出现问题时同类告警会在群里高密度发送无法主动屏蔽告警也是缺陷之一。 5. 事后复盘优化的时候没有数据支撑无法根据已有的告警统计信息来优化整个流程。
因此我们选择基于 ARMS 来建立告警系统。ARMS 强大的告警和分级响应机制为我们带来了诸多便利 1. 告警模板全球生效功能只需配置一次告警规则即可使不同的集群生效告警规则。比如没有告警模板时需要对每个 cluster 里的指标单独配置告警。而有了模板后只需通过告警规则模板的方式将 PromQL 或告警的 AlertRule apply 到全球各个 region 集群非常方便。 2. 告警排班表和动态通知系统能够动态实现轮班替班工作比手工排班更靠谱。 3. 事件处理流和告警富化可以通过 ARMS 的事件处理流、告警中心的事件处理流和告警富化功能在告警触发后动态地打上标记并且做分级处理。如上图可以给告警打上优先级标签优先级较高的告警等级升级为 P1并且可以动态地修改告警接收人。
为了实现上述功能首先需要有数据源来提供打标的依据。在告警运维中心的控制台上有数据源的功能告警触发时可以通过 HTTP 请求或 RPC 请求调用数据源而后可以从 HTTP URL 里获取打标的结果。此接口的实现主要通过 IFC 轻量工具在线写好代码代码主要负责读取 ACM 配置中心里的信息配置项然后读取配置项并对外暴露 HTTP 接口提供给告警运维中心动态地调用。
完成以上步骤后还需配置事件处理流将需要的信息通过匹配更新模式的方式传递到上述接口并返回优先级最终打到告警上。 4. 告警的认领、关闭和屏蔽ARMS 提供了认领、关闭、关注、屏蔽等实用功能显著提升了告警质量。 5. 告警的认领接手率统计大盘复盘的时候需要知道每个人处理了多少告警、处理时长、告警平均恢复时间等引入了认领、关闭、恢复、屏蔽机制后ARMS告警中心在后台记录了事件的日志通过对日志的分析即可提供有用的复盘信息。 得到告警信息后用户希望可以在白屏化的界面上处理问题因此我们引入了基于 Grafana 的白屏化运维工具链。其原理为在配置大盘的时候引入动态信息并将其以链接的形式拼接到大盘里。
我们内部有各种系统如果没有官方的链接拼接则需要自己首拼 URL 或手动搜索效率非常低。而通过在 Grafana 里嵌入链接的方式将运维动作固化成链接之间的跳转对于效率的提升非常有帮助。能够通过 Grafana 一套工具将所有工作完成将运维动作标准化、固化减少人工出错的可能性
总结和未来工作 第一告警准确度和接手率的优化。目前还没有很好的方式能够将告警的复盘信息高效地利用起来未来我们将尝试通过告警准确度和接手率的信息及时调整不合理的告警阈值也可能会尝试多阈值的告警比如告警在 A 到 B 范围之内是多少等级在 B 以上是多少等级。
第二多类型数据联动。比如在排查问题的时候除了 Metrics 、Trace 和 Log 之外还有 profiler、CPU 的火焰图等信息而目前这些信息与可观测数据的联动较低。提升数据联动可以提升问题排查效率。
第三埋点成本控制。对于外部客户而言埋点成本直接关系到客户使用阿里云的成本。我们将定期地对自监控指标的维度、发散的维度等进行针对性的治理并且对于无用的维度进行数据清理将埋点成本控制在较低水平。
作者宋傲凡星
原文链接
本文为阿里云原创内容未经允许不得转载。
