Submit Search
Upload
Monitoring - 入門監視
•
2 likes
•
1,046 views
Eiji KOMINAMI
Follow
監視とはいったいどのような状態を指すのか、何の目的でどの項目をどのように「監視」したら良いのか。普段何気なく行なっている監視について改めて考え直します。
Read less
Read more
Technology
Report
Share
Report
Share
1 of 44
Download now
Download to read offline
Recommended
Amazon Game Tech Night #25 ゲーム業界向け機械学習最新状況アップデート
Amazon Game Tech Night #25 ゲーム業界向け機械学習最新状況アップデート
Amazon Web Services Japan
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Yahoo!デベロッパーネットワーク
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
Akihiro Kuwano
Google Cloud で実践する SRE
Google Cloud で実践する SRE
Google Cloud Platform - Japan
Recommended
Amazon Game Tech Night #25 ゲーム業界向け機械学習最新状況アップデート
Amazon Game Tech Night #25 ゲーム業界向け機械学習最新状況アップデート
Amazon Web Services Japan
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Yahoo!デベロッパーネットワーク
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
Akihiro Kuwano
Google Cloud で実践する SRE
Google Cloud で実践する SRE
Google Cloud Platform - Japan
分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方
Recruit Lifestyle Co., Ltd.
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
Shota Shinogi
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
Ito Takayuki
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
Yusuke Suzuki
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
Amazon Web Services Japan
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Recruit Lifestyle Co., Ltd.
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
Masahito Zembutsu
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
disc99_
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
DevOps with Database on AWS
DevOps with Database on AWS
Amazon Web Services Japan
20050809
20050809
小野 修司
Project Management
Project Management
Kazuto Omori
More Related Content
What's hot
分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方
Recruit Lifestyle Co., Ltd.
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
Shota Shinogi
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
Ito Takayuki
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
Yusuke Suzuki
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
Amazon Web Services Japan
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Recruit Lifestyle Co., Ltd.
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
Masahito Zembutsu
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
disc99_
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
DevOps with Database on AWS
DevOps with Database on AWS
Amazon Web Services Japan
What's hot
(20)
分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
イベント・ソーシングを知る
イベント・ソーシングを知る
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
CircleCIのinfrastructureを支えるTerraformのCI/CDパイプラインの改善
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
DevOps with Database on AWS
DevOps with Database on AWS
Similar to Monitoring - 入門監視
20050809
20050809
小野 修司
Project Management
Project Management
Kazuto Omori
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Kenji Hiranabe
conference for future design case1
conference for future design case1
koichi ikeda
enterprise agile lean modeling
enterprise agile lean modeling
Kenji Hiranabe
IPA未踏ソフト成果報告(仮想秘書サービス)
IPA未踏ソフト成果報告(仮想秘書サービス)
fairyware
Eric riesstartuplessonslearned2011 ja20110605
Eric riesstartuplessonslearned2011 ja20110605
Yuki Sekiguchi
20170223 srws第八回 sof、grade、prospero登録
20170223 srws第八回 sof、grade、prospero登録
SR WS
20170223 srws第八回 sof、grade、prospero登録
20170223 srws第八回 sof、grade、prospero登録
SR WS
業務システムとマイクロサービス
業務システムとマイクロサービス
土岐 孝平
チャレンジ基盤としてのチケット駆動開発(旧版)
チャレンジ基盤としてのチケット駆動開発(旧版)
Makoto SAKAI
第24回上流工程勉強会
第24回上流工程勉強会
Zenji Kanzaki
AIを取り巻く基準について
AIを取り巻く基準について
Noriyasu Higashino
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
Yasuharu Nishi
20130213勉強会_文献レビュー (1)
20130213勉強会_文献レビュー (1)
Satoko Yamashita
シンプルでシステマチックな Oracle Database, Exadata 性能分析
シンプルでシステマチックな Oracle Database, Exadata 性能分析
Yohei Azekatsu
ICT 20years planning
ICT 20years planning
koichi ikeda
RでTwitterテキストマイニング
RでTwitterテキストマイニング
Yudai Shinbo
RでTwitterテキストマイニング~スターバックス~
RでTwitterテキストマイニング~スターバックス~
江上 ゼミナール
修士論文発表資料
修士論文発表資料
Dai Hamada
Similar to Monitoring - 入門監視
(20)
20050809
20050809
Project Management
Project Management
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
conference for future design case1
conference for future design case1
enterprise agile lean modeling
enterprise agile lean modeling
IPA未踏ソフト成果報告(仮想秘書サービス)
IPA未踏ソフト成果報告(仮想秘書サービス)
Eric riesstartuplessonslearned2011 ja20110605
Eric riesstartuplessonslearned2011 ja20110605
20170223 srws第八回 sof、grade、prospero登録
20170223 srws第八回 sof、grade、prospero登録
20170223 srws第八回 sof、grade、prospero登録
20170223 srws第八回 sof、grade、prospero登録
業務システムとマイクロサービス
業務システムとマイクロサービス
チャレンジ基盤としてのチケット駆動開発(旧版)
チャレンジ基盤としてのチケット駆動開発(旧版)
第24回上流工程勉強会
第24回上流工程勉強会
AIを取り巻く基準について
AIを取り巻く基準について
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
20130213勉強会_文献レビュー (1)
20130213勉強会_文献レビュー (1)
シンプルでシステマチックな Oracle Database, Exadata 性能分析
シンプルでシステマチックな Oracle Database, Exadata 性能分析
ICT 20years planning
ICT 20years planning
RでTwitterテキストマイニング
RでTwitterテキストマイニング
RでTwitterテキストマイニング~スターバックス~
RでTwitterテキストマイニング~スターバックス~
修士論文発表資料
修士論文発表資料
More from Eiji KOMINAMI
プリキュア番組連動スマートフォンアプリにおけるUnityや認識技術の活用
プリキュア番組連動スマートフォンアプリにおけるUnityや認識技術の活用
Eiji KOMINAMI
CloudFrontのリアルタイムログをKibanaで可視化しよう
CloudFrontのリアルタイムログをKibanaで可視化しよう
Eiji KOMINAMI
CloudFormation/SAMのススメ
CloudFormation/SAMのススメ
Eiji KOMINAMI
朝日放送グループにおける番組配信/ライブ配信事例および視聴者参加型コンテンツのご紹介
朝日放送グループにおける番組配信/ライブ配信事例および視聴者参加型コンテンツのご紹介
Eiji KOMINAMI
EC2上のWordPressをShifterに移行してみた!
EC2上のWordPressをShifterに移行してみた!
Eiji KOMINAMI
AWS Amplify - Auth/API Category & Vue 構築ハンズオン
AWS Amplify - Auth/API Category & Vue 構築ハンズオン
Eiji KOMINAMI
サーバレスアーキテクチャで実現した「M-1グランプリ」敗者復活戦投票システム
サーバレスアーキテクチャで実現した「M-1グランプリ」敗者復活戦投票システム
Eiji KOMINAMI
朝日放送グループにおける視聴者参加型コンテンツとライブ配信事例のご紹介
朝日放送グループにおける視聴者参加型コンテンツとライブ配信事例のご紹介
Eiji KOMINAMI
ATEMスイッチャーSDKを使用したライブ動画配信用制作・送出システムの開発
ATEMスイッチャーSDKを使用したライブ動画配信用制作・送出システムの開発
Eiji KOMINAMI
AWSを用いた番組連動Webコンテンツ処理基盤の構築
AWSを用いた番組連動Webコンテンツ処理基盤の構築
Eiji KOMINAMI
Lアラート情報のピンポイント送出が可能な災害システムの開発
Lアラート情報のピンポイント送出が可能な災害システムの開発
Eiji KOMINAMI
ライブ動画配信用制作・送出システムの開発
ライブ動画配信用制作・送出システムの開発
Eiji KOMINAMI
More from Eiji KOMINAMI
(12)
プリキュア番組連動スマートフォンアプリにおけるUnityや認識技術の活用
プリキュア番組連動スマートフォンアプリにおけるUnityや認識技術の活用
CloudFrontのリアルタイムログをKibanaで可視化しよう
CloudFrontのリアルタイムログをKibanaで可視化しよう
CloudFormation/SAMのススメ
CloudFormation/SAMのススメ
朝日放送グループにおける番組配信/ライブ配信事例および視聴者参加型コンテンツのご紹介
朝日放送グループにおける番組配信/ライブ配信事例および視聴者参加型コンテンツのご紹介
EC2上のWordPressをShifterに移行してみた!
EC2上のWordPressをShifterに移行してみた!
AWS Amplify - Auth/API Category & Vue 構築ハンズオン
AWS Amplify - Auth/API Category & Vue 構築ハンズオン
サーバレスアーキテクチャで実現した「M-1グランプリ」敗者復活戦投票システム
サーバレスアーキテクチャで実現した「M-1グランプリ」敗者復活戦投票システム
朝日放送グループにおける視聴者参加型コンテンツとライブ配信事例のご紹介
朝日放送グループにおける視聴者参加型コンテンツとライブ配信事例のご紹介
ATEMスイッチャーSDKを使用したライブ動画配信用制作・送出システムの開発
ATEMスイッチャーSDKを使用したライブ動画配信用制作・送出システムの開発
AWSを用いた番組連動Webコンテンツ処理基盤の構築
AWSを用いた番組連動Webコンテンツ処理基盤の構築
Lアラート情報のピンポイント送出が可能な災害システムの開発
Lアラート情報のピンポイント送出が可能な災害システムの開発
ライブ動画配信用制作・送出システムの開発
ライブ動画配信用制作・送出システムの開発
Recently uploaded
プレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツール
sugiuralab
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
Shota Ito
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
Atomu Hidaka
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
iPride Co., Ltd.
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
osamut
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
iPride Co., Ltd.
プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価
sugiuralab
Recently uploaded
(7)
プレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツール
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価
Monitoring - 入門監視
1.
⼩南 英司 Eiji KOMINAMI fukushima.dev
#8 Monitoring
2.
2 本⽇の勉強会について 本⽇のゴール 監視に対する共通認識を持つ
監視のベストプラクティスを学ぶ 現体制/環境に適した監視の形を議論する 参考テキスト
3.
3 狭義の監視 あるシステムや そのコンポーネントの振る舞いや出⼒を 観察しチェックし続ける⾏為 システムに関する リアルタイム定量データを 収集、処理、集計、表⽰を⾏うこと
4.
4 監視サービスの機能とその⽬的 システムの健全性と可⽤性を追及するための主要な⼿段 データの収集
データの蓄積 • ビジネス分析のための⽣データの提供 可視化 • ダッシュボード 分析とレポート • サービス変更に対するインパクトの計測 • ⻑期トレンドの分析 • サービス達成度の計測 • 時間軸や実験グループ間での⽐較 • 振り返り分析(でバッキング) アラートとオンコール • 緊急対応(とその対応への科学的⼿法の適⽤)
5.
アンチパターン
6.
6 ツールに依存しない ツールの制限や機能に囚われない 複数のツールを併⽤する •
⼀⽬で分かる単⼀のツールなど存在しない – ⼀⽬で分かる環境を構築することは重要 • 複数のツールを統合してまとめる必要はない – ただし、ツール同⼠が連携できるかどうかは意識する ⽬的に合ったツールを選択する • チーム内できちんと利⽤されるツールを選択する • 有名だから…はNG – なぜそのツールが開発されてなぜそれがうまく動くのかは、 単にそのツールを導⼊するだけでは分からない • ある程度の苦労は受忍する – ⾃分でツールを作ることも検討 • エージェントのインストールを恐れない
7.
7 監視を特定の⼈に押し付けない 監視はスキルであって役割ではない チーム全体が監視について⼀定レベルの知識を有すべき •
⾃分が理解できないシステムを監視だけすることはできない • チーム全員が監視について責任を持つ 監視とは他のサービスから孤⽴した存在ではない • 監視できていないサービスは本番サービスとは呼べない
8.
8 形だけの監視はしない 「監視してますよ」と⾔うためならやらない⽅がいい 形だけ監視の例 •
エラーの理由が分からない • アラートが発⽣しても無視をする • 過去の履歴を振り返ることができない やるべきこと • 動いているとはどういう状態であるのかを定義し⾼いレベルで確認する • メトリクスは少なくとも1分に1回の⾼頻度で取得する
9.
9 その他のアンチパターン ⽼朽化したシステムを延命するための監視 異常の発⽣源は必ず修正する
その場の対応のためだけに時間を割くことは、 将来のためのシステム改善の時間を奪うということを意識する 設定を⼿動で⾏う 監視の設定も⾃動化すべき • 新しい監視設定やノードの追加がすぐにできないのは、⼤きな負荷となる • 監視の⼿順書が存在するのであれば、その⼿順の⾃動化を検討
10.
デザインパターン
11.
11 組み合わせ可能な監視① 専⾨的な複数のツールを組み合わせる データ収集 •
プッシュ型(=エージェント)とプル型に⼤きな差はないが、プッシュ型の⽅がスケールする • メトリクス – カウンタ型 数値がインクリメントされていく – ゲージ型 任意のポイントの数値のみ。過去の値が分からない。 • ログ – ログはメトリクスより多くのデータを持てることを理解する – ログをパースして解析 » 構造化ログと⾮構造化ログ – アプリケーションのログは必ず出⼒する » Syslog等を⽤いてログを1ヵ所で管理/解析することも可能 ストレージ • メトリクス 時系列データベースに保存 • ログ syslogやElasticsearchなどを利⽤、容量が多いので保存コストには注意
12.
12 組み合わせ可能な監視② 専⾨的な複数のツールを組み合わせる 可視化 •
⾃分⽤に表⽰が組み合わせられるツールが望ましい – そのサービスを理解した⼈間がダッシュボードを作る – 疑問に対してすぐに答えを提⽰できるものが望ましい 分析とレポート アラート • アラートは、あくまで監視の結果の1つ • アラートを上げるために監視しているのではない
13.
13 その他のデザインパターン どこを監視すべきかをユーザ視点で考える ユーザが気にするのはアプリケーションが正常に動いているかどうか
個別のコンポーネントの正常性を気にしているわけではない 作るのではなく買う 今あるSaaSサービスの機能で⼗分 ⾃分たちで構築するために占有される時間 ドキュメント作成や使い⽅の習熟などで失う遺失損失を考える 継続的改善
14.
サービスの健全性
15.
15 リスクと信頼性、サービスレベルの規定 ビジネスKPIに即したリスクと信頼性の算出 コスト/メリット分析 •
求められている以上に信頼性を⾼めてはいけない • 過度な信頼性の向上は、不要なエンジニアリングリソースを消費するだけ サービスリスクの指標 • 計画外の停⽌時間 • リクエスト成功率 ユーザの要求に即した個別のサービスレベルの算出 指標の例 • リクエストレイテンシ, エラー率, システムスループット, 可⽤性… 項⽬の例 • ユーザ数, ユーザログイン, コメント投稿, スレッド作成, 広告の購⼊…
16.
何を監視すべきか
17.
17 監視アセスメント 何を監視すべきなのか、 なぜ監視すべきなのかをシステマチックに判断する⼿法 アプリケーションとインフラをより明確に理解することが⽬的
何が問題で何が問題ではないのかを考える出発点
18.
18 監視システムが答えなければならない問い 何が壊れたのか なぜ壊れたのか
19.
19 監視の種類 ブラックボックスモニタリング ユーザが⽬にする外部的な振る舞いのテスト
フロントエンド監視 ユーザ⽬線の監視が最も重要 • Javascriptを含むフロントエンドの挙動がサービスに与える影響の増加 – SPA(Single Page Application)の普及 • 遅いアプリケーションのコスト – ページのロードが1秒遅くなるとページビューが11%下がる – ページのロードは4秒以内を⽬指す ⼈間の⼿が必要なのは既に進⾏していて実際に症状が出ている事象 ホワイトボックスモニタリング システム内部のメトリクスに基づくモニタリング • マスクされている障害や近々に⽣じることになりそうな問題を検出できる
20.
20 監視の4⼤シグナル レイテンシ エラーのレイテンシも計測 •
⾼速なエラーよりも低速なエラーの⽅が問題 トラフィック エラー サチュレーション システムの利⽤率
21.
21 フロントエンド監視 リアルユーザ監視 実際のユーザトラフィックを⽤いて監視する
Google Analyticsが代表例 監視項⽬ • Navigation Timing API – navigationStart, domLoading, domInteractive, domContentLoaded, domCreated • Javascriptの例外をロギング シンセティック監視 テスト環境下で偽のトラフィックを⽣成 ロードが許容時間内に収まるかなどを計測 WebpageTestが代表例 • Speed Indexの利⽤
22.
22 アプリケーション監視 性能評価 ARMツール(Datadogなど)を使⽤
ツールの制限事項やどのような観点で評価すべきかに注意 ビルドとリリースの監視 障害の70%はシステム変更の結果⽣じる 変更管理の⾃動化 • 漸進的なロールアウト • ⾼速かつ正確な問題の検出 • 問題が⽣じたときのロールバック ヘルスポイントデザインパターン アプリのステータスをWebのレスポンスコードで返す 複雑性, メンテナンス性, 実装量の増加に注意
23.
23 サーバ監視 OSの標準的なメトリクス あまり意味を成さない場合が多い •
アプリケーションが動いているかどうかが重要 • 診断やトラブルシューティングには有効 アラート設定の対象にしないほうが良い 確認項⽬の詳細は後述
24.
24 ログ監視 Syslogの利⽤ Syslogに送信
Syslogがディスク上のログを収集するように設定変更 データの保存 SaaSサービスの利⽤が便利 分析の例 HTTPレスポンス sudoの利⽤ SSHログイン Cronジョブの結果 DBのスロークエリ
25.
アラート
26.
26 良いアラートにするためには? 良いアラートは難しい アラートの設定⾃体がそもそも難しい
受け取る⼈間の注意⼒には限界がある 何のためのアラートか 誰かをたたき起こすためのアラート • 確実に気づく必要がある 参考情報としてのアラート
27.
27 メールは使わない メールは不適切な連絡⼿段 メールで⼈を叩き起こすことは出来ない
受け取る側がうんざりする 情報のレベルに合わせて送り先を変える すぐに応答する必要があるものはSMS等を⽤いる 参考情報や喚起情報はチケット, チャット等に送信する 経歴や診断が必要な情報はログに書き込む ...など
28.
28 障害対応⼿順書を作成する ⼿順書は知識を共有するための良い⼿段 以下の疑問に答える内容が望ましい •
何をするための何のサービスか • 誰が責任者か • どんな依存性を持っているか • インフラの構成はどのようなものか • どんなメトリクスを送っていて、それらはどういう意味なのか • どんなアラートが設定されていて、その理由は何なのか アラートの中に以下を記述する • ⼿順書へのリンク • 期待される動作と実際の動作 ⼿順書の内容が簡単なものであれば⼿順⾃体を⾃動化すべき • ⼿順書は⼈間の判断と診断が存在するからこそある
29.
29 設定の最適化① シンプルなルール チーム全員でシンプルかつ包括的なものを保つ
ルールは理解しやすく障害を明確に表現するものであるべき • そのルールは、そのルール無しには検出できないものか • そのアラートは無害だとして無視してよいものか – どういったときに無視してよいのか • ユーザに悪影響を与えるものか • アラートに対してアクションを起こせるか – どのくらいの時間でアクションを取らないといけないか ルールとターゲットを分離 固定の閾値だけがアラートの基準値ではない 閾値だけでは変化量に気づけない 変化量やグラフの傾きなども材料にする
30.
30 設定の最適化② アラートの量を減らす ⼤量のアラートはアラート疲れを引き起こす •
エンジニアの負荷を適度に低く保つことが必要 • 何かがおかしいというだけでアラートを上げてはいけない 以下に限ってアラートを出すべき • システム⾃⾝が⾃動修復できないもの • ⼈間の判断と診断を必要とし具体的な対応が可能であるもの – 調査 – 問題に対処 – 根本原因を判断 • 緊急でユーザに影響を与えるもの
31.
オンコールと緊急対応
32.
32 オンコールとは システムの守護者 1. アラートの受信 2.
⼀連の観察結果と理論的な基盤を基に原因の仮説を⽴てる 3. 事前に合意したレスポンスタイム(5-30分)内に処理を⾏う • 他のエンジニアとの協⼒とエスカレーション – イベント対応の優先度を規定 – 影響度に応じてエスカレーション
33.
33 オンコールと緊急対応① トラブルシューティングの⼿法 トリアージ •
問題の持つインパクトを判断 • インパクトに応じて何をすべきかはっきりさせる • 根本原因の追究を急ぐのではなく、まずはサービスの継続⽅法を模索する 観察と検証 • ダッシュボードを⽤いてメトリクスとログの確認 • 経験が少ない場合、関係のない症状を⾒たりメトリクスの意味を取り違えたりする場合がある
34.
34 オンコールと緊急対応② トラブルシューティングの⼿法 診断 •
システム構成や本来の動作、障害の発⽣パターンから仮説を⽴てる – 何が、どこで、なぜ – 最後の修正や更新を確認する • 単純化と削減 – コンポーネント間の接続およびその情報を⾒て正しく動作しているか判断 – 既知のテストデータを与えてた悪しく動作するか確認 » 再現性のあるテストケースがあればデバッグが進む – 分割統治法 » コンポーネントを順番に追いかける » もしくはパスを2つに分けて追いかけてエラーの発⽣したパスを掘り進む • あり得ない仮説を⽴てたり過去の原因に固執すると判断を誤る • 相関と因果を誤り間違った関係性を追求してしまう場合がある
35.
35 オンコールと緊急対応③ トラブルシューティングの⼿法 テストおよび対処 •
証拠を⾒つけ出して根本原因を特定する • システムに⼿を加えて再度観察する – システムに与える影響を考慮してテストを進める • 経験が少ない場合にシステムの⼊⼒や環境の変更⽅法を誤解する場合がある
36.
36 良いオンコール体制を築くためには?① 負荷の低減と均⼀化 量におけるバランス •
ローテーションを導⼊ • PagerDutyなどのツールの活⽤ 質におけるバランス • 緊急対応が発⽣した場合 その対応とポストモーテムの執筆に掛かる平均時間は約6時間 • ソフトウェア等の品質向上によって緊急対応の頻度を下げる 過負荷の防⽌ • チケット数などを⽤いた負荷の計測 • アラートルールの⾒直し • 負荷が低すぎるのも問題(!) 補償
37.
37 良いオンコール体制を築くためには?② 継続的改善 前⽇に送られたアラートに⽬を通して、 アラートの出し⽅を改善/削除できないか検討する、など
場当たり的な対応を減らす 監視⾃体はシステムを何も修復してくれない • システムを修復するのは⼈間 • システム⾃体の回復⼒を⾼める ストレスを軽減することで理性かつ集中を保った対処を実現する • エスカレーションパスの⽤意 • インシデントの管理規定を準備 • ⾮難を伴わないポストモーテム⽂化
38.
インシデント管理
39.
39 インシデント管理プロセス① 1. インシデントの認識 2. インシデントのロギング
ライブインシデントドキュメントの作成 3. チケットの発⾏ 4. インシデントの分類 5. インシデントの優先順位付け 1. 事態の深刻化を避ける 2. サービスを復旧させる 3. 根本原因を追究する
40.
40 インシデント管理プロセス② 6. 初期診断 7. エスカレーション
責任の再帰的な分離 • ⾃分の役割を認識して他の誰かの領域に踏み込まない はっきりとした引継ぎ 8. インシデントの解決 ⾃⼰観察 • ⾃分の感情の状態に注意を払う 9. インシデントのクローズ
41.
41 インシデントの定義と発⽣時の役割分担 インシデントの定義の例 別のチームに関わってもらう必要がある
サービス障害がユーザに影響している 集中して分析を1時間⾏っても解決していない インシデント発⽣時の役割分担 1⼈が2つ以上の役割を担当しない • 現場指揮官 – エンジニアが望ましい • 記録係 • 対外連絡調整係 – マネージャーや役職者が望ましい • SME(Subject Matter Expert) – 実際のインシデントに対応する⼈
42.
監視項⽬の例
43.
43 監視項⽬の例① 項目 コマンドやログの例 メトリクスの例 CPU
top Memory free MemAvaliable スワップ数 /var/log/messages OOMKiller Network トラフィック量 エラー ドロップ数 Disk iostat iowait await util IOPS エラー Load Avarage procs ロードアベレージ OSの標準的メトリクス 項目 メトリクスの例 SSL証明書 Web Server Load Balancer 秒間リクエスト 数 レスポンスコー ド リクエスト時間 Database 秒間クエリ数 スロークエリ レプリカの挙動 IOPS Message Que Amazon SQS キューの長さ 消費率 Cache Elasticache キャッシュから 追い出された アイテム数 ヒット/ミス率 その他 項目 メトリクスの例 DNS ゾーン転送 秒間クエリ数 NTP time drift DHCP リース数 SMTP 外向け メッセージキュ ー メール総数 受信箱のサイズ
44.
44 監視項⽬の例② ネットワーク監視 SNMPはつらい •
セキュリティ上の問題 • ポーリングであるためスケールアウトが難しい でもネットワーク機器のほとんどがSNMPが標準 • 監視項⽬の例 – インタフェース » 帯域幅 » スループット » レイテンシ » エラー(送受信, ドロップ, CRC, オーバラン, キャリア, リセット, コリジョン) – ログ » トランクポートへの変更 » リンクアグリゲーションの設定変更
Download now