Synthetics du gestionnaire de tâches configuration

Les variables sont fournies au démarrage à l'aide de l'argument -e, --env .

Le tableau suivant présente toutes les variables d’environnement prises en charge par le gestionnaire de tâches Synthetics. PRIVATE_LOCATION_KEY est obligatoire et toutes les autres variables sont facultatives.

Les variables sont fournies au démarrage à l'aide de l'argument -e, --env .

Le tableau suivant affiche toutes les variables d’environnement prises en charge par le gestionnaire de tâches Synthetics. PRIVATE_LOCATION_KEY est obligatoire et toutes les autres variables sont facultatives. Pour exécuter le gestionnaire de tâches Synthetics dans un environnement Podman, la version minimale doit être sortie-418 ou supérieure.

Les variables sont fournies au démarrage à l'aide de l'argument --set .

La liste suivante répertorie toutes les variables d’environnement prises en charge par le gestionnaire de tâches Synthetics. synthetics.privateLocationKey est obligatoire et toutes les autres variables sont facultatives.

Un certain nombre de paramètres avancés supplémentaires sont disponibles et entièrement documentés dans notre fichier README de la charte Helm

Les variables sont fournies au démarrage à l'aide de l'argument --set .

La liste suivante répertorie toutes les variables d’environnement prises en charge par le gestionnaire de tâches Synthetics. synthetics.privateLocationKey est obligatoire et toutes les autres variables sont facultatives.

Un certain nombre de paramètres avancés supplémentaires sont disponibles et entièrement documentés dans notre fichier README de la charte Helm

L'utilisateur peut créer un fichier au format JSON et monter le volume où se trouve le fichier sur un chemin cible spécifié dans le conteneur SJM.

Le fichier doit disposer d'autorisations de lecture et contenir une carte au format JSON. Exemple de fichier de variables définies par l'utilisateur :

{
  "KEY": "VALUE",
  "user_name": "MINION",
  "my_password": "PASSW0RD123",
  "my_URL": "https://newrelic.com/",
  "ETC": "ETC"
}

Placez le fichier dans le répertoire source sur l'hôte. Le SJM s'attend à ce que le nom du fichier soit user_defined_variables.json

Exemple de Docker :

Le répertoire cible attendu est : /var/lib/newrelic/synthetics/variables/

$
docker run ... -v /variables:/var/lib/newrelic/synthetics/variables:rw ...

Exemple de Podman :

Dans le cas de SELinux, montez le volume en plus avec :z ou :Z. Pour plus d'informations, reportez-vous à la documentation de Podman. Le répertoire cible attendu est : /var/lib/newrelic/synthetics/variables/

$
podman run ... -v /variables:/var/lib/newrelic/synthetics/variables:rw,z ...

Exemple de Kubernetes :

L'utilisateur dispose de deux options lorsqu'il fournit un fichier au pod SJM dans Kubernetes. Ils peuvent :

• Transmettre dans un fichier local.
• Fournissez un PersistentVolume qui inclut le user_defined_variables.json.

Passer dans un fichier local

Cette option crée une ressource Kubernetes ConfigMap et la monte sur le pod SJM.

$
helm install newrelic/synthetics-job-manager ... --set-file "synthetics.userDefinedVariables.userDefinedFile=[local-path]/user_defined_variables.json" ...

Monter un PersistentVolume

Cette option nécessite que l'utilisateur fournisse un PersistentVolume qui inclut le fichier user_defined_variables.json ou un PersistentVolumeClaim au même. Pour plus de détails sur l'installation du graphique de barre à l'aide d'un PersistentVolume, suivez les instructions sur le stockage permanent des données.

Une fois que l'utilisateur a préparé un PersistentVolume comme décrit ci-dessous, lancez le SJM, en définissant le chemin où se trouve le fichier user_defined_variables.json et en définissant toutes les autres variables synthetics.persistence si nécessaire.

$
helm install newrelic/synthetics-job-manger ... --set synthetics.userDefinedVariables.userDefinedPath="variables"

Les variables peuvent être transmises à leur système conteneur respectif via une variable d'environnement.

Exemple de Docker :

Utilisez l'indicateur -e pour configurer une variable d'environnement nommée USER_DEFINED_VARIABLES et donnez-lui la valeur d'une chaîne de carte au format JSON.

$
docker run ... -e USER_DEFINED_VARIABLES='{"key":"value","name":"sjm"}' ...

Exemple de Podman :

Utilisez l'indicateur -e pour configurer une variable d'environnement nommée USER_DEFINED_VARIABLES et donnez-lui la valeur d'une chaîne de carte au format JSON.

