2018/11/23 OpsJAWS-JAWSUG-KANAZAWAでの登壇資料(公開用)です。
CloudWatch Logs設計Tips2018/11/23JAWS-UG KANAZAWA×OpsJAWS
View Slide
Agenda1. What’s CloudWatch Logs ??2. 設計Tips1. サービス構造を意識する2. トレースフローを意識した通知3. コストを意識する4. 目的を明確に
1. What’s CloudWatch Logs ??https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html
2.1 設計Tips:サービス構造を意識する
2.1 設計Tips:サービス構造を意識する• 構造• ロググループ – ログストリームの親子関係• 監視(通知)も可能• メトリクスフィルタを使用• 通知はロググループ単位• 設定方法• Systems ManagerからCloudWatch Agentをインストール• 対象のログをどのログループ、ログストリームに送るかを設定• ワイルドカード指定可能• あらかじめ用意された動的変数(IPアドレスやインスタンス名など)を指定可能ロググループ ログストリームログストリームログストリーム通知の単位通知の単位
2.1 設計Tips:サービス構造を意識する• 通知の方式• メトリクスフィルタで検知した数がメトリクスとしてあがる• その数を閾値にアラーム発報• 通知される内容(SNS経由でメール送信する場合)• アラーム名、該当メトリクス• メトリクス情報の詳細• 例えばErrorで引っかかった件数は分かるが、ログ内容は含まれず
2.2 設計Tips:トレースフローを意識した通知
• 通知するのはサーバ単位か?ログ単位か?• 設計パターン1:• ロググループ:サーバ単位• ログストリーム:ログ単位• 設計パターン2:• ロググループ:サービス単位• ログストローム:ログ単位例:N台のサーバのテキストログを監視したいサーバ名 or IP ログBログCログA通知の単位通知の単位ログA サーバ名 or IPサーバ名 or IPサーバ名 or IP通知の単位通知の単位
• どうなるか?• 設計パターン1:• アラーム・SNS Topicはサーバ単位で作成することになる• どのサーバでアラームが起きたかはわかるが、何のログで起こったかは分からない• 設計パターン2:• アラーム・SNS Topicはログ単位で作成することになる• どのサービスでアラームが起きたかはわかるが、どのサーバで起こったかは分からない例:N台のサーバのテキストログを監視したい
• マネジメントコンソールでの確認方法• 設計パターン1 :• ロググループ内で該当文字列で検索(ログストリーム横断)• ログストリームが特定できることで問題のサービスを特定• 設計パターン2 :• ロググループ内で該当文字列で検索(ログストリーム横断)• ログストリームが特定できることで問題のサーバを特定例:N台のサーバのテキストログを監視したい
• とはいえ…• 絶対にマネジメントコンソールを見ないといけないのは辛い• 現実、無視できるものとキモい内容もある…• 通知は受けたうえで簡易的に判断できる仕組みは欲しい…• ので作った• LambdaからCloudWatch Logs内の該当箇所を抽出し本文に埋め込む• SDKからSNS publishすれば本文を自由に設定可能• どのサーバ・どのログなのかも、1つのアラームで表現できる• ついでに日本語化例:N台のサーバのテキストログを監視したい
2.3 設計Tips:コストを意識する
どこぞに以下のようなキラキラした話が…• サーバ内に入って調査・確認するのは負け!!• 外部に逃がしてステートレスに!!
2.3 設計Tips:コストを意識する• 全体利用料の1/3がCloudWatch Logs…• 一般的にAWS利用料はEC2/DB系が80%以上と言われているのに…• 価格体系を確認 https://aws.amazon.com/jp/cloudwatch/pricing/• 保存料金はS3程度 :$0.33/GB• 取り込みにも金がかかる :$0.76/GB• これが馬鹿にならない• 見積もり時にある程度積んでおくと後で安心
• 当たり前だけど、対象をちゃんと整理する• 本当に必要なログ(種類)のみ連携• アプリ内でのログ出力最適化• なんでもかんでも出せばいいってもんでもない• イベントログ(エラー)に出力し、Agentでイベントログのエラーのみ連携(Windowsの場合)• 別にサーバに入ってログを確認するでも、いいっちゃいい• 現実、皆がクラウドネイティブなわけじゃない• 組織みたいな話もある• ガバナンスが効いていることが大事2.3 設計Tips:コストを意識する
$8,000くらい削減
2.4 設計Tips:目的を明確に
2.4 設計Tips:目的を明確に• 監視したいのか?保管したいのか?可視化したいのか?• 監視したいだけなら、対象のログだけ連携• エラーだけ通知したければエラーログだけ• 保管したいだけなら、CloudWatch Logsじゃなくてもいい• カスタムスクリプトで纏めてS3へ とか• 可視化もしたければAthena – QuickSightとか?• S3への置き方大事• 要件に応じて3rd partyも検討• Splunk, Sumo logicなど• CloudWatch Agentでテキストログのフィルターかけたい
3. まとめ• サービス構造を意識する• トレースフローを意識した通知• コストを意識する• 目的を明確に
Thank you