NewRelicでEKS FargateのPod/Containerメトリクスを取得する

EKS FargateにNew Relic Kubernetes Integrationを連携する方法

上記の記事を書いたが、NewRelicのKubernetes integration(nri-bundle)自体は既に導入済みで、Namespace単位・Deployment単位のGolden Metricsは普通に取れていたにもかかわらず、Pod/Container単位の詳細メトリクスだけが一切収集されていないことに気づいた。

原因

前提として、コスト・影響範囲を絞るためにnamespaceSelectorで明示的にオプトインしたnamespaceだけに限定する設計になっている。

EKS Fargate環境特有の制約で、DaemonSetという概念がない。(何回書いてるんや!?) そのためNewRelicはFargate向けに、対象PodへNewRelic Infrastructureのサイドカーコンテナが必要。

ブラスして肝心のnewrelic.com/scrape: “true”ラベルが、どのnamespaceにも付与されていなかった。nri-bundle自体の導入直後で、個別アプリのオプトインまで確認していなかった。これは盲点。

対応方法

反映後にはkubectl rollout restart deploymentでローリング再起動が必要。

収集できるようになったデータ

https://docs.newrelic.com/jp/docs/kubernetes-pixie/kubernetes-integration/understand-use-data/find-use-your-kubernetes-data/

  • Pod状態: status(Running等), isReady
  • リソース使用率: cpuCoresUtilization, memoryWorkingSetUtilization: restartCount, restartCountDelta
  • ネットワーク: net.rxBytesPerSecond, net.txBytesPerSecond- Pod状態: status(Running等), isReady

Failed to watchが出る場合

これで終わりじゃないということに注意してほしい。 このサイドカーは注入先Podの既存ServiceAccountで動作するため、権限がそのままエージェントの権限になる。ここが罠で、operatorが自動生成するClusterRoleは以下の通りget・listのみでwatchが含まれていない。なので上記デプロイ後にエラーが出る想定。

方法としはServiceAccountにwatch権限だけを追加で付与するClusterRole/ClusterRoleBindingを作成した。KubernetesのRBACは複数のBindingが単純に足し算(union)される仕組みなので、operator管理の既存Bindingとは競合しない。

Was this helpful?

1 / 0

コメントを残す