在本地化环境中，CloudWatch代理和Prometheus的协同工作

2 年 ago
雅, 悟
3 minutes

概述

去年，CloudWatch Agent（以下简称CWA）进行了更新，
增加了从Prometheus的Exporter收集指标，并将其推送到CloudWatch的功能。
参考：使用Amazon CloudWatch上的Prometheus指标。

通过这一改进，不仅可以通过CWA的标准功能收集指标，还可以通过现有的Prometheus Exporter进行收集，进一步将其聚合到CloudWatch中。
在上述参考链接中，介绍了在EKS上部署CWA，并从内部各种容器中收集指标的方法。
这样做可能会让人觉得只适用于EKS，但实际上同样适用于任何与EKS无关的环境，包括本地环境等。
虽然非常简单，但首先介绍适用于任何与EKS无关的方法。
虽然本文的标题写着本地环境，但总的来说就是除了EKS以外的环境都可以。

最近，我在寻找一种能够在现有的本地环境上利用Prometheus资产，并与AWS结合的好方法。因此，这个过程更多地是为自己记录备忘。非常抱歉。

环境

    • CentOS Linux release 8.3.2011

 

    amazon-cloudwatch-agent 1.247346.1b249759

CWA即使在较低版本也能运行，但我们在本文中验证的版本是这个版本。

请注意

詳細は後で説明しますが、CWAによって exporter から収集されたメトリックスはログに記録され、CloudWatch Logs に集められます。直接的な形でメトリックスとして保存されるわけではありませんので、メトリックス化するためにログから手作業で変換する必要があります。

步骤

安装CWA

从下面下载并安装适合你的环境的软件包。

    Download and Configure the CloudWatch Agent Using the Command Line

如果是CentOS，你可以用这个。
https://s3.amazonaws.com/amazoncloudwatch-agent/centos/amd64/latest/amazon-cloudwatch-agent.rpm

$ rpm -Uvh https://s3.amazonaws.com/amazoncloudwatch-agent/centos/amd64/latest/amazon-cloudwatch-agent.rpm

顺便说一下，在最初进行验证时，发现在rpm等软件包中公开的版本中没有实施这一功能。
所以需要从GitHub上公开的上游源代码中进行编译。
在撰写本文时再次确认后发现，即使是在公开的rpm中也没有问题，所以以该步骤进行介绍。

将验证用的出口商投入运营

    • node_exporterをコンテナとして起動しておく

 

    あとでCWAにこのexporterからメトリクス収集させてCloudWatchに集約させる
$ docker run -d \
  --rm \
  --net="host" \
  --pid="host" \
  -v "/:/host:ro,rslave" \
  --name node_exporter \
  quay.io/prometheus/node-exporter \
  --path.rootfs=/host
    curlで動作確認
$ curl localhost:9100/metrics -s | head
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
go_gc_duration_seconds{quantile="0.5"} 0
go_gc_duration_seconds{quantile="0.75"} 0
go_gc_duration_seconds{quantile="1"} 0
go_gc_duration_seconds_sum 0
go_gc_duration_seconds_count 0
# HELP go_goroutines Number of goroutines that currently exist.

准备AWS的Config和Credential。

根据自身环境适当准备。

$ cat ~/.aws/config
[default]
region = ap-northeast-1
[profile AmazonCloudWatchAgent]
region = ap-northeast-1

$ cat ~/.aws/credentials
[default]
aws_access_key_id = hoge
aws_secret_access_key = hogehoge
[AmazonCloudWatchAgent]
aws_access_key_id = foo
aws_secret_access_key = foobar

配置准备完成

所需的是CWA的配置和加载到CWA的Prometheus配置。
本次只需要最基本的配置。

CWA配置

安装rpm后，会在/etc/amazon/amazon-cloudwatch-agent目录下创建amazon-cloudwatch-agent.d子目录。在该子目录下，放置名为file_amazon-cloudwatch-agent.json的配置文件。由于*.json可以读取任何json文件，因此可以随意更改文件名。

    • /etc/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.d/file_amazon-cloudwatch-agent.json

最低限これだけ書いていれば動くと思う

log_group_nameに指定した名前でCloudWatch Logsにロググループを作成する (今回は検証用途なのでtest)

prometheus_config_pathにはPrometheusのコンフィグパスを指定する (別にどこでも良い)

{
  "agent": {
    "run_as_user": "root"
  },
  "logs": {
    "metrics_collected": {
      "prometheus": {
        "log_group_name": "test",
        "prometheus_config_path": "/etc/prometheusconfig/prometheus.yaml"
      }
    },
    "force_flush_interval": 5
  }
}

Prometheus的配置文件

