小白也能轻松上手的Prometheus教程

这篇文章将承接此前关于使用Prometheus配置自定义告警规则的文章。在本文中，咱们将demo安装Prometheus的过程以及配置Alertmanager，使其可以在触发告警时能发送邮件，但咱们将以更简单的方式进行这一切——经过Rancher安装。

咱们将在这篇文章中看到没有使用依赖项的状况下如何完成这一操做。在本文中，咱们不须要：

• 专门配置运行指向Kubernetes集群的kubectl

• 有关kubectl的知识，由于咱们可使用Rancher UI

• Helm binary的安装/配置

前期准备

• 一个谷歌云平台帐号（免费的便可），其余云也是同样的

• Rancher v2.4.2（文章发布时的最新版本）

• 运行在GKE（版本为1.15.11-gke.3）上的Kubernetes集群（EKS或者AKS也能够）

启动一个Rancher实例

首先，启动一个Rancher实例。你能够根据Rancher的指引启动：

https://www.rancher.cn/quick-start/

使用Rancher部署一个GKE集群

使用Rancher来设置并配置一个Kubernetes集群。你能够访问下方连接获取文档：

https://rancher2.docs.rancher.cn/docs/cluster-provisioning/_index

部署Prometheus

咱们将利用Rancher的应用商店来安装Prometheus。Rancher的应用商店主要集合了许多Helm Chart，以便于用户可以重复部署应用程序。

咱们的集群起来而且开始运行以后，让咱们在“Apps”的标签下选择为其建立的默认项目，而后单击“Launch”按钮。

如今咱们来搜索咱们感兴趣的chart。咱们能够设置不少字段——可是对于本次demo来讲咱们将保留默认值。你能够在Detailed Description部分找到关于这些值的有用信息。无需担忧出现问题，尽管去查看它们的用途。在页面底部，点击【Launch】。Prometheus Server以及Alertmanager将会被安装以及配置。

当安装完成时，页面以下所示：

接下来，咱们须要建立Services以访问Prometheus Server以及Alertmanager。点开资源下方的工做负载标签，在负载均衡部分，咱们能够看到目前尚未配置。点击导入YAML，选择prometheus namespace，一次性复制两个YAML并点击导入。稍后你将了解咱们如何知道使用那些特定的端口和组件tag。

apiVersion: v1
kind: Service
metadata:
  name: prometheus-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 9090
      protocol: TCP
  selector:
    component: server

apiVersion: v1
kind: Service
metadata:
  name: alertmanager-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 9093
      protocol: TCP
  selector:
    component: alertmanager

完成以后，service将显示Active。

在右侧垂直省略号的下拉菜单里你能找到IP并点击View/Edit YAML。在yaml文件的底部，你将会看到相似的部分：

status:
  loadBalancer:
    ingress:
      - ip: 34.76.22.14

访问IP将为咱们展现Prometheus Server和Alertmanager的GUI。你会发现这时没有什么内容能够查看的，由于还没有定义规则以及配置告警。

添加规则

规则可让咱们触发告警。这些规则都是基于Prometheus的表达式语言。不管什么时候，只要符合条件，告警就会被触发并发送给Alertmanager。

如今来看看咱们如何添加规则。

在资源->工做负载标签下，咱们能够看到Deployment在运行chart时建立了什么。咱们来详细看看prometheus-server和prometheus-alertmanager。

咱们从第一个开始并理解其配置，咱们如何编辑它并了解服务在哪一个端口上运行。点击垂直省略号菜单按钮并点击View/Edit YAML。

首先，咱们看到的是两个与Deplolyment关联的容器：prometheus-server-configmap-reload和prometheus-server。容器prometheus-server的专属部分有一些相关信息：

正如咱们所了解的，Prometheus经过prometheus.yml进行配置。该文件（以及其余在serverFiles中列出的文件）将挂载到server pod。为了添加/编辑规则，咱们须要修改这个文件。实际上，这就是一个Config Map，能够在Resources Config的标签页下找到。点击垂直的省略菜单按钮并Edit。在规则部分，让咱们添加新的规则并点击保存。

groups:
  - name: memory demo alert
    rules:
      - alert: High Pod Memory
        expr: container_memory_usage_bytes{pod_name=~"nginx-.*", image!="", container!="POD"} > 5000000
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: High Memory Usage

  - name: cpu demo alert
    rules:
      - alert: High Pod CPU
        expr: rate (container_cpu_usage_seconds_total{pod_name=~"nginx-.*", image!="", container!="POD"}[5m]) > 0.04
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: High CPU Usage