$
podman run ... -e USER_DEFINED_VARIABLES='{"key":"value","name":"sjm"}' ...

Exemple de Kubernetes :

Utilisez l’indicateur --set-literal pour transmettre la chaîne au format JSON.

$
helm install newrelic/synthetics-job-manager ... --set-literal synthetics.userDefinedVariables.userDefinedJson='{"key":"value","name":"sjm"}' ...

Pour Docker, lancez SJM en montant le répertoire à /var/lib/newrelic/synthetics/modules. Par exemple:

$
docker run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw ...

Pour podman, lancez SJM en montant le répertoire à /var/lib/newrelic/synthetics/modules. Dans le cas de SELinux, montez le volume en plus avec :z ou :Z. Pour plus d'informations, reportez-vous à la documentation Podman. Par exemple:

$
podman run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw,z ...

Pour Kubernetes, le répertoire /var/lib/newrelic/synthetics/modules doit exister sur un PV avant de lancer le SJM avec les modules personnalisés activés.

Une méthode consiste à créer un pod qui monte le PV uniquement dans le but de copier votre répertoire de modules personnalisés sur le PV. L'exemple suivant utilise Amazon EFS avec Amazon EKS :

Créer l'espace de nommage, le volume persistant et la revendication de volume persistant

1. Assurez-vous d'avoir déjà configuré votre système de fichiers EFS et installé le pilote EFS CSI sur votre cluster. Vous aurez également besoin de votre ID de système de fichiers EFS pour les PV spec.csi.volumeHandle.

   bash

   Copier

   $
   kubectl apply -f - <<EOF
   $
   apiVersion: v1
   $
   kind: Namespace
   $
   metadata:
   $
     name: newrelic
   $
   
   $
   ---
   $
   kind: StorageClass
   $
   apiVersion: storage.k8s.io/v1
   $
   metadata:
   $
     name: efs-sc
   $
   provisioner: efs.csi.aws.com
   $
   
   $
   ---
   $
   apiVersion: v1
   $
   kind: PersistentVolume
   $
   metadata:
   $
     name: custom-modules-pvc
   $
   spec:
   $
     capacity:
   $
       storage: 5Gi
   $
     volumeMode: Filesystem
   $
     accessModes:
   $
       - ReadWriteMany
   $
     persistentVolumeReclaimPolicy: Retain
   $
     storageClassName: efs-sc
   $
     csi:
   $
       driver: efs.csi.aws.com
   $
       volumeHandle: <your-efs-filesystem-id>
   $
   
   $
   ---
   $
   apiVersion: v1
   $
   kind: PersistentVolumeClaim
   $
   metadata:
   $
     name: custom-modules-pvc
   $
     namespace: newrelic
   $
   spec:
   $
     accessModes:
   $
       - ReadWriteMany
   $
     storageClassName: efs-sc
   $
     resources:
   $
       requests:
   $
         storage: 5Gi
   $
   EOF

2. Passez à l'espace de nommage newrelic dans votre ~/.kube/config.

   bash

   Copier

   $
   kubectl config get-contexts
   $
   kubectl config set-context YOUR_CONTEXT --namespace=newrelic
   $
   kubectl config view --minify | grep namespace:

3. À ce stade, le PVC doit être lié au PV avec le mode d’accès RWX.

   bash

   Copier

   $
   kubectl get pv,pvc
   NAME                                  CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                         STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
   persistentvolume/custom-modules-pvc   5Gi        RWX            Retain           Bound    newrelic/custom-modules-pvc   efs-sc         <unset>                          4m46s
   NAME                                       STATUS   VOLUME               CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
   persistentvolumeclaim/custom-modules-pvc   Bound    custom-modules-pvc   5Gi        RWX            efs-sc         <unset>                 4m10s

   Créez mount-custom-mods-pod pour copier votre répertoire de modules personnalisés

   bash

   Copier

   $
   kubectl apply -f - <<EOF
   $
   apiVersion: v1
   $
   kind: Pod
   $
   metadata:
   $
     name: mount-custom-mods-pod
   $
   spec:
   $
     containers:
   $
     - name: mount-custom-mods-pod
   $
       image: nginx
   $
       resources:
   $
         requests:
   $
           memory: "64Mi"
   $
           cpu: "250m"
   $
         limits:
   $
           memory: "128Mi"
   $
           cpu: "500m"
   $
       volumeMounts:
   $
         - mountPath: "/var/lib/newrelic/synthetics/modules"
   $
           name: custom-modules-storage
   $
     volumes:
   $
     - name: custom-modules-storage
   $
       persistentVolumeClaim:
   $
         claimName: custom-modules-pvc
   $
   EOF

   À ce stade, le mount-custom-mods-pod doit être créé et configuré pour utiliser le volume.

   bash

   Copier

   $
   kubectl describe po mount-custom-mods-pod | grep -A4 Volumes:
   Volumes:
     custom-modules-storage:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  custom-modules-pvc
       ReadOnly:   false

   Vérifiez événement pour tous les avertissements liés au PV, au PVC ou mount-custom-mods-pod.

   bash

   Copier

   $
   kubectl get events --field-selector type=Warning --sort-by='.lastTimestamp'

   Copiez votre répertoire de modules personnalisés dans le PV

   Il n'est pas nécessaire de copier node_modules car il sera généré par le SJM sur npm install.

   bash

   Copier

   $
   cd custom-modules
   $
   rm -rf node_modules && cd ..

