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
270
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.5k
Kubernetesモニタリングのベストプラクティス_JAWSDays2021_20210320
kaojiri
0
910
AWS SummitTokyo2019-reCap_20190620
kaojiri
1
70
JAWS-UG_SAITAMA_20190420
kaojiri
1
190
AWS Systems ManagerとAWS Configのちょっといい話
kaojiri
3
1.6k
組織を意識したAWS構成管理プロセスを考える_20180112
kaojiri
0
720
JAWS Days2017 EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
kaojiri
0
1.7k
OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~
kaojiri
1
1.1k
OpsJAWS#5 20160420 背伸びをしないAWS構成管理
kaojiri
0
2.9k
Other Decks in Technology
See All in Technology
Fediverse Discovery Providers overview
andypiper
0
170
PdMはどのように全てのスピードを上げられるか ~ 非連続進化のための具体的な取り組み ~
sansantech
PRO
4
1.3k
JTCや セキュリティチェックリストが夢の跡
nikinusu
0
620
Developer Experienceを向上させる基盤づくりの取り組み事例集
coconala_engineer
0
150
リアルお遍路+SORACOM IoT
ozk009
1
140
言葉は感情の近似値である。その感情と言葉の誤差を最小化しよう ~コミュニケーションにおけるアナログ/デジタル変換の課題に立ち向かう~
nktamago
0
220
『GRANBLUE FANTASY Relink』キャラクターの魅力を支えるリグ・シミュレーション制作事例
cygames
0
120
「家族アルバム みてね」における運用管理・ オブザーバビリティの全貌 / Overview of Operation Management and Observability in FamilyAlbum
isaoshimizu
4
160
たった1人からはじめる【Agile Community of Practice】~ソース原理とFearless Changeを添えて~
ktc_corporate_it
1
480
忙しい人のためのLangGraph概要まとめ
__ymgc__
1
190
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
46k
スタッフエンジニアの道: The Staff Engineer’s Path
snoozer05
PRO
44
14k
Featured
See All Featured
Atom: Resistance is Futile
akmur
261
25k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
27
7.4k
Making Projects Easy
brettharned
113
5.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
58k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
A Philosophy of Restraint
colly
202
16k
Designing for humans not robots
tammielis
248
25k
Documentation Writing (for coders)
carmenintech
65
4.3k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
5
480
A designer walks into a library…
pauljervisheath
201
24k
How to train your dragon (web standard)
notwaldorf
85
5.6k
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