高性能、高可用、免运维-云原生Prometheus方案与实践

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
云备份 Cloud Backup,100GB 3个月
简介: SLS(阿里云日志服务)一直致力于发展成一个DevOps的数据中台,为用户提供丰富的机器数据接入、存储、分析、可视化等能力。本文主要介绍SLS如何支持Prometheus的方案,为大家提供云原生的高性能、高可用、免运维的Prometheus引擎。

Prometheus-云原生监控的事实标准


近年来,云原生技术在全球的发展与普及可谓是开花结果、五彩缤纷,其背后的强力支撑是目前IT领域最具影响力之一的CNCF(Cloud Native Computing Foundation)。CNCF作为Linux Foundation下的非盈利组织,管理着数十个和云原生相关的Project,其中最大名鼎鼎的当属K8s(Kubernetes),这一容器编排领域的事实标准。


而Prometheus则是CNCF下第二个毕业的项目,也是CNCF除Kubernetes外最火爆的项目。可以毫不夸张的说,Prometheus已经成为了云原生领域监控的事实标准,如果说开启云原生的第一步是拥有一个Kubernetes环境,那Prometheus就是云原生下监控的第一步。


image.png


当你在K8s中部署了几个应用后,便会发现需要去查看集群以及应用的运行状态,然而在虚拟机环境下的一些监控方式已经不再适用,在进行一番详细的调研之后,你会发现Prometheus是最佳之选:

  1. Prometheus非常容易部署,尤其在Kubernetes下,部署了Prometheus Operator后,只需要几个yaml就可以把Prometheus和监控项配置好,配合grafana以及上面丰富的Prometheus模板,监控大盘一步到位。
  2. Prometheus的服务发现机制非常丰富,尤其是对Kubernetes的支持,采集Pod指标只需声明一个简单的annotation即可。
  3. Prometheus的Exporter几乎覆盖了所有的开源软件系统,而很多商业软件和系统也都支持Prometheus的Exporter,例如阿里云的云监控也提供了Prometheus Exporter
  4. 当你想在应用中暴露指标时,你会发现Prometheus提供了几乎所有语言的SDK,而这些SDK设计是如此的优雅、暴露Metrics是如此的方便。
  5. 作为CNCF下的Project,完全开源,不用担心过两年软件没人维护。
  6. 当你开始研究Kubernetes代码时,你会发现Kubernetes所有的组件都会暴露出Prometheus的metrics,监控Kubernetes完全离不开Prometheus。

Prometheus在生产环境的那些痛


当我们刚开始把测试环境的应用以及相关监控手段部署到线上集群时,一切都是那么地的顺利,应用平稳的运行、相关监控也都非常正常。而当生产环境部署的应用越来越多,访问压力逐渐增加时,我们才会逐渐意识到Prometheus的一些痛点:

  1. 内存占用:由于Prometheus会把近两小时所有的数据缓存在内存中,当Pod数越来越多,系统中的Metric会越来越多,最终可能会触发OOM。有些情况下100个节点的集群,需要专门用一台64GB内存来运行Prometheus。
  2. 异常恢复问题:Prometheus使用binlog的方式将实时写入的数据持久化,在crash的时候会重新回放binlog来恢复。但由于数据在内存中保存2小时,一次恢复的时间可能很长,而一旦是因为OOM问题重启,Prometheus将无限重启下去。
  3. 存储时长:这是Prometheus被吐槽最多的点: long term storage (LTS),默认Prometheus最多支持15天的存储,虽然可以调整启动参数来设置更长时间,但受限于单机限制,还是无法实现长期存储。
  4. 单机问题:Prometheus是单机应用,无论是数据抓取、存储、计算都只能单点执行,几乎无法适应大规模的集群。为此社区提供了很多分布式的解决方案,例如cortexthanosm3db等。
  5. AIOps相关:Prometheus中的指标监控还是属于传统的Metric监控手段,PromQL也主要是一些算数类运算,并不支持时序类的AI算法,例如:预测、异常检测、变点检测、折点检测、多周期估计算法等。


image.png

SLS 与云原生相遇


SLS(阿里云日志服务)一直致力于发展成一个DevOps的数据中台,为用户提供丰富的机器数据接入、存储、分析、可视化等能力。让广大用户能够尽可能便捷地、一站式的完成DevOps场景中的数据相关工作,快速构建企业自身的可观察性平台。




image.png


