上記の記事を書いたが、NewRelicのKubernetes integration（nri-bundle）自体は既に導入済みで、Namespace単位・Deployment単位のGolden Metricsは普通に取れていたにもかかわらず、Pod/Container単位の詳細メトリクスだけが一切収集されていないことに気づいた。
原因
前提として、コスト・影響範囲を絞るためにnamespaceSelectorで明示的にオプトインしたnamespaceだけに限定する設計になっている。
EKS Fargate環境特有の制約で、DaemonSetという概念がない。(何回書いてるんや！？) そのためNewRelicはFargate向けに、対象PodへNewRelic Infrastructureのサイドカーコンテナが必要。
|
1 2 3 4 5 6 7 |
newrelic-infra-operator: config: infraAgentInjection: policies: - namespaceSelector: matchLabels: newrelic.com/scrape: "true" |
ブラスして肝心のnewrelic.com/scrape: “true”ラベルが、どのnamespaceにも付与されていなかった。nri-bundle自体の導入直後で、個別アプリのオプトインまで確認していなかった。これは盲点。
対応方法
|
1 2 3 4 5 6 7 8 9 10 11 |
# namespace.yaml metadata: labels: ... {{- if .Values.namespace.newrelicScrape }} newrelic.com/scrape: "true" {{- end }} # values/hoge namespace: newrelicScrape: true |
反映後にはkubectl rollout restart deploymentでローリング再起動が必要。
収集できるようになったデータ
- Pod状態: status（Running等）, isReady
- リソース使用率: cpuCoresUtilization, memoryWorkingSetUtilization: restartCount, restartCountDelta
- ネットワーク: net.rxBytesPerSecond, net.txBytesPerSecond- Pod状態: status（Running等）, isReady
Was this helpful?
1 / 0
1989年生まれのSRE 。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。 現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、オブザーバビリティ、 緊急対応、AWSでのインフラ構築、Docker開発環境の提供、IaC、新技術の検証、リファクタリング、セキュリティ強化を担当している。
個人事業主では数社サーバー保守とベンチャー企業のインフラコンサルティングを行うほか、TechBullを創業し、ジュニアエンジニアのコミュニティを運営している。さらに、エンジニア向けYouTubeメディア「TECH WORLD」ではSRE関連の動画に出演し、過去には脆弱性スキャナ「Vuls」のOSS活動にも貢献。 ガジェット系エンジニアYouTuberとしても発信。