はじめに
この記事はNew Relic Advent Calender 2022の14日目の記事です。
Kubernetesを対象としたオブザーバビリティ（可観測性）を実現するためには、システム構成、要件に応じたモニタリングツールの選定が重要となります。
Kubernetesは環境の状態が一定ではなく、特定のノードで特定のPodが稼働する、などとあらかじめ見込んでモニタリングすることができません。
また、複数のコンポーネント・サービスが組み合わさっているため、問題が起きた際の瞬時の原因切り分けや調査、特定は従来のモニタリングでは困難です。
以上の背景から、様々なモニタリングツールを実際に触ってみる、つまり、どのような情報がとれるか、どう可視化できるか、どう案件に適用できそうか、
などを把握することは非常に重要だと考えます。
さて、ツールとしてクラウドサービスでは、AWSのContainer InsightsやAzureのAzure Monitor、OSSでは、PrometheusやGrafanaなどが広く利用されています。
本記事では、有償製品であるNewRelicとAmazon Elastic Kubernetes Service（EKS）を連携し、導入手順と連携結果をまとめてみました。
前提条件
- Amazon Elastic Kubernetes Service（EKS）v1.23
- New Relic One（執筆時点：2022/12/14）
導入手順
New Relicにログインし、Add dataメニューからKubernetesを選択します。
NewRelicアカウントIDと、これから連携するEKSクラスタ識別用の名前を設定します。(今後NewRelicコンソール上に表示される名前です。)
また、エージェントがインストールされるKubernetes上のNamespaceはnewrelicとしました。
次にエージェント導入に関わるオプション設定をしていきます。
今回は、以下の通りの設定としました。
上記オプションに関する説明は以下の通りです。
Scrape Prometheus endpoints
- クラスター内のPrometheusエンドポイントからメトリクスを収集するか（ON：収集）
⇒ 今回はPrometheus形式のメトリクスは収集しないためOFFとしました。
Gather Log data
- Kubernetesコントロールプレーン及び、全てなコンテナログを収集するか（ON：収集）
⇒ 今回はログ収集ありに設定しています。
Instant service-level insights, full-body requests, and application profiles through Pixie
- Pixieを導入するか（ON：導入）
⇒ Pixieは、アプリケーションパフォーマンスデータやリクエストデータを収集できるモニタリングツールです。
詳しくはこちらで紹介されています。
今回はONにしました。
Pixie is already running in this cluster
- Pixieがすでにクラスタ上で起動状態か（ON：起動済）
⇒ 未導入なのでOFFにしました。
Set up for unprivileged mode
- 非特権モードのセットアップを有効化するか（ON：有効）
⇒ 今回は特権モードでセットアップしメトリクス収集します。
※セキュリティ要件レベルが高い場合は、非特権モードでインストールすることを推奨。
Reduce the amount of ingested data
- 取込データ量を削減するか（ON：削減）
⇒ 取込データ量を減らし、NewRelicへの転送コストを減らしたい場合に選択します。今回は削減します。
次に、Choose Install method選択画面に移ります。ここではHelm3を選択し、Helmによるインストールを実施していきます。
画面上には、先ほどのオプション設定を反映し、自動作成されたスクリプトが表示されています。
Helmチャートのvalues.yamlのパラメータを上書く設定が入っていますね。
その他のパラメータに関する説明は以下に載っていますので、必要に応じてご参照ください。
HelmによるKubernetesインテグレーションのインストール | NewRelic
次にEKSに接続可能な端末から、Helmコマンドを実行してきます。
端末へのインストールが済んでいない場合は、事前にこちらからインストールをお願いします。
$ helm repo add newrelic https://helm-charts.newrelic.com && helm repo update && \
kubectl create namespace newrelic ; helm upgrade --install newrelic-bundle newrelic/nri-bundle \
--set global.licenseKey=YOUR_LICENSE_KEY \
--set global.cluster=eks-work-cluster \
--namespace=newrelic \
--set newrelic-infrastructure.privileged=true \
--set global.lowDataMode=true \
--set ksm.enabled=true \
--set kubeEvents.enabled=true \
--set logging.enabled=true \
--set newrelic-pixie.enabled=true \
--set newrelic-pixie.apiKey=YOUR_PIXIE_API_KEY \
--set pixie-chart.enabled=true \
--set pixie-chart.deployKey=YOUR_PIXIE_DEPLOY_KEY \
--set pixie-chart.clusterName=eks-work-cluster
実行後、しばらく待ってから、kubectlコマンドでPodが起動していることを確認します。
上と同じく、端末へのインストールが済んでいない場合は、事前にインストールをお願いします。
$ kubectl get pod -n newrelic
NAME READY STATUS RESTARTS AGE
kelvin-7756fb8f47-bvjdg 1/1 Running 0 72s
newrelic-bundle-kube-state-metrics-547fc6d94f-8m78p 1/1 Running 0 111s
newrelic-bundle-newrelic-logging-2v78z 1/1 Running 0 111s
newrelic-bundle-newrelic-logging-csps4 1/1 Running 0 111s
newrelic-bundle-newrelic-pixie-xx58v 0/1 Completed 0 111s
newrelic-bundle-nri-kube-events-f8ffcd4db-sn8jx 2/2 Running 0 111s
newrelic-bundle-nri-metadata-injection-df5b566d6-k4fnz 1/1 Running 0 111s
newrelic-bundle-nrk8s-ksm-769dcc4d5c-mwt5s 2/2 Running 0 111s
newrelic-bundle-nrk8s-kubelet-tjftj 2/2 Running 0 111s
newrelic-bundle-nrk8s-kubelet-zg5s4 2/2 Running 0 111s
pl-nats-0 1/1 Running 0 76s
vizier-cloud-connector-d578bcf4f-56pnx 1/1 Running 0 72s
vizier-metadata-0 1/1 Running 0 72s
vizier-pem-c6gff 1/1 Running 0 72s
vizier-pem-flmpr 1/1 Running 0 72s
vizier-query-broker-6b795b84b7-q95mk 1/1 Running 0 72s
Podが起動すると、NewRelicコンソール側でもこのようにエージェントとの連携ができたことを確認できます。
インストールされるリソース
導入が終わりましたので、いったんここでは実際にインストールされたエージェントについて詳しくみていきます。
今回の環境で導入したKubernetesリソースのうち、いくつかをピックアップして記載してみました。
参考：Kubernetes 統合バージョン 3 で導入された変更 | NewRelic
| オブジェクト | 名前 | 説明 |
|---|---|---|
| ReplicaSet | newrelic-bundle-kube-state-metrics | kube-state-metricsのエクスポータ。 kube-state-metricsは、Podの情報やDeploymentやStatefulSetの正常に稼働しているPodの数などの多くの情報を収集する。 |
| ReplicaSet | newrelic-bundle-nrk8s-ksm | kube-state-metricsからメトリクスを収集しNewRelicに送信する。 |
| ReplicaSet | newrelic-bundle-nri-kube-events | KubernetesイベントをNewRelicに送信する 。 |
| DaemonSet | newrelic-bundle-nrk8s-kubelet | Kubeletから取得したCPU、メモリなどのインフラメトリクスを収集し、NewRelicに送信する。 |
| DaemonSet | newrelic-bundle-newrelic-logging | ログをNewRelicに転送するためのコンポーネント。 FluentBitプラグインを利用し転送する。 |
| DaemonSet | vizier-pem | Pixieのコンポーネント。 eBPFを用いてテレメトリーデータの収集やデータの一時保管を行う。 |
概要図としてまとめると、以下のようなイメージになります。
今回は2 ノード構成としているため分かりにくいですが、各ノードで起動するDaemonSetとクラスター内で任意のレプリカ数起動するReplicaSetの2種類のPodが稼働しています。
また、メトリクス、ログ、トレースの収集・転送といった各役割毎にPodを構成していることがわかります。
※ vizier-pem等のPixieコンポーネントは、Pixieエージェントとしてまとめて表記しています。
NewRelicでの可視化
それでは、NewRelicでどのように可視化されるか確認していきます。
Kubernetesダッシュボード
Infrastructureメニュー > Third-party-servicesからKubernetes dashboardを選択します。
Kubernetesダッシュボードでは、Kubernetesクラスタのオブジェクト数やPod数、各コンテナ毎のメトリクス、Deploymentに関する情報など
クラスタ全体の様々な情報を数値、グラフ等で可視化することができます。
また、Filterメニューからクラスタやノード、Podなどの属性でフィルタすることもできます。
Kubernetes Cluster Explorer
Infrastructureメニュー > Kubernetesから参照するクラスタ識別子を選択します。
Kubernetes Cluster Explorerでは、以下の通りPod、ノードをマップとして表現しています。
1つ1つのハニカムがPodとなっており、Podのステータスを色や配置箇所（中心からの位置）で表現しているため、
全体を俯瞰し一目で問題のあるPodを特定することができます。
また、稼働しているNodeもマップ上でわかるようになっています。
Podを選択すると、そのPodにひもづくコンテナのCPU使用量やメモリ使用量、スループット等を確認でき、
また、そこからPodやコンテナの詳細画面、ログ、APM&Service画面へ遷移することができます。
※ 補足：選択しているbackend-appアプリケーションは、以下参考文献2で紹介されていたJavaサンプルアプリケーションを利用
以下は、Podの See logリンク（上画像の右上箇所）から遷移した後のログ画面です。
上部のテキストボックスでクエリを編集することも可能です。
また、先ほどのPodを選択した状態からCheck metrics in Pixieリンクを押下すると、
以下の通り対象のサービスに対するHTTPリクエスト、レスポンスの情報といったアプリケーションの性能情報を得ることもできました。
まとめ
NewRelicとEKSを連携してみました。
連携は非常に簡単で、数分でインストールとダッシュボード上での可視化ができることにも驚きました。
また、クラスターに何かしらの問題が起きた際にはCluster ExplorerからPod・ノードの状態を確認することで
いち早いボトルネックの特定にもつながり、このような非常に有用なダッシュボードが揃っていると感じました。
Podを選択しドリルダウンして、各コンテナのメトリクス、ログ、トレースデータをすばやく参照できるのも非常に良いですね。
参考文献
この記事は以下の情報を参考にして執筆しました。