CloudWatchの詳しい設定など色々調べてみた #AWS

##CloudWatch Alarm##

###期間###

上記の図のような設定の場合、
5 分間隔で 5 回のうち 2 回、
CPUUtilization が 20％を超えたときにCloudWatch アラームが通知されるようになる。

Amazon CloudWatch アラームで､ある期間に N 個のメトリクスのうち M 個のメトリクスデータポイントがしきい値を上回った場合にアラートが表示される

###欠落データの処理方法###

EC2インスタンスに対する CPUUtilization や StatusCheckFailed であれば、インスタンス起動中は連続して通知されるため、任意の閾値でアラームの発生・復旧をコントロールできます。
しかし、ELBの HTTPCode_ELB_5XX のような、事象発生時のみ通知される不連続なメトリックスでは、通知発生時にはアラームとすることが可能ですが、何も通知がない状態では「不明」のステータスとなってしまいました。

missing(見つかりません)—このアラームは、状態を変更するかどうかを評価する際に、欠落データポイントを考慮に入れません。
notBreaching(適正)—欠落データポイントはしきい値内として扱われます。
breaching(不正)—欠落データポイントはしきい値超過として扱われます。
ignore(無視)—現在のアラーム状態が維持される

[CloudWatch アラームの欠落データの処理の設定]
(https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)

##CloudWatch Events##

###イベントパターン###
イベントパターンとスケジュールの2つから設定できる。
イベントタイプは↓から確認できる。
サポートされている各サービスからの CloudWatch イベントイベントの例

###スケジュール###
例えば、指定の時間にEC2を停止し、指定の時間にEC2を起動するように設定し、コストを抑えたいときなどに便利。

Cron 式は↓の形式で記述する。↑の設定、0 13 * * ? *　タイムゾーンに注意。
グリニッジ標準時(GMT)で解釈されます。日本時間(JST)の設定をGMTに変換して入力する必要があります。(日本時間の22時は、GMTだと13時)
ルールのスケジュール式

###ターゲット###
ターゲットとして設定できるのは↓。
Amazon CloudWatch Events とは

##CloudWatch Logs##

詳しい設定は省きますが、EC2にawslogsをインストールし、EC2のlogsをCloudWatchへ送ると↓な感じになる。

sudo yum install -y awslogs

vim　/etc/awslogs/awscli.conf
[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-1

vim　/etc/awslogs/awslogs.conf
[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/messages

sudo service awslogs start
sudo chkconfig awslogs on

###メトリックスフィルタの設定###
フィルタパターンの書き方は↓を参照。
フィルターとパターンの構文

###メトリクス値とデフォルト値###
例えば↓の例だと「Error」を含む各ログイベントのカウントは 1 ずつ増分されるということになる。
デフォルト値については、一致が見つかった場合のメトリクス値の変更方法の設定のページを見た方がいいかも。

###カスタムメトリクスの削除###
メトリックスフィルタからは削除した。

でもなぜか、消えない。

カスタムメトリックスを明示的に削除する手段は、マネージメントコンソールにもAPIにも存在しない。
2週間待って、CloudWatchのから自然消滅するのを待て、ということらしい。
カスタムメトリックスを削除