su-kun1899/入門監視.md

## 入門監視.md

      
    Raw
  

              入門監視.md
            
          
    はじめに


"監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である"
基本原則は時代を超えるもの

１章 監視のアンチパターン


慣習を見直す

「いつもやってることだから」で済まさない


ツール依存

ツール駆動なチームは、ミッション駆動なチームより効率的にならない
ひとつのツールで解決できる問題ではない

APM ツールやアプリケーション自身による計測: アプリケーションのプロファイリングや監視
サーバ監視ソリューション: クラウドインフラのパフォーマンス監視
ネットワークに焦点をあてたツール: スパニングツリーのトポロジ変更やルーティングの更新を監視


観察者効果を気にしない

今は監視ツールそのものの負荷は小さくなっている


ツールの数を気にしない

同じ情報なら集約する
違う情報なら問題ない


ツールの統合のために必要性に合ってないツールを使うより、問題を解決するツールを使う
ツール同士が連携されていないなら問題になる
☹️ ツールの整理は人とたくさん話すこと


チームが成功したことによってツールや手順が作られたのであってその逆ではありません
ツールは評価し試してみるのが重要
小さく何かに特化したツールは自作も有効
一目でわかると言うのは1つの場所の事

1つのツールや1つのダッシュボードと言うわけではない


監視は役割ではなくスキル

チーム内の全員がある程度のレベルに至っておくべき


監視するまで本番環境とは言えない
チェックボックス監視

これを監視してますと言うための監視システム


アンチパターンの兆候

システム負荷CPU使用率メモリ使用率などのメトリクスは記録しているがシステムダウンの理由がわからない
誤検知が多すぎるのでアラートを常に無視する
各メトリクスを5分あるいはそれより長い間隔で監視
メトリクスの履歴を保存していない


動いているとはどういう状態か聞いてみる

ウェブアプリケーションの場合

httpレスポンスステータス
レイテンシ


何が悪いかわからないが何かがおかしい事はわかる


OSのメトリクスはアラートにはあまり意味がない

診断や分析には重要
最低でも60秒に1回メトリクスを取得する
メトリクスの保存は間引きを適切に行う


監視は問題を通知するためのもので問題の修正は別で行う
監視は自動化すべき

２章 監視のデザインパターン


組み合わせ可能な監視

ツールを組み合わせてプラットフォームを作る


💭 監視でも Unix 哲学
監視サービスの要素

データ収集

プッシュ式とプル式

プル型は中央集権になるのでスケールしにくい
プッシュ型は冗長性に優れる
💭 使い方によるといいつつ、プッシュ型のほうがよさそう


メトリクス

カウンタ

増加していく値（車の走行距離計）


ゲージ

ある時点の値（車の速度計）


ログ

基本はタイムスタンプと関連付けられた文字列
非構造化ログと構造化ログ

JSON などで構造化できる


収集はシステムでログ転送設定するの方法がメジャー


データストレージ

時系列データベース (TSDB, Time Series Database)

RRD や Whisper がよく使われている
間引きや有効期限切れが発生する
間引き

平均や合計で行う
多くの運用データでは、古いものはトレンドが分かれば十分


高度な保存方法としては検索エンジン（Elasticsearch など）


可視化

求める形で理解できないなら、そのデータは無駄
時系列データの一般的な可視化方法は折れ線グラフ
円グラフは使わない

変化の少ない値を表現するもの
棒グラフのほうがよい場合が多い


価値あるダッシュボード

異なる視点とスコープがある


素晴らしいダッシュボード

ある時点の疑問に回答をくれる


最高のダッシュボード

ひとつのサービスやプロダクトのステータスを表示する


ダッシュボードは、そのサービスを最も良く理解している人たちに作られ運用されるべき


分析とレポート

SLA は願望や嘘である

目指すべき目標


サンプリングエラー

1秒のダウンタイムを計測するには1秒未満の間隔でデータを収集する必要がある


内部を無視して、全体の可用性を計算する
依存を見落とさない

AWS EC2 は一つのリージョンに対して 99.95% の可用性


多くの顧客は 99% と 99.9% の違いは分からない


アラート

監視は、質問を投げかけるためにある
監視とはアラートを出すために存在しているのではない


