• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

Synthetics du gestionnaire de tâches configuration

Ce document vous guidera dans la configuration de votre gestionnaire de tâches Synthetics en vous montrant comment :

configuration à l'aide de variables d'environnement

Les variables environnementales vous permettent d'affiner la configuration du gestionnaire de tâches Synthetics pour répondre à vos besoins environnementaux et fonctionnels spécifiques.

variables définies par l'utilisateur pour le moniteur scripté

Les gestionnaires de tâches Private Synthetics vous permettent de configurer des variables d'environnement pour le moniteur scripté. Ces variables sont gérées localement sur le SJM et sont accessibles via $env.USER_DEFINED_VARIABLES. Vous pouvez définir des variables définies par l'utilisateur de deux manières. Vous pouvez monter un fichier JSON ou fournir une variable d'environnement au SJM au lancement. Si les deux sont fournis, le SJM utilisera uniquement les valeurs fournies par l'environnement.

Accéder aux variables d'environnement définies par l'utilisateur à partir d'un script

Pour référencer une variable d'environnement configurée définie par l'utilisateur, utilisez le $env.USER_DEFINED_VARIABLES réservé suivi du nom d'une variable donnée avec une notation par points (par exemple, $env.USER_DEFINED_VARIABLES.MY_VARIABLE).

Prudence

Les variables d'environnement définies par l'utilisateur ne sont pas nettoyées dans les logs. Pensez à utiliser la fonctionnalité d’informations d’identification sécurisées pour les informations sensibles.

Modules de nœuds personnalisés

Des modules de nœuds personnalisés sont fournis à la fois dans CPM et dans SJM. Ils vous permettent de créer un ensemble personnalisé de modules de nœuds et de les utiliser dans un moniteur scripté (API scriptée et navigateur scripté) pour monitoring Synthétique.

Configurez votre répertoire de modules personnalisés

Créez un répertoire avec un fichier package.json suivant les directives officielles de npm dans le dossier racine. Le SJM installera toutes les dépendances répertoriées dans le package.json champ dependencies . Ces dépendances seront disponibles lors de l'exécution du moniteur sur le gestionnaire de tâches Synthetics privé. Voir un exemple ci-dessous.

Exemple

Dans cet exemple, un répertoire de modules personnalisé est utilisé avec la structure suivante :

/example-custom-modules-dir/
    ├── counter
    │   ├── index.js
    │   └── package.json
    └── package.json            ⇦ the only mandatory file

Le package.json définit dependencies à la fois comme un module local (par exemple, counter) et comme tout module hébergé (par exemple, smallest version 1.0.1) :

{
    "name": "custom-modules",
    "version": "1.0.0",                                ⇦ optional
    "description": "example custom modules directory", ⇦ optional
    "dependencies": {
    "smallest": "1.0.1",                               ⇦ hosted module
    "counter": "file:./counter"                        ⇦ local module
    }
}

Ajoutez votre répertoire de modules personnalisés au SJM pour Docker, Podman ou Kubernetes

Pour vérifier si les modules ont été installés correctement ou si des erreurs se sont produites, recherchez les lignes suivantes dans les logs du conteneur ou pod synthetics-job-manager :

