设为首页 - 加入收藏 乌海站长网 (http://www.0473zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 基于 数据 物理 使用方法
当前位置: 首页 > 服务器 > 搭建环境 > Windows > 正文

一文读懂如何在Kubernetes上轻松实现自动化部署Prometheus

发布时间:2019-08-28 11:14 所属栏目:[Windows] 来源:火眼狻猊
导读:简介 Prometheus 是当下火热的监控解决方案,尤其是容器微服务架构,Kubernetes 的首选监控方案。关于为什么要用 Prometheus,我这里就不多讲,相关的文章太多了,大家也可以看看官方的说法。本文就讲讲如何自动化的搭建一套基于 Kubernetes 集群的 Promet

?一文读懂如何在Kubernetes上轻松实现自动化部署Prometheus

简介

Prometheus 是当下火热的监控解决方案,尤其是容器微服务架构,Kubernetes 的首选监控方案。关于为什么要用 Prometheus,我这里就不多讲,相关的文章太多了,大家也可以看看官方的说法。本文就讲讲如何自动化的搭建一套基于 Kubernetes 集群的 Prometheus 监控系统。

我这里使用 Prometheus Operator 以及 helm 工具在 Kubernetes 集群上部署,后面给大家提供一个全自动运维 (http://t.cn/Ai8t4jLw) 的例子参考,这里直接看代码。

关于 helm 的使用不清楚的可以参考这几篇文章:

  • ?Helm 入门指南
  • ?利用 Helm 快速部署 Ingress
  • ?Kubernetes 实操手册-Helm使用 (http://t.cn/Ai85DU9N)

关于什么是 Prometheus Operator 以及为什么要用 Prometheus Operator?

Operator 是以软件的方式定义运维过程,是一系列打包、部署和管理 Kubernetes 应用的方法。简单来说就是将运维过程中的手动操作转换为自动化流程,通过 Kubernetes 的 CRD(Custom Resource Definition)将部署前后的相关操作自动化,同时以参数的方式提供了灵活性。而 Prometheus Operator 是 CoreOS 提供的一整套 Prometheus 的 Operator,方便了 Prometheus 的部署。

下面我们先简单讲讲 Prometheus 的架构。

Prometheus 核心

下图是 Promtheus 官方的架构图

一文读懂如何在Kubernetes上轻松实现自动化部署Prometheus

Prometheus Server

Prometheus Server 是监控系统的服务端,服务端通过服务发现的方式,抓取被监控服务的指标,或者通过 pushgateway 的间接抓取,抓取到指标数据后,通过特定的存储引擎进行存储,同时暴露一个 HTTP 服务,提供用 PromQL 来进行数据查询。注意,Prometheus 是定时采样数据,而不是全量数据。

Exporter

Prometheus 需要服务暴露 http 接口,如果服务本身没有,我们不需要改造服务,可以通过 exporter 来间接获取。Exporter 就充当了 Prometheus 采集的目标,而由各个 exporter 去直接获取指标。目前大多数的服务都有现成的 exporter,我们不需要重复造轮子,拿来用即可,如 MySQL,MongoDB 等,可以参考这里。

Push Gateway

Prometheus 采集指标的方式主要有两种,一种是服务端暴露接口(Exporter),由 Prometheus 主动去抓取指标,称为 pull 模式。另一种是服务端主动上报,服务端将指标主动上报至 Push Gateway,Prometheus 再从 Push Gateway 中获取,称为 push 模式。而 Push Gateway 就是 push 模式中重要的中介角色,用于暂存服务端上报的指标,等待 Prometheus 收集。

为什么要有两种模式呢?我们来比较一下这两种模式的特点。

Pull 模式:Prometheus 主动抓取的方式,可以由 Prometheus 服务端控制抓取的频率,简单清晰,控制权在 Prometheus 服务端。通过服务发现机制,可以自动接入新服务,去掉下线的服务,无需任何人工干预。对于各种常见的服务,官方或社区有大量 Exporter 来提供指标采集接口,基本无需开发。是官方推荐的方式。

Push 模式:由服务端主动上报至 Push Gateway,采集最小粒度由服务端决定,等于 Push Gateway 充当了中介的角色,收集各个服务主动上报的指标,然后再由 Prometheus 来采集。但是这样就存在了 Push Gateway 这个性能单点,而且 Push Gateway 也要处理持久化问题,不然宕机也会丢失部分数据。同时需要服务端提供主动上报的功能,可能涉及一些开发改动。不是首选的方式,但是在一些场景下很适用。例如,一些临时性的任务,存在时间可能非常短,如果采用 Pull 模式,可能抓取不到数据。

Alert Manager

Alert Manager 是 Prometheus 的报警组件,当 Prometheus 服务端发现报警时,推送 alert 到 Alert Manager,再由 Alert Manager 发送到通知端,如 Email,Slack,微信,钉钉等。Alert Manager 根据相关规则提供了报警的分组、聚合、抑制、沉默等功能。

Web UI/Grafana

Prometheus 提供了一个简单的 web UI 界面,用于查询数据,查看告警、配置等,官方推荐使用另一个开源项目 grafana 来做指标的可视化展示,制作仪表盘等。

部署

下面详细讲讲如何自动化部署 Promethues,自动化监控以及遇到的一些坑。

部署这块 Prometheus Operator 已经帮我们做的非常好了,我们只需要调整一些参数即可实现部署。我们使用 helm 来部署 Prometheus,只需要一个命令。

  1. helm?install?--name?my-release?stable/prometheus-operator?

不过这不可能满足我们的需求,我们需要的不是演示,而是实战。

下面是详细讲解,完整的项目可以参考这里:http://t.cn/Ai8tzUaR 。

我们首先要确定的是如何持久化存储 Prometheus 的指标数据,默认的方式是以文件的方式保存在服务端的磁盘上,但这样不利于服务端的横向扩展以及数据的备份恢复。Prometheus 还提供了其他存储后端的整合,详见这里。目前比较流行的做法是使用 InfluxDB 作为存储后端,InfluxDB 是一款强大的时序数据库,就是为监控指标等时序数据而生的。

首先,我们来部署 InfluxDB,为了持久化 InfluxDB 的数据,我们先创建一个 PVC 来持久化数据。

pvc.yaml

  1. apiVersion:?v1??
  2. kind:?PersistentVolumeClaim??
  3. metadata:??
  4. ??name:?influxdb-pvc??
  5. ??namespace:?monitoring??
  6. ??labels:??
  7. ????app:?influxdb??
  8. ????release:?influxdb??
  9. spec:??
  10. ??accessModes:??
  11. ????-?ReadWriteOnce??
  12. ??storageClassName:?monitor-ebs??#?选择合适的存储类??
  13. ??resources:??
  14. ????requests:??
  15. ??????storage:?200Gi??#?设置合适的存储空间?

然后我们创建 InfluxDB 的配置文件

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章