规则将会由Prometheus Server自动加载，而后咱们在Prometheus Server GUI中能看到它们：

这是关于以上两条规则的解释：

• container_memory_usage_bytes：当前内存使用状况（以字节为单位），包括全部内存，不管任什么时候候访问。

• container_cpu_usage_seconds_total：累积的CPU时间（以秒为单位）

全部的指标都可以在如下页面中找到：

https://github.com/google/cadvisor/blob/master/metrics/prometheus.go

在Prometheus中全部正则表达式都使用RE2 syntax。使用正则表达式，咱们只能为名称与特定模式匹配的Pod选择时间序列。在咱们的示例中，咱们须要寻找以nginx-开头的pod，而且排除“POD”，由于这是容器的父cgroup，并且会显示pod内全部容器的统计信息。

对于container_cpu_usage_seconds_total来讲，咱们使用所谓的子查询（Subquery）。它会每5分钟返回咱们的指标。

若是你想了解更多关于查询以及例子，能够在官方的Prometheus文档中查看。

配置告警

只要出现问题，告警就能当即提醒咱们，使得咱们可以马上知道系统中发生了错误。而Prometheus经过Alertmanager组件来提供告警。

与Prometheus Server的操做步骤相同：在资源->工做负载标签页下，点击prometheus-alertmanager右侧菜单栏按钮，选择View/Edit YAML，检查其配置：

Alertmanager经过alertmanager.yml进行配置。该文件（及其余列在alertmanagerFiles内的文件）将挂载到alertmanager pod上。接下来咱们须要修改与alertmanager相关联的configMap以便于设置告警。在Config标签页下，点击prometheus-alertmanager行的菜单栏，而后选择Edit。使用如下代码代替基本配置：

global:
  resolve_timeout: 5m
route:
  group_by: [Alertname]
  # Send all notifications to me.
  receiver: demo-alert
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  routes:
    - match:
        alertname: DemoAlertName
      receiver: "demo-alert"

receivers:
  - name: demo-alert
    email_configs:
      - to: your_email@gmail.com
        from: from_email@gmail.com
        # Your smtp server address
        smarthost: smtp.gmail.com:587
        auth_username: from_email@gmail.com
        auth_identity: from_email@gmail.com
        auth_password: 16letter_generated token # you can use gmail account password, but better create a dedicated token for this
        headers:
          From: from_email@gmail.com
          Subject: "Demo ALERT"

新配置将会由Alertmanager从新加载，而且咱们能在Status标签页下看到GUI。

测试End-to-End方案

让咱们部署一些组件来进行监控。对于练习来讲部署一个简单的nginx deployment就足够了。使用Rancher GUI，在资源->工做负载标签页下点击导入YAML，粘贴如下代码（本次使用默认的命名空间）并点击导入：

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
            - containerPort: 80

在Prometheus UI中，咱们为使用此前为告警配置的两个表达式中的1个来查看一些指标：

rate (container_cpu_usage_seconds_total{pod_name=~"nginx-.*", image!="", container!="POD"}[5m])

让咱们在其中一个Pod中添加一些负载以查看值的变化。当值大于0.04时，咱们应该得到告警。为此，咱们须要选择其中一个nginx Deployment Pod并点击Execute Shell。在其中咱们将执行一个命令：

告警有3个阶段：

• Inactive-条件不知足

• Pending-知足条件

• Firing-告警被触发

咱们已经看到告警处于inactive状态，因此继续在CPU上增长负载让咱们能观察到剩余两种状态：

只要告警触发，将会显示在Alertmanager中：

将Alertmanager配置为在咱们收到告警时发送电子邮件。若是咱们查看收件箱，则会看到相似的内容：

总 结

咱们都知道监控在整个运维过程当中多么重要，可是若是没有告警，监控是不完整的。告警能够在问题发生时，而后咱们马上知道系统中出现了问题。Prometheus囊括了这两种功能：监控解决方案以及其Alertmanager组件的告警功能。本文中咱们看到了使用Rancher部署Prometheus如此容易而且将Prometheus Server与Alertmanager集成。咱们还使用Rancher配置了告警规则并推送了Alertmanager的配置，因此它能在问题发生时提醒咱们。最后，咱们了解了如何根据Alertmanager的定义/集成收到一封包含触发告警详细信息的电子邮件（也能够经过Slack或PagerDuty发送）。