Instalar y configurar NRDOT para el monitoreo de MySQL con Helm

Puede instalar y configurar el monitoreo de MySQL en Kubernetes usando el chart de Helm mysql-otel. Opcionalmente, el chart también puede ejecutar un trabajo de configuración que crea el usuario de monitoreo.

Instalación guiada

Para instalar a través de la UI de New Relic en su lugar, vaya a one.newrelic.com > Integrations & Agents > MySQL (Database 360) . Esta página solo cubre la instalación manual.

Importante

El chart despliega el recolector como un despliegue de Kubernetes que se conecta a MySQL de forma remota a través de la red. Como resultado, siempre se conecta a través de TCP (el monitoreo de sockets de Unix no es compatible) y solo reporta métricas de MySQL (no hay métricas de host o infraestructura para la máquina en la que se ejecuta MySQL). Al usar mysql.*, monitorea una instancia de MySQL por release; para monitorear varias instancias desde un solo release, use mysqlMulti.* en su lugar (consulte Monitorear múltiples instancias desde un release a continuación).

Requisitos previos

Una clave de licencia de New Relic válida.
MySQL 5.7 o posterior.
Helm 3.0 o posterior, y kubectl configurado para acceder al clúster de Kubernetes.
Conectividad de red desde el clúster de Kubernetes al host de MySQL (o extremo de RDS) y puerto:
- Autohospedado: una ruta enrutada al host de MySQL (VPN, peering o red compartida), resolución de DNS si es un nombre de host y el firewall del lado de MySQL debe permitir la IP de origen real de la conexión (que puede ser una puerta de enlace NAT, no la IP del pod en sí).
- AWS RDS: emparejamiento de VPC, una puerta de enlace de tránsito o ubicación de VPC compartida con la instancia de RDS, y el grupo de seguridad de RDS debe permitir el puerto de MySQL (3306 por defecto) desde el origen de salida del clúster.
Ya sea un usuario de monitoreo que ya haya creado o credenciales de administrador de MySQL para que el trabajo de configuración del chart pueda crear uno. Consulte Configurar las credenciales de monitoreo a continuación.

Cree el namespace

Cree el namespace en el que realizará la instalación. Debe existir antes de crear cualquier secreto en el siguiente paso, ya que helm install --create-namespace solo crea el namespace durante el paso de instalación final:

bash

$kubectl create namespace newrelic

Sugerencia

Establézcalo como el namespace predeterminado para el contexto kubectl actual para que no necesite pasar -n en cada comando a continuación:

bash

$kubectl config set-context --current --namespace=newrelic

Configurar las credenciales de monitoreo

Decida si desea que el trabajo de configuración del chart cree el usuario de monitoreo de MySQL por usted y, de no ser así, cómo proporcionará sus credenciales:

Con este método no hay un trabajo de configuración, por lo que nada aquí crea el usuario de monitoreo. Antes de instalar el chart, créelo mediante el paso Configurar el usuario de la base de datos de MySQL autohospedado o MySQL en RDS, o ejecute el SQL equivalente como usuario administrador:

CREATE USER IF NOT EXISTS 'newrelic'@'%' IDENTIFIED BY '<password>';
GRANT SELECT ON performance_schema.* TO 'newrelic'@'%';
FLUSH PRIVILEGES;

Configurará el nombre de usuario y la contraseña de monitoreo directamente en values.yaml en el siguiente paso.

Con este método tampoco hay un trabajo de configuración. Cree el usuario de monitoreo primero, exactamente como en el método de credenciales en texto sin formato anterior. La única diferencia es dónde residen sus credenciales: en lugar de texto sin formato en values.yaml, almacénelas en un secreto de Kubernetes:

bash

$kubectl create secret generic mysql-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic

Con este método, el trabajo de configuración del chart crea el usuario de monitoreo usando las credenciales de administrador de MySQL. Tanto las credenciales de monitoreo como las de administrador deben proporcionarse como secretos de Kubernetes: el trabajo de configuración nunca acepta credenciales de administrador en texto plano, y habilitarlo también requiere credenciales de monitoreo basadas en secretos.

