概要

CloudWatchについて調べる機会があったのでまとめた

CloudWatchの基本機能

監視ツールとしての以下の基本的な機能が備わっているらしい。

基本機能

内部リソース(CPUとか)データの収集
ログの収集(※)
収集データに対して閾値を設定してのアラート通知の発砲・インスタンスの停止・再起動
収集したデータの視覚化

※EC2のログ監視には別途「CloudWatchエージェント」というツールを監視対象インスタンスへインストールする必要あり(※)。
- また、標準でないメトリクス(=カスタムメトリクス。メトリクスとは監視項目・測定基準データの意味)の収集にも別途「CloudWatchエージェント」というツールを監視対象インスタンスへインストールする必要あり(※)。
- 標準メトリクスは下記
- CPU使用率
- ディスク読み取り(数、サイズ)
- ディスク書き込み(数、サイズ)|
- ネットワーク受信量
- ネットワーク送信量
- ステータスチェック(インスタンスステータスチェック/システムステータスチェックのどちらかが失敗した場合に失敗となる)(※)
- インスタンスステータスチェック(※)
- システムステータスチェック(※)

※CloudWatchエージェントのインストール
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html

※ステータスチェック
以下2つがあり、全項目OKならば「ステータスチェック」がOKとなる。

システムステータスチェック
インスタンスステータスチェック

なお、ステータスチェックについてはCloudWatchじゃなくてEC２のコンソールでもOK/NGは確認できる。

システムステータスチェック
- 対象のインスタンスに対して物理的な問題が発生していないか？のチェック。
- AWSが関与しないと解決できない、自身ではどうにもならない問題の部分である。
- 以下が原因となる例らしい。
  - ネットワーク接続の喪失
  - システム電源の喪失
  - 物理ホスト上のソフトウェアの問題
  - ネットワークの到達可能性に影響を与える物理ホスト上のハードウェアの問題
- 物理歴な問題が発生した時のリスクを低減するには以下のようにするらしい
  - RDSならマルチAZ構成(マスターで障害が発生したらスレーブに自動で切り替えてくれる)
  - EC2ならマルチリージョン、マルチAZ構成(EC2インスタンスを各箇所にちりばめ、ELBを通してアクセスさせることでどこかで障害が発生しても生きているインスタンスで応答するようにする)
インスタンスステータスチェック
- インスタンス内のステータスチェック。以下がNGとなる原因の例らしい。
  - システムステータスチェックの失敗
  - 不正なネットワークまたはスタートアップ構成
  - メモリ不足
  - 破損したファイルシステム
  - 互換性のないカーネル
- インスタンスステータスチェックについてはなかなか疑問あり。
- 実際にメモリがめちゃくちゃ使われていて、実際にサーバーが死んでいた状態だったときにも引っかかることはなかったし、そもそも全項目が公開されているわけではなく、その判定基準もブラックボックスなので今回の要件には不確定要素が多すぎて使えない。「なんかインスタンス内でなんかおきてまっせ！」というのを検知できるんだなー程度にとどめておき、過度な期待はしない方がよいだろう。

CloudWatchを導入するメリット、デメリット

CloudWatchには以下のメリット、デメリットがあるらしい。

メリット	デメリット
・標準メトリクスの収集については自身での設定すら不要・監視対象であるAWSサービスがアップデートされても自動で追従してくれる	・メトリクスの保管期間が短い(※)(=長期的に保管したいなら自身でCloudWatchから収集済みのメトリクスを抜き出して保管する必要あり(※)) ・CloudWatch単体でアラートの発砲や自動再起動をしない期間の設定ができない(やるなら他のサービスも併用しての設定が必要(※))

※メトリクスの保管期間

監視間隔	保管期間
1分	15日間
5分	63日間
1時間	455日間

※メトリクスの長期保管
参考:https://qiita.com/Kept1994/items/aa76ae065d8d16c557a8

※アラートを一時的に止める
参考：https://qiita.com/kapioz/items/f2de33075d7f88f00ffe

CloudWatchエージェントのセットアップ

SSM経由でCloudWatchエージェントをインストール
EC2上で設定ファイルの雛形を作ってSSMのパラメータストアに保存
パラメータストア上の設定ファイルを編集
SSMから起動

1. SSMエージェントのセットアップ

SSMまとめ-SSMエージェントのセットアップに従って実施。

2. Cloudwatchエージェントのインストール

SSMまとめ-SSMコンソールからEC2へ任意のエージェントをセットアップに従って実施。

3. CloudWatchエージェントの設定

