做轴承生意的网站,开个网站卖机器怎么做,软件开发培训一般要多少钱,广州网站推广费用作者#xff1a;淡唯#xff08;啃唯#xff09;、阳其凯#xff08;逸陵#xff09;
引言
Prometheus 作为目前最主流的可观测开源项目之一#xff0c;已经成为云原生监控的事实标准#xff0c;被众多企业广泛应用。在使用 Prometheus 的时候#xff0c;我们经常会遇…作者淡唯啃唯、阳其凯逸陵
引言
Prometheus 作为目前最主流的可观测开源项目之一已经成为云原生监控的事实标准被众多企业广泛应用。在使用 Prometheus 的时候我们经常会遇到全局视图的需求但是数据确分散在不同的 Prometheus 实例中遇到这种情况该怎么解决呢本文列举了社区一般解决方案同时给出了阿里云的全局视图解决方案最后给出了某客户基于阿里云 Prometheus 的实践案例希望能给您带来启发与帮助。
背景
在使用阿里云 Promtheus 时由于地域的限制、业务原因或者其他原因经常会遇到 Prometheus 多实例的场景。如下图所示某用户在杭州区域有多个 Prometheus “通用”实例。在多实例的背景下我们经常会遇到一些问题。 2.1. 问题 1-单一 Grafana 大盘数据源
我们知道 Grafana 大盘是观测 Prometheus 数据最常规、最普遍的方式。通常情况下每观测一个 Prometheus 集群就需要创建一个数据源假设我有 100 个 Prometheus 集群就需要创建 100 个数据源。听着是个很麻烦的事情如果你还能接受那么继续往下看。 在编辑 Grafana panel 并填写 PromQL 时我们可以选择数据源但是为了保证数据查询和展示的一致性与简洁性Grafana 仅允许一个 panel 使用一个数据源。 如果我们需要在一个大盘内同时绘制多个数据源的 panel那么使用以上 100 个数据源时就会产生 100 个 panel并且需要编辑 100 次 panel 并编写 100 次 PromQL非常不利于运维。理想状态下应该是合并为一个 panel并且每个数据源一个时间线不仅方便指标监控更是大大减少大盘的维护动作。 2.2. 问题 2-实例间数据计算与查询
当不同的业务使用了不同的 Prometheus 实例但这些实例都有在上报着相同的指标我们希望将这些数据做聚合sum、增长率rate等运算由于存在着实例间的存储隔离这样的操作是不允许的。同时我们并不希望把这些数据都上报到同一个实例中因为根据业务场景可能这些数据来自不同的 ACK 集群、ECS、Flink 实例等甚至数据来源不是同一个地区因此保持实例级别的隔离是有必要的。 社区解决方案
所以针对多 Prometheus 实例存在的上述问题社区是如何解决的呢
3.1. Federation 方案
Prometheus Federation 机制是 Promehteus 本身提供的一种集群化的扩展能力,但是也可以用于解决数据的中心化查询问题。当我们要监控的服务很多的时候我们会部署很多的 Prometheus 节点分别 Pull 这些服务暴露的 MetricsFederation 机制可以将这些分别部署的 Prometheus 节点所获得的指标聚合起来存放在一个中心点的 Prometheus。如下图所示为常见的 Federation 架构 边缘节点每一个 Prometheus 实例都会包含一个/federate 的接口用于获取一组指定的时间序列的监控数据Global 节点只需要配置一个采集任务用于从边缘节点获取监控数据即可。为了更好的理解 Federation 机制下面给出了 Global Prometheus 的配置文件的配置。
scrape_configs:- job_name: federatescrape_interval: 10shonor_labels: truemetrics_path: /federate# 根据实际业务情况进行Pull metrics通过match参数配置要拉取的Metricsparams:match[]:- {jobPrometheus}- {jobnode}static_configs:# 其他 Prometheus 节点- targets:- Prometheus-follower-1:9090- Prometheus-follower-2:90903.2. Thanos 方案
对于开源的 Prometheus 版本我们可以使用 Thanos 实现聚合查询如下为 Thanos 的 Sidecar 部署模式 这张图中包含了 Thanos 的几个核心组件但并不包括所有组件
Thanos Sidecar连接 Prometheus将其数据提供给 Thanos Query 查询并且将其上传到对象存储以供长期存储。Thanos Query实现了 Prometheus API提供全局查询视图将来 StoreAPI 提供的数据进行聚合最终返回给查询数据的 client如 Grafana。Thanos Store Gateway将对象存储的数据暴露给 Thanos Query 去查询。Thanos Compact将对象存储中的数据进行压缩和降低采样率加速大时间区间监控数据查询的速度。Thanos Ruler对监控数据进行评估和告警还可以计算出新的监控数据将这些新数据提供给 Thanos Query 查询并且/或者上传到对象存储以供长期存储。Thanos Receiver从 Prometheus 的远程写入 WAL 接收数据将其公开和/或上传到云存储。
那 Thanos 如何实现 global 查询的呢
Thanos Query 实现了 Prometheus 的 HTTP API这样查询 Prometheus 监控数据的 client 就不直接查询 Prometheus 本身了而是去查询 Thanos QueryThanos Query 再去下游多个存储了数据的地方查数据最后将这些数据聚合去重后返回给 client从而实现了 global 查询。而为了实现 Thanos Query 去查下游分散的数据Thanos 为此抽象了 Store API 的内部 gRPC 接口其它一些组件通过这个接口来暴露数据给 Thanos Query。 在上述的架构中单个的 Prometheus 会将采集的数据存到本机磁盘上每个 Prometheus 附带部署一个 Sidecar这个 Sidecar 实现 Thanos Store API由于 Prometheus 本地磁盘有限所以对于长时间周期的存在通过 Sidecar 的 Thanos Store API 会将数据存储在对象存储无论对于单个 Prometheus 上的数据查询还是对象存储的查询都是基于“Store API”如下对查询进行进一步的抽象。 3.3. Prometheus Remote Write 方案
Remote Write 也是解决 Prometheus 多实例全局查询的有效解决方案其基本思想与 Prometheus Federation 机制非常类似将分别部署的 Prometheus 节点所获得的指标利用 Remote Write 机制存放在一个中心点的 Prometheus 或者第三方存储中。 用户在 Prometheus 配置文件中指定 Remote Write 的 URL 地址一旦设置了该配置项Prometheus 将采集到的样本数据通过 HTTP 的形式发送给适配器 (Adaptor)而用户则可以在适配器中对接外部任意的服务。外部服务可以是开源 Prometheus也可以是真正的存储系统也可以是公有云的存储服务。 如下为样例修改 Prometheus.yml 添加 Remote Storage 相关的配置内容。
remote_write:- url: http://*****:9090/api/v1/write阿里云解决方案
4.1. 阿里云 Prometheus 全局聚合实例解决方案
4.1.1. 阿里云 Prometheus 全局聚合实例方案介绍
阿里云推出了“Prometheus 全局聚合实例”其目标是实现跨多个阿里云 Prometheus 实例的数据聚合在查询数据时同时从多个实例中读取数据其原理为 “查询时指标聚合”。 使用阿里云全局聚合实例以下简称 Gloabal View可以保证单个阿里云 Prometheus 实例间的数据隔离即每个 Prometheus 实例后端拥有独立的存储不是通过合并数据到一个中央存储而是在查询时动态地从各个实例的存储中检索需要的数据。这样当用户或者前端应用程序发起查询请求时Global View 会并行地对所有相关 Prometheus 实例进行查询并将结果汇总提供一个统一的视图。
4.1.2. 对比分析
下面针对开源 Prometheus Federation 以及 Thanos 方案以及阿里云全局聚合实例方案进行简单的汇总说明。
1Prometheus Federation
虽然 Prometheus Federation 能解决全局聚合查询但是还存在一些问题。
边缘节点和 Global 节点依然是单点需要自行决定是否每一层都要使用双节点重复采集进行保活也就是仍然会有单机瓶颈。对历史数据的存储问题仍旧未得到解决必须依赖第三方存储切缺少对历史数据的降准采样能力。整体运维成本比较高。可扩展性较差添加或移除 Prometheus 实例需要修改配置文件。
2Thanos Federation
架构比较复杂运维成本较高。仍存在 Prometheus 副本的单点问题。时间线发散的情况下支持的上限不够不提供维度发散场景优化。不支持降采样长周期查询性能不高。不支持算子下推大数据量的请求性能有限并且处理开销大。
3阿里云全局聚合实例
Prometheus 实例托管、免运维。支持图形化界面进行多实例的管理灵活性强、可扩展性高。这种模式允许系统轻松地添加或移除阿里云 Prometheus 实例而不需要重新配置整个存储系统。不占用额外的存储空间。由于没有将数据复制到集中的存储中这种方法可以节约存储空间每个 Prometheus 实例只需要维护自己的数据集。在不额外配置存储的情况下查询到的数据仅是临时用于展示真正的数据持久化仍然归于被聚合的实例。隔离性每个实例的自治性能够提高系统的容错性因为单个实例的问题不会直接影响到其他实例。支持跨 region 实例以及跨账号实例聚合满足企业个性化的需求。
但是需要注意的是 Thanos Federation 与阿里云全局聚合实例都是非合并数据的方式实现全局查询。由于需要在查询时从多个数据源检索数据这可能会导致查询性能下降特别是当查询涉及大量不需要的数据时需要等待多个数据源筛选出需要的数据等待这些数据处理的过程可能导致查询超时或长时间等待。
4.1.3. 阿里云 Prometheus 全局聚合实例实践
阿里云 Prometheus 极大简化了用户的操作无需手动部署 Prometheus 扩展组件用户通过控制台操作便可实现全局视图的功能。在创建 Prometheus 实例时选择“全局聚合实例”勾选需要聚合的实例并选择查询前端所在的地区影响查询域名的生成点击“保存”后即可。 进入创建好的全局聚合实例点击任意大盘可以看到该实例已经能查询到刚刚聚合的其他实例数据。实现了我们在 Grafana 一个数据源查询多个实例数据的需求。 4.2. 阿里云 Prometheus Remote Write 解决方案
4.2.1. 阿里云 Prometheus Remote Write 解决方案
阿里云 Prometheus remote write 的能力是阿里云 Prometheus 数据投递的原子能力。Prometheus 数据投递的原理为 “存储时的指标聚合” 其目标是将跨多个 Prometheus 实例的数据通过 ETL 服务提取出来再写入某个聚合实例的存储中。 通过这种方式相同的 Prometheus 数据可以同时存储在不同的实例中 在被聚合的 Prometheus 实例中存储着该实例所有的原始数据包括期望被聚合查询的实例以及其他数据。用于原业务场景中单实例的查询。 在中央/聚合 Prometheus 中存储着其他“被聚合实例”的“期望被聚合的数据”在统一管理的场景下可以通过该实例获取全局视图的查询执行跨实例数据的搜索。
4.2.2. 阿里云 Prometheus Remote Write VS 社区 Prometheus Remote Write
1Prometheus Remote Write
开源 Remote Write 的形式最大的弊端在于对 Prometheus Agent 的影响在 Agent 设置 Remote Write 会增加 Agent 的资源消耗影响数据采集的性能而这一点往往是致命的。
2阿里云 Prometheus Remote Write
阿里云 Prometheus Remote Write 的优势还是非常明显的。
查询性能高因为只存储了必要的聚合数据聚合 Prometheus 实例的查询响应时间更短极大地提升了用户体验。此外在查询时本质上只是对一个 Prometheus 实例进行操作而非多个实例读写的性能、计算的性能更高。数据质量高经过筛选后的数据更加干净没有不必要的 “脏数据”这有助于进行更加精准和有效的数据分析。提供丰富的 ETL 能力: 在写入聚合实例之前提供丰富的处理能力如过滤筛选、指标富化等。图形化配置操作简单便捷。
同时当然也有一些劣势大家需要综合权衡取舍。
费用问题由于需要额外的 Prometheus 实例来作为聚合和全局查询的存储点这意味着需要额外的 TSDB 后端存储需要被聚合的数据这些独立的存储空间是需要计费的。网络消耗在数据投递过程中跨网络的数据传输会增加带宽占用特别是在跨数据中心或宽带有限的环境中所以需要进行合理的评估。
4.2.3. 阿里云 Prometheus Remote Write 使用
在左侧导航栏选择 Prometheus 监控 数据投递beta 进入可观测监控 Prometheus 版的数据投递页面。 在数据投递页面的顶部菜单栏选择地域然后单击新建任务。 在对话框中输入任务名称和任务描述后单击确定。 在任务编辑页面配置数据源和投递目标。 配置 Prometheus Remote Write 地址以及认证方式。 配置网络。 4.3. 阿里云解决方案总结与选择
阿里云提供了全局聚合实例以及数据投递-Remote Write解决方案各有优劣。 Prometheus 全局聚合实例的设计理念是在保持 Prometheus 实例的存储独立性的同时提供一个统一的接口对多个实例进行查询来实现全局视图。该方案的核心理念为“查询时指标聚合”也就是说数据原封不动地存储在多个实例中当统一查询时才将多个实例的数据获取并聚合。这种方法有其明显的优点如节省存储空间但也存在一些挑战对于实例数量较多、数据量大的场景查询性能会受较大影响。
Prometheus 数据投递-Remote Write 的设计理念是将查询的流量转化为数据写入的流量它消耗了额外的存储空间提供多实例聚合数据的方案它通过在写入之前筛选数据使得中心实例精简地存储着聚合数据。该方案的核心理念为“存储时指标聚合”此时多个实例的数据副本将存储在统一中心化实例中对多个实例的查询将转化为单实例查询大大提升了查询速率与数据质量。 案例分析
5.1. 某客户运维平台可观测现状
5.1.1. 介绍
下图所示为某客户的内部运维平台这里暂且称为“A 运维平台”客户公司利用 A 运维平台进行公司内部 K8s 集群的生命周期管理。在 A 运维平台中只能针对单个集群进行相关监控数据的查看当有多个集群有问题需要排查时只能一个一个处理。 同样的在使用 Grafana 时当前大盘只能查看某个集群的具体数据无法对多个集群同时监控。 此时 SRE 团队无法对所有集群状态有全局的视角难以准确获取该产品的健康状态。 在平时的运维工作中大多依赖告警提示某个集群处于非健康状态。目前 A 运维平台托管了上百个集群全部依赖告警会有消息过多的风险导致等级较高的故障无法快速定位。
5.1.2. 诉求
当前在“A 运维平台”的运维管理面临一个挑战缺少对所有地区集群状态的一目了然的全局视图。“A 运维平台”的目标是配置单一的 Grafana 大盘通过引入单一的数据源实现对个产品线整所有租户集群运行状况的实时监控这应。包括关键指标的可视化例如集群的整体状态包括集群的数量、各节点和 Pod 的数量、全网集群的 CPU 使用情况等以及\APIServer 的 SLO服务水平目标状态诸如全网非 500 响应的动词比例、50X 错误的详细信息、请求成功率等。
通过这个精心设计的大盘运维团队可以迅速锁定任何处于非健康状态的集群快速概览业务量并对潜在问题进行快速调查大幅提升运维效率和响应速度。这样的集成不仅优化了监控流程也为运维团队提供了一个强大的工具以确保系统的稳定性和服务的连续性。
5.1.3. 难点
跨大洲数据传输 “A 运维平台”的场景涉及到全球所有区域SRE 团队在运维时希望能在杭州区域的大盘查看全球所有区域的实例数据这就涉及到了跨大洲的数据传输。当在 Grafana 进行跨大洲的实例查询时因为网络传输的延迟存在经常性地出现查询超时的问题。 请注意 当您使用 Promethues 配置数据跨境时。您同意并确认您完全拥有该份业务数据的所有处置权限对数据传输的行为全权负责。您应确保您的数据传输符合所有适用法律包括提供充分的数据安全保护技术和策略履行获得个人充分明示同意、完成数据出境安全评估和申报等法定义务且你承诺您的业务数据不含任何所适用法律限制、禁止传输或披露的内容。如您未遵守前述声明与保证您将承担对应的法律后果导致阿里云和或其他关联公司遭受任何损失的您应承担赔偿责任。 单实例数据量过大 并非所有的数据都需要全区域全实例聚合查询全球视角的运维一般只关心某几个表示集群状态的指标或是针对某些指标只关心几个特定的 labelnamespace。随着被“A 运维平台”托管的集群增加、租户增加上报指标的 label 越来越多样化可能涉及到指标纬度发散的问题。目前针对指标纬度发散的问题业界仍没有统一的解决方案此时查询会大量消耗 TSDB 的内存。在单 Prometheus 实例的场景下对这类发散指标查询时就已经给 TSDB 实例很大的压力当一次性获取“A 运维平台”所有 Prometheus 实例数据时给服务器的压力过大。
超大空间跨度的查询 需要对某几个指标把当前区域/全球的所有实例数据求和等计算。在问题 2 单实例数据量的基础上推广至“A 运维平台” 上百个 Prometheus 实例此时所有实例涉及到的数据量更加庞大。当 TSDB 进行查询、筛选、计算操作时会占用大量的内存一般的计算资源配额无法满足。
5.2. 通过数据投递实现中心化数据查询
5.2.1. 方案选型
是选择全局聚合实例还是数据投递在“A 运维平台”的场景下针对以上讨论的需求以及难点选择数据投递是更好的方案。有如下原因
1传输延迟容忍度
当使用数据投递时链路能承受更大的网络延迟。 当使用全局聚合实例查询时 每次请求都会产生多个跨大洲的网络延迟。在测试过程中跨大洲网络传输延迟在 500ms700ms 间在特殊时段、网络波动等情况下延迟甚至能达到 1min极易造成查询超时。“A 运维平台”实例部署在全球各个地区当其中 99% 的数据都成功查询某个地区由于网络波动导致查询超时那么其他 99% 成功查询到的数据也就不可用了对数据齐全度要求很高。在查询时客户的 PromQL、时间跨度是不固定的导致查询的数据量是任意的。当查询数据量过大数据可能会分到多个 HTTP 包传输受限于网络提供商此时网络延迟很大。 当使用数据投递时 数据投递的数据网络传输不会随着用户查询量改变而是将各 Prometheus 实例采集到的数据实时的投递至中心化 Prometheus 实例中此时数据包不超过 1MB 大小网络延迟维持在固定的范围。聚合数据都保存在中心化 Prometheus 实例中因此只需保证对该实例的查询不出错即可无需考虑查询齐全度的问题。即使经过了超大的跨大洲网络传输我们仍然能通过攒批、重试等方式保证数据成功写入了中心 Prometheus 实例。尽管中心实例中的最新数据与当前时间有分钟级的延迟查询成功率有了保证。
2节省计算资源
执行 PromQL 查询时指标的时间线数量决定了查询所需的 CPU、内存资源。也就是说指标的 label 越多样所消耗的资源就越多。 当使用全局聚合实例查询时 被聚合的实例存储着所有的原始数据查询的资源消耗较大。由于 TSDB 的特性即使进行了 label 的筛选仍有可能将该时间段的全量数据加载到内存中。在“A 运维平台”的场景中由于每次查询都涉及到海量数据因此对内存的消耗是非常大的往往会触发查询限流。在测试的过程中查询时间跨度为 1 小时需要等待 30 秒后才能返回结果。 当使用数据投递时 被查询的实例仅有一个并且该实例存储的数据经过前置筛选是我们所关心的需要聚合的相关数据。假设我们要在杭州地区查询全球上百个实例的数据此时底层相当于只查询当前杭州地区的某个实例效率很高。在测试的过程中查询时间跨度为 1 小时只需等待 1 秒就能返回结果。
总的来说当我们选择多实例数据统一管理的方案时除了考虑是否需要额外的存储空间针对业务场景来说查询成功率是更重要的参考指标。
在“A 运维平台”的场景下因为涉及到了跨大洲、海量实例、海量数据因此查询时再进行指标聚合容易产生网络请求超时、数据库查询限流、数据库内存消耗过大等问题使得查询成功率降低。
而使用存储时指标聚合的数据投递方案将数据提前存储至中心化实例把查询的网络传输转化为写数据的网络传输把全球多实例的查询请求转换为当前地区实例的查询查询成功率高并且满足业务场景。
5.2.2. 方案架构
如图为 Prometheus 数据投递-Remote Write 的产品形态。数据投递服务由两个组件组成一是 Prometheus 投递组件该组件负责从源头 Prometheus 实例获取数据经过指标过滤、格式化后发送给公网转发服务组件。公网转发服务组件负责将数据路由通过公网的方式把数据发送至杭州的中心化实例。
在未来的计划中我们将使用事件总线 EventBridge 替换现有公网转发服务组件以支持更多的投递目标生态。 5.3. 效果
通过 Prometheus 数据投递-Remote Write 功能将“A 运维平台”全球多个区域的上百个实例的数据投递至杭州的一个中心化实例中配置了 Grafana 的单一数据源配置大盘后即可对“A 运维平台”管理的所有集群进行可视化监控。杜绝了之前的每个集群一个数据源的配置方式大大方便了运维的操作。 广告时间
6.1. 阿里云可观测监控 Prometheus 版 VS 开源 Prometheus
阿里云可观测监控 Prometheus 版全面对接开源 Prometheus 生态支持类型丰富的组件监控覆盖绝大部分开源基础设施软件指标采集能力。提供多种开箱即用的预置监控大盘并集成丰富的 Kubernetes 基础监控以及常用服务预设看板且提供全面托管的 Prometheus 服务。阿里云可观测监控 Prometheus 版的优势可以归纳为“开箱即用”、“低成本”、“开源兼容”、“数据规模无上限”、“高性能”、“高可用性”。 6.2. 产品计费
目前可观测监控 Prometheus 版已开启全新按数据写入量计费模式并每月提供 50GB 免费额度。每日上报 1000 万指标指标数据存储 90 天仅需 37 元。 相关链接
[1] Remote Write 和 Remote Read 地址使用说明
https://help.aliyun.com/zh/prometheus/user-guide/use-remote-read-endpoints-and-remote-write-endpoints
[2] 查看 RAM 用户的 AccessKey 信息
https://help.aliyun.com/zh/ram/user-guide/view-the-accesskey-pairs-of-a-ram-user
[3] 官方文档
https://prometheus.io/docs/concepts/remote_write_spec/
[4] promlabs
https://promlabs.com/blog/2022/10/05/whats-new-in-prometheus-2-39/
参考文档
[1] https://thanos.io/
[2] https://yunlzheng.gitbook.io/Prometheus-book/part-ii-Prometheus-jin-jie/readmd/Prometheus-remote-storage
[3] https://www.squadcast.com/blog/how-to-implement-global-view-and-high-availability-for-Prometheus
[4] https://help.aliyun.com/zh/arms/Prometheus-monitoring/posting-Prometheus-data-to-other-Prometheus-instances
[5] https://help.aliyun.com/zh/arms/Prometheus-monitoring/create-a-global-aggregation-instance
