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

OpsJAWS-JAWSUG-KANAZAWA_20181123

C8b3d5eaa8c8a490a1530b9b5256a2a9?s=47 kaojiri
November 23, 2018

 OpsJAWS-JAWSUG-KANAZAWA_20181123

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

C8b3d5eaa8c8a490a1530b9b5256a2a9?s=128

kaojiri

November 23, 2018
Tweet

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. • 通知するのはサーバ単位か?ログ単位か? • 設計パターン1: • ロググループ:サーバ単位 • ログストリーム:ログ単位 • 設計パターン2:

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

    • 設計パターン2: • アラーム・SNS Topicはログ単位で作成することになる • どのサービスでアラームが起きたかはわかるが、どのサーバで起こったかは 分からない 例:N台のサーバのテキストログを監視したい
  10. • マネジメントコンソールでの確認方法 • 設計パターン1 : • ロググループ内で該当文字列で検索(ログストリーム横断) • ログストリームが特定できることで問題のサービスを特定 •

    設計パターン2 : • ロググループ内で該当文字列で検索(ログストリーム横断) • ログストリームが特定できることで問題のサーバを特定 例: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