概要

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となる原因の例らしい。
    • システム ステータス チェックの失敗
    • 不正 な ネットワーク また は スタートアップ 構成
    • メモリ不足
    • 破損したファイルシステム
    • 互換性のないカーネル
  • インスタンス ステータス チェックについてはなかなか疑問あり。
  • 実際 に メモリ が めちゃくちゃ 使う れ て い て 、 実際 に サーバー が 死ぬ で い た 状態 だっ た とき に も 引く かかる こと は なかっ た し 、 そもそも 全 項目 が 公開 さ れ て いる わけ で は なく 、 その 判定 基準 も ブラック ボックス な の で 今回 の 要件 に は 不 確定 要素 is 使え が 多い すぎる て 使える ない 。 「 なん か インスタンス 内 で なんか おきる て まつ せ ！ 」 と いう の を 検知 できる ん だ なー 程度 に とどめる て おく 、 過度 な 期待 は し ない 方 is よい が よい だろう 。

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

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

※ メトリクス の 保管 期間

※ メトリクス の 長期 保管
参考: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のセットアップ

EC 2 内 の 「 ディスク 使用 状況 」 や システム 全体 と し て の 「 メモリ 使用 状況 」 の メトリクス を 取得 する に は collectd と いう ソフトウェア を EC 2 へ 導入 する 必要 is ある が ある 。
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 で 収集 できる メトリクス