Cree un secreto con el nombre de usuario y la contraseña de monitoreo. Esta es la identidad que crea el trabajo de configuración y con la que se conecta el recolector:

bash

$kubectl create secret generic mysql-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic

El trabajo de configuración solo acepta credenciales de administrador a través de un secreto de Kubernetes (sin nombre de usuario/contraseña en texto sin formato en values.yaml). Dado que esta credencial puede ejecutar CREATE USER y otorgar un amplio acceso a performance_schema, créela como su propio secreto. Use la cuenta root para MySQL autohospedado, o el usuario maestro de RDS para MySQL en AWS RDS:
bash
```
$kubectl create secret generic mysql-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
```

Configurar los valores de Helm

Establezca mysql.topology para que coincida con su entorno:

Valor	Descripción
`self-hosted`	MySQL autohospedado, al que se accede a través de la red.
`rds`	MySQL o Aurora en AWS RDS.

Utilice el values.yaml que coincida con el método de credenciales que eligió en el paso anterior:

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

mysql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  username: <YOUR_MONITORING_USERNAME>
  password: <YOUR_MONITORING_PASSWORD>

# No setup job runs, so create the monitoring user yourself
# before installing the chart.
setupJob:
  enabled: false

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

mysql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  existingSecret: mysql-monitor-creds

# No setup job runs, so the monitoring user referenced by
# this secret must already exist - create it yourself
# before installing the chart.
setupJob:
  enabled: false

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

mysql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  existingSecret: mysql-monitor-creds

setupJob:
  enabled: true
  mysqlAdmin:
    existingSecret: mysql-admin-creds
  # -- Also grants UPDATE on performance_schema.setup_consumers,
  # needed for wait-time data. Optional.
  enableWaitTimeMetrics: false

Parámetro	Descripción
`licenseKey`	Su clave de licencia de New Relic.
`otlpEndpoint`	El extremo OTLP/gRPC de la región, como un `host:port` simple sin esquema : `otlp.nr-data.net:4317` (EE. UU.) o `otlp.eu01.nr-data.net:4317` (UE). Para obtener más información, consulte la documentación de los extremos OTLP de New Relic .
`mysql.server` / `mysql.port`	El host de MySQL (o extremo de RDS) y el puerto, accesibles desde el clúster.
`mysql.database`	Opcional. Restrinja el monitoreo a una base de datos. Deje vacío para monitorear todas las bases de datos.
`additionalReceiverConfig.tls.*`	Opcional. El chart no declara un bloque `tls` y no tiene valores `mysql.tls.` . Se aplican los valores predeterminados del propio receptor ( `insecure: false` , `insecure_skip_verify: false` ), que requieren una conexión cifrada con validación de certificados. Sobrescríbalos mediante `additionalReceiverConfig` : configure `additionalReceiverConfig.tls.insecure_skip_verify=true` para omitir la validación de certificados (solo para pruebas con certificados autofirmados, ya que debilita la seguridad de la conexión), o `additionalReceiverConfig.tls.ca_file` para apuntar a un paquete de CA montado en el contenedor del recolector. Una instancia de Amazon RDS con la aplicación de Require SSL/TLS necesita que `ca_file` se configure en el paquete de CA de RDS de Amazon* . El chart deliberadamente no incluye ningún paquete predeterminado, ya que un paquete codificado de forma rígida corre el riesgo de quedar obsoleto a medida que Amazon rota las CA.
`setupJob.image.repository` / `setupJob.image.tag`	La imagen de la CLI de `mysql` que usa el trabajo de configuración. De forma predeterminada, se usa la `mysql:8.4` oficial y con mantenimiento activo, por lo que habilitar el trabajo de configuración no requiere indicadores de imagen adicionales. Sobrescriba solo si necesita una versión diferente.
`setupJob.enableWaitTimeMetrics`	Opcional. También otorga `UPDATE` en `performance_schema.setup_consumers` , lo cual es necesario para los datos de tiempo de espera.

