• /
  • 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 Kubernetes et Docker

Conseil

Les considérations de dimensionnement spécifiques à Docker seront bientôt disponibles.

Si vous travaillez dans des environnements plus vastes, vous devrez peut-être personnaliser la configuration du gestionnaire de tâches pour répondre aux exigences minimales afin d'exécuter efficacement Synthétique Monitorer. De nombreux facteurs peuvent avoir un impact sur les exigences de dimensionnement pour un déploiement de gestionnaire de tâches Synthetics, notamment :

  • Si tous les runtimes sont requis en fonction de l'utilisation prévue
  • Le nombre de tâches par minute par type de moniteur (ping, navigateur simple ou scripté et API scriptée)
  • Durée de la tâche, y compris les tâches qui expirent au bout d'environ 3 minutes
  • Le nombre d'échecs de travail. En cas d'échec d'une tâche, de nouvelles tentatives automatiques sont planifiées lorsqu'un moniteur commence à échouer afin de fournir une logique de nouvelle tentative 3/3 intégrée. Ces tâches supplémentaires s'ajoutent aux exigences de débit du gestionnaire de tâches Synthétique.

En plus des paramètres configuration de dimensionnement répertoriés ci-dessous, des gestionnaires de tâches Synthetics supplémentaires peuvent être déployés avec la même clé privée de site pour équilibrer la charge des tâches sur plusieurs environnements.

Kubernetes

Chaque runtime utilisé par le gestionnaire de tâches Kubernetes 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.