Guide de dimensionnement et de mise à l'échelle du gateway

Il est essentiel d’allouer suffisamment de ressources au gateway pour maintenir sa fiabilité et éviter la perte de données. Si le gateway tombe en panne, vous risquez de perdre des données télémétriques, ce qui peut avoir un impact sur vos capacités monitoring et d'analyse.

Ce guide vous aide à déterminer les ressources appropriées pour déployer et mettre à l'échelle le gateway Contrôle de pipeline dans votre environnement. Comprendre ces spécifications est essentiel pour garantir des performances optimales et un traitement efficace des données.

Configuration par défaut

Par défaut, le gateway est configuré avec une allocation de mémoire par défaut de 2 Go et 1 vCPU par pod. De plus, le cluster de gateways est initialement configuré lors de l'installation avec les paramètres suivants (ceux-ci peuvent être modifiés après la configuration initiale du gateway) :

minReplicas : 2 maxReplicas : 10 targetCPUUtilizationPercentage : 60

Mise à l'échelle du gateway

Le gateway Contrôle de pipeline doit maintenir une capacité de compute suffisante pour traiter l'intégralité des données télémétriques qu'elle reçoit. Compte tenu des tailles et des débits variables des différents agents et de la charge de travail de télémétrie, nous vous recommandons d'adopter une approche par étapes pour la mise à l'échelle de votre cluster de gateways afin de prévoir la capacité dont vous pourriez avoir besoin :

1. Configurez un petit ensemble (env. 15-35) d'agents hors production pour envoyer des données télémétriques au gateway. Assurez-vous que ces agents sont représentatifs des types d'agents et des frais de télémétrie que vous prévoyez d'envoyer au gateway en production (par exemple NR Infra, Java APM et Fluent Bit). Prenez note du nombre d'agents de chacun.
2. Confirmez que vous collectez ces données télémétriques dans New Relic.
3. Monitorez le cluster de gateway pour identifier le nombre de vCPU et l'utilisation moyenne du CPU sur quelques minutes de charge. Cela vous donnera une idée du nombre de vCPU nécessaires pour exécuter cet ensemble d'agents.
4. Extrapolez linéairement en fonction du nombre d'agents que vous avez configurés, du nombre d'agents que vous prévoyez d'exécuter en production maximale et de l'utilisation du processeur à l'étape 3. Par exemple, si vous exécutez 25 agents Java APM via le gateway et que vous ne voyez qu'un seul vCPU exécuté à 65 % de charge, vous devriez pouvoir exécuter 200 agents Java APM avec <= 8 vCPU.
5. Configurer un plus grand nombre d'agents pour envoyer des données au gateway (par exemple 100) et confirmez que votre extrapolation linéaire à l’étape 4 est toujours vraie.
6. Assurez-vous que votre maxReplicas est suffisamment grand pour mettre à l'échelle suffisamment de pods en fonction du nombre d'agents que vous prévoyez d'exécuter en production.
7. Après avoir configuré tous les agents de production et les données télémétriques pour envoyer des données au gateway, continuez monitoring votre cluster de gateways pour vous assurer qu'ils ne fonctionnent pas à 100 % ou au-delà de leur capacité.

Spécifications de performance

Avec un seul cœur de processeur et 100 règles de drop par type MELT, le gateway peut traiter les volumes de données télémétriques suivants :

Capacité de traitement des agents

Un seul pod de gateway peut gérer entre 15 et 35 agents, avec des tailles de requête allant de 26 à 250 Ko de données non compressées par seconde.

Recommandations pour la configuration du gateway

Pour améliorer davantage les performances et l'évolutivité de votre passerelle, tenez compte des paramètres configuration suivants en fonction de la modélisation de votre agent. Pour accéder à ces paramètres, accédez à New Relic Control > Gateway > Settings.

Répliques minimales et maximales

• Répliques minimales : définissez un nombre de réplicas de gateway de référence pour prendre en charge les charges de données régulières, garantissant ainsi la redondance et la fiabilité. Cela permet d’éviter la perte de données et de maintenir la stabilité des performances pendant les périodes de pointe. La valeur minimale recommandée est 2, qui est également le paramètre par défaut.
• Nombre maximal de répliques : déterminez le nombre maximal de répliques nécessaires pour gérer efficacement les périodes d’utilisation de pointe. Cette configuration permet au cluster de gateway de s'adapter de manière dynamique, fournissant des ressources suffisantes pour un trafic élevé sans compromettre les performances. Vous pouvez configurer jusqu'à un maximum de 15 répliques.

seuil d'utilisation du processeur

• Seuil de mise à l'échelle : spécifiez le pourcentage d'utilisation du processeur auquel votre cluster de gateway sera automatiquement mis à l'échelle. La configuration d'un seuil de mise à l'échelle garantit une gestion efficace des ressources, évitant la surpopulation et maintenant un traitement des données stable. Le paramètre par défaut est 60 %.

Gestion de la santé et de la performance

• Collecter les logs de diagnostic : Vérifiez régulièrement les logs de diagnostic du gateway pour obtenir des informations détaillées sur l'état et le fonctionnement du gateway. Les logs de monitoring sont essentiels pour un dépannage rapide et le maintien de performances optimales. Par défaut, le logging des diagnostics est désactivé.
• Contourner les règles de gateway : en cas de faibles ressources CPU disponibles, contournez les règles de gateway complexes. Cette précaution garantit un flux de données continu vers New Relic, même si des données sensibles sont reçues, permettant la conservation des ressources et un traitement de télémétrie ininterrompu. Par défaut, le contournement des règles de gateway est désactivé.

Prochaine étape

Ensuite, vous apprendrez à modifier la configuration de votre agent pour envoyer des données via le gateway.