2024-06-29 03:51:28,407{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Detected mounted path for custom node modules
2024-06-29 03:51:28,408{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Validating permission for custom node modules package.json file
2024-06-29 03:51:28,409{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Installing custom node modules...
2024-06-29 03:51:44,670{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Custom node modules installed successfully.

Vous pouvez maintenant ajouter "require('smallest');" dans le script du moniteur que vous envoyez sur ce site privé.

Changement package.json

En plus des modules locaux et hébergés, vous pouvez également utiliser des modules Node.js. Pour mettre à jour les modules personnalisés utilisés par votre SJM, apportez des modifications au fichier package.json et redémarrez le SJM. Pendant le processus de redémarrage, le SJM reconnaîtra le changement de configuration et effectuera automatiquement des opérations de nettoyage et de réinstallation pour garantir que les modules mis à jour sont appliqués.

Prudence

Modules locaux : bien que votre package.json puisse inclure n’importe quel module local, ces modules doivent résider dans l’arborescence sous votre répertoire de modules personnalisés. Si stocké en dehors de l'arbre, le processus d'initialisation échouera et vous verrez un message d'erreur dans les logs Docker après le lancement de SJM.

Stockage permanent des données

l'utilisateur peut souhaiter utiliser un stockage de données permanent pour fournir le fichier user_defined_variables.json ou prendre en charge des modules de nœuds personnalisés.

Docker

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
    $
    docker run ... -v /sjm-volume:/var/lib/newrelic/synthetics:rw ...

Podman

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
$
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
    $
    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
    $
    helm install ... --set synthetics.persistence.existingVolumeName=sjm-volume --set synthetics.persistence.storageClass=standard ...

Considérations de dimensionnement pour Docker, Kubernetes et OpenShift

Docker

Pour garantir que votre site privé fonctionne efficacement, vous devez provisionner suffisamment de ressources CPU sur votre hôte Docker 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 simultané (c'est-à-dire chaque navigateur scripté ou test 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 : Pour diagnostiquer 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.

L'équation : $$C_req = (J_processed + Q_growth) \times D_j$$

  • $C_req$ = Cœurs de processeur requis
  • $J_processed$ = Le taux de tâches traitées par minute.
  • $Q_growth$ = Le taux de croissance de votre file d'attente jobManagerHeavyweightJobs par minute.
  • $D_j$ = La durée moyenne d'un travail en minutes.

Voici comment cela fonctionne : cette formule calcule votre véritable taux d'arrivée des tâches en ajoutant les tâches que votre système traite aux tâches qui s'accumulent dans la file d'attente. En multipliant cette charge totale par la durée moyenne du travail, vous obtenez exactement le nombre de cœurs dont vous avez besoin pour effectuer tout le travail sans mettre en file d'attente.

Formule 2 : Pour 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.

L'équation : $$C_req = N_m \times F_j \times D_j$$

  • $C_req$ = Cœurs de processeur requis
  • $N_m$ = Le nombre total de moniteurs lourds que vous prévoyez d'exécuter.
  • $F_j$ = La fréquence moyenne du moniteur en tâches par minute (par exemple, un moniteur exécuté toutes les 5 minutes a une fréquence de 1/5 ou 0,2).
  • $D_j$ = La durée moyenne d'un travail en minutes.

Voici comment cela fonctionne : cela calcule votre workload attendue à partir des premiers principes : le nombre de moniteurs dont vous disposez, la fréquence à laquelle ils s'exécutent et le temps qu'ils prennent.

Facteurs de dimensionnement importants

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

  • Durée du travail ($D_j$) : votre moyenne doit inclure les travaux qui expirent (souvent environ 3 minutes), car ceux-ci détiennent 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 fréquence, 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).

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. Rechercher les tâches traitées par minute ($J_processed$) : 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

2. Rechercher la croissance de la file d'attente par minute ($Q_growth$) : cette requête calcule la croissance moyenne par minute de la file d'attente jobManagerHeavyweightJobs sur un graphique de séries chronologiques. Une ligne au-dessus de zéro indique que la file d'attente s'allonge, 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

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. Rechercher la durée moyenne d'une tâche en minutes ($D_j$) : cette requête recherche la durée moyenne d'exécution des tâches non ping terminées et convertit le résultat de millisecondes en minutes. Pourquoi utiliser executionDuration? Il représente le temps que le travail a pris pour s'exécuter sur l'hôte, ce que nous voulons mesurer.

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

4. Rechercher le nombre total de moniteurs lourds ($N_m$) : cette requête recherche 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

5. Trouver la fréquence moyenne des moniteurs lourds ($F_j$) : si la file d'attente jobManagerHeavyweightJobs du site privé augmente, il n'est pas précis de calculer la fréquence moyenne des moniteurs à partir des résultats existants. Cela devra être estimé à partir de la liste des moniteurs sur la page des moniteurs Synthétique. 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, vous devrez peut-être augmenter les ressources de votre hôte ou les déployer en déployant davantage de gestionnaires de tâches pour maintenir la file d'attente pingJobs claire et éviter les retards.

Kubernetes et OpenShift

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.

Des durées d'exécution de ping supplémentaires peuvent être démarrées pour aider à exécuter la charge du moniteur de ping en augmentant le paramètre ping-runtime.replicaCount par rapport à la valeur par défaut de 1.

Les environnements d'exécution de Node.js l'API et Node.js Browser sont dimensionnés indépendamment à l'aide d'une combinaison des paramètres parallelism completions et. La configuration idéale pour ces paramètres variera en fonction des exigences des clients.

Le paramètre parallelism contrôle le nombre de pods d'un runtime particulier exécutés simultanément. Le paramètre parallelism est l'équivalent de la configuration synthetics.heavyWorkers dans le minion privé conteneurisé (CPM). Assurez-vous que votre cluster Kubernetes dispose de suffisamment de ressources disponibles pour exécuter ce nombre de pods en fonction de leur demande de ressources et de leurs valeurs limites.

Le paramètre completions contrôle le nombre de pods d'un runtime particulier qui doivent être terminés avant que CronJob puisse démarrer un autre travail Kubernetes pour ce runtime. Notez la différence entre un travail Kubernetes (J majuscule) et un travail du monitoring Synthetics. Pour une efficacité améliorée, completions doit être défini sur 6 à 10 fois la valeur parallelism . Cela peut aider à minimiser l'inefficacité de « l'approche de la fin des achèvements » où moins de parallelism pods pourraient finir par s'exécuter pendant que le travail Kubernetes attend que tous les completions se terminent.

Lorsque completions est supérieur à 1, le pod avec un statut « Terminé » restera visible dans la sortie de kubectl get pods -n YOUR_NAMESPACE jusqu'à ce que toutes les complétions définies dans le travail Kubernetes aient été respectées, par exemple 6/6 complétions. Les ressources sont sorties du nœud lorsqu'un pod a le statut Terminé ou Échec.

Un âge de travail Kubernetes de 5 minutes (kubectl get jobs -n YOUR_NAMESPACE) est un objectif prudent pour tenir compte de la variabilité du temps nécessaire au pod pour se terminer et du nombre de tâches Synthetics devant être exécutées par minute (taux de tâches). Les équations suivantes peuvent être utilisées comme point de départ pour completions et parallelism pour chaque temps d’exécution. Des ajustements peuvent s'avérer nécessaires en fonction des observations de la croissance de la file d'attente privée du site.

completions = 300 / avg job duration (s)
parallelism = synthetics jobs per 5 minutes / completions

Des durées d'exécution différentes auront probablement des durées et des taux de tâches Synthetics différents. La requête suivante peut être utilisée pour obtenir la durée moyenne et le tarif d'un site privé.

-- non-ping average job duration by runtime type
FROM SyntheticCheck SELECT average(duration) AS 'avg job duration'
WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION' FACET type SINCE 1 hour ago


-- non-ping jobs per minute by runtime type
FROM SyntheticCheck SELECT rate(uniqueCount(id), 5 minutes) AS 'jobs per 5 minutes'
WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION' FACET type SINCE 1 hour ago

Conseil

La requête ci-dessus est basée sur les résultats actuels. Si votre site privé n'a aucun résultat ou si le gestionnaire de tâches ne fonctionne pas de manière optimale, les résultats de la requête peuvent ne pas être précis. Dans ce cas, essayez quelques valeurs différentes pour completions et parallelism jusqu'à ce que vous voyiez une durée kubectl get jobs -n YOUR_NAMESPACE d'au moins 5 minutes (assez de complétions) et que la file d'attente ne s'agrandisse pas (assez de parallélisme).

Exemple

Description

parallelism=1

completions=1

Le runtime exécutera 1 tâche Synthetics par minute. Une fois la tâche terminée, la configuration CronJob démarrera une nouvelle tâche à la minute suivante. Throughput will be extremely limited with this configuration.

parallelism=1

completions=6

Le runtime exécutera 1 tâche Synthetics à la fois. Une fois le travail terminé, un nouveau travail démarrera immédiatement. Une fois le nombre de tâches défini sur completions terminé, la configuration CronJob démarrera une nouvelle tâche Kubernetes et réinitialisera le compteur d'achèvements. Throughput will be limited, but slightly better. Une seule tâche Synthetics de longue durée bloquera le traitement de toutes les autres tâches Synthetics de ce type.

parallelism=3

completions=24

Le runtime exécutera 3 tâches Synthetics à la fois. Une fois l’une de ces tâches terminées, une nouvelle tâche démarre immédiatement. Une fois le nombre de tâches défini sur completions terminé, la configuration CronJob démarrera une nouvelle tâche Kubernetes et réinitialisera le compteur d'achèvements. Throughput is much better with this or similar configurations. Une seule tâche Synthetics de longue durée aura un impact limité sur le traitement des autres tâches Synthetics de ce type.

Si les tâches Synthetics prennent plus de temps à se terminer, moins de complétions sont nécessaires pour remplir 5 minutes avec des tâches, mais davantage de pods parallèles seront nécessaires. De même, si davantage de tâches Synthetics doivent être traitées par minute, davantage de pods parallèles seront nécessaires. Le paramètre parallelism affecte directement le nombre de tâches Synthetics pouvant être exécutées par minute. Une valeur trop petite et la file d'attente risque de s'allonger. Une valeur trop élevée peut entraîner des contraintes en termes de ressources sur les nœuds.

Si vos paramètres parallelism fonctionnent bien pour maintenir la file d'attente à zéro, définir une valeur plus élevée pour completions que celle calculée à partir de 300 / avg job duration peut aider à améliorer l'efficacité de plusieurs manières :

  • Acceptez la variabilité des durées de travail de sorte qu'au moins 1 minute soit remplie de travaux Synthetics, ce qui correspond à la durée minimale de CronJob.
  • Réduisez le nombre de cycles d'achèvement afin de minimiser l'inefficacité de « l'approche de la fin des achèvements » où la prochaine série d'achèvements ne peut pas démarrer tant que la tâche finale n'est pas terminée.

Il est important de noter que la valeur completions ne doit pas être trop grande, sinon le CronJob rencontrera un événement d'avertissement comme le suivant :

8m40s       Warning   TooManyMissedTimes     cronjob/synthetics-node-browser-runtime                  too many missed start times: 101. Set or decrease .spec.startingDeadlineSeconds or check clock skew

Conseil

Veuillez garder à l’esprit que New Relic n’est pas responsable des modifications que vous apportez aux fichiers du gestionnaire de tâches Synthetics.

Droits d'auteur © 2025 New Relic Inc.
RecrutementConditions de servicePolitique DMCAAvis de confidentialitéCookiesLoi britannique sur l'esclavage

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.