Si tiene servicios que se ejecutan en Kubernetes y son compatibles con nuestra integración aplicable, puede habilitar esa integración a través de nuestra integración Kubernetes .
Empezar
Nuestra integración Kubernetes viene incluida con algunas de nuestras integraciones en el host. Esto le permite obtener datos para esos servicios agregando una sección a la configuración de la integración de Kubernetes, que se encuentra como ConfigMap
dentro de un manifiesto.
Para ver un ejemplo de cómo monitorear Redis ejecutándose en un libro de visitas PHP de Kubernetes, consulte este tutorial.
Requisitos
Para monitor los servicios que se ejecutan en Kubernetes, necesita:
Un clúster de Kubernetes que ejecuta una versión compatible.
Un clúster de Kubernetes que ejecuta la integración de Kubernetes (instalar | verificar versión | actualizar).
Un servicio compatible que se ejecuta en Kubernetes y que cumple con nuestros requisitos. Los servicios soportados son:
Para este método de instalación, nuestra integración RabbitMQ y Apache no reportan datos de inventario.
Habilite el monitoreo de servicios usando Helm Chart
Los servicios de monitoreo en Kubernetes funcionan aprovechando nuestro agente de infraestructura e integración en el host y un mecanismo de descubrimiento automático para señalarlos al pod con un selector específico.
Vea este ejemplo de configuración para la versión 2.
Para permitir que nuestra integración Kubernetes monitor uno o más servicios:
Obtener la configuración básica
Puede obtener un archivo de configuración de ejemplo para nuestra integración que se puede ejecutar en K8 en los siguientes enlaces:
Tenga en cuenta que la mayoría de estos ejemplos deberán configurarse para su entorno particular, principalmente para ingresar las credenciales necesarias para autenticarse en el servicio en particular. Puede leer más sobre cómo configurar cada integración en detalle en las páginas específicas de la integración, vinculadas en el menú desplegable de arriba.
Añade la configuración a tu values-newrelic.yaml
Sugerencia
Este formato se aplica a la integración de Kubernetes v3. Para la versión anterior v2, consulte Monitorear servicios que se ejecutan en Kubernetes.
Un fragmento de configuración funcional debe ser un documento YAML con la siguiente estructura:
# Top level name can be arbitrary, akin to a config file nameredis-sampleapp.yaml: # Discovery section will define which pods will be monitored. discovery: command: # nri-discovery-kubernetes is a tool that connects to the Kubelet to fetch local pods # without putting stress in the API Server. It accepts the following arguments: # --namespaces: Comma separated namespaces to limit discovery on # --tls: Use tls for connecting to the kubelet # --port: Port used to connect to the kubelet. Defaults to 10255. exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250 # Monitor pods which have a `app=sampleapp` label match: label.app: sampleapp
# Integrations section contains the integration configs. # ${placeholders} will be replaced with the specified attributes for each pod that is discovered integrations: - name: nri-redis # Integration name, should not be changed env: # Using the discovered pod IP as the hostname address HOSTNAME: ${discovery.ip} PORT: 6379 # Other integration options go here
Este fragmento debe agregarse a la sección integrations
, debajo de newrelic-infrastructure
en su archivo values-newrelic.yaml
. Por ejemplo:
global: licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_ cluster: _K8S_CLUSTER_NAME_
# Other settings...
newrelic-infrastructure: # verboseLog: true integrations: redis-sampleapp.yaml: discovery: command: # --namespaces: Comma separated list of namespaces to discover pods on # --port: Port used to connect to the kubelet. Default is 10255 # --tls: Use secure (TLS) connection exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250 match: label.app: sampleapp
integrations: - name: nri-redis env: HOSTNAME: ${discovery.ip} PORT: 6379
Sugerencia
Observe que estamos especificando --tls --port 10250
. Es posible que las versiones anteriores de la integración funcionaron sin esto; a partir de la versión 3 de la integración de Kubernetes es obligatorio especificarlas. El motivo de este cambio es que la integración ahora se conecta a Kubelet empleando el nodeIP en lugar de localhost
; el primero requiere TLS mientras que el segundo no.
La integración dirigida a otro grupo debe tener su propia sección junto a redis-sampleapp.yaml
.
Integración son binarios independientes y son ejecutados por el agente de infraestructura que está incluido en el pod newrelic-nrk8s-kubelet-xxxxx
. Los archivos de configuración se distribuyen en todos los pods del nrk8s-kubelet
DaemonSet, pero el descubrimiento garantiza que cada pod solo tendrá como objetivo el pod de servicio que esté programado en el mismo nodo que ese pod nrk8s-kubelet
en individuo. Si una instancia de nrk8s-kubelet
DaemonSet no tiene ningún pod que coincida con las etiquetas especificadas, esa instancia ###
no ejecutará la integración.
Verifique que la integración esté funcionando
Vaya a one.newrelic.com > All capabilities > Infrastructure, seleccione Third party services y luego seleccione el dashboard del servicio. Debería ver los datos que se informan.
Si no ve los datos allí, es posible que a la integración le falte algún parámetro que requiere ejecutarse o que no pueda alcanzar el servicio objetivo. Puedes obtener el log de la integración ejecutando:
$kubectl logs -n newrelic newrelic-nrk8s-kubelet-xxxxx agent
Asegúrese de seleccionar el pod particular del nrk8s-kubelet
DaemonSet que está programado junto al pod al que debe dirigirse la integración. Puede verificar qué instancia se está ejecutando en qué nodo ejecutando el siguiente comando:
$kubectl get pods -n newrelic -o wide -l app.kubernetes.io/component=kubelet
Notas adicionales sobre la habilitación de servicios
- Habilitar varios servicios puede utilizar más recursos de los establecidos en los límites de recursos del archivo de configuración de integración de Kubernetes. Si esto se convierte en un problema, aumente el límite en la sección
resources
. - La integración de Kubernetes no se actualiza automáticamente. Para obtener mejores resultados, actualice periódicamente.
Aprende más
Más recursos para aprender sobre la configuración:
- Conozca los detalles técnicos sobre cómo funciona la configuración.
- Aprenda a configurar el monitoreo de múltiples servicios con el mismo archivo de configuración.
- Vea un tutorial paso a paso que muestra cómo monitorear un servicio de Redis en Kubernetes.
Habilitar el monitoreo de servicios usando manifiestos
Sugerencia
Le recomendamos encarecidamente que configure la integración a través del archivo values-newrelic.yaml
y nuestro Helm Chart, como se explica en la sección anterior. Configurar el monitoreo del servicio además del manifiesto de instalación es sustancialmente más difícil y no ofrece ninguna ventaja.
Para cada servicio que desee monitor, debe agregar un archivo de configuración para esa integración a la configuración de nuestra integración de Kubernetes . Este documento cubrirá estos temas:
- Cómo funciona el fragmento YAML de configuración específica del servicio
- Agregar el YAML específico del servicio en el archivo de configuración de la integración de Kubernetes
- Agregar múltiples servicios al archivo de configuración de la integración de Kubernetes
Cómo funciona la configuración YAML específica del servicio
La configuración de nuestra integración de Kubernetes sigue el formato ConfigMap
. Usar un ConfigMap
nos permite desacoplar la configuración para la integración de la imagen Kubernetes . El otro beneficio es que un ConfigMap
se puede actualizar automáticamente sin recargar el contenedor en ejecución.
Debido a que el agente de infraestructura usa YAML para configurar su integración asociada, ConfigMaps
es una buena opción para almacenar YAML. (Para obtener más información sobre el formato del archivo de configuración, consulte Formato del archivo de configuración de integración).
La imagen de integración Kubernetes viene con una característica de descubrimiento automático que simplifica la configuración de múltiples instancias de servicios utilizando un único archivo de configuración. Por ejemplo, si tiene varias instancias de NGINX ejecutándose, crear un archivo de configuración de integración NGINX para cada instancia sería difícil de implementar y de actualizar. Con nuestra opción de descubrimiento automático, puede descubrir y monitor todas sus instancias de NGINX con un único archivo de configuración.
Cada integración tiene su propia configuración YAML específica. Nuestro archivo de configuración predeterminado de integración NGINX se ve así:
discovery: command: # Use the following optional arguments: # --namespaces: Comma separated list of namespaces to discover pods on # --port: Port used to connect to the kubelet. Default is 10255 # --tls: Use secure (TLS) connection # Custom Example: # exec: /var/db/newrelic-infra/nri-discovery-kubernetes --namespaces namespace1,namespace2 --port 10250 --tls # Default exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250 match: label.app: nginxintegrations: - name: nri-nginx env: STATUS_URL: http://${discovery.ip}/status STATUS_MODULE: discover METRICS: 1
La configuración anterior permite lo siguiente:
Ejecuta
nri-discovery-kubernetes
para consultar los datos del nodo en el que nos encontramos actualmente.Analiza los datos que regresan y busca cualquier pod de Kubernetes que tenga un contenedor de Kubernetes con una etiqueta
app=
con valornginx
.Para cualquier coincidencia, intenta ejecutar la integración NGINX. La URL de estado se construye a partir de:
- La dirección IP del pod
- La página de estado se extrae de la etiqueta del pod K8 llamada
status_url
Este descubrimiento automático funciona igual que el descubrimiento automático de contenedores utilizado por el agente de infraestructura. Para opciones más avanzadas, consulte descubrimiento automático de contenedores.
Agregue un servicio YAML a la configuración de integración de Kubernetes
La integración reconocerá el fragmento anterior si lo coloca dentro de un ConfigMap
designado. Si está empleando nuestra integración de Kubernetes v3, ya debería existir un ConfigMap
con un nombre que termine en -integrations-cfg
.
Si emplea la versión 2 de integración de Kubernetes, consulte Agregar un servicio YAML.
Localice el mapa de configuración y agréguele el fragmento modificado, para que termine luciendo así:
---apiVersion: v1kind: ConfigMapmetadata: name: newrelic-infrastructure-integrations-cfg namespace: newrelicdata: nginx-config.yml: | discovery: command: # Use the following optional arguments: # --namespaces: Comma separated list of namespaces to discover pods on # --port: Port used to connect to the kubelet. Default is 10255 # --tls: Use secure (TLS) connection # Custom Example: # exec: /var/db/newrelic-infra/nri-discovery-kubernetes --namespaces namespace1,namespace2 --port 10250 --tls # Default exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250 match: label.app: nginx integrations: - name: nri-nginx env: STATUS_URL: http://${discovery.ip}/status STATUS_MODULE: discover METRICS: 1
Si está empleando nuestra integración de Kubernetes v3, este ConfigMap
ya estará montado en el contenedor requerido.
Tenga en cuenta que el mismo ConfigMap
puede contener varios archivos de configuración, lo que se recomienda para mantener las modificaciones en los manifiestos al mínimo.
---apiVersion: v1kind: ConfigMapmetadata: name: newrelic-infrastructure-integrations-cfg namespace: newrelicdata: nginx-config.yml: | discovery: # ... integrations: - name: nri-nginx # ... redis-config.yml: | discovery: # ... integrations: - name: nri-redis # ...
Cómo utilizar los datos reportados
Puede obtener más información sobre cómo encontrar y utilizar sus datos de Kubernetes aquí y puede revisar nuestro esquema de datos K8sServiceSample aquí.