在AWS上搭建Prometheus (2)

由于时间有点紧迫，所以我会省略详细的内容。关于systemd的问题，上一篇文章已经提及过，所以这次我会从头开始。

要做的事情 zuò de shì

当CPU/内存使用率超过一定限制时，通过node_exporter发送警报。
如果fluentd进程数低于预期，通过发送警报通知。
如果crond进程停止，通过发送警报通知。（通常情况下不会发生，但由于个人经历引起的创伤）
只发送通知到slack。

被监视的一方

有一个叫做fluent-plugin-prometheus的东西，但这次我们并不想完全检查它，所以决定使用process-exporter。
据说按照prometheus的主流方法，是使用各个应用程序的专用exporter，
但是好吧，我们要使用的这个exporter也在这里列出来了https://prometheus.io/docs/instrumenting/exporters/，应该没问题的。

安装 process-exporter。

cd /opt/prometheus
wget https://github.com/ncabatoff/process-exporter/releases/download/v0.5.0/process-exporter-0.5.0.linux-amd64.tar.gz
tar -zxf process-exporter-0.5.0.linux-amd64.tar.gz
mv process-exporter-0.5.0.linux-amd64/ ./process-exporter
rm -f process-exporter-0.5.0.linux-amd64.tar.gz

Process-exorter的配置文件

mkdir -p /opt/prometheus/process-exporter/config/
vi /opt/prometheus/process-exporter/config/process-exporter.yml

process_names:
  - name: "{{.Comm}}"
    comm: 
    - fluentd
  - name: "{{.Comm}}"
    comm:
    - crond

https://github.com/ncabatoff/process-exporter 上提供了关于如何使用的大致指南。

我认为通常情况下使用comm即可解决问题。
在一些无法通过comm解决的应用程序或进程时，可能需要使用exe或者通过运行时参数来将同一应用程序标记为监视对象。可以考虑使用cmdline来实现此功能。
在fluent中，每个启动设置会启动两个进程，一个包含参数ascii-8bit，另一个不包含。例如，如果有三个启动设置，其中两个是使用multi-proc启动的父子进程，总共会启动六个进程。
为了更好的效果，可以将其中一个标记为非监视对象，但由于这次懒得麻烦，所以就放置不管了。

创建、安装、更新和启动配置文件。

这里的内容与上次做的99%相同，所以我会简略描述。

完成后从计划变成Prometheus服务器的实例中使用curl命令发送请求：
curl http://[[实例IP]]:[[设置的端口]]/metrics
如果返回了大量的字符串，则表示正常
由于标签namedprocess_namegroup_num_procs相对主要，所以可以用它来筛选。

监视的一方

进程导出器

将配置信息放入scrape_configs，用于process-exporter的设置。

vi /opt/prometheus/prometheusserver/prometheus.yml

#### 途中省略 ####
  - job_name: 'process_test'
    ec2_sd_configs:
      - region: '監視したいインスタンスがいるリージョン'
        port: xxxx # process-exporterのlistenポート
    relabel_configs:
      - source_labels: [__meta_ec2_tag_Service]
        regex: prom_test
        action: keep
      - source_labels: [__meta_ec2_tag_Name]
        target_label: instance

设置警报经理

cd /opt/prometheus
wget https://github.com/prometheus/alertmanager/releases/download/v0.16.2/alertmanager-0.16.2.linux-amd64.tar.gz
tar -zxf alertmanager-0.16.2.linux-amd64.tar.gz
mv alertmanager-0.16.2.linux-amd64 alertmanager
rm -f alertmanager-0.16.2.linux-amd64.tar.gz

警报规则的配置文件

在上一篇文章中被推迟到后面的设定部分

rule_files:
  - /opt/prometheus/prometheusserver/alert_rules.yml