作るのではなく買う

システムがツールを超えて成長してから次へ進もう


5年間は Sass を監視に使うべき

安い
専門性が必要
プロダクトにフォーカスする


継続的に改善する

3章 アラート、オンコール、インシデント管理


p36: アラートは人間に送られるが、人間の注意力には限りがある
p36: アラートの2つの定義

誰かを叩き起こすためのアラート
参考情報としてのアラート

事実上アラートではない
💭 Error と Warn の使い分けにこういう話ありますね


p37: よいアラートを作るための方法

p37: アラートにメールを使うのをやめよう

すぐ応答が必要なら SMS, PagerDuty などのページャを使う

💭 ページャってポケベルのことらしい


即アクションがいらないならチャットルーム
💭 受け手が人間なら、連携と受け渡しのしやすさでメールもありだと思う
アラートのログをとる


p38: 手順書を書こう

よい手順書

これは何のサービスで、何をするものか
誰が責任者か
どんな依存性をもっているか
インフラの構成はどのようなものか
どんなメトリクスやログを送っていて、それらはどういう意味なのか
どんなアラートが設定されていて、その理由は何なのか
💭 Sentry のやつ、これに従って Documentation するのもよさそう


各アラートに手順書へのリンクを入れる
コピペで済むような手順書なら自動化する
⚠️ 人間の判断が必要なときのためのもの
💭 付録Aちらっと見たけど、メンテナンスが機能するようにしないといけなそう


p39: 固定の閾値を決めることだけが方法ではない

特定の値を閾値にすると、急激な増加などは拾えない

変化量やグラフの傾きを使う


💭 これは難しそう。。4章に期待


アラートを削除し、チューニングしよう

p40: アラートを減らす

誰かがアクションをする必要があるか
アラートの履歴はどうか

どんな影響があったか？閾値は妥当か？デザインし直せないか？


アラートを消すために自動化できないか？


p40: メンテナンス期間を使おう

作業を行う際に、アラートされるのが事前に分かっているなら止める
ただし止めすぎには注意

💭 思考停止で止めるんじゃなくて、精査して止める


まずは自動復旧を目指そう

💭 自動復旧は素晴らしい
💭 Fargate とかサービスで提供されている感じ


p42: オンコール

問題が起きたときに呼び出しに答える担当のこと
オンコールの悩みを解決する

P43: 誤報を修正する

100%の正確性は難しいが、かなりの量までチューニングできる
前日のアラートの一覧を作り、改善できないか自問自答する
💭 Sentry隊で近いことやってる！


p43: 無用の場当たり対応を減らす

監視自体は何も修復しない
2つの戦略

オンコールシフト中、システムの回復力や安定性にオンコール担当が役割として取り組む
前週のオンコールの情報を元に、翌週の計画で回復性や安定性について取り上げる
💭 いずれにせよ、ちゃんと改善の時間を確保するのが大事ということだな


p44: オンコールローテーションを組む

カレンダーの週ではなく、出勤日にオンコールのローテーションを始める

💭 カレンダーが日曜始まりだから？
水曜午前10:00から一週間後がおすすめ


バックアップ担当は大きなチームでなければ必要ない

1サイクルで2回担当がある
通常のシフトには３週間空けるのがおすすめ
バックアップローテーションを組むなら 8 人が必要


ソフトウェアエンジニアもローテーションに入れる

丸投げを避ける
よりよいソフトウェアを作ろうというインセンティブが生まれる
共感の気持ちを避ける


P47: インシデント管理

ITIL をシンプルにしたプロセス

インシデントの認識（監視が問題を認識）
インシデントの記録（自動でチケットを作成）
インシデントの診断、分類、解決、クローズ
必要に応じたコミュニケーション
回復力を高めるための改善策を考える


社内標準でインシデント対応を決めることに価値はある


p49: 数分以上かかるインシデントには明確な役割を建てる

兼務はしない
現場指揮官

サービス停止に関する調査を監督する役割
💭 手段に関する意思決定はどこでやるんだろ？


スクライブ

記録する人


コミュニケーション調整役

💭 外からの窓口になるってことなんだろうな


SME

実際に対応する人


💭 インシデントのとき大事にしていること

