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
76
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
「伝える」を加速させるCursor術
naomix
0
640
(新URLに移行しました)FASTと向き合うことで見えた、大規模アジャイルの難しさと楽しさ
wooootack
0
740
kotlin-lsp を Emacs で使えるようにしてみた / use kotlin-lsp in Emacs
nabeo
0
160
Kotlinで学ぶ 代数的データ型
ysknsid25
5
1.1k
Snowflake Intelligenceで実現できるノーコードAI活用
takumimukaiyama
1
250
技術職じゃない私がVibe Codingで感じた、AGIが身近になる未来
blueb
0
130
從四件事帶你見識見識 事件驅動架構設計 (EDA)
line_developers_tw
PRO
0
130
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
240
自分を理解するAI時代の準備 〜マイプロフィールMCPの実装〜
edo_m18
0
110
vLLM meetup Tokyo
jpishikawa
1
240
CSS、JSをHTMLテンプレートにまとめるフロントエンド戦略
d120145
0
100
原則から考える保守しやすいComposable関数設計
moriatsushi
3
460
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
68
11k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Done Done
chrislema
184
16k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Cult of Friendly URLs
andyhume
79
6.4k
Code Reviewing Like a Champion
maltzj
524
40k
Producing Creativity
orderedlist
PRO
346
40k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
The Invisible Side of Design
smashingmag
299
51k
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