3.1. CloudWatchエージェントの設定ファイルの雛形作成とパラメータストアへの保存

設定ウィザードに従って実施する。

# メトリクスデータ取得対象のEC2インスタンスへSSHログイン

# 設定ウィザードを開始
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

# 以降、ウィザードに従って回答
## CloudWatchウィザードの設問について解説
On which OS are you planning to use the agent? 
=>CloudWatchエージェント動作させるOSを選択

Trying to fetch the default region based on ec2 metadata...
Are you using EC2 or On-Premises hosts? 
=>CloudWatchエージェントを動作させるのはEC2かオンプレミスのサーバーかを選択

Which user are you planning to run the agent? 
=>CloudWatchエージェントを起動するマシン内のユーザー名を設定

Do you want to turn on StatsD daemon?
=>StatsDデーモンを起動するか？(StatsDについては後述)

Do you want to monitor metrics from CollectD?
=>CollectDでカスタムメトリクスを採取したいか

Do you want to monitor any host metrics? e.g. CPU, memory, etc.
=>CPU、メモリといったシステム全体に対するカスタムメトリクスを採取したいか

Do you want to monitor cpu metrics per core? Additional CloudWatch charges may apply.
=>コアごとのCPUのカスタムメトリクスを採取したいか(これをYesにしても設定ファイル上はONになっていなかったのでバグかもしれない）

Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available?
=>利用できるならばImage ID、Instance　ID、Instance Type、Auto Scaling
 Group Nameというディメンジョンを全カスタムメトリクス内に追加したいか

※必要でない限りやらない方がよい。CloudWatch上でのデータ表示時も冗長になるし、APIでデータを取得するときにも全ディメンジョンを指定しないと取れないため面倒になる。

Would you like to collect your metrics at high resolution (sub-minute resolution)? This enables sub-minute resolution for all metrics, but you can customize for specific metrics in the output json file.
=>カスタムメトリクスを高解像度で取得したいか？全メトリクスに対して高解像度の設定になるが、個々に設定しあにのであれば、このウィザードを終えて出力される設定ファイルをカスタマイズすれば可能。

※高解像度にするとCloudWatch上に残る期間は短くなる。基本1分でいいのでは。

Which default metrics config do you want?
採取対象のカスタムメトリクスのデフォルト項目。
Basic、Standard、Advancedから選択できる(具体的に各選択肢がどの項目を採取することになるのかは
「https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html」を参照)。
選択すると、・・・にあるカスタムメトリクスが採取対象として設定ファイルに載ってくる。

Current config as follows:
{
....
}
Are you satisfied with the above config? Note: it can be manually customized after the wizard completes to add additional items.
=>ウィザードを経て設定ファイルは上記の内容で作成されることになるが問題ないか？
注記：ウィザードの後、手動で設定ファイルをいじることは可能。

※ウィザードではざっくり設定しかできないので、結局手動で設定ファイルをいじることになるが、いじる前の状態が最終形に近い方が後の設定作業が楽になるので、ここまで真面目に答えておいた方がいい。

Do you have any existing CloudWatch Log Agent (http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) configuration file to import for migration?
=>移行のためにインポートする既存のCloudWatch Log エージェント設定ファイルを持っているか？

※CloudWatchエージェントでCloudWatｃｈ Logsのための設定もできるようになったが、移行するか？ってことみたい。

Do you want to monitor any log files?
=>CloudWatch LogsへEC2内のログを送信したいか？


Current config as follows:
{
...
}
Please check the above content of the config.
The config file is also located at /opt/aws/amazon-cloudwatch-agent/bin/config.json.
Edit it manually if needed.
=>設定ファイルは/opt/aws/amazon-cloudwatch-agent/bin/config.json に保存されている。必要あれば手動で編集せい。

※SSMでパラメータストアから設定ファイルを指定してCloudWatchを起動する際にはこの場所には配置されない。
SSMから設定ファイルを適用してエージェントを起動した場合、その設定ファイルはEC2内の/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/ssm_<設定ファイル名>に保存される。

Do you want to store the config in the SSM parameter store?
=>SSMのパラメータストアに設定を保存するか？
ここは「yes」を選択する

What parameter store name do you want to use to store your config? (Use 'AmazonCloudWatch-' prefix if you use our managed AWS policy)
default choice: [AmazonCloudWatch-linux]
=>設定をパラメータストアへどんな名前で保存するか？AWSポリシーに従うのであれば「AmazonCloudWatch-」から始めろ。

Which region do you want to store the config in the parameter store?
=>どのリージョンのパラメータストアに設定を保存するか？

Which AWS credential should be used to send json config to parameter store?
=>パラメータストアに設定ファイルを送信するにあたってどのAWSクレデンシャルを使うか？

なんかよくわからんかった。
(デフォルトのクレデンシャルの番号に憶えがなかった)。
デフォルトの選択肢で一応動いたので新しく作られる？っぽい

3.2. CloudWatchエージェントの設定ファイルの手動編集

SSMまとめ-パラメータストア-設定ファイルの編集に従ってSSMコンソールのパラメータストア上で実施する。

3.3. collectdのセットアップ

EC2内の「ディスク使用状況」やシステム全体としての「メモリ使用状況」のメトリクスを取得するにはcollectdというソフトウェアをEC2へ導入する必要がある。
CloudWatchエージェントの設定ファイルにcollectd使いますと書いておきながら未インストールの状態でcloudwatchエージェントを起動すると、以下のようなエラーが出力される。

```
2020/05/22 08:33:21 E! Error parsing /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml, 
open /usr/share/collectd/types.db: no such file or directory

```

例. Ubuntu 14.04の場合の手順

# EC２へSSHログイン

# collectdのインストール
sudo apt-get update
sudo apt-get install collectd

# collectdの設定
curl -s -S -O "https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py"
chmod u+x setup.py
sudo ./setup.py

# 以下、質問に答えてセットアップ
Choose AWS region for published metrics:
  1. Automatic [ap-northeast-1]
  2. Custom
Enter choice [1]: 1
DEBUG:urllib3.util.retry:Converted retries value: 1 -> Retry(total=1, connect=None, read=None, redirect=None, status=None)
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 169.254.169.254:80
DEBUG:urllib3.connectionpool:http://169.254.169.254:80 "GET /latest/meta-data/instance-id/ HTTP/1.1" 200 19

Choose hostname for published metrics:
  1. EC2 instance id [XXXXXXXX]
  2. Custom
Enter choice [1]: 1
DEBUG:urllib3.util.retry:Converted retries value: 1 -> Retry(total=1, connect=None, read=None, redirect=None, status=None)
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 169.254.169.254:80
DEBUG:urllib3.connectionpool:http://169.254.169.254:80 "GET /latest/meta-data/iam/security-credentials/ HTTP/1.1" 200 37

Choose authentication method:
  1. IAM Role [<EC2へアタッチしたIAMロール>]
  2. IAM User
Enter choice [1]: 1

Enter proxy server name:
  1. None
  2. Custom
Enter choice [1]: 1

Enter proxy server port:
  1. None
  2. Custom
Enter choice [1]: 1

Include the Auto-Scaling Group name as a metric dimension:
  1. No
  2. Yes
Enter choice [1]: 1

Include the FixedDimension as a metric dimension:
  1. No
  2. Yes
Enter choice [1]: 1

Enable high resolution:
  1. Yes
  2. No
Enter choice [2]: 2

Enter flush internal:
  1. Default 60s
  2. Custom
Enter choice [1]: 1

Choose how to install CloudWatch plugin in collectd:
  1. Do not modify existing collectd configuration
  2. Add plugin to the existing configuration
Enter choice [2]: 2
Plugin configuration written successfully.
Stopping collectd process ... OK
Starting collectd process ... OK

※環境によってはsudo apt-get install collectdの場面でエラーが発生することも。自分の場合は以下が発生した(設定ファイル書き換え&sudo service collectd startで事なきを得た)。
https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1077732

なお、CloudWatch の Endpoint(monitoring.{{region}}.amazonaws.com) へ送信しているため、Outbound制限を掛けている場合は 443 ポートの許可が必要らしい。

補足:collectd, procstat, StatsDの違い

CloudWatchエージェントを使ってカスタムメトリクスを採取するにあたって、
状況に応じてcollectd, StatsD, procstatを使いわける必要がある模様。
色々調べた結果、役割上の違いは以下の通りと解釈した。

方法	概要
collectd	システム全体としてのディスク使用率、メモリ使用率などの内部リソースが取得できる。別途ソフトウェアのインストールが必要。
procstat	プロセス単位のCPU使用率、メモリ使用量などの内部リソースが取得できる。別途ソフトウェアのインストールは不要。
statsD	上記では叶えられないメトリクスデータを収集、送信する(自前でプログラムを用意する必要あり)

collectdで収集できるメトリクス
 procstatで収集できるメトリクス

CloudWatchまとめ

概要