目前SLS提供了非常丰富的数据接入手段,也支持了非常多和云原生可观察性相关的数据接入,上图展示的是SLS支持接入的CNCF landscape上的Project,其中Monitoring、Logging和Tracing均支持CNCF官方毕业的Project(Prometheus、Fluentd、Jaeger)。使用SLS存储Prometheus监控数据主要的诉求有:

  1. SLS的数据支持永久保存,很多用户希望把Prometheus的关键指标的长期保存在SLS中。
  2. 现在很多用户都已经把日志、Trace数据存储在SLS上,希望把Prometheus的数据也放在SLS,实现一体化的可观察性数据方案,减少运维负担。
  3. 目前SLS已经提供了很多和Metric相关的AIOps算法,例如多周期估算、预测、异常检测、时序分类等,客户希望也能对Prometheus的数据进行更加智能的使用。
  4. SLS本身也支持数据管道的模型,Prometheus的指标通过对接下游的流计算可以获得更加快速的报警能力,同时也可以对接数仓进行离线的统计分析。

SLS的Prometheus支持方案

SLS的MetricStore原生提供了对PromQL的支持,所有的数据通过Shard的方式分散在多台机器分布式存储,计算层集成Prometheus的QueryEngine模块,实现存储计算分离,轻松应对超大规模数据压力。
image.png
相比社区提供的Prometheus分布式扩展方式(cortexthanosm3dbFiloDBVictoriaMetrics),SLS的分布式实现方案更加彻底,也更加贴近社区解决原生Prometheus使用限制的目标:

  1. 兼容性:SLS的实现直接复用Prometheus代码且无任何修改,可实时跟上官方更新;
  2. 全局视图:SLS是SaaS化的服务,支持多租户多实例,因此可以将多个集群的数据写入到同一实例中用来展示全局视图;
  3. 长期存储:SLS的数据支持TTL概念,支持永久存储;
  4. 高可用:每个实例内包含多个Shard,不同的Shard会分配在不同的机器上,即使部分Shard所在机器宕机也不影响整体写入;同时每个Shard的数据在pangu上3副本存储,保证单Shard的可靠性。


除了能够支持社区的这些需求外,SLS可以为Prometheus附加更多的优势:

  1. 更大的存储:SLS是完全云化的服务,对于每个用户来讲,我们提供的存储空间都是无限大。
  2. 更低的成本:  从人力成本上看,SLS的Prometheus接入方式无需自己运维Prometheus实例;从使用角度看,SLS MetricStore使用按量计费的模式,无需单独购买机器、磁盘用于数据计算和存储。
  3. 更快的速度:SLS存储计算分离架构充分发挥集群能力,尤其在大量数据下端对端的速度提升显著。
  4. 更智能的算法:SLS提供的和Metric相关的AIOps算法都可以套用在Prometheus接入的数据上,例如多周期估算、预测、异常检测、时序分类等,为Prometheus附加AI的力量。
  5. 更全的生态:利用SLS上下游生态打通的能力,可以将Prometheus的指标对接流计算来获得更加快速的报警能力、对接数仓进行离线的统计分析、对接OSS进行归档存储等。
  6. 更好的支持:可观察性根本上还需要彻底打通Metrics、Logging、Tracing,SLS致力于打造Open Telemetry统一的存储平台,为各种智能的数据应用做好基础数据底盘。

云原生Kubernetes监控

Prometheus作为面向云原生的监控软件,原生对Kubernetes提供了友好的支持。而且在Kubernetes中,几乎所有的组件都提供了Prometheus的指标接口,因此Prometheus基本成为Kubernetes监控的实施标准。下面将为大家介绍如何部署Kubernetes的Prometheus监控并使用SLS的MetricStore作为存储后端。

前提条件

  1. 拥有一个Kubernetes集群,集群版本在1.10以上。
  2. 在SLS创建一个MetricStore,创建方式可参考:MetricStore。

自建Kubernetes安装方式

自建Kubernetes推荐以注册集群的方式接入到阿里云,注册好后可以直接按照下述阿里云Kubernetes安装方式来安装。
若您不使用注册集群方式,可参考官方Helm安装包来安装,安装前需要创建保密字典并调整默认配置,具体可参考下述阿里云Kubernetes安装方式。

阿里云Kubernetes安装方式

如果您使用阿里云Kubernetes,可直接在应用目录中安装并配置Prometheus将数据存储到SLS。配置方式如下:

1 创建保密字典

  • 打开容器服务Kubernetes控制台
  • 在左侧标签栏选择"命名空间",创建一个名为 monitoring 的命名空间。
  • 在左侧标签栏选择"应用配置"-"保密字典",选择新创建的 monitoring 命名空间(若没有请强制刷新整个页面)。
  • 点击"创建"开始创建保密字典,名称填写为 sls-ak ,增加两个键值对 usernamepassword,分别填写为您的阿里云AccessKeyId和AccessKeySecret,请使用子账号并只授予日志服务写权限,授权可参考:授予指定Project的写入权限

