OpsJAWS-JAWSUG-KANAZAWA_20181123

2018/11/23 OpsJAWS-JAWSUG-KANAZAWAでの登壇資料（公開用）です。

Transcript

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

   View Slide

2. Agenda
   1. What’s CloudWatch Logs ??
   2. 設計Tips
   1. サービス構造を意識する
   2. トレースフローを意識した通知
   3. コストを意識する
   4. 目的を明確に
   

   View Slide

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

   View Slide

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

   View Slide

5. 2.1 設計Tips:サービス構造を意識する
   • 構造
   • ロググループ – ログストリームの親子関係
   • 監視（通知）も可能
   • メトリクスフィルタを使用
   • 通知はロググループ単位
   • 設定方法
   • Systems ManagerからCloudWatch Agentをインストール
   • 対象のログをどのログループ、ログストリームに送るかを設定
   • ワイルドカード指定可能
   • あらかじめ用意された動的変数（IPアドレスやインスタンス名など）を指定可能
   ロググループ ログストリーム
   ログストリーム
   ログストリーム
   通知の単位
   通知の単位
   

   View Slide

6. 2.1 設計Tips:サービス構造を意識する
   • 通知の方式
   • メトリクスフィルタで検知した数がメトリクスとしてあがる
   • その数を閾値にアラーム発報
   • 通知される内容（SNS経由でメール送信する場合）
   • アラーム名、該当メトリクス
   • メトリクス情報の詳細
   • 例えばErrorで引っかかった件数は分かるが、ログ内容は含まれず
   

   View Slide

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

   View Slide

8. • 通知するのはサーバ単位か?ログ単位か?
   • 設計パターン１:
   • ロググループ:サーバ単位
   • ログストリーム:ログ単位
   • 設計パターン２:
   • ロググループ:サービス単位
   • ログストローム:ログ単位
   例:N台のサーバのテキストログを監視したい
   サーバ名 or IP ログB
   ログC
   ログA
   通知の単位
   通知の単位
   ログA サーバ名 or IP
   サーバ名 or IP
   サーバ名 or IP
   通知の単位
   通知の単位
   

   View Slide

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

   View Slide

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

    View Slide

11. • とはいえ…
    • 絶対にマネジメントコンソールを見ないといけないのは辛い
    • 現実、無視できるものとキモい内容もある…
    • 通知は受けたうえで簡易的に判断できる仕組みは欲しい…
    • ので作った
    • LambdaからCloudWatch Logs内の該当箇所を抽出し本文に埋め込む
    • SDKからSNS publishすれば本文を自由に設定可能
    • どのサーバ・どのログなのかも、1つのアラームで表現できる
    • ついでに日本語化
    例:N台のサーバのテキストログを監視したい
    

    View Slide

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

    View Slide

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

    View Slide

14. View Slide

15. View Slide

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

    View Slide

17. • 当たり前だけど、対象をちゃんと整理する
    • 本当に必要なログ（種類）のみ連携
    • アプリ内でのログ出力最適化
    • なんでもかんでも出せばいいってもんでもない
    • イベントログ（エラー）に出力し、Agentでイベントログのエラーのみ連携
    （Windowsの場合）
    • 別にサーバに入ってログを確認するでも、いいっちゃいい
    • 現実、皆がクラウドネイティブなわけじゃない
    • 組織みたいな話もある
    • ガバナンスが効いていることが大事
    2.3 設計Tips:コストを意識する
    

    View Slide

18. $8,000くらい削減
    

    View Slide

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

    View Slide

20. 2.4 設計Tips:目的を明確に
    • 監視したいのか?保管したいのか?可視化したいのか?
    • 監視したいだけなら、対象のログだけ連携
    • エラーだけ通知したければエラーログだけ
    • 保管したいだけなら、CloudWatch Logsじゃなくてもいい
    • カスタムスクリプトで纏めてS3へ とか
    • 可視化もしたければAthena – QuickSightとか?
    • S3への置き方大事
    • 要件に応じて3rd partyも検討
    • Splunk, Sumo logicなど
    • CloudWatch Agentでテキストログのフィルターかけたい
    

    View Slide

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

    View Slide

22. Thank you
    

    View Slide