New Relic Kubernetesインテグレーションにより、New Relic Infrastructureエージェントを活用して、環境の健全性とパフォーマンスのフルオブザーバビリティを実現します。このエージェントは、Kubernetesイベントインテグレーション、Prometheusエージェント、New Relicログプラグインなど、その他のさまざまなNew Relicインテグレーションとともにクラスタからメトリクスを収集します。
Why use the guided install?
To install our Kubernetes integration, we recommend that you follow the instructions here for our guided install. We recommend this interactive installation tool for servers, VMs, and unprivileged environments. Here are some advantages of using the guided install:
It can provide either a Helm command with the required values filled, or a plain manifest if you don't want to use Helm.
It gives you control over which features are enabled and which data is collected.
It also offers a quickstart option that includes some optional, pre-built resources such as dashboards and alerts alongside the Kubernetes integration so that you can gain instant visibility into your Kubernetes clusters.
ヒント
For some environments, you may need (or prefer) to do a manual install instead of the guided install. We have docs for the following: Manual install with Helm, Windows, and EKS Fargate.
Before you start the guided install
Take a look at the following to make sure you're ready:
If you are installing our integration on a managed cloud, please take a look at these preliminary notes before proceeding.
Make sure you are using the supported Kubernetes versions and make sure to check out the preliminary notes for your managed services or platforms on our compatibility and requirements page.
Make sure you have New Relic
. You can set up an account that's free—no credit card required.
Make sure you whitelist the domains (newrelic dockerhub and Google's registry registry.k8s.io) from where the installation will pull container images. Note, you may need to follow the commands to identify the additional Google registry domain to be whitelisted, because registry.k8s.io is typically redirected to your local registry domain (e.g., asia-northeast1-docker.pkg.dev) based on your region.
Start the guided install
We have some links below that will take you to the guided install that is right for you. After you start the installation process, you can use the tips in the remainder of this guide to help you make decisions about the various setup options.
Use this option if your New Relic organization does not use the EU data center, and you also want to install some bonus dashboards and alerts from the quickstart.
Navigating the Kubernetes integration guided install
Once you start the guided install, use the following information to help you make decisions about the configurations.
ヒント
The steps that follow skip the preliminary steps for the quickstart. If you chose the guided install with the quickstart, just click through the pages Confirm your Kubernetes quickstart installation and Installation plan to reach the main guided install pages described below.
Step 1 of 3
On the page Configure the Kubernetes Integration complete the following fields:
フィールド
説明
We'll send your data to this account
Choose the New Relic account that you want your Kubernetes data written to.
Cluster name
Cluster name is the name we will use to tag your Kubernetes data with so that you can filter for the data specific to the cluster you’re installing this integration in. This is important if you choose to connect multiple clusters to your New Relic account so choose a name that you’ll recognize!
Namespace for the integration
Namespace for the integration is the namespace we will use to house the Kubernetes integration in your cluster. We recommend using the default namespace of newrelic.
Step 2 of 3
On the page Select the additional data you want to gather, choose the options that are right for you:
Scrape Prometheus endpoints
By selecting this option, we will install Prometheus in agent mode to collect metrics from the Prometheus endpoints exposed in your cluster. Expand the collapsers to see details about each option:
We recommend this configuration because various other components of the Kubernetes integration, such as kube-state-metrics, newrelic-infrastructure, and nri-prometheus will already collect these metrics and configuring Prometheus to exclude those metrics will save your data ingest costs by removing any metric redundancies.
Select Scrape all Prometheus endpoints if you prefer to preserve Prometheus’ metric naming conventions across all Prometheus metrics regardless of any metric redundancies.
New Relic provides quickstarts, which are pre-made dashboards, alerts, and entities for various services. Select this option to have Prometheus only scrape for services which have a pre-made quickstart and are ready to go for instant observability.
Here's an example from newrelic-prometheus-configurator/charts/newrelic-prometheus-agent/values.yaml showing in the app_values field which services will be scraped for the Prometheus quickstart option:
kubernetes:
# NewRelic provides a list of Dashboards, alerts and entities for several Services. The integrations_filter configuration
# allows to scrape only the targets having this experience out of the box.
# If integrations_filter is enabled, then the jobs scrape merely the targets having one of the specified labels matching
# one of the values of app_values.
# Under the hood, a relabel_configs with 'action=keep' are generated, consider it in case any custom extra_relabel_config is needed.
integrations_filter:
# -- enabling the integration filters, merely the targets having one of the specified labels matching
# one of the values of app_values are scraped. Each job configuration can override this default.
enabled:true
# -- source_labels used to fetch label values in the relabel config added by the integration filters configuration
You'll find this option useful if you're an advanced user who has a good idea of what services you want to see Prometheus metrics from. Enter a comma-separated list of services you want Prometheus to scrape, and Prometheus will perform a wildcard match on the service name in order to find you metrics from your desired endpoint.
This option will only provide metrics from the services that match the submitted list, so be careful to validate the entry for correctness. To learn more about custom app labels, see Advanced configuration for the Prometheus agent.
The services you add to the submitted list will overwrite the data in app_values below, and Prometheus will only scrape metrics from those services.
Here is an example from newrelic-prometheus-configurator/charts/newrelic-prometheus-agent/values.yaml:
kubernetes:
# NewRelic provides a list of Dashboards, alerts and entities for several Services. The integrations_filter configuration
# allows to scrape only the targets having this experience out of the box.
# If integrations_filter is enabled, then the jobs scrape merely the targets having one of the specified labels matching
# one of the values of app_values.
# Under the hood, a relabel_configs with 'action=keep' are generated, consider it in case any custom extra_relabel_config is needed.
integrations_filter:
# -- enabling the integration filters, merely the targets having one of the specified labels matching
# one of the values of app_values are scraped. Each job configuration can override this default.
enabled:true
# -- source_labels used to fetch label values in the relabel config added by the integration filters configuration
"message":"[2021/09/14 12:30:49] [ info] [engine] started (pid=1)\n",
"plugin":{
"source":"kubernetes",
"type":"fluent-bit",
"version":"1.8.1"
},
"stream":"stderr",
"time":"2021-09-14T12:30:49.138824971Z",
"timestamp":1631622649138
}
]
If you want to prioritize data ingest costs, you can choose to gather log data with minimal enrichment. This option drops labels and annotations from their logs and only shares standard Kubernetes log data such as the name of the cluster, container, namespace, and pod, along with the message and timestamp.
In minimal enrichment, only the following fields are retained:
[FILTER]
Name record_modifier
Match *
Record cluster_name ${CLUSTER_NAME}
Allowlist_key container_name
Allowlist_key namespace_name
Allowlist_key pod_name
Allowlist_key stream
Allowlist_key message
Allowlist_key log
Here's an example of minimal log enrichment:
[
{
"cluster_name":"api-test",
"container_name":"newrelic-logging",
"namespace_name":"nrlogs",
"pod_name":"nri-bundle-newrelic-logging-jxnbj",
"message":"[2021/09/14 12:30:49] [ info] [engine] started (pid=1)\n",
"stream":"stderr",
"timestamp":1631622649138
}
]
Enable service-level insights, full-body requests, and application profiles through Pixie
Pixie is an open source observability tool for Kubernetes applications that uses eBPF to automatically collect telemetry data. If you don't have Pixie installed on your cluster, but want to leverage Pixie's powerful telemetry data collection and visualization on the New Relic platform, check Enable service-level insights, full-body requests, and application profiles through Pixie.
If you're already using Community Cloud, select Community Cloud hosted Pixie is already running on this cluster. Keep the following in mind about the different ways Pixie can be hosted. New Relic provides a different level of integration support for each Pixie hosting option.
If you're already leveraging Pixie's Community Cloud, you can provide an API key to connect Pixie to New Relic. This approach will embed Pixie's live UI into your New Relic account for easy access (via Pixie's Live Debugging tool), as well as write Pixie data into New Relic through the New Relic OpenTelemetry endpoint.
If you're using Pixie with a self-hosted Pixie Cloud, you can also connect Pixie to New Relic. This approach will enable the export of Pixie telemetry data into New Relic via the OpenTelemetry endpoint for long-term data retention and visibility. Unfortunately, if you're self-hosting your Pixie Cloud, New Relic does not support embedding Pixie's Live UI.
If you are self-hosting Pixie Cloud and would like to enable the export of Pixie telemetry data into New Relic, simply enable Pixie in the Kubernetes Integration without checking the Community Cloud hosted Pixie option. The Kubernetes Integration will detect that Pixie is running in your cluster and enable the data export for instant data visibility and insight.
Step 3 of 3
Finalize the Kubernetes installation setup by choosing one of the following:
The Kubernetes integration only monitors worker nodes into Amazon EKS as Amazon abstracts the management of master nodes away from the Kubernetes platform.
Before using our guided install to deploy the Kubernetes integration in Amazon EKS, make sure to install eksctl, the command line tool for managing Kubernetes clusters on Amazon EKS.