image.png

2 创建PrometheusOperator

  1. 打开容器服务Kubernetes控制台
  2. 在左侧标签栏选择"市场"-"应用目录"
  3. 在"应用目录"中点击"ack-prometheus-operator"
  4. 在弹出的安装页面中,点击"参数"标签栏,修改其中的配置项,主要修改的内容有:

    1. 调整 prometheusSpec 下的 retention ,建议改成 1d 或者 12h
    2. prometheusSpec 下的 enable 设置为true,并增加 remoteWrite 配置(注意修改URL参数):
      remoteWrite:
      - basicAuth:
          username:
            name: sls-ak
            key: username
          password:
            name: sls-ak
            key: password
        queueConfig:
          batchSendDeadline: 20s
          maxBackoff: 5s
          maxRetries: 10
          minBackoff: 100ms
        ### url 为 https://{sls-enpoint}/prometheus/{project}/{metricstore}/api/v1/write
        ### 其中 sls-endpoint可参考 https://help.aliyun.com/document_detail/29008.html
        ###      project、metricstore替换为您对应的project和metricstore
        url: https://cn-beijing.log.aliyuncs.com/prometheus/sls-zc-test-bj-b/prometheus-raw/api/v1/write

多样化时序数据查询分析

image.png
SLS针对时序数据提供三种模式,整体上以SQL为主,辅助让SQL支持调用PromQL使简化的语法和强大的功能可以兼得;同时也支持直接调用PromQL,以支持开源生态,例如被grafana集成:

1. 纯PromQL查询

在实现metrics store的时候,我们就支持了prometheus remote write协议写入,也支持调用prometheus api用PromQL查询,这样也可以直接作为grafana的数据源以兼容开源生态。如果用户的数据是prometheus写入的,那这是最合适的。
 

2. 纯SQL查询

因为metrics store本身复用了sls的底层架构,因此他天生就是可以用SQL去查询的,比如上面长长的SQL就是用纯SQL查询的,纯SQL查询还需要做很多优化,才能比较轻松的处理时序数据,这需要长时间的投入,所以我们还有第三种方案:
 

3. SQL+PromQL混合查询

我们把PromQL封装成几个函数,并可以将其作为子查询,支持在外层嵌套完整的SQL,举个栗子:
纯PromQL查询:

SELECT promql_query('up') FROM metrics
SELECT promql_query_range('up', '1m') FROM metrics


PromQL作为子查询:**

SELECT sum(value) FROM (SELECT promql_query('up') FROM metrics)


PromQL作为子查询,复杂SQL:**

select ts_predicate_arma(time, value, 5, 1, 1 , 1, 1, true) from ( SELECT (time/1000) as time, value   from ( select  promql_query_range('1 - avg(irate(node_cpu_seconds_total{instance=~".*",mode="idle"}[10m]))', '10m') as t from metrics ) order by time asc ) limit 10000

 
目前支持了PromQL中最常用的API: query(varchar)query_range(varchar,varchar?)labels()label_values(varchar)series(varchar)


其中query_range不填第二个参数时也支持自动的step。

多种可视化支持

在SLS上访问Prometheus数据

SLS默认为时序场景提供了多种可视化方式,支持使用标准的SQL以及PromQL+SQL的方式进行分析,关于SLS可视化的文章,可以参考《日志服务可视化-专属你的炫酷仪表盘
image.png

使用Grafana访问Prometheus数据

除了支持原生的SLS可视化方式外,我们还支持直接使用Grafana访问时序数据,可直接将SLS作为Grafana的Prometheus数据源进行接入,兼容所有的Prometheus大盘模板。
image.png
和Prometheus无鉴权的方式不同,SLS提供的Prometheus接口支持HTTPS协议,且需要进行BasicAuth鉴权,数据更加安全。

  • 注意:一定要使用HTTPS。
信息 说明 示例
访问入口(Endpoint) https://endpoint/prometheus/{project-name}/{logstore-name} https://cn-beijing.log.aliyuncs.com/prometheus/sls-prometheus-test/prometheus
BasicAuth username 为AK ID,password为 AK Secret。建议使用子账号AK,授予该project、logstore只读权限即可
  1. 添加datasource, 选择Prometheus:

image.png

  1. 配置URL:

