网站代理备案表,免费的网站软件下载安装,天津市做网站的公司,网站怎么做404 301文章目录 一.监控现状二.Thanos原理分析SidecarQuerierStoreCompactor 三.Sidecar or ReceiverThanos Receiver工作原理 四.分布式运维架构 一.监控现状
Prometheus是CNCF基金会管理的一个开源监控项目#xff0c;由于其良好的架构设计和完善的生态#xff0c;迅速成为了监控… 文章目录 一.监控现状二.Thanos原理分析SidecarQuerierStoreCompactor 三.Sidecar or ReceiverThanos Receiver工作原理 四.分布式运维架构 一.监控现状
Prometheus是CNCF基金会管理的一个开源监控项目由于其良好的架构设计和完善的生态迅速成为了监控领域事实上的标准尤其是在云原生领域。 Prometheus的优势有很多服务自动发现社区众多exporter基本涵盖了所有的开源软件与k8s深度结合。对于一家小型公司Prometheus够用了足以应对所有监控需求。 但随着监控数据量的不断增多Prometheus的局限性逐渐显现出来了
扩展性差Prometheus自身的TSDB是一个单机的数据库不支持分布式扩展性差的第二个方面在于Prometheus对大量metrics的数据分析能力很差内存使用 量成线性增长Prometheus不支持降采样单机存储捉襟见肘
Prometheus社区也意识到了这个问题因此推出了prometheus高可用的解决方案—Thanos
二.Thanos原理分析
分层是一个很好的思想如果划分一层解决不了的问题利用分层的思想能将复杂问题化整为零。
长短期指标分离短期指标用来提供给告警系统高频查询近期数据长期指标用来提供给人查询时间集。 Thanos架构图如上图所示主要由四个组件组成Querier、Slidercar、Store和Compactor。
Sidecar
每个Prometheus节点都配置了一个Sidecar组件通过k8s的部署可以将Prometheus和Sidecar容器集成到一个容器中Sidecar主要有两个作用和一个后来新增的可选功能一是用来代理Querier对Prometheus本地数据的读取二是将Prometheus本地的监控数据一般是未压缩的块通过对象存储接口保存到对象存储中Sidecar每30s读取一次本地元数据看是否有新的监控数据产生如果有则读取本地数据块将其上传到对象存储标记最新的读取时间并且通过本地的JSON文件保存相关信息包含块的元信息例如统计信息时间范围和压缩机制避免重复上传。
Querier
Querier是Thanos实现多集群监控以及全局视图的关键。Querier接收HTTP的PromQL查询组件负责数据查询汇聚查询流程如下图 简而言之就是从基础StoreAPI查询所需的数据返回结果。Querier是完全无状态的并且可以水平扩展。Thanos Querier本质上允许在单个Prometheus Query端点下聚合和可选地对多个度量后端进行重复数据删除。对于Querier来说可以整个Store API的所有内容因此可以从任意数量的不同存储中聚合数据例如* Prometheus需要包含Sidecar * 对象存储 * 记录规则和警报规则 * 符合Promtheus远程读写的标准的数据库 * 另外一个Querier * 非Prometheus系统例如OpenTSDB Querier不仅可以从多个后端获取数据将他们汇总还可以对其中的重复数据删除必须为整个集群选择固定的单个或多个副本标签然后在启动时将其传递给查询节点。仅通过给定副本标签区分的两个或多个序列将合并为一个时间序列。这也掩盖了单个数据源收集方面的差距。
Store
Store在对象存储中的历史数据之上实现StoreAPI使对象存储中的数据可以作为Querier查询的后端。Store主要有两个作用一个在对象存储中数据实现StoreAPI使对象存储中的数据可以被查询二是充当一个API网关可以负责所有StoreAPI的服务发现因此Store不需要大量的本地磁盘空间。它在启动的时候加入Thanos集群并发布它可以安全访问的数据。他在本地磁盘上保留有关所有远程块的少量信息并使它与桶同步。
Compactor
Compator是一个批处理组件主要针对对象存储的数据压缩可以将历史的小对象block块合并压缩成大文件对象对其数据并且删除这些小文件从而节省存储占用。 Compator是Thanos实现无限存储的关键组件。
Compator主要有两个作用一个是负责对数据的压缩另一个是负责历史数据的降准。
三.Sidecar or Receiver
Thanos支持两种方式与Prometheus集成Sidecar和Receiver Thanos Sidecar工作原理 如上图所示为了实现高可用Prometheus实例与sidecar组件一起运行sidecar每隔一段时间抓取prometheus数据存储在对象存储中。此外Sidecar在Prometheus的远程读API上实现了Thanos的Store API,从而可以从Thanos Queries组件中查询Prometheus的数据。因此 Queries组件在Store API中查询历史数据最新未上传数据可通过Sidecar查询下层Prometheus数据。
Thanos Receiver工作原理 Receiver 是作为一个单独的 StatefulSet 来运行的在这种方法中Thanos 的所有其他组件都以与 Sidecar 方式相同的方式存在和运行但 Receiver 取代了 Sidecar 组件TSDB 的查询和传输到对象存储的方式发生了巨大的变化。
Receiver 组件实现了 Prometheus 的远程写 API直接接收 Prometheus 的数据Receiver 将数据上传到对象存储 Bucket 中去并且也有自己的保留期Querier 被配置为通过 Store 查询 Receiver 和存储桶上的数据。 Receiver 则是基于 push 的模式TSDB 由 Prometheus 实例本身远程写入到 Receiver从而使 Prometheus 最接近无状态。然后数据从 Receiver 进一步上传到对象存储。
结论具体应该选用哪种类型要根据具体的业务场景如果Sidecar数量非常多且Sidecar距离Queries比较远每次查询Querise都会调用Sidecar会消耗很多资源并且速度很慢而我们看监控大多数都是看最新的数据。 而Receiver模式下数据实时push到Receiver组件中Querise组件无需去sidecar中查询最新数据了。但这种模式下大量的数据汇总到Receiver组件也会增加Receiver的压力需要给Receiver较多的计算和存储资源。当然设计这个组件时肯定会考虑这个问题Receiver 实现了一致性哈希支持集群部署所以即使规模很大也不会成为性能瓶颈。 没有完美的方案具体应用哪种模式需要我们压测和取舍。
四.分布式运维架构
上一节我们了解了Thanos的力量和能力总结一下Thanos提供了可靠、低成本的规模化历史数据存储在上层提供了统一的全局查询视图通过降准采样特性满足长时间范围的数据查询分析全局的告警规则。特别适合集团—子公司这种数据架构的应用场景
注意⚠️Thanos的每个组件都可以部署多个副本实现高可用 我们通过架构图描述整个的监控架构
Thanos部署实战可参考 http://www.dockone.io/article/10053 https://blog.csdn.net/csdnzxm/article/details/120279085
参考文档 http://dockone.io/article/9988 http://dockone.io/article/6019 https://mp.weixin.qq.com/s/YFx1cY5IsrcHzXFEEu8Z6A https://zhuanlan.zhihu.com/p/383969247 https://blog.csdn.net/csdnzxm/article/details/120279085 https://blog.csdn.net/u012140251/article/details/121454958