Sugerencia

Consulte el values.yaml del chart para ver todas las opciones de configuración disponibles, incluidas mysql.collectionInterval, mysql.explainMode, los bloques statementEvents/querySampleCollection/topQueryCollection y la vía de escape additionalReceiverConfig.

(Opcional) Monitorear múltiples instancias desde un release

En lugar de mysql.*, configure mysqlMulti.enabled: true para monitorear varias instancias de MySQL (autohospedadas o RDS) desde un solo pod recolector en un lanzamiento. Los dos modos son mutuamente excluyentes: no configure mysql.server y mysqlMulti.enabled: true en el mismo lanzamiento.

El modo multiinstancia no tiene una ruta de nombre de usuario/contraseña en texto plano: cada instancia necesita su propio secreto de Kubernetes con credenciales de monitoreo. Decida si también desea que el trabajo de configuración cree cada usuario de monitoreo:

Cree usted mismo el secreto del usuario de monitoreo de cada instancia antes de instalar (repita por instancia, haciendo coincidir el name que le asigne en values.yaml):

bash

$kubectl create secret generic db1-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
$# Repeat for every instance (db2-monitor-creds, ...)

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

# EDIT the two example entries below (or add more) to match
# your real instances - each `name` must be unique within
# this release and match the Secret you created for it.
mysqlMulti:
  enabled: true
  topology: <self-hosted|rds>
  databases:
    - name: db1
      server: <YOUR_DB_1_HOST>
      existingSecret: db1-monitor-creds
    - name: db2
      server: <YOUR_DB_2_HOST>
      existingSecret: db2-monitor-creds

# No admin credential is configured here since the setup
# job is disabled - create each instance's monitoring user
# yourself first.
setupJob:
  enabled: false

Cada instancia necesita tanto su propio secreto de usuario de monitoreo como su propio secreto de credenciales de administrador (repita por instancia):

bash

$kubectl create secret generic db1-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
>kubectl create secret generic db1-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
$# Repeat for every instance (db2-monitor-creds, db2-admin-creds, ...)

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

# EDIT the two example entries below (or add more) to match
# your real instances - each `name` must be unique within
# this release and match the Secrets you created for it.
mysqlMulti:
  enabled: true
  topology: <self-hosted|rds>
  databases:
    - name: db1
      server: <YOUR_DB_1_HOST>
      existingSecret: db1-monitor-creds
      mysqlAdmin:
        existingSecret: db1-admin-creds
    - name: db2
      server: <YOUR_DB_2_HOST>
      existingSecret: db2-monitor-creds
      mysqlAdmin:
        existingSecret: db2-admin-creds

setupJob:
  enabled: true

Parámetro	Descripción
`mysqlMulti.enabled`	Establezca en `true` para monitorear varias instancias desde un lanzamiento en lugar de `mysql.*` . Por defecto es `false` .
`mysqlMulti.topology`	`self-hosted` o `rds` , mismo significado que `mysql.topology` , compartido por cada instancia en esta versión.
`mysqlMulti.databases`	Lista de instancias para monitorear. Cada entrada requiere un único `name` , `server` ( `port` por defecto es `3306` ) y `existingSecret` ; `database` restringe opcionalmente el monitoreo a una base de datos (mismo significado que `mysql.database` ); agregue `mysqlAdmin.existingSecret` por entrada solo cuando `setupJob.enabled` sea `true` .

Parámetro

Descripción

mysqlMulti.enabled

Establezca en

true

para monitorear varias instancias desde un lanzamiento en lugar de

mysql.*

. Por defecto es

false

mysqlMulti.topology

self-hosted

rds

, mismo significado que

mysql.topology

, compartido por cada instancia en esta versión.

mysqlMulti.databases

Lista de instancias para monitorear. Cada entrada requiere un único

name

server

(

port

por defecto es

3306

) y

existingSecret

;

database

restringe opcionalmente el monitoreo a una base de datos (mismo significado que

mysql.database

); agregue

mysqlAdmin.existingSecret

por entrada solo cuando

setupJob.enabled