并不是说与CWA组合使用就有特别的东西。只是普通的Prometheus配置而已。
我想这里可能有其他人进行了详细的解释，所以我省略了细节。
顺便说一下，CloudWatch上的日志流将以您在job_name中指定的名称创建。
这次我们准备了node_exporter并针对其进行了配置。在实际环境中，我们可能会进行Service Discovery。

本文介绍了需要在路径/etc/prometheusconfig/prometheus.yaml中准备好的内容。

global:
  evaluation_interval: 1m
  scrape_interval: 1m
  scrape_timeout: 10s
scrape_configs:
- job_name: 'node_exporter'
  sample_limit: 10000
  metrics_path: /metrics
  static_configs:
  - targets: ['localhost:9100']

启动CWA

    rpmでインストールしたので、自動的にunitファイルが作成済み
$ systemctl list-unit-files | grep cloudwatch
amazon-cloudwatch-agent.service            disabled
    起動。一応、自動起動も有効化しておきましょう。
$ systemctl start amazon-cloudwatch-agent
$ systemctl enable amazon-cloudwatch-agent

请检查日志。

可以使用journalctl命令查看日志。但是，输出的内容并不重要。
如果出现某种问题导致无法启动，这个日志将不会输出有用的信息，几乎没有什么用处。

$ journalctl -xu amazon-cloudwatch-agent

CWA的实体存在于/opt/aws/amazon-cloudwatch-agent。日志文件被输出到这里。看这边方便一些。
比如，就算有IAM权限问题，这边也会完整输出，有助于故障排除。
顺便说一下，日志还可以检测到是在本地环境。
似乎是根据能否获取元数据来判断的，如果在EKS上运行，它能正确检测到是EKS环境。

    /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log
$ cat /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log
2021/01/03 02:29:34 I! 2021/01/03 02:29:34 E! ec2metadata is not available
I! Detected the instance is OnPrem
2021/01/03 02:29:34 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json ...
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json does not exist or cannot read. Skipping it.
2021/01/03 02:29:34 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_amazon-cloudwatch-agent.json ...
Valid Json input schema.
I! Detecting runasuser...
Got Home directory: /root
I! Set home dir Linux: /root
I! SDKRegionWithCredsMap region:  ap-northeast-1
Got Home directory: /root
No csm configuration found.
Under path : /logs/ | Info : Got hostname localhost.localdomain as log_stream_name
No metric configuration found.
Configuration validation first phase succeeded

2021/01/03 02:29:34 I! Config has been translated into TOML /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
2021/01/03 02:29:34 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json ...
2021/01/03 02:29:34 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_amazon-cloudwatch-agent.json ...
2021/01/03 02:29:34 I! Detected runAsUser: root
2021/01/03 02:29:34 I! Change ownership to root:root
2021-01-03T02:29:34Z I! Starting AmazonCloudWatchAgent 1.247346.1
2021-01-03T02:29:34Z I! Loaded inputs: prometheus_scraper
2021-01-03T02:29:34Z I! Loaded aggregators:
2021-01-03T02:29:34Z I! Loaded processors:
2021-01-03T02:29:34Z I! Loaded outputs: cloudwatchlogs
2021-01-03T02:29:34Z I! Tags enabled: host=localhost.localdomain
2021-01-03T02:29:34Z I! [agent] Config: Interval:1m0s, Quiet:false, Hostname:"localhost.localdomain", Flush Interval:1s
2021-01-03T02:29:34Z I! [logagent] starting
2021-01-03T02:29:34Z I! [logagent] found plugin cloudwatchlogs is a log backend

确认云监控侧

如果配置正确并且能够从导出者收集指标，并将其推送到CloudWatch，则应该创建以下日志组和流。

image.png

日志会不断积累，除非停止CWA或导出，否则会持续增加。

image.png

只需要在这个日志上创建一个度量过滤器。
虽然在这里是将CPU使用率进行度量化，但只要能够推送到CloudWatch，任何度量化都是可能的。

参考：过滤器和模式语法

image.png
image.png

最后的话

監視和指标收集之类的东西很难对吧。不知道正确答案。
不论是什么机制好、什么系统好、什么架构好，统统都是难以确定的。
由于本来就对这个领域不熟悉，所以更加不清楚。
嗯，可能因为环境和服务的特性等原因，很难有明确的说法，也没有正确答案吧。
最近，我觉得使用Prometheus的用户很多。
在继续使用exporter的同时，将Prometheus本体替换为CloudWatch…这种方法也是一个可行的选项吧。

在先日的re:Invent大会上，AWS宣布推出了全托管的Prometheus，非常令人感兴趣。
虽然我还没有尝试过，所以具体的优缺点还不清楚，但看起来AWS-Prometheus的集成应该很方便，对此抱有期待。
如果能够熟练使用这个，可能就不需要再使用类似CWA收集数据的方法了。我打算以后试试看。

bannerAds