👁️
【要約】入門監視
監視のアンチパターン
- ツールに依存する
- 万能なツールはない
- 監視が役割になっている
- 監視は役割ではなくスキルであり、全員がやるべき
- 監視するのは PDCA を回すため
- チェックボックス監視
- これを監視してます、と言うためだけの監視
- 形が先行すると非効率なものが出来上がる
- 誤検知が多いのでアラートを常に無視するようになる
- メトリクスは取っているが、システムがダウンした理由はわからない
- 5分間隔など、長すぎるインターバルで監視してる
- 監視を支えにする
- 監視してるから壊れてもいいわけではないし、壊れたからといって監視を増やせばいいわけでもない
- 手動設定
監視のデザインパターン
監視サービスのコンポーネント
- データ収集
- プッシュ型とプル型
- プル型は中央サーバーが必要なのでスケールしにくい
- メトリクス
- カウンタとゲージ
- プッシュ型とプル型
- データストレージ
- 間引き
- 古いデータを詳細に見たいことはまずないので、分単位のデータを時間単位に集約するなどして間引く
- 可視化
- 分析とレポート
- SLAの監視レポート
- 標本化定理
- 2分間のダウンタイムを計測するには1分間隔でデータを収集する必要がある
- コンポーネントが組み合わさって一つのサービスとなっている場合は複雑性が増す
- 内部のコンポーネントごとの可用性を出し、それから全体の可用性を出す方が正確だが、複雑だし費用対効果は悪い
- サービス全体で算出した方が簡単だし欲しい値になることが多い
- 依存コンポーネントの可用性に依存することに注意
- 例えば EC2 は99.95%なので、シングルAZ構成なら、そこで稼働するサービスはそれ以上の可用性は定義できない
- アラート
どこから始めるか
- まずはユーザーに近いところから始める
- ユーザーが叩くエンドポイントが正しいステータスを返すか
- いきなり CPU やサーバーメモリの監視をしてもメリットがない
- CPU が90％だからといって、それが悪いとは限らない
作るのではなく買う
- 買った方がコストが安い
- 我々は監視ツールを作る専門家ではない
- プロダクトのフォーカス
- 大抵のことはSaasS でできる
- 著名な企業も数年かけて監視ツールを醸成させてきたはずで、一朝一夕でできるものではない
アラート、オンコール、インシデント管理
アラート
- アラートは、それを受け取った人に緊急性があり、すぐに対応する必要があることを認識させるもの
- アラートにメールを使うのはやめる
- メールというのは基本的に非同期で目を通すもの
- 緊急性があるものは SMS など、すぐに気づけるものに送るべき
- アラートには対応手順を含める
-
固定の閾値のみに依存しない
- 例えばディスク利用率が90%になったら、みたいな設定だと10%から80%に急上昇した、みたいな異常値を見逃しかねない
- 変化量、グラフの傾きもウォッチする
- 不必要なアラートは削除する
- アラートが多すぎると無視するようになる
- アラート疲れが起こる前にチューニングする
- アラートに対応するのに時間を浪費するのではなく、システムの安定性をあげることに時間を使おう
- メンテ時はアラートを切っておく
-
アラート対象の異常を自動復旧できないか検討する
- 自動復旧できない時だけアラートを送る
オンコール
- 待機
- 上手にローテーションさせる
- 規模が大きければタイムゾーンごとにオンコールを置く、 Follow The Sun ローテーションが組める
インシデント管理
- 発生した問題を扱う正式かつ自社に最適な手順を確立しておく
- ITIL が有名
- インシデントが長期化する場合、適切にロールを割り振って対処する
- 指揮官、書記、コミュニケーター、対応者
- 起きた後はポストモーテムを行い、振り返りをすることが大切
- 避難せず、問題の本質を明らかにする
統計入門
- mean と average
- 算術平均
- 平準化すると識別しやすい滑らかnデータセットを得られるが、スパイク値などの重要かもしれないデータポイントを失う可能性もある
- 中央値
- 周期生
- 分位数
- パーセンタイル
- 極端な値を弾ける
- パーセンタイル
- 標準偏差
- 正規分布しているデータセットのみに有効
ビジネス KPI
- 月次計上収益
- 顧客あたりの収益
- 課金顧客の収益
- 顧客生涯価値
- 顧客あたりのコスト
- 顧客獲得単価
- 顧客の解約数
- アクティブユーザー数
- バーンレート
- ランレート
- TAM（total addressable market）
- 粗利
- etc...
ウォッチすべき値は必ずあるはず
フロントエンド監視
- SPA が普及し、http エラーが起きてないのに js エラーが発生してるなんてことも
-
フロント監視のゴールは、動き続けることよりも速く動くこと
- ページロードが1秒遅くなると、pv が11％、cv が7％、顧客満足度が16％下がると言われている
- リアルユーザー監視
- GA など
- シンセティック監視
-
Navigation Timing API でいくつかの有用なメトリクスが取れる
- domComplete - navigationStart = ページの総ロード時間
- domInteractive - navigationStart = ページがロードされたとユーザーが体感する時間
- ユーザーの体感速度を測るには Speed_index の値を見てみると良い
アプリケーション監視
- そもそもアプリケーションが生きている、とはを定義する
- ディスクに書くか、ネットワーク越しに送るべきか
- まずはファイルに書いて、それをネットワークで送る
- 一回一回コネクションを張るのは高コスト
- 非同期でやる
- マイクロサービスの監視には分散トレーシングを活用する
- Distributed Tracing
- 外からのリクエストに一意の ID を振り、そのリクエストがどのサービスにどれぐらい滞留したかを測る
- 非常に複雑で根気がいるので、スタッフ不足、疲労気味のチームには向かない
サーバー監視
- CPU
- メモリ
- free コマンドは二行目を見る
- OOMKiller の実行回数を監視するという手
- ネットワーク
- ディスク
- ロードアベレージ
web サーバー
- スループット指標としての重要なのが request per second
- http status code
- connection 数は keep alive 設定に依存することに注意
DB サーバー
- コネクション数
- MySQL ではスレッドと表現されることに注意
- 秒間クエリ数
- サーバーへの負荷を測るいい指標となる
- スロウクエリ
- レプリカ同期遅延
- IOPS
メッセージキュー
- キューの長さ
- キューの消費率
キャッシュ
- キャッシュヒット率
ネットワーク監視
むずい
SNMP が辛い
セキュリティ監視
- コンプラ目的の監視要求は見た目よりも simple なことも多いが、easy とは限らない
- auditd を使ったユーザー、コマンド、ファイルシステム監視
- ホストレベルの侵入検知は難しい場合があるが、rkhunter から始めるのが良い
- ファイアウォールは十分ではない
- fw は真n湯させないための仕組みだが、侵入された後に気づける仕組みも必要
- NIDS を使ってより多くの情報を得る
監視 SaaS
SaaS選定時に考えること
- 課題を見つける
- 自分達のサービスの課題を定義する
- 機能要件を精査する
- そもそも運用しているサーバーにインスコ可能か
- 欲しいメトリクスは取れるか
- インターネットに出れない構成でも使えるか
- etc
- 組み合わせて使う
- 運用をサービスに合わせる
- ハッカビリティを備えているか
- 外部の力を活用できるか
- テクニカルサポートやコミュニティの活発度、ネット上の情報量
Discussion