go实现重新给metric打标签上传到prometheus_高性能、高可用、免运维-云原生Prometheus方案与实践...

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

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

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

当你在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是单机应用，无论是数据抓取、存储、计算都只能单点执行，几乎无法适应大规模的集群。为此社区提供了很多分布式的解决方案，例如cortex、thanos、m3db等。
5. AIOps相关：Prometheus中的指标监控还是属于传统的Metric监控手段，PromQL也主要是一些算数类运算，并不支持时序类的AI算法，例如：预测、异常检测、变点检测、折点检测、多周期估计算法等。

SLS 与云原生相遇

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

目前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模块，实现存储计算分离，轻松应对超大规模数据压力。

相比社区提供的Prometheus分布式扩展方式（cortex、thanos、m3db、FiloDB、VictoriaMetrics），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](todo)。

自建Kubernetes安装方式

自建Kubernetes推荐以注册集群的方式接入到阿里云，注册好后可以直接按照下述阿里云Kubernetes安装方式来安装。

若您不使用注册集群方式，可参考官方Helm安装包来安装，安装前需要创建保密字典并调整默认配置，具体可参考下述阿里云Kubernetes安装方式。

阿里云Kubernetes安装方式

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

1 创建保密字典

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

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

多样化时序数据查询分析

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可视化的文章，可以参考《日志服务可视化-专属你的炫酷仪表盘》

使用Grafana访问Prometheus数据

除了支持原生的SLS可视化方式外，我们还支持直接使用Grafana访问时序数据，可直接将SLS作为Grafana的Prometheus数据源进行接入，兼容所有的Prometheus大盘模板。

和Prometheus无鉴权的方式不同，SLS提供的Prometheus接口支持HTTPS协议，且需要进行BasicAuth鉴权，数据更加安全。

• 注意：一定要使用HTTPS。

1. 添加datasource, 选择Prometheus:

1. 配置URL:

请填写上述URL

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

访问入口