Kubernetes上で動くサービスの何を監視すればよいのか
はじめに
サーバーを安定して運用するためには、システムの状態を正確に把握できる監視システムは欠かせません。
従来はVMインスタンスやベアメタルサーバーのリソース使用状況やデータベース、ネットワーク、アプリケーション固有のメトリクスを監視していました。
しかし、近年ではサーバーをKubernetes上で動かすことが当たり前になっており、Kubernetesの恩恵を受ける反面、これまでよりもサーバーの監視は複雑になっているように思えます。
そこで、本記事ではKubernetes上で動くサービスの何を監視すればよいのかを整理していきます。
简而言之
-
- ユーザーの視点から監視システムを設計する
-
- ユーザー視点のメトリクスから何か問題が起こっていることを知る
- システム内部のメトリクスから原因を探る
監視の目的
システムの監視の目的は、ユーザーに快適なサービスを提供できているか、また今後サービスに影響が出そうな問題が発生していないかを事前に検知することです。
リソース使用状況を美しくグラフにしたり、アラートをいたずらに飛ばすことではありません。
你打算看什么？
快適なサービスを提供できているかという観点から、まず観ておきたいのは、ユーザーがサービスと触れる部分のメトリクス(ユーザー目線のメトリクス）です。この部分のメトリクスに異常値が検出されると、何かはわからないがユーザーに不利益が発生していることがわかります。
一方、事前に問題を検知するという観点やトラブルシューティングのことを考えると、システム内部のメトリクスも観ておく必要がありそうです。例えば、実施予定のプロモーションに対して、現時点のリソースでは足りなさそうであれば、事前のプロビジョニングの判断材料にもなります。
用户视角的度量指标
ユーザーがサービスと触れる部分のメトリクスとしては、例えば次のようなものがあります。
-
- レイテンシ(レスポンス時間）
- エラー率
レイテンシ（レスポンス時間）
レイテンシが平常時より悪化している場合、UXに悪影響を与える上に、それがリソースの枯渇や非効率なクエリによるものであれば最悪の場合は近いうちにサービスダウンも考えられます。
また、95%ileや99%ileのレイテンシは、サービスの利益にとって重要なユーザーによるものかもしれません。これら外れ値のレイテンシを改善することには一定の効果があります。
エラー率
当错误率超过一定阈值时发出警报是有益的，因为它是最明确地展示给用户带来不利影响的指标。
システム内部のメトリクス
Kubernetesの監視において、大きく分けて次の4つの項目は観るとよいかと思います。
-
- Kubernetesのコントロールプレーン
-
- Kubernetesノード
-
- Kubernetes Workloads
- コンテナのリソース制限に対する使用率
その他、ネットワークやデータベース、アプリケーション固有のメトリクスは本記事では取り扱いません。
Kubernetes的控制平面
Kubernetes上でサービスを動かすのであれば、その大元であるKubernetesのコントロールプレーンを監視するべきでしょう。
例えば次の項目[1]を監視することにより、Kubernetesの恩恵を安定して享受することができます。これらのメトリクスはkube-state-metricsによって簡単に収集することが可能です。
-
- kube-apiserver
-
- kube-scheduler
-
- kube-controller-manager
- etcd
Kubernetesノード
サーバーのPodを稼働させるのに十分なリソースの余裕があるか、過剰なインフラリソースをプロビジョニングしていないかを把握するために、Kubernetesノードのメトリクスは観るべきです。
Kubernetes 工作负载
DeploymentやDaemonSetなどのWorkloadsが適切にデプロイされているかを把握します。
例えば、WebサーバーのPodが本来100デプロイされているはずが、50しかデプロイされていない状況が長く続いているならば、ノードのリソース不足や設定の不備が考えられます。
容器资源限制的使用率
コンテナがリソース制限を超えるとOOM KillやCPUスロットリングに直面するため、
リソース制限に対する使用率を監視することは重要です。
OOM Kill -> 欠内存打死
例如，如果Web服务器的内存使用量被限制为100MiB，将会启动OOM安全保护并终止容器，然后重新启动Pod。
また、Podはコンテナのリソース要求に基づいてデプロイされます。
そのため、ノードにデプロイされたPodのメモリのリソース制限の合計が、ノードのメモリ容量を超えることがあります（オーバーコミット）。この場合、Kubernetesは一部のPodをKillしメモリを開放します。
CPU降频
与内存不同，即使超过资源限制，Pod也不会被终止，而是会发生CPU节流，并对服务器性能产生影响。[2]
与内存不同，即使超过资源限制，Pod不会被终止，而是会发生CPU节流，对服务器性能会造成不良影响。[2]
与内存不同，即使超过资源限制，也不会导致Pod被终止，而是会发生CPU节流，对服务器性能产生影响。[2]
最后
今年在DeNA，我們寫了以下三種不同種類的聖誕日曆！請一定要去看看各個不同的風格。
DeNA Advent Calendar 2020：DeNA エンジニアによるアドベントカレンダー
DeNA 20 新卒 Advent Calendar 2020：DeNA 20 新卒エンジニアによるアドベントカレンダー
DeNA 21 新卒 Advent Calendar 2021：DeNA 21 内定者エンジニアによるアドベントカレンダー
この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！
また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！
Follow @DeNAxTech
参考
以下是中文的同义表达：
[1] Datadog，Kubernetes控制平面监控
[2] kubernetes.io，了解Kubernetes中的CPU限制以提高应用性能。
