CloudWatchと正面から向き合ってみる

みんな苦闘するCloudWatch。
習熟すれば少しは好きになれるんじゃないかと思いきちんと把握してみます。
AWSで完結できればいろいろ楽だし安いので、DataDogを入れる前に。

先に所感とまとめ

• 何だかんだ言ってCloudWatchはありがたい存在
  • いろいろ使いづらいところがあるとはいえ、色々な面倒事を無条件でやってくれるので
    • データ収集(ロギング、メトリクス化)、ストレージ、可視化
      • オンプレではFluentd, Zabbix, Kibanaなど構築しないとできないこと
    • 特にサーバレスだとその恩恵は大きい
• イベントで担保できるものはアラームではなくイベント駆動で通知する
  • サポートされている各サービスからの CloudWatch イベント イベントの例
  • ※CloudWatch EventsはAmazon EventBridgeに名称とサービスの立ち位置が変更され、将来的にこちらに統一される予定です。
• デフォルトのメトリクスは即座にアラームを作成して監視しましょう
  • CloudWatch メトリクスを発行する AWS のサービス
  • わざわざAWSがメトリクスまで作成してくれているので、アラームを作成するだけで監視できます
    • 例: Lambda のErrorsメトリクスを監視すれば、該当リージョンで発生した全てのLambdaのエラーを検知できます
• CloudWatchインサイトは普通に使いましょう
  • 一番意識の低いAWS CloudWatch Insights入門
• CloudWatch周りもすべてコード化すべき
  • 参考: serverless framework、Cloudformation & AWS SAM
  • 自動化されていない監視は何かを見落としているサイン（入門 監視）
• 監視は超重要
  • 入門 監視

用語

厳密には正しくないかもだけど、CloudWatchの用語を図と一言でざっくりまとめる。

ログイベント: 1行のログ
ログストリーム: ログをまとめたもの。例えば同じEC2インスタンスからのログは同じログストリームにまとめられる。
ロググループ: ログストリームをまとめたもの。
メトリクスフィルタ: ログをメトリクスに加工。またメトリクスをフィルタして別のメトリクスに加工。
メトリクス: ログを、グラフ描画やアラート通知に利用できる数値に加工したもの。
ディメンション: メトリクスのプロパティ。
統計: 指定した期間のメトリクスのデータの集計
アラーム: 指定した期間の単一のメトリクスの数値を監視し、設定したしきい値等を基準にアクションを起こす

• 詳細は以下を参照。
  • Amazon CloudWatch Logs の概念
  • ログデータの検索およびフィルタリング

監視と検知

• イベントで拾えるものはイベントで拾う
  • ※CloudWatch EventsはAmazon EventBridgeに名称とサービスの立ち位置が変更され、将来的にこちらに統一される予定です。
• イベントで拾えないものはアラームを使ってSNSに流す
  • AWS Chatbotは便利なので使いましょう
    • Slackのチャンネルに aws のユーザを登録しないと機能しないのでお気を付けください
  • CloudWatchアラーム通知をSlackにする

ログの中に Error という文字列が含まれていたら通知したい

• メトリクスフィルタを作成してError通知用メトリクスを作成し、それをアラームに使う
  • 例: 語句の出現回数をカウントする

調査・分析

ログデータの調査方法、検索方法、分析方法についてまとめる。
現状は↓の順に確認を行っている。

1. インサイト
2. デフォルトのダッシュボード(下の方に記載)
3. メトリクスからのログ確認

インサイト

CloudWatchを使っていて、まだインサイトを使っていない人は今すぐ使うべきです。
なぜなら5分の習熟で使いこなせて、それで充分に実用的だからです。

• 詳細は以下の記事を参照:
  • 一番意識の低いAWS CloudWatch Insights入門

ドキュメントではデフォでCLIを推奨される

マネコンのUIがつらいから？

それでもマネコンを使う場合

• フィルターパターンを使用したログデータ検索

可視化

ログデータの可視化についてまとめる。

ダッシュボード

デフォルトのダッシュボードは手っ取り早くAWSのサービスの状況を確認できる。

リソースグループ

• CloudWatchのダッシュボードでは表示できる件数が限られる(Lambdaなら100件までなど)ので、それを超過する場合は可視性の観点で導入するメリットが大きい
• タグベース or CloudFormationスタックベースでリソースをグルーピングできる

すべてのCFnスタックにリソースグループを作成するスクリプト

#!/usr/bin/env bash

# Stack IDのリストを取得(削除済みは除く)
TMP=/tmp/_tmp_stack_id
targets=(`aws cloudformation list-stacks | jq -r '.[][] | select(.DeletionTime==null) | .StackId'`)

# リソースグループを作成
for id in "${targets[@]}"
do
  stack=`echo $id | awk  -F'/' '{print $2}'`
  aws resource-groups create-group \
    --name ${stack} \
    --resource-query '{"Type": "CLOUDFORMATION_STACK_1_0", "Query": "{\"ResourceTypeFilters\":[\"AWS::AllSupported\"],\"StackIdentifier\":\"'${id}'\"}"}'
done

カスタムダッシュボード

便利だが、新規に作成されたリソースの追加が漏れがちなので悩ましいところ。

メモ

• 1つのロググループに属することができるログストリームの数に制限なし
• ログのストリームをダイレクトにLambdaに流せるらしい
• VPCを利用する場合はCloudWatch Logsにプライベート接続可能
• メトリクスはリージョン間で完全に分離されている
• AWS SDK Metricsでメトリクスをサポートと共有し効率よく問題解決
• メトリクス作成チュートリアル
• CloudWathch よくある質問
  • バイナリのログはサポートしていない
• TODO: 新機能の雑な感想
  • Syntheticsは外部監視(外形監視)として普通に使えそう
  • ServiceLensはX-Rayがより便利になった感じ(分散トレーシング)
  • Contributor Insightsは性能検証につかえそうだけど触ってない
  • CloudWatch settingsはマルチアカウントの監視が便利になったっぽい
  • Container Insightsはコンテナ用で便利でしょうが未検証