窓口の一本化・情報の集約
進捗がなくても定期的な報告をする
エスカレーションフロー・コミュニケーションパス
物理的な本部を作る

ホワイトボードに誰が何をやっているか書く


まずは深呼吸


p50: 振り返り

4章 統計入門


p53: Nagios 嫌い過ぎではｗ
p54: フラッピングの検出はよくないアラートを隠しているだけ
p54: データを保存すれば、統計を使える
p55: mean(算術平均)、average(移動平均)

スパイクの多いグラフを平滑化
データの間引きやメトリクスの集合に使える


p57: 中央値

(n + 1) / 2
一方向に大きな偏りがあるデータセットを扱う場合に有効


p58: 周期性

計画や予測に使える
周期性が常にあるとは限らない


p59: 分位数

よく使われるのはパーセンタイル
外れ値（上位n%）を除外する
レイテンシのレポートなどに有効
パーセンタイルは平均できない
外れ値を捨てている（最悪のシナリオ）ことを忘れない


p60: 標準偏差

平均からどの程度離れているか、近いかを表現する
正規分布しているデータにしか期待する結果は出ない

適用できるものが少ない


使うのを諦めるほうが幸せになるかもしれません


p62: データについて考慮すること

どちらか一方に大きな偏りがあるか？
極端な外れ値はよく発生するか？
上限か下限はあるか？


5章 ビジネスを監視する


p66~

💭 KPI の具体例がまとまっているのよい


p70:

KPI を監視すると、問題の先行指標になる

ユーザーへの影響も分かる


p71:

💭 重要な機能はレイテンシを個別に取っておくといいのかな


p72: メトリクスがない時はアプリケーションを変更する

💭 自動車のメーターはよいメタファーだなぁ


p73: プロダクトマネージャーと話す

プロダクトマネージャーの仕事

顧客が何を必要としているか理解し、実現するためにエンジニアリングチームと協力する


6章 フロントエンド監視


p76: フロントエンドのパフォーマンス監視のゴール

動き続けることではなく、素早くロードされること


p77: ページロード時間は4秒以下を目指す

💭 重要性を知りながら、軽視されがちな気はする


p78: RUM とシンセティック監視

RUM: リアルユーザー監視

実際のユーザートラフィックを使う


シンセティック監視

テスト環境下で偽のリクエストを使う


p81: Navigation Timing API

ブラウザがメトリクスを公開している


p82: Speed Index が事実上の標準パフォーマンステストツール
p83: GA 使うのがよさそう
p84: ロギング

「exception tracking saas」で検索してみてね


7章 アプリケーション監視


p87: シンプルにはじめる

クエリの実行にかかった時間
APIの応答にかかった時間
1日のログインの数


p89: StatsD がメトリクス追加に便利

UDP を使っている


p92: ビルドとリリースパイプラインを監視する

💭 何かが起きるのは大概リリース起因よね


p93: health エンドポイントパターン

💭 Spring だと actuator があるね
p98:

エンドポイントはアプリケーション内にあるべき


p100: アプリケーションロギング

メタデータからメトリクスは取れるけど、ツールの成熟が追いついてない

💭 Kibana とかは近い気がするけどな


メトリクスかログか

チームにとってどちらで考えるほうが楽か？
そのユースケースにとってどちらが効果的か？


p101: ログのレベル

正常に動いている前提でレベル分けしてしまう
💭 確かに問題が起きたとき欲しいのは DEBUG レベルのログだよなあ


p102: 理解していないシステムのログや監視を設定するのは無理

💭 何の助けにもならないログとかあるよね。。


p102: ディスクかネットワーク越しか

ディスクに書いた後、外部に送るサービスを組み合わせる
直接送るのは便利だが、ボトルネックになりがち


p103: サーバーレスや Function-as-a-Service

ポーリングは実行時間が短くて使い物にならない
StatsD や既存のサービスを使う


マイクロサービスアーキテクチャを監視する

p105 分散トレーシングを使う

リクエストIDをタグづけする


8章 サーバ監視


p109: OSの標準的なメトリクス

CPUはtop
メモリはfree
💭このへん昔まとめたな


p112: OOMKiller を監視する

ネットワークはifconfigやip


