New Relic で k8s を監視してみた

はじめに

半年ぶりです。おとです。

当ブログでちょうど1年前、蓑代さんが New Relic の記事

blog.ecbeing.tech

を執筆されておりまして、その中で、

「New Relic と連携さえしてしまえば、アプリケーションのログだけではなく、クラウドサービス基盤のインフラログ、果ては k8s のモニタリングまで出来ちゃいます。」

と、かるーく k8s と New Relic に触れていました。

その記事(というか部内の New Relic 布教)に影響を多大に受けて New Relic に触れて6か月ちょっと、
これまで業務で扱ってきた k8s と 合わせて少し勉強したので、 New Relic を使った k8s の監視についてご紹介したいと思います。

k8s とは

Kubernetesの略で、コンテナベースのアプリケーションを管理するためのオープンソースプラットフォームです。
詳しくは公式ドキュメント

kubernetes.io

をご参照ください。

New Relic とは

New Relic は、アプリケーションのパフォーマンスやエラーをリアルタイムで監視することができるツールです。
こちらも詳しくは公式ドキュメント

docs.newrelic.com

をご参照ください。


New Relic を使って k8s を監視する

NewRelicには数多くのインテグレーションが提供されていますが、もちろんk8sインテグレーションも提供されています。
インテグレーションのインストール手順も公式で用意されており、 AzureやAWS、Googleなどのマネージドサービスへのインストール方法も個別に用意されています。

手順に従ってインテグレーションのインストールとアプリケーションの設定が完了すると、

k8sのサマリーボード(New Relic 公式ドキュメントより引用)
このようにnodeとpodを視覚的にわかりやすくあらわした図で確認することができます。

もちろんこのサマリボードだけではなく、 NRQL(New Relic におけるクエリ言語)を用いて k8s の様々なデータを照会できます。

k8sダッシュボード(New Relic 公式ドキュメントより引用)

NRQLで照会できるデータの種類は以下の通り

k8s のイベント一覧(2022/12/19現在のNew Relic 公式ドキュメントより)
「発売日」列(自動翻訳がかかっていますが、おそらくリリースバージョンのこと)にある通り、 New Relic の k8s インテグレーションは現在も開発中で、新機能や新しい Kubernetes バージョン、新しいクラウドプロバイダーのサポートを含むアップデートが定期的にリリースされています。

また、監視に必須となるアラートの設定もインテグレーションをインストールするとデフォルトで定義されています。
(アラートの条件のみで、通知チャンネルは自分で設定する必要があります。)

【例】

  • コンテナのCPU使用率が5分以上90%を超えているとき(CPU使用率が高すぎる)
  • Podが7分間Scheduledにならないときアラートをあげる(Podのスケジューリングに失敗)


k8sの稼働状況をダッシュボードに表示する

NRQLを用いてk8sの基本的なデータをNew Relicのダッシュボードに表示してみます。

K8sDeploymentSampleはDeployment(ローリングアップデートやロールバックといったデプロイ管理の仕組みを提供するもの)に関する情報を提供してくれます。

Deployment別Pod数
図のクエリでは、Deployment別のPod数を円グラフで表示し、指定した数のPodが起動しているかを確認できます。
(Facet句はSQLにおけるGroupBy句のようなものです)

K8sPodSampleはPod(k8s 内で作成・管理できるコンピューティングの最小のデプロイ可能なユニット)に関する情報を提供してくれます。

Pending Pod 発生推移
図のクエリでは、状態がPending(準備中)のPodを面グラフで表示しています。
(TIMESERIES句は時系列表示したいときに使用します。図ではMAXを指定していますが、1分単位などの期間指定もできます。)
Pending状態が発生しているということは、ノードのキャパシティが不足している可能性があるので、キャパシティを見直す指標になります。

K8sNodeSampleはNode(Podが動作するVMまたは物理マシン)に関する情報を提供してくれます。

NodeのCPU/メモリ使用率
図のクエリでは、各NodeのCPU使用率/メモリ使用率を線グラフで表示することで、Nodeの負荷状況を可視化しています。
複数あるNodeの内、1つだけが飽和している場合はPodの再配置を検討します。
すべてのNodeが100%に近い場合は、Nodeのスケールアウトやスケールアップが検討できます。

Node同様にPodの負荷状況も可視化できます。
Podの負荷状況をみるにはK8sPodSampleではなくK8sContainerSampleを照会します。

K8sContainerSampleはContainer(Podで実行されるコンテナ)に関する情報を提供してくれます。

PodのRequestに対するCPU/メモリ使用率
PodのLimitに対するCPU/メモリ使用率

k8s ではPodが利用できる最低限/最大限(Request/Limit)のリソースサイズを指定することができ、図のクエリはRequest/Limitそれぞれに対する使用率を表示しています。
Limitに対する使用率が100%に近い場合は、 Podのlimitsを調整してより大きなリソースを確保できるようにする、もしくはレプリカ数を増やしてDeployment全体としてのリソースキャパシティを拡大することを検討します。
Requestに対する使用率が継続的に著しく高い場合はrequestサイズを大きくし、オーバーコミット(PodのRequestとLimitの合計が、そのNodeで利用できるリソースを超えた状態)の発生リスクを下げることを検討します。


おわりに

New Relic で k8s を監視する一例を紹介しました。
New Relic はパフォーマンスデータを可視化からアラート通知の設定、ビジネス指標やカスタマーエンゲージメントなどの分析まで、できることが多岐に渡ります。
公式ドキュメントを漁るたびに、アレもできる!コレもできる!となり、New Relic を使い尽くすにはまだまだ勉強が必要そうです。
k8s だけでなく他のリソースの監視も含めて使い尽くせるよう、今後もNew Relicの機能を調べて使っていきたいと思います。

ecbeingではモダンを追い求めるエンジニアを募集しています!! careers.ecbeing.tech