CloudWachLogsのロググループ設計について見直してみた
CloudWatchLogsのロググループ設計について考えたことをシェアしたいと思います。
結論
AutoScalingグループで運用している場合は、グループごとにロググループを作成したほうが良い。
AutoScalingグループを使用していないのであれば、一つのロググループにまとめてしまった方がいい。
考えるに至った経緯
CloudWatchLogsにsyslogを転送できていないEC2インスタンスが複数あり、対応することになりました。
現在はEC2インスタンスごとにロググループを作成されているが、ベストプラクティス的には同じ用途のログは一つのロググループで管理し、ログストリーム名をインスタンスIDにするらしいです。
syslogを一元管理しておけば、AWS障害などが発生したときに影響あるインスタンスを1発で洗い出せるので便利そうだなと思いました。
もちろん、ログストリームで個別のインスタンスごとのトラブルシューティングも可能なので、ロググループの設計を見直した方がよさそう？
検討
まずは、一つのロググループにまとめるか、今のままでいくかのメリデメを調べてみました。
以下のサイトがわかりやすかったです。
ベストプラクティスは「一つにまとめる」 なので、そのデメリットが許容できるかどうかの調査をしました。調査結果は以下の通りです。
・インスタンス数は20台程度で、コンテナ化も別途進めているので将来的にもどんどん少なくなっていく。
・syslogは、AWS障害時の影響調査で横断的にログを確認したいケースも普通にあるので、インスタンスごと、インスタンス全体でログを見れるようにしておくメリットは大きい。
・アカウントにゴミリソースがたくさんあり、別途整理中なので、その観点からもロググループは減らせるなら減らしたい。
ざっくり、ログの用途とログイベントの量を確認できれば、syslog以外でも「ひとつにまとめる」か否かの判断ができるかなと思いました😎
ロググループをインスタンスごとの管理から「一つにまとめる」ための手順は以下になります。
「一つにまとめる」ための手順
まず、注意しなくてはならないのが、メトリクスフィルターの存在です。
メトリクスフィルターについては以下が参考になります。
メトリクスフィルターはロググループに紐づくので、「一つにまとめる」過程で機能しなくなります。
そうなると、後続のCloudWatchAlarmやSNS等が機能しなくなるので、既存監視に穴が生まれます。
というわけで、まずはメトリクスフィルターの状況を確認します。
※出力量が多い場合は、適宜整形をしてください🙇♂️
aws logs describe-metric-filters
CloudShellから上記のCLIを叩いて、各メトリクスフィルターのLogGroupNameに一元管理対象となるロググループが含まれていないかを確認します。
もしあれば、MetricTransformations内のMetricNameを控えます。
aws cloudwatch desribe-alarms
上記のCLIでMetricNameが前述のMetricTransformations内のMetricNameと一致しているものがあれば、そのCloudWatchAlarmは「一つにまとめる」過程で機能しなくなるので別途対応する必要があります。
同じような容量でSNS等も調べる形になるかと思います。
私は幸いにもメトリクスフィルターが使われていないことが分かったので、この辺は割愛させていただきます🙇♂️
懸念事項の整理が終わったところで、実際にCloudWatchArgentのインストールや設定を行いたいと思います。(既にCloudWatchArgentが入っていればインストールは当然不要です)
SystemsManagerのRun Commandを使えば、対象のEC2インスタンス全てに設定を付与できるのでお勧めです。(後述の理由により、エアプ🙇♂️)
CloudWatchArgentの設定はロググループを一元管理するのであれば、ロググループが全インスタンスで共通になるのでRun Commandが使えます。
落とし穴
ここまで手順を整理していたわけですが、結局、ロググループを「一つにまとめる」ことはせず、今のままのロググループ設計を採用することにしました。。。
AutoScalingグループの存在を完全に見落としていました😭
ロググループを「一つにまとめる場合」、ログストリーム名を見て、どのインスタンスのログなのか判断することになりますが、AutoScalingグループ管理のものが混じっていると色々大変です。
インスタンス名はわかったとして、そもそもAutoScalingグループに属しているのか、どのAutoScalingグループに属しているのかといったことが見えにくくなり、かえって効率が悪くなります。
fluentbitなどでログ整形をして、例えばログイベントの頭にAutoScalingグループ名を入れたりとかもできなくはないですが、結局、ログストリームからさらに一段下のログイベントを見ていかないと判断できないし、ログ整形するなら、他にも色々な観点を踏まえて、出力ログの設計から実施するべきだと思います。前述の通り、コンテナ化を進めていて最終的にEC2は廃止する予定であることや工数などを踏まえて、今のままの運用をしていくのがベストという結論に至りました。
Run Command使ってみたかったですが、ロググループ分けるのであれば、インスタンスごとに個別対応となるので今回は使用できず。。。😭
まとめ
CloudWatchLogsにログ転送できていないインスタンスをできるようにはしましたが、設計の観点からいくと、何も変更しないという面白みのない着地となってしまいました😭
結論変わらずとも、検討内容をシェアすれば、自分の理解を深めることもできるはず！という考えで、今後発信していきたいと思います！
Discussion