4. Vérifiez que le mount-custom-mods-pod est en cours d’exécution.

   bash

   Copier

   $
   kubectl get po
   NAME                    READY   STATUS    RESTARTS   AGE
   mount-custom-mods-pod   1/1     Running   0          5m43s

5. Copie au PV.

   bash

   Copier

   $
   kubectl cp custom-modules newrelic/mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules

6. Vérifiez que /var/lib/newrelic/synthetics/modules/custom-modules/package.json existe sur le PV.

   bash

   Copier

   $
   kubectl exec -it mount-custom-mods-pod -- bash
   root@mount-custom-mods-pod:/# cd /var/lib/newrelic/synthetics/modules/
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# ls -l
   total 4
   drwxr-xr-x 2 root root 6144 Jun 29 03:49 custom-modules
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# ls -l custom-modules/
   total 4
   -rw-r--r-- 1 501 staff 299 Jun 29 03:49 package.json

   lancement du SJM avec la fonctionnalité des modules personnalisés activée

   Définissez les valeurs pour persistence.existingClaimName et customNodeModules.customNodeModulesPath dans la ligne de commande ou dans un fichier YAML lors de l'installation. La valeur customNodeModules.customNodeModulesPath doit spécifier le sous-chemin sur le volume persistant où existent vos fichiers de modules personnalisés. Par exemple:

   bash

   Copier

   $
   helm upgrade --install synthetics-job-manager newrelic/synthetics-job-manager -n newrelic --set global.persistence.existingClaimName=custom-modules-pvc --set global.customNodeModules.customNodeModulesPath=custom-modules --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY
   Release "synthetics-job-manager" does not exist. Installing it now.
   NAME: synthetics-job-manager
   LAST DEPLOYED: Fri Jun 28 16:53:28 2024
   NAMESPACE: newrelic
   STATUS: deployed
   REVISION: 1
   TEST SUITE: None

   Le répertoire custom-modules doit maintenant contenir le package installé dans node_modules.

   bash

   Copier

   $
   kubectl exec -it mount-custom-mods-pod -- bash
   root@mount-custom-mods-pod:/# cd /var/lib/newrelic/synthetics/modules/
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# ls -l custom-modules/
   total 16
   -rw-r--r--  1 root root   836 Jun 29 03:51 README
   drwxr-xr-x 18 root root  6144 Jun 29 03:51 node_modules
   -rw-r--r--  1  501 staff  299 Jun 29 03:49 package.json
   -rw-r--r--  1 root root   190 Jun 29 03:51 package.json.shasum

   Si les modules de nœuds personnalisés ne sont pas détectés, ajustez les autorisations sur le répertoire custom-modules et le fichier package.json .

   bash

   Copier

   $
   kubectl exec -it mount-custom-mods-pod -- bash
   root@mount-custom-mods-pod:/# cd /var/lib/newrelic/synthetics/modules/
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# chmod -R 777 custom-modules
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# chown -R 2000:2000 custom-modules

Pour définir le stockage permanent des données sur Docker :

1. Créez un répertoire sur l’hôte où vous lancez le gestionnaire de travaux. Ceci est votre répertoire source.

2. lancement du Job Manager, en montant le répertoire source dans le répertoire cible /var/lib/newrelic/synthetics.

   Exemple:

   bash

   Copier

   $
   docker run ... -v /sjm-volume:/var/lib/newrelic/synthetics:rw ...

Pour définir le stockage permanent des données sur Podman :

1. Créez un répertoire sur l’hôte où vous lancez le gestionnaire de travaux. Ceci est votre répertoire source.

