使用Thanos强化Prometheus

背景 Prometheus 是目前云原生架构中监控解决方案中的基石,而对于 “metrics”,“traces” 和 “logs” 是组成云原生架构中“可观测性”的一个基础,当在扩展 Prometheus,那么 Prometheus 提供的基础架构是无法满足需求的(高可用性和可扩展性), 而高可用性与可扩展性是满足不断增长基础设施的一个基本条件。而 Prometheus 本身并没有提供“弹性”的集群配置,也就是说,多个副本的 Prometheus 实例,对于分布在每个 Pod 上的数据也会不一致,这时也需要保证指标的归档问题。 并且在一定的集群规模下,问题的出现远远大于 Prometheus 本身的能力,例如: 如何经济且搞笑的存储历史数据(TB, PB)?如何快速的查询历史数据? 如何合并 Promehtues 多个实例收集来的副本数据? 以及多集群间的监控? 由于 TSDB 的块同步,Prometheus 严重依赖内存,使得 Prometheus 监控项的扩展将导致集群中的CPU/MEM 的使用加大 .. 解决 Thanos 是一款可以使 Prometheus 获得 ”长期存储“,并具体有”高可用性“ 的 Prometheus 的功能扩展,“Thanos” 源自希腊语“ Athanasios”,英文意思是”不朽“。这也正是 ”Thanos“ 提供的功能:”无限制的对象存储“,并与原生 Prometheus API 高度兼容,你可以理解为 Thanos API 就是 Prometheus API。 Cortexmetrics 与 Thanos 类似,是用通过将 Prometheus 实例的”存储“和”查询“等功能分离到独立的组件中,实现水平扩展。它使用对象存储来持久化历史指标,块存储(TSDB)是他的存储后端;此外,Cortex 还提供了多租户与多租户隔离等功能 联邦集群,联邦集群是 Prometheus 官方提供的一个概念,使用了联邦将允许 Prometheus 从另一个 Prometheus 中抓取选定的指标。可以使用的一些模型如下: 分层联邦:大规模的集群中,Prometheus 部署模型如一个”树形“,高级别的从多个低级实例中抓取指标,并存储聚合 跨服务联邦:Prometheus 从另一个 Prometheus 只抓取指定的数据 图:Prometheus 联邦 Source:https://www....

 ·  · 

在Kubernetes集群上安装 Calico cni 的注意事项

开始前的实验环境 Resources controller worker-1 worker-2 OS CentOS 7.9 CentOS 7.9 CentOS 7.9 Storage 20GB 20GB 20GB vCPU 2 2 2 RAM 4GB 4GB 4GB NIC 10.0.0.4 10.0.0.4 10.0.0.4 Kubernetes Version 1.19.10 1.19.10 1.19.10 选择匹配 Kubernetes 版本的 Calico 版本 通常情况下,查看 Calico 所支持的 Kubernetes 版本,可以通过路径 Install Calico ==> Kubernetes ==> System requirements 可以找到自己的 Kubernetes 集群所支持的 Calico 版本。 例如在实验环境中,Kubernetes 1.19 版本所支持的版本有 Calico 3.20,这个时候直接 apply 这个版本提供的资源清单即可 如何开启纯 BGP 模式 默认情况下下,Calico 使用的是 full mesh 和 IPIP, 如果想通过在部署时就修改关闭 IPIP 模式,可以通过修改资源清单中的环境变量来关闭 CALICO_IPV4POOL_IPIP: Never。...

 ·  · 

Kubernetes中的资源限制 - Request&Limit

原作者 Javier Martínez 背景 在学习 Kubernetes 调度时,有两个重要的概念,“request “与 “limit”,而对应的资源就是“内存” 与 “CPU” ,而这两个决定了 Pod 将如何调度;“request “与 “limit” 也是整个调度系统中的基数因子。 什么是 request 和 limit 在 Kubernetes 中,Limit 是容器可以使用的最大资源量,这表示 “容器” 的内存或 CPU 的使用,永远不会超过 Limit 配置的值。 而另一方面,Request 则是为 “容器” 保留的最低资源保障;换句话来说,Request 则是在调度时,容器被允许所需的配置。 图:Kubernetes 中Limit 和 Request 图示 Source:https://sysdig.com/blog/kubernetes-limits-requests/ 如何配置 request 和 limit 下列清单是 Deployment 的部署清单,他将部署一个 redis 与 一个 busybox yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 kind: Deployment apiVersion: extensions/v1beta1 … template: spec: containers: - name: redis image: redis:5....

 ·  · 

