Aperçu
Nous travaillons toujours sur cette fonctionnalité, mais nous aimerions que vous l'essayiez !
Cette fonctionnalité est actuellement fournie dans le cadre d'un aperçu conformément à nos politiques de pré-sortie.
Avant de commencer à monitorer votre MySQL avec NRDOT, assurez-vous que votre environnement répond à ces exigences.
Prérequis
Avant de commencer, assurez-vous d’avoir les éléments suivants :
- Clé de licenceNew Relic valide
- Connectivité réseau entre l'hôte où vous installez le Collector NRDOT et votre base de données MySQL. Si vous prévoyez d'installer le Collector NRDOT sur un hôte différent de votre base de données MySQL, consultez les exigences d'accès réseau.
- Connectivité réseau vers la documentation sur les points de terminaison OTLP de New Relic
- Cette intégration est disponible dans le cadre du programme de préversion publique de New Relic. Vérifiez auprès de votre responsable d’organisation pour vous inscrire depuis la page Préversions et essais.
Versions MySQL prises en charge
Le Récepteur détecte le produit et la version de la base de données lors de la première connexion et ajuste son comportement en conséquence — les versions non prises en charge/plus anciennes fonctionnent toujours, mais avec des fonctionnalités réduites :
Versions | Plans de requête activés
| Propagation de traceparent |
/
| Syntaxe de l'état du réplica |
|---|---|---|---|---|
| Non | Oui | 0 |
|
–
| Non | Oui | 0 |
|
–
| Oui | Oui | 0 |
|
| Oui | Oui | Renseigné |
|
| Oui | Oui | Renseigné |
|
| Oui | Oui | Renseigné |
|
Important
La détection de version est non fatale : si elle échoue, le Récepteur revient au comportement de MySQL < 8 plutôt que de générer une erreur.
Exigences d'accès réseau
Par défaut, NRDOT se connecte via TCP (transport: tcp dans la configuration du Récepteur, la valeur par défaut). Si le collecteur s'exécute sur le même hôte que la base de données, vous pouvez plutôt définir transport: unix et pointer endpoint vers le socket de domaine Unix de la base de données (par exemple, /var/run/mysqld/mysqld.sock), ce qui contourne entièrement les vérifications réseau ci-dessous. Pour tout autre déploiement — collecteur et base de données sur des hôtes, conteneurs ou VPC différents — TCP est requis.
déploierons | Ce qu'il faut vérifier |
|---|---|
MySQL autogéré sur EC2 | Groupe de sécurité : ajoutez une règle entrante sur le port de la base de données (par défaut
) à partir de la source du collecteur — son propre ID de groupe de sécurité (même VPC, préféré à une adresse IP brute) si le collecteur s'exécute sur une instance EC2 différente, ou aucune règle n'est nécessaire s'il s'exécute en tant que sidecar sur la même instance. Vérifiez également
dans
: de nombreuses valeurs par défaut de distribution incluent
, qui refuse toute connexion TCP non locale — définissez-la sur l'adresse IP privée de l'instance ou sur
avant qu'un collecteur distant ne puisse l'atteindre. |
Amazon RDS/Aurora pour MySQL | Groupe de sécurité VPC : ajoutez une règle entrante sur le port de l'instance RDS (par défaut
) à partir du groupe de sécurité ou de l'adresse IP privée du collecteur ; RDS n'a pas de
au niveau du système d'exploitation à modifier, c'est donc la seule passerelle réseau. Les autorisations doivent provenir de l'utilisateur maître RDS — RDS n'a pas de compte
. Privilèges restreints :
et
sont restreints ou indisponibles selon la version du moteur RDS et le groupe de paramètres. TLS : les instances RDS avec l'application de la règle « Require SSL/TLS » nécessitent que le collecteur fasse confiance à l'autorité de certification RDS d'Amazon — définissez
(ou
) sur le groupe de certificats Amazon RDS et laissez
/
sur
. |
Tout déploiement distant/inter-hôte | MySQL traite
et
(ou un hôte/CIDR spécifique) comme des comptes différents , même avec un nom d'utilisateur identique — la création de l'utilisateur de monitoring en tant que
échoue silencieusement à s'authentifier à partir d'un collecteur s'exécutant n'importe où ailleurs, avec une erreur d'accès refusé indiscernable d'un mot de passe incorrect. Utilisez
ou limitez-le à l'IP/CIDR privé spécifique du collecteur. |
Important
Vérifié sur une instance Amazon RDS pour MySQL active : la famille de groupes de paramètres mysql8.0 de RDS n’expose aucun paramètre performance_schema_consumer_* — seuls les paramètres de dimensionnement/tampon ainsi que performance_schema, slow_query_log et long_query_time y sont configurables. Cela signifie que events_waits_current (nécessaire pour mysql.events_waits_current.timer_wait et les dashboards basés sur l’attente en général) ne peut être activé qu’à l’exécution sur RDS, et qu’il ne survit pas à un redémarrage ou à un basculement.
Configuration côté serveur recommandée
Configurez ces paramètres de serveur MySQL pour vous assurer que le Récepteur peut collecter toutes les métriques et plans de requête disponibles. Le tableau suivant répertorie les paramètres et leurs valeurs recommandées :
paramètres | Valeur recommandée | Pourquoi |
|---|---|---|
| Activé | Les échantillons de requêtes, les requêtes principales et la détection des blocages en dépendent tous. |
|
| Texte de résumé plus long avant que MySQL ne le tronque |
|
| Identique, au niveau de la couche Performance Schema |
|
| Si une instruction capturée est tronquée, le Récepteur ignore complètement
pour celle-ci. Les plans de requête disparaissent silencieusement pour les instructions longues à la valeur par défaut de
octets |
Prochaines étapes
Une fois que vous avez vérifié que votre environnement respecte ces prérequis :
- Choisissez votre méthode d'installation :
- Passez en revue les métriques disponibles qui seront collectées
- Consultez la configuration avancée pour des fonctionnalités facultatives telles que les plans de requête d'instructions d'écriture et le suivi de la durée d'attente de verrouillage
- Consultez notre guide de dépannage pour les problèmes courants