Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
OpsJAWS-JAWSUG-KANAZAWA_20181123
kaojiri
November 23, 2018
Technology
1
230
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
4.7k
Kubernetesモニタリングのベストプラクティス_JAWSDays2021_20210320
kaojiri
0
370
AWS SummitTokyo2019-reCap_20190620
kaojiri
1
52
JAWS-UG_SAITAMA_20190420
kaojiri
1
180
AWS Systems ManagerとAWS Configのちょっといい話
kaojiri
3
990
組織を意識したAWS構成管理プロセスを考える_20180112
kaojiri
0
500
JAWS Days2017 EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
kaojiri
0
1.3k
OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~
kaojiri
1
760
OpsJAWS#5 20160420 背伸びをしないAWS構成管理
kaojiri
0
2.4k
Other Decks in Technology
See All in Technology
音のような言葉 〜ちゃちゃっとチャットで楽しむちょっとしたコツ〜 / words like sounds
satoryu
1
1.3k
2022年度新卒技術研修「良いコードの書き方」講義
excitejp
PRO
0
290
Azure Arc Virtual MachineとAzure Arc Resource Bridge / VM provisioning through Azure portal on Azure Stack HCI (preview)
sashizaki
0
120
【Pythonデータ分析勉強会#33】「DearPyGuiに入門しました」の続き~Image-Processing-Node-Editor~
kazuhitotakahashi
0
110
多様な成熟度のデータ活用を総合支援するKADOKAWA Connectedのデータ組織について
kadokawaconnected
PRO
0
200
GeoLocationAnchor and MKTileOverlay
toyship
0
110
JFrog 最新情報 - JFrog DevOps プラットフォームの今までとこれから / jfrog-update-for-devopskaigi-2022
tsuyo
0
150
DOM Invader - prototype pollution対応の衝撃 - / DOM Invader - prototype pollution
okuken
0
100
Istio入門
nutslove
15
4.9k
History of the ML system in KARTE
kargo113
0
610
How to start with DDD when you have a Monolith
javujavichi
0
270
データ分析で切り拓け! エンジニアとしてのデータ分析職キャリア戦略
ksnt
0
110
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
46
3.9k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
172
8.4k
Rebuilding a faster, lazier Slack
samanthasiow
62
7.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
181
15k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
236
1M
Design by the Numbers
sachag
271
17k
Typedesign – Prime Four
hannesfritz
33
1.3k
Three Pipe Problems
jasonvnalue
89
8.7k
Become a Pro
speakerdeck
PRO
3
840
Designing for Performance
lara
597
63k
We Have a Design System, Now What?
morganepeng
35
3k
Infographics Made Easy
chrislema
233
17k
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