我在Prometheus监控中高基数问题中的优化之路

背景 对于整个 Kubernetes 集群来说,随着业务不断地打磨,新增指标,那么对于 Prometheus 特性来说,那么内存 与 存储的使用势必是增加。这是对于存储压力是很重的,通常情况下,使用 Prometheus,都会是用于 Kubernetes 集群中,而 应用于 Kubernetes 集中的存储势必是 PVC 之类的网络存储。 这种场景中,我将尝试拆解如何分析和配置 Prometheus 以显著的减少其资源使用并解决高基数问题 高基数 基数 (cardinality) 通俗来说是一个集合中的元素数量 [1] 基数的来源通常为: label 的数量 series(指标) 的数量 时间:label 或者 series 随时间而流失或增加,通常是增加 那么这么看来高基数就是,label, series, 时间这三个集合的笛卡尔积,那么高基数的情况就很正常了。 而高基数带来的则是 Prometheus 资源使用,以及监控的性能。下图是 Grafana Lab 提到的一张图,很好的阐述了高基数这个问题 图:Prometheus中的基数 Source:https://grafana.com/blog/2022/02/15/what-are-cardinality-spikes-and-why-do-they-matter 如图所示:一个指标 server_responses 他的 label 存在两个 status_code 与 environment ,这代表了一个集合,那他的 label value 是 1~5xx,这个指标的笛卡尔积就是10。 那么此时存在一个问题,如何能定位 基数高不高,Grafana Lab 给出了下面的数据 [1],但是我不清楚具体的来源或者如何得到的这些值。也就是 label:value 低基数:1: 5 标准基数:1: 80 高基数:1: 10000 为什么指标会指数级增长 在以 Kubernetes 为基础的架构中,随着抽象级别的提高(通常为Pod, Label, 以及更多抽象的拓扑),指标的时间序列也越来越多。因为在这种基础架构中,在传统架构中运行的一个应用的单个裸机,被许多运行分散在许多不同节点上的许多不同微服务的 Pod 所取代。在这些抽象层中的每一个都需要一个标签,以便可以唯一地标识它们,并且这些组件中的每一个都会生成自己的指标,从而创建其独特的时间序列集。...

 ·  · 

踩坑nginx proxy_pass GET 参数传递

场景 在配置代理后,GET 请求的变量全部失效,配置如下 conf location /fw { proxy_pass http://127.0.0.1:2952; } 我的需求是,/fw/ 的都发往 2952端口,但实际情况是404,原因为“在没有指定 URI 的情况下,在1.12版本后会传递原有的URI” 这时会导致一个404错误,因为我的后端接口本身就是 /fw/xxx/ 会出现重复 接下来做了一个变量传递 conf location ~* /fw/(?<section>.*) { proxy_pass http://127.0.0.1:2952/fw/$section; } 这时存在一个问题,就是 GET 请求的变量无法传递过去 解决 nginx 官方给出一个样例,说明了,存在某种情况下,nginx 不会确定请求 URI 中的部分参数 使用正则表达式时 在 localtion 名称内 例如,在这个场景下,proxy_pass 就会忽略原有的请求的URI,而将拼接后的请求转发 conf location /name/ { rewrite /name/([^/]+) /users?name=$1 break; proxy_pass http://127.0.0.1; } 那么这服务我遇到的问题,nginx官方给出了使用方式 当在 proxy_pass 中需要变量,可以使用 $request_uri; 另外也可以使用 $is_args$args 参数 来保证原有的请求参数被传递 conf location ~* /fw/(?<section>.*) { proxy_pass http://127.0.0.1:2952/fw/$section$is_args$args; } $is_args...

 ·  ·