2. lancement du Job Manager, en montant le répertoire source dans le répertoire cible /var/lib/newrelic/synthetics.

   Exemple:

   bash

   Copier

   $
   podman run ... -v /sjm-volume:/var/lib/newrelic/synthetics:rw,z ...

Kubernetes

Pour définir un stockage permanent des données sur Kubernetes, l'utilisateur dispose de deux options :

1. Fournissez un PersistentVolumeClaim (PVC) existant pour un PersistentVolume (PV) existant, en définissant la valeur de configuration synthetics.persistence.existingClaimName . Exemple:

   bash

   Copier

   $
   helm install ... --set synthetics.persistence.existingClaimName=sjm-claim ...

2. Fournissez un nom PersistentVolume (PV) existant, en définissant la valeur de configuration synthetics.persistence.existingVolumeName . Helm générera un PVC pour l'utilisateur. L'utilisateur peut également définir éventuellement les valeurs suivantes :

• synthetics.persistence.storageClass:La classe de stockage du PV existant. Si non fourni, Kubernetes utilisera la classe de stockage par défaut.

• synthetics.persistence.size:La taille de la réclamation. Si non défini, la valeur par défaut est actuellement 2Gi.

  bash

  Copier

  $
  helm install ... --set synthetics.persistence.existingVolumeName=sjm-volume --set synthetics.persistence.storageClass=standard ...

Pour garantir que votre site privé fonctionne efficacement, vous devez provisionner suffisamment de ressources CPU sur votre hôte pour gérer votre workload monitoring. De nombreux facteurs influencent le dimensionnement, mais vous pouvez rapidement estimer vos besoins. Vous aurez besoin d'un cœur de processeur pour chaque moniteur lourd (c'est-à-dire un navigateur simple, un navigateur scripté ou un moniteur d'API scripté). Vous trouverez ci-dessous deux formules pour vous aider à calculer le nombre de cœurs dont vous avez besoin, que vous diagnostiquiez une configuration actuelle ou que vous en planifiiez une future.

Formule 1 : Diagnostic d'un emplacement existant

Si votre site privé actuel a du mal à suivre et que vous pensez que des tâches sont en file d'attente, utilisez cette formule pour savoir de combien de cœurs vous avez réellement besoin. Il est basé sur les performances observable de votre système.

$$ C_{est} = (R_{proc} + R_{growth}) \cdot D_{avg,m} $$

• C\_\{est} = Cœurs de processeur estimés.

• R\_\{proc} = Le taux de tâches lourdes traitées par minute.

• R\_\{growth} = Le taux auquel votre file d'attente jobManagerHeavyweightJobs augmente par minute.

• D\_\{avg,m} = La durée moyenne des tâches lourdes en minutes.

  Cette formule calcule votre taux réel d'arrivée des tâches en additionnant les tâches que votre système est en train de traiter aux tâches qui s'accumulent dans la file d'attente. Multiplier cette charge totale par la durée moyenne d'une tâche vous indique précisément le nombre de cœurs nécessaires pour traiter tout le travail sans mise en file d'attente.

  Formule 2 : Prévoir un emplacement nouveau ou futur

  Si vous configurez un nouveau site privé ou prévoyez d'ajouter plus de moniteurs, utilisez cette formule pour prévoir vos besoins à l'avance.

  $$ C_{est} = N_{mon} \cdot D_{avg,m} \cdot \frac{1}P_{avg,m} $$

• C\_\{est} = Cœurs de processeur estimés.

• N\_\{mon} = Le nombre total de moniteurs lourds que vous prévoyez d'exécuter.

• D\_\{avg,m} = La durée moyenne d'une tâche lourde en minutes.