image.png
请填写上述URL

  1. 开启Basic Auth, 并填写ak信息

image.png

信息 说明 示例
访问入口(URL) https://{endpoint}/prometheus/{project-name}/{metricstore-name}
其中endpoint为SLS对应Region的访问域名:具体请参考访问入口
https://cn-beijing.log.aliyuncs.com/prometheus/sls-prometheus-test/prometheus
BasicAuth username 为AK ID,password为 AK Secret。建议使用子账号AK,授予该project、metricstore只读权限即可
相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
目录
相关文章
|
5天前
|
运维 Kubernetes Cloud Native
云原生技术入门及实践
【10月更文挑战第39天】在数字化浪潮的推动下,云原生技术应运而生,它不仅仅是一种技术趋势,更是企业数字化转型的关键。本文将带你走进云原生的世界,从基础概念到实际操作,一步步揭示云原生的魅力和价值。通过实例分析,我们将深入探讨如何利用云原生技术提升业务灵活性、降低成本并加速创新。无论你是云原生技术的初学者还是希望深化理解的开发者,这篇文章都将为你提供宝贵的知识和启示。
|
4天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
24 5
|
5天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
5天前
|
消息中间件 缓存 Cloud Native
云原生架构下的性能优化实践与挑战####
随着企业数字化转型的加速,云原生架构以其高度解耦、弹性伸缩和快速迭代的特性,成为现代软件开发的首选模式。本文深入探讨了云原生环境下性能优化的关键策略与面临的主要挑战,通过案例分析,揭示了如何有效利用容器化、微服务、动态调度等技术手段提升应用性能,同时指出了在复杂云环境中确保系统稳定性和高效性的难题,为开发者和架构师提供了实战指南。 ####
18 3
|
5天前
|
运维 Kubernetes Cloud Native
深入理解云原生架构:从理论到实践
【10月更文挑战第38天】本文将引导读者深入探索云原生技术的核心概念,以及如何将这些概念应用于实际的软件开发和运维中。我们将从云原生的基本定义出发,逐步展开其背后的设计哲学、关键技术组件,并以一个具体的代码示例来演示云原生应用的构建过程。无论你是云原生技术的初学者,还是希望深化理解的开发者,这篇文章都将为你提供有价值的见解和实操指南。
|
6天前
|
Cloud Native 持续交付 云计算
云原生技术入门与实践
【10月更文挑战第37天】本文旨在为初学者提供云原生技术的基础知识和实践指南。我们将从云原生的概念出发,探讨其在现代软件开发中的重要性,并介绍相关的核心技术。通过实际的代码示例,我们展示了如何在云平台上部署和管理应用,以及如何利用云原生架构提高系统的可伸缩性、弹性和可靠性。无论你是云原生领域的新手,还是希望深化理解的开发者,这篇文章都将为你打开一扇通往云原生世界的大门。
|
4天前
|
弹性计算 Kubernetes Cloud Native
云原生技术的实践与思考
云原生技术的实践与思考
18 2
|
5天前
|
Kubernetes Cloud Native 持续交付
云原生技术在现代应用架构中的实践与思考
【10月更文挑战第38天】随着云计算的不断成熟和演进,云原生(Cloud-Native)已成为推动企业数字化转型的重要力量。本文从云原生的基本概念出发,深入探讨了其在现代应用架构中的实际应用,并结合代码示例,展示了云原生技术如何优化资源管理、提升系统弹性和加速开发流程。通过分析云原生的优势与面临的挑战,本文旨在为读者提供一份云原生转型的指南和启示。
19 3
|
6天前
|
存储 Cloud Native 持续交付
云原生入门:从理论到实践
【10月更文挑战第38天】云原生技术正在重塑软件开发和运维的面貌。本文将带你走进云原生的世界,理解其核心理念,并探索如何将这些理念应用于实际项目中。我们将一起学习容器化、微服务架构、持续集成与持续部署(CI/CD)等关键概念,并通过代码示例加深理解。无论你是云原生新手还是希望深化知识的开发者,这篇文章都将为你提供宝贵的知识和启示。
16 3
|
5天前
|
运维 Kubernetes Cloud Native
云原生技术在现代应用架构中的实践与挑战####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在实际项目中的应用案例,分析了企业在向云原生转型过程中面临的主要挑战及应对策略。不同于传统摘要的概述性质,本摘要强调通过具体实例揭示云原生技术如何促进应用的灵活性、可扩展性和高效运维,同时指出实践中需注意的技术债务、安全合规等问题,为读者提供一幅云原生技术实践的全景视图。 ####