sea

true

Sugerencia

La configuración de extracción (intervalo de recopilación, TLS, eventos de sentencia, recopilación de muestras de consultas, recopilación de consultas principales) se aplica de manera idéntica a cada instancia en mysqlMulti.databases. No hay sobrescritura por instancia. Use additionalReceiverConfig para cualquier cosa que deba ser diferente. El trabajo de configuración se ejecuta una vez por instancia (<release>-setup-<name>) en lugar de una vez por versión.

Instale el chart de Helm

Agregue el repositorio Helm de New Relic:

bash

$helm repo add newrelic https://helm-charts.newrelic.com
$helm repo update

Instale el chart utilizando su archivo values.yaml:

bash

$helm upgrade --install mysql-otel newrelic/mysql-otel \
>  -n newrelic \
>  --create-namespace \
>  -f values.yaml

Verifique la instalación

Compruebe que el trabajo de configuración se haya completado (si está habilitado) y que el pod del recolector se esté ejecutando:
bash
```
$kubectl get jobs,pods -n newrelic --watch
```

Ejecute esta consulta en el generador de consultas para confirmar que los datos están llegando:

SELECT count(*) FROM Metric
WHERE metricName LIKE 'mysql.%'
AND instrumentation.provider = 'opentelemetry'
SINCE 10 minutes ago

Encuentra y utiliza tus datos

Una vez que sus datos se estén recopilando, puede acceder al monitoreo integral de bases de datos MySQL a través de la UI de New Relic.

Para encontrar su entidad de base de datos MySQL en New Relic:

Vaya a one.newrelic.com > All capabilities > Databases.
En el menú desplegable Entity type, seleccione MySQL instance y luego haga clic en Apply.
Seleccione su base de datos MySQL de la lista de entidades.

Introducción al monitoreo de MySQL con NRDOT

Conozca todos los métodos de instalación disponibles para el monitoreo de MySQL con New Relic.

Instalación de la CLI

Aprenda a instalar y configurar el monitoreo de MySQL con un solo comando de la CLI de New Relic.

Instalación con Ansible

Aprenda a instalar y configurar el monitoreo de MySQL a escala con newrelic.newrelic_install rol de Ansible.

Instalación con Chef

Aprenda a instalar y configurar el monitoreo de MySQL a escala con el cookbook de Chef newrelic-install.

Te ofrecemos esta traducción automática para facilitar la lectura.

Instalar y configurar NRDOT para el monitoreo de MySQL con Helm

Instalación guiada

Importante

Requisitos previos

Cree el namespace

Sugerencia

Configurar las credenciales de monitoreo

Sin trabajo de configuración: nombre de usuario y contraseña en texto sin formato

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Configurar los valores de Helm

Sin trabajo de configuración: nombre de usuario y contraseña en texto sin formato

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Sugerencia

(Opcional) Monitorear múltiples instancias desde un release

Sin trabajo de configuración

Trabajo de configuración automatizado

Sugerencia

Instale el chart de Helm

Verifique la instalación

Encuentra y utiliza tus datos

Introducción al monitoreo de MySQL con NRDOT

Instalación de la CLI

Instalación con Ansible

Instalación con Chef

Te ofrecemos esta traducción automática para facilitar la lectura.

Instalar y configurar NRDOT para el monitoreo de MySQL con Helm

Instalación guiada

Importante

Requisitos previos .css-21sua1{background:none;border:none;width:0;padding:0;}

Cree el namespace

Sugerencia

Configurar las credenciales de monitoreo

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Configurar los valores de Helm

Sin trabajo de configuración: nombre de usuario y contraseña en texto sin formato

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Sugerencia

(Opcional) Monitorear múltiples instancias desde un release

Sin trabajo de configuración

Trabajo de configuración automatizado

Sugerencia

Instale el chart de Helm

Verifique la instalación

Encuentra y utiliza tus datos

Documentación relacionada

Introducción al monitoreo de MySQL con NRDOT

Instalación de la CLI

Instalación con Ansible

Instalación con Chef

Requisitos previos