タダです.

システムの中で CloudWatch Logs に Apache のログを保存しているのですが,大量のログとなっています.このログの中から HTTP ステータスコードが4XX 系を抽出してエラー発生数をモニタリングしたい時に,「check-aws-cloudwatch-logs-insights」の Mackerel プラグインを使って検証してみたのでその内容をこの記事でまとめます.

check-aws-cloudwatch-logs-insights とは

Mackerel の「check-aws-cloudwatch-logs-insights」プラグインは現在(2020年12月29日時点)β版公開されているもので,CloudWatch Logs Insights 経由で大量のログ監視に有用な機能とされてます.この機能を使って監視を入れてみました.

mackerel.io

プラグインの導入

プラグインの実行環境は CentOS 7 の EC2 です.導入コマンドは下記のコマンドを実行して完了です.mkr コマンドがない場合は導入してから実行します.

sudo mkr plugin install mackerelio-labs/check-aws-cloudwatch-logs-insights@v0.0.2

監視の設定の実施

IAM ロールの設定

EC2 の IAM ロールにlogs:GetQueryResults/logs:StartQuery/logs:StopQuery の権限をつけた IAM ポリシーをアタッチします.検証なのでリソースは絞ってないですが,権限制御する場合はリソースで特定のロググループを指定します(ex. arn:aws:logs:ap-northeast-1:XXXXXXXXXXXX:log-group:/XXXX/access_log:* 等).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "check-aws-cloudwatch-logs-insights-test",
            "Effect": "Allow",
            "Action": [
                "logs:StartQuery",
                "logs:GetQueryResults",
                "logs:StopQuery"
            ],
            "Resource": "*"
        }
    ]
}

mackerel-agent のコンフィグ定義

監視の設定例はプラグインの紹介記事にも記載がありますが,他のプラグイン同様に/etc/mackerel-agent/mackerel-agent.confで次のような定義を行います.

[plugin.checks.aws-cloudwatch-logs-insights-test]
command = ["/opt/mackerel-agent/plugins/bin/check-aws-cloudwatch-logs-insights", "--log-group-name", "/XXX/access_log", "--filter", "parse '* - * [*] \"* * *\" * * * *' as host, identity, date, method, path, protocol, statuscode, bytes,referer,useragent | sort date desc | filter statuscode like /(4\\d\\d)/" "--critical-over", "10", "--warning-over", "1"]
env = { AWS_REGION = "ap-northeast-1" }

--log-group-name で CloudWatch Logs Insights を実行するロググループ名を指定してます.
--filter で CloudWatch Logs Insights のクエリ文を書いています.Apache のログフォーマットをパースしてフィルタリングしています.parse 以降の ""とステータスコードの4\d\d にはエスケープ文字を追加しないと認識しないため定義しています.後述しますがここが一番苦労した部分です.
--critical-over で CloudWatch Logs Insights のクエリの結果の Critical になる件数を定義しています.10件超えたら Critical と言う定義です.
--warning-over で CloudWatch Logs Insights のクエリの結果の Warning になる件数を定義しています.1件超えたら Warning と言う定義です.

アラートの設定確認

ステータスコードが4XX 系エラーであれば1件出れば Warning,10件出れば Criticalとしているのですが,mackerel-agent を起動した後アラート一覧の画面をみてみると意図通りアラートが出ているのを確認できました.

f:id:sadayoshi_tada:20201229123644p:plain

設定のよもやま話

上述したように --filter の箇所の定義が一番苦労し,Mackerel User Group の Slack で開発者の id:astj さんに調査サポートいただきました...ここで改めて感謝いたします.ありがとうございました🙇‍♂️

mackerel-ug-slackin.herokuapp.com

一番ハマったのがエスケープ文字の認識のところです.当初は parse 内の [*] の箇所を \\[*\\]のようにしていました.コマンドでの実行(AWS_REGION=ap-northeast-1 /opt/mackerel-agent/plugins/bin/check-aws-cloudwatch-logs-insights --log-group-name=/xxx/access_log --filter="parse '* - * \[\*\]\ \"\* * *\"\ * * * *' as host, identity, date, method, path, protocol, statuscode, bytes,referer,useragent | sort date desc | filter statuscode like /(4\d\d)/")やMackerel のコンフィグ的には通るのですが,ログを見ると CloudWatch Logs Insights OK: 0 messages とでており,ログ検索ができていませんでした.調査をサポートいただき,最終的にエスケープ文字は不要で [*] に戻しています.Mackerel を通した時に CloudWatch Log Insights 側まで \[*\] のフィルターの形で検索してしまっていたため元に戻すことにして意図通りの設定を実現できました.

まとめ

「check-aws-cloudwatch-logs-insights」のプラグインを検証した内容をまとめました.意図した監視ができるようになったので本番の方にも組み込んでいきたいと思いますし,改めて Slack のユーザーグループで開発者の方とやりとりできるありがたさを実感しました.もし入ってない方がいれば入って困っていることや悩み事を利用者の皆さんや開発者の皆さんと会話してみると良いかも知れません！

sadayoshi-tada.hatenablog.com