groups:
  - name: node_exporter # 任意のグループ名
    rules:
      - alert: cpu_exceed # 任意のアラート名
        # 各インスタンスごとの各コアごとCPU idleの使用率を合計してコア数で割ったものが80%を超えていれば
        expr: sum(100 * (1 - rate(node_cpu_seconds_total{job='ec2-test',mode='idle'}[5m]))) by (instance) / count(node_cpu_seconds_total{job='ec2-test',mode='idle'}) by (instance) > 80
        # 80%を超えた状態がこの時間継続すれば。なお省略可能、省略すると即時になるようです。
        # 解除時はここの値は影響しないようです。即座にfiringが解除される模様。
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "cpu of [{{ $labels.instance }}] has been used over 80% for more than 5 minutes."
      - alert: memory_exceed
        expr: 100 * (1 - node_memory_MemFree_bytes{job='ec2-test'} / node_memory_MemTotal_bytes{job='ec2-test'}) > 90
        for: 5m
        labels:
          severity: critical 
        annotations:
          summary: "memory of [{{ $labels.instance }}] has been used over 90% for more than 5 minutes."
  - name: process_exporter
    rules:
      - alert: crond
        expr: namedprocess_namegroup_num_procs{job='process_test',groupname='crond'} < 1
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "[{{ $labels.instance }}] The number of crond process is less than 1 for 1 minutes."
      - alert: fluentd
        expr: namedprocess_namegroup_num_procs{job='process_test',groupname='fluentd'} < 6
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "[{{ $labels.instance }}] The number of fluentd process is less than 6 for 1 minutes."

追踪公式的这一部分的运算符和查询相关信息，然后在Prometheus的图形界面上发送查询并确认值的情况下进行操作，我认为不会遇到太大困难。
其中包括node_exporter的速率等等。
标签/注释也在这里解释了一下。
（顺便一提，特意让进程持续1分钟的原因是，如果立即重新启动进程的话可能会有些烦人。）

警报管理器的设置文件

mkdir -p /opt/prometheus/alertmanager/config/
vi /opt/prometheus/alertmanager/config/alertmanager.yml

global:
  slack_api_url: [[slackのwebhook url]]

route:
  receiver: 'slack'
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval:  1m
  repeat_interval: 10m

receivers:
  - name: 'slack'
    slack_configs:
      - channel: '#通知先チャンネル'
        title: '{{ if eq .Status "firing" }}[FIRING]{{else}}[RESOLVED]{{end}} {{ .GroupLabels.alertname }}'
        text: '{{ .CommonAnnotations.summary }}'
        title_link: "http://[[prometheus本体サーバのipなりなんなり]]:[[listen port]]/alerts"
        send_resolved: true

slack的设置我认为在官方信息中不会有太多困扰，所以没有什么特别要说的，但对于等待/间隔方面会在后面提及。（我觉得并没有遇到足够困扰的问题以至于要追踪源代码解决，而且也厌倦了一直对行为的疑惑，所以在中途停止了研究。）
之所以区分标题，是因为在发生和恢复时，只有消息正文左侧条带的颜色会改变，所以这是我仅有的一点抵抗。

以及警报管理器的启动设置和启动。

因为流程完全与以往相同，所以省略不提。

试着停止 crond，就能确认一下了。

神秘的的group_interval

我自己可能存在误解意思的可能性很多，但不排除这种可能。

# 通知発生から実際に通知するまで待つ時間
group_wait: 2m
# 2つ目以降の通知が発生し、それが同一グループである場合に通知するまで追加で待つ時間
# alert_rule上で言うとnameは同じだがalertが違う
group_interval:  4m
# 一度通知したアラートの条件が満たされ続けている時、次に通知するまで追加で待つ時間
# alert_rule上で言うとname/alert共に同じ
repeat_interval: 8m

虽然没有什么大不了的事情，比如我想知道等待和每个间隔是否会合计，所以我根据上述条件试了一下。

08:34 プロセス1 stop
08:34 プロセス2 stop
08:36 プロセス1 アラート通知
08:36 プロセス2 アラート通知
しばらく放置
08:48 プロセス1 アラート通知
08:48 プロセス2 アラート通知
08:54 プロセス1 start
08:54 プロセス2 start
08:56 プロセス1 resolve通知
08:56 プロセス2 resolve通知

group_wait和repeat_interval似乎被合并了，但是group_interval是什么？

09:02 プロセス1 stop
09:04 プロセス1 アラート通知
09:04 プロセス2 stop
09:06 プロセス2 アラート通知
09:16 プロセス1 アラート通知リピート
09:18 プロセス2 アラート通知リピート
09:27 プロセス1 start
09:27 プロセス2 start
09:29 プロセス1 resolve通知
09:30 プロセス2 resolve通知

group_interval是什么？

虽然我认为等待和重复操作应该是直观的，但既然调查已经结束，我不介意。如果有人知道更多的信息，请悄悄告诉我。