• P\_\{avg,m} = La période moyenne des moniteurs lourds en minutes (par ex. un moniteur qui s'exécute toutes les 5 minutes a P\_\{avg,m} = 5).

  Ce système calcule votre workload prévue à partir de principes fondamentaux : le nombre de moniteurs dont vous disposez, leur fréquence d’exécution et leur durée.

  Facteurs de dimensionnement importants

  Lorsque vous utilisez ces formules, n’oubliez pas de tenir compte des facteurs suivants :

• Durée du job (D\_\{avg,m}) : Votre moyenne doit inclure les jobs qui tombent en timeout (souvent 3 minutes), car ils occupent un cœur pendant toute leur durée.

• Échecs et nouvelles tentatives de tâches : lorsqu'un moniteur échoue, il est automatiquement réessayé. Ces nouvelles tentatives sont des tâches supplémentaires qui s’ajoutent à la charge totale. Un moniteur qui échoue systématiquement et réessaye multiplie efficacement sa période, ce qui a un impact significatif sur le débit.

• Mise à l'échelle : en plus d'ajouter des cœurs supplémentaires à un hôte (mise à l'échelle), vous pouvez déployer des gestionnaires de tâches Synthetics supplémentaires avec la même clé privée de site pour équilibrer la charge des tâches sur plusieurs environnements (mise à l'échelle).

  Il est important de noter qu'un seul gestionnaire de tâches Synthetics (SJM) a une limite de débit d' environ 15 tâches lourdes par minute. Cela est dû à une stratégie de threading interne qui favorise la concurrence efficace des tâches sur plusieurs SJM par rapport au nombre brut de tâches traitées par SJM. Si vos calculs indiquent un besoin de débit plus élevé, vous devez augmenter la capacité en déployant des SJM supplémentaires. Vous pouvez vérifier si votre file d'attente de tâches augmente pour déterminer si davantage de SJM sont nécessaires.

  L'ajout de plusieurs SJM avec la même clé privée de site offre plusieurs avantages :

• Équilibrage de charge: Les jobs du site privé sont répartis sur tous les SJM disponibles.

• Protection de basculement: si une instance SJM tombe en panne, les autres peuvent continuer à traiter les tâches.

• Débit total plus élevé: le débit total pour votre site privé devient la somme du débit de chaque SJM (par exemple, deux SJM fournissent jusqu’à 30 tâches/minute).

  Requête NRQL pour le diagnostic

  Vous pouvez exécuter ces requêtes dans le générateur de requêtes pour obtenir les entrées de la formule de diagnostic. Assurez-vous de définir la plage horaire sur une période suffisamment longue pour obtenir une moyenne stable.

  1. Trouver le taux de tâches traitées par minute (R\_\{proc}): Cette requête compte le nombre de tâches non-ping (lourdes) terminées au cours de la dernière journée et affiche le taux moyen par minute.

  FROM SyntheticCheck
  SELECT rate(uniqueCount(id), 1 minute) AS 'job rate per minute'
  WHERE location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE'
  SINCE 1 day ago

  Copier

  2. Trouver le taux de croissance de la file d'attente par minute (R\_\{growth}): Cette requête calcule la croissance moyenne par minute de la file d'attente jobManagerHeavyweightJobs sur un graphique de séries temporelles. Une ligne au-dessus de zéro indique que la file d'attente augmente, tandis qu'une ligne en dessous de zéro signifie qu'elle diminue.

  FROM SyntheticsPrivateLocationStatus
  SELECT derivative(jobManagerHeavyweightJobs, 1 minute) AS 'queue growth rate per minute'
  WHERE name = 'YOUR_PRIVATE_LOCATION'
  TIMESERIES SINCE 1 day ago

  Copier

  Conseil

  Assurez-vous de sélectionner le compte sur lequel le site privé existe. Il est préférable de considérer cette requête comme une série chronologique, car la fonction dérivée peut varier considérablement. L’objectif est d’obtenir une estimation du taux de croissance de la file d’attente par minute. Play avec différentes plages horaires pour voir ce qui fonctionne le mieux.

  3. Trouver le nombre total de moniteurs lourds (N\_\{mon}): Cette requête trouve le nombre unique de moniteurs lourds.

  FROM SyntheticCheck
  SELECT uniqueCount(monitorId) AS 'monitor count'
  WHERE location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE'
  SINCE 1 day ago

  Copier

  4. Trouver la durée moyenne des tâches en minutes (D\_\{avg,m}): Cette requête détermine la durée moyenne d'exécution des tâches non-ping terminées et convertit le résultat de millisecondes en minutes. executionDuration représente le temps que la tâche a mis à s'exécuter sur l'hôte.

  FROM SyntheticCheck
  SELECT average(executionDuration)/60e3 AS 'avg job duration (m)'
  WHERE location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE'
  SINCE 1 day ago

  Copier

  5. Déterminer la période moyenne du moniteur lourd (P\_\{avg,m}) : Si la file d'attente jobManagerHeavyweightJobs de l'emplacement privé augmente, il est inexact de calculer la période moyenne du moniteur à partir des résultats existants. Ceci devra être estimé à partir de la liste des moniteurs sur la page Moniteurs synthétiques. Assurez-vous de sélectionner le bon compte New Relic et vous devrez peut-être filtrer par privateLocation.

  Conseil

  Le moniteur synthétique peut exister en plusieurs sous-compte. Si vous avez plus de sous-comptes que ce qui peut être sélectionné dans le générateur de requêtes, choisissez les comptes avec le plus de monitorage.

  Remarque sur le moniteur de ping et la file d'attente pingJobs

  Les moniteurs de ping sont différents. Il s’agit de tâches légères qui ne consomment pas chacune un cœur de processeur complet. Au lieu de cela, ils utilisent une file d’attente distincte (pingJobs) et s’exécutent sur un pool de threads de travail.

  Bien qu'ils soient moins gourmands en ressources, un volume élevé de tâches de ping, en particulier celles qui échouent, peut néanmoins entraîner des problèmes de performances. Gardez ces points à l’esprit :

• Modèle de ressources : les tâches Ping utilisent des threads de travail et non des cœurs de processeur dédiés. Le calcul du nombre de cœurs par emploi ne s’applique pas à eux.

• Délai d'expiration et nouvelle tentative : une tâche de ping en échec peut occuper un thread de travail jusqu'à 60 secondes. Il tente d’abord une requête HTTP HEAD (délai d’expiration de 30 secondes). Si cela échoue, il réessaye immédiatement avec une requête HTTP GET (un autre délai d'attente de 30 secondes).

• Mise à l'échelle : Bien que la formule de dimensionnement soit différente, les mêmes principes s'appliquent. Pour gérer un volume important de tâches de ping et empêcher la file d'attente pingJobs de croître, vous devrez peut-être effectuer une mise à l'échelle verticale et/ou horizontale. La mise à l'échelle signifie augmenter les ressources CPU et mémoire par hôte ou espace de nommage. La mise à l'échelle signifie ajouter davantage d'instances de l'environnement d'exécution ping. Cela peut être réalisé en déployant plus de gestionnaires de tâches sur plus d'hôtes, dans plus d'espace de nommage, ou même au sein d'un même espace de nommage. Alternativement, le ping-runtime dans Kubernetes vous permet de définir un plus grand nombre de réplicas par déploiement.

Chaque runtime utilisé par le gestionnaire de tâches Kubernetes et OpenShift Synthétique peut être dimensionné indépendamment en définissant des valeurs dans le graphique Helm. Les node-api-runtime et node-browser-runtime sont dimensionnés indépendamment à l'aide d'une combinaison des paramètres parallelism et completions.

• Le paramètre parallelism contrôle le nombre de pods d'un environnement d'exécution particulier exécutés simultanément.

• Le paramètre completions contrôle le nombre de pods qui doivent se terminer avant que le CronJob ne démarre un autre travail Kubernetes pour cette période d'exécution.

  Bonnes pratiques pour le dimensionnement de votre déploiement

  Il est souvent impossible de calculer avec précision les valeurs de parallélisme et de complétions nécessaires, car la durée moyenne observée dans New Relic peut ne pas être exacte, en particulier si l'emplacement privé existant ne fonctionne pas correctement. Suivez cette approche pratique pour ajuster le parallélisme et les complétions. Les équations ci-dessous peuvent être utilisées pour obtenir des valeurs approximatives de départ.

  1. Estimer les complétions et le parallélisme

  Faites de votre mieux pour estimer la durée moyenne d'exécution et le nombre de jobs par 5 minutes. Cela vous fournit un point de départ approximatif pour l'étape suivante, qui consistera à procéder par tâtonnements pour ajuster les valeurs de parallélisme et de complétions dans un cluster actif. Veillez à les mettre à l'échelle proportionnellement, par exemple en passant des valeurs par défaut de 1 et 6 à 10 et 60.

  Achèvements estimés : Cela détermine le temps nécessaire à l'achèvement de votre charge de jobs de 5 minutes.

  -- Get average execution duration in minutes
  FROM SyntheticCheck
  SELECT average(executionDuration / 60e3) AS 'Avg Duration (min)'
  WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION'
  SINCE 1 hour ago

  Copier

  $$ Completions = \frac{5}D_{avg,m} $$

  Où D\_\{avg,m} est votre durée moyenne d'exécution des jobs en minutes.

  Parallélisme estimé : Cela détermine le nombre de workers (pods) que vous devez exécuter simultanément pour gérer votre charge de travail de 5 minutes.

  -- Get jobs per 5 minutes
  FROM SyntheticCheck
  SELECT rate(uniqueCount(id), 5 minutes) AS 'Number of monitor jobs per 5 minutes'
  WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION'
  SINCE 1 hour ago

  Copier

  $$ P_{est} = \frac{N_m}{Completions} $$

  Où $N\_m$ est votre nombre de jobs par 5 minutes. Cette valeur P\_\{est} est votre parallélisme estimé.

  2. Effectuer un déploiement Helm

  Effectuez un déploiement Helm avec des valeurs estimées de parallélisme et de complétions, ainsi que votre meilleure estimation pour ping-runtime.replicaCount compte tenu du nombre de cœurs CPU par nœud et du nombre de moniteurs ping qui doivent s'exécuter par minute.

  3. Monitorer la croissance de la file d'attente

  Avec les moniteurs synthétiques configurés pour envoyer des tâches à l'emplacement privé, vérifiez la croissance de la file d'attente sur un graphique linéaire de séries temporelles pour pingJobs et jobManagerHeavyweightJobs.

• Si la file d'attente pingJobs a une pente positive, augmentez ping-runtime.replicaCount et redéployez.

• Si la file d'attente jobManagerHeavyweightJobs présente une pente positive, augmentez parallelism et completions proportionnellement jusqu'à ce que la file cesse de croître (pente négative).

  Une pente négative indique que le gestionnaire de tâches dispose d'un parallélisme suffisant pour gérer la demande de tâches. Il finira par atteindre zéro avec une pente négative.

  FROM SyntheticsPrivateLocationStatus
  SELECT average(jobManagerHeavyweightJobs) AS 'Heavyweight Queue Growth', average(pingJobs) AS 'Ping Queue Growth'
  WHERE name = 'YOUR_PRIVATE_LOCATION'
  SINCE 1 day ago TIMESERIES

  Copier

  4. Ajuster en fonction de l'état d'exécution du pod

  Avec la file d'attente en baisse ou à zéro, recherchez les pods node-api-runtime et node-browser-runtime qui sont à l'état "running" depuis plus de 10 minutes. Cela indique que le parallélisme est trop élevé et qu'il y a plus de pods que nécessaire.

  Pour éviter de gaspiller inutilement des ressources, réduisez parallelism et completions pour réduire l'âge de chaque pod d'exécution "en cours d'exécution". Si vous ciblez un âge de job Kubernetes de 5 minutes, les pods d'exécution doivent être en cours d'exécution pendant moins de 5 minutes, ce qui signifie que le pod a été créé, a rapidement reçu un job à exécuter et s'est terminé.

  5. Mettre à l'échelle horizontalement si nécessaire

  Si la file d'attente ne diminue pas alors que de nombreux pods sont à l'état "running" depuis plus de 10 minutes, il est probable que le gestionnaire de jobs atteigne un goulot d'étranglement de performance. L'étape suivante consiste à réduire le parallélisme et à effectuer une mise à l'échelle horizontale avec un ou plusieurs déploiements supplémentaires.

  Par exemple, avec parallelism: 100, completions: 600 la file d'attente continue de croître alors que de nombreux pods sont à l'état "running" depuis plus de 10 minutes, et que l'âge du Job Kubernetes est de 20 minutes ... définissez parallelism: 50, completions: 200 et mettez à l'échelle horizontalement (out) en ajoutant 2 déploiements supplémentaires. Cela donne un total de 150 pods parallèles et devrait réduire la durée du job K8s à moins de 20 minutes tout en réduisant le nombre de pods "running" de longue durée. Visez un âge de Job K8s de 5 à 10 minutes.

  Pour plus d'informations sur l'ajout de déploiements, consultez Mise à l'échelle avec plusieurs déploiements SJM.

  Conseil

  Vous pouvez utiliser la requête suivante pour vous aider à déterminer si vous devez effectuer une mise à l'échelle horizontale.

  Remarque : Les moniteurs peuvent exister dans plusieurs sous-comptes.

  -- monitors per minute per SJM
  FROM SyntheticCheck SELECT
    round(rate(uniqueCount(id), 1 minute)/uniqueCount(minionId),0.1) AS 'heavy jobs per minute per SJM',
    uniqueCount(minionId) AS 'number of SJMs (namespaces)',
    round(rate(uniqueCount(id), 1 minute),0.1) AS 'heavy jobs per minute total'
  WHERE minionContainerSystem = 'KUBERNETES' AND minionDeploymentMode = 'private' AND location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE' FACET location SINCE 1 hour ago TIMESERIES

  Copier

  Conseil

  Réduire le nombre de cycles de Jobs K8s peut également améliorer les performances. À mesure que chaque cycle atteint le nombre défini de complétions, il y a de moins en moins de pods « en cours d'exécution » pour prendre en charge les nouvelles tâches Synthetics. Par exemple, avec completions défini sur 200 et parallelism sur 50, nous avons initialement 50 pods en cours d'exécution, mais ce nombre commence à diminuer lorsque nous dépassons 150 completions. À 199 exécutions terminées, il ne reste qu'un pod en cours d'exécution.

  Définir une valeur plus élevée pour les completions n'est pas une mauvaise idée, mais cela peut entraîner des événements d'avertissement dans K8s concernant TooManyMissedTimes pour le cronjob.

  Évolutivité avec plusieurs déploiements SJM

  Pour évoluer au-delà du débit de 15 jobs/minute d'un seul SJM, vous devez installer plusieurs sorties SJM Helm distinctes.

  Important

  N'utilisez pas de répliques pour mettre à l'échelle le pod du gestionnaire de tâches. L'architecture SJM nécessite une relation 1:1 entre un pod d'exécution et son pod SJM parent. Si les pods d'exécution renvoient des résultats au mauvais réplica SJM (par exemple, via un service Kubernetes), ces résultats seront perdus. Cependant, ping-runtime.replicaCount peut être utilisé.

  La stratégie correcte consiste à déployer plusieurs instances SJM, chacune en tant que sortie Helm distincte. Chaque SJM sera en concurrence pour les tâches du même site privé, assurant ainsi l'équilibrage de charge, la protection contre les pannes et une augmentation du débit total de tâches.

  Stratégie de mise à l'échelle horizontale

  Si vous avez besoin de faire évoluer horizontalement, vous pouvez simplifier la maintenance en traitant chaque déploiement SJM comme une unité à capacité fixe.

1. Définir le parallélisme : Pour chaque SJM, définissez parallelism sur le même maximum qu'un seul SJM peut gérer sans créer trop de pods d'exécution "running" à longue durée de vie. Cela maximise le débit potentiel de chaque SJM sans gaspiller de ressources.

2. Définir les complétions : Pour chaque SJM, définissez également completions sur la même valeur fixe. Ajustez selon les besoins pour cibler un âge de job Kubernetes de 5 minutes par runtime, c'est-à-dire node-browser-runtime et node-api-runtime.

3. Installer des releases : Installez autant de releases Helm distinctes que nécessaire pour gérer la demande totale de vos jobs, c'est-à-dire ramener la file d'attente à zéro ou obtenir une pente négative sur le graphique linéaire.

4. Monitorer et ajouter : Monitorez la file d'attente des jobs de l'emplacement privé. Si cela commence à augmenter (pente positive), installez simplement une autre release Helm (par ex. sjm-delta) en utilisant la même configuration fixe.

   En fixant le parallélisme et les complétions à des valeurs statiques, l'augmentation ou la diminution de la capacité devient un processus plus simple consistant à ajouter ou supprimer des releases Helm. Cela permet d'éviter de gaspiller les ressources du cluster avec une valeur de parallélisme supérieure à ce que le SJM peut utiliser efficacement.

   Exemple d'installation

   Lors de l'installation de plusieurs sorties SJM, vous devez fournir un nom unique pour chaque sortie. Toutes les instances doivent être configurées avec la même clé privée de site.

   Il est fortement recommandé de définir fullnameOverride pour créer des noms de ressources plus courts et plus faciles à gérer. Par exemple, pour installer deux SJM nommés sjm-alpha et sjm-beta dans l'espace de nommage newrelic (utilisant tous deux le même values.yaml avec votre parallélisme et vos complétions fixes) :

   bash

   Copier

   $
   # Install the first SJM deployment
   $
   helm upgrade --install sjm-alpha newrelic/synthetics-job-manager \
   >
     -n newrelic \
   >
     -f values.yaml \
   >
     --set fullnameOverride=sjm-alpha \
   >
     --set ping-runtime.fullnameOverride=sjm-alpha-ping \
   >
     --set node-api-runtime.fullnameOverride=sjm-alpha-api \
   >
     --set node-browser-runtime.fullnameOverride=sjm-alpha-browser

   bash

   Copier

   $
   # Install the second SJM deployment to add capacity
   $
   helm upgrade --install sjm-beta newrelic/synthetics-job-manager \
   >
     -n newrelic \
   >
     -f values.yaml \
   >
     --set fullnameOverride=sjm-beta \
   >
     --set ping-runtime.fullnameOverride=sjm-beta-ping \
   >
     --set node-api-runtime.fullnameOverride=sjm-beta-api \
   >
     --set node-browser-runtime.fullnameOverride=sjm-beta-browser

   Vous pouvez continuer ce modèle (sjm-charlie, sjm-delta, etc.) pour autant de SJM que nécessaire pour empêcher la file d'attente des tâches de s'agrandir.