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
290
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.7k
Kubernetesモニタリングのベストプラクティス_JAWSDays2021_20210320
kaojiri
0
1.1k
AWS SummitTokyo2019-reCap_20190620
kaojiri
1
74
JAWS-UG_SAITAMA_20190420
kaojiri
1
200
AWS Systems ManagerとAWS Configのちょっといい話
kaojiri
3
1.7k
組織を意識したAWS構成管理プロセスを考える_20180112
kaojiri
0
760
JAWS Days2017 EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
kaojiri
0
1.8k
OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~
kaojiri
1
1.2k
OpsJAWS#5 20160420 背伸びをしないAWS構成管理
kaojiri
0
2.9k
Other Decks in Technology
See All in Technology
[CATS]Amazon Bedrock GenUハンズオン座学資料 #2 GenU環境でRAGを体験してみよう
tsukuboshi
0
140
Symfony in 2025: Scaling to 0
fabpot
2
170
3/26 クラウド食堂LT #2 GenU案件を通して学んだ教訓 登壇資料
ymae
1
200
Go製のマイグレーションツールの git-schemalex の紹介と運用方法
shinnosuke_kishida
1
400
OPENLOGI Company Profile for engineer
hr01
1
22k
Vision Language Modelを活用した メルカリの類似画像レコメンドの性能改善
yadayuki
9
1.2k
Cloud Native PG 使ってみて気づいたことと最新機能の紹介 - 第52回PostgreSQLアンカンファレンス
seinoyu
1
180
モンテカルロ木探索のパフォーマンスを予測する Kaggleコンペ解説 〜生成AIによる未知のゲーム生成〜
rist
4
1.1k
新卒エンジニア研修の試行錯誤と工夫/nikkei-tech-talk-31
nishiuma
0
190
Redefine_Possible
upsider_tech
0
240
20250326_管理ツールの権限管理で改善したこと
sasata299
1
360
AI・LLM事業部のSREとタスクの自動運転
shinyorke
PRO
0
300
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
336
57k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
7
610
The Language of Interfaces
destraynor
157
24k
Java REST API Framework Comparison - PWX 2021
mraible
29
8.5k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.4k
Typedesign – Prime Four
hannesfritz
41
2.6k
Rails Girls Zürich Keynote
gr2m
94
13k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
How to train your dragon (web standard)
notwaldorf
91
5.9k
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