Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
OpsJAWS-JAWSUG-KANAZAWA_20181123
Search
kaojiri
November 23, 2018
Technology
1
300
OpsJAWS-JAWSUG-KANAZAWA_20181123
2018/11/23 OpsJAWS-JAWSUG-KANAZAWAでの登壇資料(公開用)です。
kaojiri
November 23, 2018
Tweet
Share
More Decks by kaojiri
See All by kaojiri
コンテナ監視って何見るの?~初心者編~
kaojiri
8
5.8k
Kubernetesモニタリングのベストプラクティス_JAWSDays2021_20210320
kaojiri
0
1.1k
AWS SummitTokyo2019-reCap_20190620
kaojiri
1
75
JAWS-UG_SAITAMA_20190420
kaojiri
1
200
AWS Systems ManagerとAWS Configのちょっといい話
kaojiri
3
1.7k
組織を意識したAWS構成管理プロセスを考える_20180112
kaojiri
0
790
JAWS Days2017 EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
kaojiri
0
1.9k
OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~
kaojiri
1
1.2k
OpsJAWS#5 20160420 背伸びをしないAWS構成管理
kaojiri
0
3k
Other Decks in Technology
See All in Technology
Digitization部 紹介資料
sansan33
PRO
1
3.8k
いまさら聞けない Git 超入門 〜Gitって結局なに?から始める第一歩〜
devops_vtj
0
160
Data Hubグループ 紹介資料
sansan33
PRO
0
1.7k
AIとSREの未来 / AI and SRE
ymotongpoo
2
1.3k
技術書典18結果報告
mutsumix
2
180
GoogleのAI Agent
shukob
0
140
OTel meets Wasm: プラグイン機構としてのWebAssemblyから見る次世代のObservability
lycorptech_jp
PRO
1
300
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
38k
セキュリティSaaS企業が実践するCursor運用ルールと知見 / How a Security SaaS Company Runs Cursor: Rules & Insights
tetsuzawa
0
450
ソフトウェアテストのAI活用_ver1.10
fumisuke
0
240
What's Next in OpenShift Q2 CY2025
redhatlivestreaming
1
820
プロジェクトマネジメント実践論|現役エンジニアが語る!~チームでモノづくりをする時のコツとは?~
mixi_engineers
PRO
3
180
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
A Tale of Four Properties
chriscoyier
159
23k
Writing Fast Ruby
sferik
628
61k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
6
660
Gamification - CAS2011
davidbonilla
81
5.3k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.2k
A designer walks into a library…
pauljervisheath
205
24k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Navigating Team Friction
lara
186
15k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Transcript
CloudWatch Logs 設計Tips 2018/11/23 JAWS-UG KANAZAWA × OpsJAWS
Agenda 1. What’s CloudWatch Logs ?? 2. 設計Tips 1. サービス構造を意識する
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:コストを意識する
どこぞに以下のようなキラキラした話が… • サーバ内に入って調査・確認するのは負け!! • 外部に逃がしてステートレスに!!
None
None
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