ディスクはiostat

p113: 💭IOPSはインフラの人が気にするイメージ


p114: ロードアベレージはuptime

代理指標として役立つ
💭平常時の数値を知っておくのが大事だよなぁ


p115: SSL証明書の期限を監視しよう
p116: SNMPをサーバ監視には使わない
Webサーバ

秒間リクエスト数（スループットの指標）
HTTPステータスコード
リクエスト時間


p118: データベースサーバ

コネクション数
秒間クエリ数
スロークエリ
レプリケーションの遅延
IOPS


p120: ロードバランサ
p120: メッセージキュー

キューの長さと消費率


p121: キャッシュ

追い出されたアイテム数
ヒット・ミス比率


p121: DNS

自前運用でないなら特に監視するものはない
自前ならゾーン転送と秒間クエリに注意する


p122: NTP

クライアントだけなら、ntpstatで同期に注意する


DHCP
SMTP
p124: スケジュールジョブの監視

デッドマン装置を使う


p126: ロギング

収集

syslog

設定を変えるとディスク上のファイルを取り込める


UDPよりTCPがおすすめ
保存
Saas を使おう


分析

手始めにとる項目

HTTPレスポンス
sudoの使用
SSHログイン
cronジョブの結果
スロークエリ


9章 ネットワーク監視


p131

ネットワークの可用性をアプリケーションの可用性は越えられない


SNMP のつらさ

SNMP とは

Simple Network Management Protocol


SNMP の仕組み

エージェントとマネージャ
エージェントがネットワーク上のデバイス（で動くプロセス）
マネージャが情報を問い合わせて受け取る
エージェントはオブジェクト ID (OID) のツリーで構成されるデータを提供する

.1.3.6.1.2.1.1.1.0


MIB (Management Information Base) ファイル

OID をテキスト表記に変換するためのマッピングを含むファイル
sysDescr.0


p134: 💭 SNMPトラップってなんだろ？

異常時に、エージェント側からマネージャへ通知することのよう
ログは大抵デバイスの syslog に残されるので、無効にすることが多い


RFC はあるが、実装標準はない


セキュリティについて

本質的にセキュアではない
v3 よりも v2c が広く使われている


SNMP の使い方

💭 コマンドラインでの使い方が紹介されている
💭 結局どう使うのかは正直よくわからん


インタフェイスのメトリクス

p140: ネットワークパフォーマンスの要素

帯域幅

理論上の最大情報量 (bits per second, bps)


スループット

実際のパフォーマンス
プロトコルと送信のオーバーヘッドがあり、帯域幅を最大には使えない


レイテンシ

パケットがネットワークリンクを通じてやり取りされるのにかかる時間


エラー

最も監視すべきは物理的問題

電気的干渉、送受信機やケーブルの欠陥
CRCエラーとキャリアエラーから監視できる


ジッタ

あるメトリックの通常の測定値からの狂い
ネットワークの世界ではレイテンシに関して使われることが多い
レイテンシがずっと 3ms なら、ジッタは全くない状態


p143: 💭 高速道路の喩えは面白い


音声と映像

パフォーマンスはレイテンシ、ジッタ、パケットロスの計測項目がすべて
コーデックも重要


p147

💭 トポロジという単語を見るたびにググるマン

コンピュータネットワークの配線に端末や各種機器がどのような形状で接続されているのかを表す用語


💭 9章は難しい話が多くて流し読み。。

物理ネットワークとかサーバの監視を想定してそう


10章 セキュリティ監視


p54:

💭 セキュリティはリスクとのバランス

自宅にホワイトハウスと同レベルのセキュリティは妥当でない


ユーザ、コマンド、ファイルシステムの監査

例

すべての sudo の実行、コマンドの実行、誰が実行したか
ファイルアクセスや特定ファイルの変更、その時刻、誰によって変更されたか
ユーザ認証の試行と失敗


11章 監視アセスメントの実行


フロントエンド監視

p167:

💭 RUM ってなんだったっけ。。

Real User Monitoring だった


付録C 実践 監視 SaaS


p178:

監視の民主化


p191:

💭 ヘルスチェックの RFC が議論されてるのか
/health エンドポイントはステートレスに作る

前回値との差分等にはしない