OpsJAWS-JAWSUG-KANAZAWA_20181123

Transcript

1. CloudWatch Logs 設計Tips 2018/11/23 JAWS-UG KANAZAWA × OpsJAWS

2. Agenda 1. What’s CloudWatch Logs ?? 2. 設計Tips 1. サービス構造を意識する

   2. トレースフローを意識した通知 3. コストを意識する 4. 目的を明確に

3. 1. What’s CloudWatch Logs ?? https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html

4. 2.1 設計Tips:サービス構造を意識する

5. 2.1 設計Tips:サービス構造を意識する • 構造 • ロググループ – ログストリームの親子関係 • 監視（通知）も可能

   • メトリクスフィルタを使用 • 通知はロググループ単位 • 設定方法 • Systems ManagerからCloudWatch Agentをインストール • 対象のログをどのログループ、ログストリームに送るかを設定 • ワイルドカード指定可能 • あらかじめ用意された動的変数（IPアドレスやインスタンス名など）を指定可能 ロググループ ログストリーム ログストリーム ログストリーム 通知の単位 通知の単位

6. 2.1 設計Tips:サービス構造を意識する • 通知の方式 • メトリクスフィルタで検知した数がメトリクスとしてあがる • その数を閾値にアラーム発報 • 通知される内容（SNS経由でメール送信する場合）

   • アラーム名、該当メトリクス • メトリクス情報の詳細 • 例えばErrorで引っかかった件数は分かるが、ログ内容は含まれず

7. 2.2 設計Tips:トレースフローを意識した通知

8. • 通知するのはサーバ単位か?ログ単位か? • 設計パターン１: • ロググループ:サーバ単位 • ログストリーム:ログ単位 • 設計パターン２:

   • ロググループ:サービス単位 • ログストローム:ログ単位 例:N台のサーバのテキストログを監視したい サーバ名 or IP ログB ログC ログA 通知の単位 通知の単位 ログA サーバ名 or IP サーバ名 or IP サーバ名 or IP 通知の単位 通知の単位

9. • どうなるか? • 設計パターン１: • アラーム・SNS Topicはサーバ単位で作成することになる • どのサーバでアラームが起きたかはわかるが、何のログで起こったかは 分からない

   • 設計パターン２: • アラーム・SNS Topicはログ単位で作成することになる • どのサービスでアラームが起きたかはわかるが、どのサーバで起こったかは 分からない 例:N台のサーバのテキストログを監視したい

10. • マネジメントコンソールでの確認方法 • 設計パターン１ : • ロググループ内で該当文字列で検索（ログストリーム横断） • ログストリームが特定できることで問題のサービスを特定 •

    設計パターン２ : • ロググループ内で該当文字列で検索（ログストリーム横断） • ログストリームが特定できることで問題のサーバを特定 例:N台のサーバのテキストログを監視したい

11. • とはいえ… • 絶対にマネジメントコンソールを見ないといけないのは辛い • 現実、無視できるものとキモい内容もある… • 通知は受けたうえで簡易的に判断できる仕組みは欲しい… • ので作った

    • LambdaからCloudWatch Logs内の該当箇所を抽出し本文に埋め込む • SDKからSNS publishすれば本文を自由に設定可能 • どのサーバ・どのログなのかも、1つのアラームで表現できる • ついでに日本語化 例:N台のサーバのテキストログを監視したい

12. 2.3 設計Tips:コストを意識する

13. どこぞに以下のようなキラキラした話が… • サーバ内に入って調査・確認するのは負け!! • 外部に逃がしてステートレスに!!

14. None
15. None

16. 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 • これが馬鹿にならない • 見積もり時にある程度積んでおくと後で安心

17. • 当たり前だけど、対象をちゃんと整理する • 本当に必要なログ（種類）のみ連携 • アプリ内でのログ出力最適化 • なんでもかんでも出せばいいってもんでもない • イベントログ（エラー）に出力し、Agentでイベントログのエラーのみ連携

    （Windowsの場合） • 別にサーバに入ってログを確認するでも、いいっちゃいい • 現実、皆がクラウドネイティブなわけじゃない • 組織みたいな話もある • ガバナンスが効いていることが大事 2.3 設計Tips:コストを意識する

18. $8,000くらい削減

19. 2.4 設計Tips:目的を明確に

20. 2.4 設計Tips:目的を明確に • 監視したいのか?保管したいのか?可視化したいのか? • 監視したいだけなら、対象のログだけ連携 • エラーだけ通知したければエラーログだけ • 保管したいだけなら、CloudWatch

    Logsじゃなくてもいい • カスタムスクリプトで纏めてS3へ とか • 可視化もしたければAthena – QuickSightとか? • S3への置き方大事 • 要件に応じて3rd partyも検討 • Splunk, Sumo logicなど • CloudWatch Agentでテキストログのフィルターかけたい

21. 3. まとめ • サービス構造を意識する • トレースフローを意識した通知 • コストを意識する • 目的を明確に

22. Thank you