モニタリング
モニタリングとは
サーバのCPU使用率やサイトのアクセス数などシステムに関するリアルタイム定量データの収集、処理、集計、表示を行うことです。
- システムの異変にいち早く気付ける
- システムに障害が起きたときに原因調査が容易になる
- 障害を未然に防ぐ
監視の定義
監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。
Greg Poirier Monitorama 2016 https://vimeo.com/173610062 via 入門 監視
カテゴリ
- プロファイリング
- トレーシング
- ロギング
- メトリクス
プロファイリング
時間的な制約があればコンテキストを残すことが可能
代表的なプロファイリングツールはtcpdump
メモリの消費が激しいため常時モニタリングする際に使用することは不可
トレーシングとは
注目している処理、例えばHTTPリクエスト100中の1のような一部のイベントを追いたい時に使用する
ロギングとは
イベントの一部を対象として、それらのイベント１つ１つのコンテキストの一部を記録する
ストレージの過度な消費を防ぐためにログレベルで振り分けたりフィールド数を制限する必要がある
利点はフィールド数に制限があっても問題のあるリクエストが特定のAPIの特定のユーザーなどと判断ができること
主なロギング
- トランザクションロギング
- リクエストログ
- アプリケーションログ
- デバッグログ
メトリクス
コンテキストを無視したシステムに関する定量的なデータ
ログよりもフィールドが多めなので追跡する数値には上限を加える必要がある
レイテンシと個々のアプリケーションが処理するデータボリュームを追跡であったりシステム全体的な情報を集めることができる。
主なメトリクス
- 各マイクロサービスが使用するNodeのCPU、メモリ、ロードアベレージ、ネットワーク、ディスク
- Webアプリケーション 秒間リクエスト数、Httpステータスコード、Httpレスポンス、リクエスト数、コネクション数、リクエスト時間、レイテンシ
- データベース コネクション数、秒間クエリ数、スロークエリ、クエリレイテンシ
- メッセージキュー(pub-sub) キューの長さ、消費率
- ログ sudoの使用、SSHログイン
- ヘルスチェック
- パフォーマンス
- データベース接続数
- エラー
ヘルスチェックエンドポイント
アプリケーションの健全性と状態についての情報を取得
モニタリングのメリット
- システムの異変にいち早く気づくことができる
- システムに障害が起きた時に原因調査が容易になる
- システムに障害が起きる前にシステムの成長傾向などが把握でき未然に障害を食い止めることができる
モニタリングの手法
- ブラックボックスモニタリング
- ホワイトボックスモニタリング
ブラックボックスモニタリング
システム外部から見た時の振る舞いに関するモニタリング
主にクラスター外からのアクセスを定期的に確認する。
ホワイトボックスモニタリング
システム内部から見た時の状態に関するモニタリング
主にシステム傾向やキャパシティの把握、障害時の原因調査
モニタリングの要件
- ロギング
- ダッシュボード
- アラート
- オンコール
- デプロイメントパイプラインのメタ情報
- ヘルスチェックエンドポイント
- ネットワーク
ロギング
各マイクロサービスの状態を常に把握するため、障害が起きた際の原因を特定するために必要
収集
kubectl logs、sternコマンド、 kiali logsで標準出力、標準エラー出力をロギング
GKEの場合はFluentdのDaemonSetが同じNode上の全コンテナのログを収集する
保存
GKEの場合はFluentdのDaemonSet(fluentd-gcp-v3.2.0)が同じNode上の全コンテナのログをStackdriver Loggingに転送して保存している
分析
アプリケーションロギング
構造化ログを使用することを推奨
メトリクスからログに変換することは可能だがその反対は難しい？
ログの書き込みかかる時間の方がボトルネックになるようなことにならないように注意する
GKEの場合FluentdのDaemonSetがStackdriver Loggingにコンテナログを送信している。
ダッシュボード
サービスの健全性を視覚的に把握するためやユーザーにとって最も重要なメトリクスを表示するのに必要
アラート
各マイクローサービスの機能が停止する前に問題を緩和、解決するために必要
- ページロード時間の増加
- エラー率やレイテンシの増加
- DBクエリのレイテンシの増加
オンコール
機能停止の際に迅速に対応できるように標準化されたオンコール手続きがある
https://pagerduty.digitalstacks.net/blog/prep-on-call-engineer/
デプロイメントパイプラインのメタ情報
httpステータスの急激な変化などに対応する指標としてデプロイがいつ始まったか、終わったか、どのビルドがデプロイされたか誰がデプロイを実行したか等
ヘルスチェックエンドポイント
アプリケーションの健全性と状態についての情報をプル
ロードバランサやサービスディスカばりツールによるヘルスチェックにも使用できる(kubernetes service)
DB使用の場合一行selectなどを定義しておく
継続的に監視するツール（kubernetes Readiness Probe, Liveness Proveなど）を設置する必要性やサーバーサイドの作業が増えるというデメリットもある
ネットワーク
- 帯域幅 ... ある接続から一度に送れる理論上の最大情報量
- スループット ... ネットワークの実際のパフォーマンス
- レイテンシ ... パケットがネットワークリンクを通じてやり取りされるのにかかる時間
基本的な知識のみでネットワークエンジニアリングを行わない