Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OpsJAWS-JAWSUG-KANAZAWA_20181123

kaojiri
November 23, 2018

 OpsJAWS-JAWSUG-KANAZAWA_20181123

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

kaojiri

November 23, 2018
Tweet

More Decks by kaojiri

Other Decks in Technology

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. • 通知するのはサーバ単位か?ログ単位か?
    • 設計パターン1:
    • ロググループ:サーバ単位
    • ログストリーム:ログ単位
    • 設計パターン2:
    • ロググループ:サービス単位
    • ログストローム:ログ単位
    例:N台のサーバのテキストログを監視したい
    サーバ名 or IP ログB
    ログC
    ログA
    通知の単位
    通知の単位
    ログA サーバ名 or IP
    サーバ名 or IP
    サーバ名 or IP
    通知の単位
    通知の単位

    View Slide

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

    View Slide

  10. • マネジメントコンソールでの確認方法
    • 設計パターン1 :
    • ロググループ内で該当文字列で検索(ログストリーム横断)
    • ログストリームが特定できることで問題のサービスを特定
    • 設計パターン2 :
    • ロググループ内で該当文字列で検索(ログストリーム横断)
    • ログストリームが特定できることで問題のサーバを特定
    例: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