• /
  • 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 et Podman

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_req = (R_proc + R_growth) \cdot D_avg,m $$

  • C_reqC\_req = Cœurs de processeur requis.
  • R_procR\_proc = Le taux de tâches lourdes traitées par minute.
  • R_growthR\_growth = Le taux de croissance de votre file d'attente jobManagerHeavyweightJobs par minute.
  • D_avg,mD\_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_req = N_mon \cdot D_avg,m \cdot \frac1P_avg,m $$

  • C_reqC\_req = Cœurs de processeur requis.
  • N_monN\_mon = Le nombre total de moniteurs lourds que vous prévoyez d'exécuter.
  • D_avg,mD\_avg,m = La durée moyenne d'un travail lourd en minutes.
  • P_avg,mP\_avg,m = La période moyenne pour un moniteur lourd en minutes (par exemple, un moniteur qui s'exécute toutes les 5 minutes a P_avg,m=5P\_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 travail (D_avg,mD\_avg,m) : votre moyenne doit inclure les travaux qui expirent (souvent environ 3 minutes), car ceux-ci conservent 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 de votre site privé devient la somme du débit de chaque SJM (par exemple, deux SJM fournissent jusqu'à ~30 jobs/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. Trouvez le taux de tâches traitées par minute (R_procR\_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 typeLabel != 'Ping'
SINCE 1 day ago

2. Trouvez le taux de croissance de la file d'attente par minute (R_growthR\_growth): Cette requête calcule la croissance moyenne par minute de la file d'attente jobManagerHeavyweightJobs sur un graphique de série chronologique. 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 se raccourcit.

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. Trouver le nombre total de moniteurs lourds (N_monN\_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 typeLabel != 'Ping'
SINCE 1 day ago

4. Trouver la durée moyenne des tâches en minutes (D_avg,mD\_avg,m): Cette requête trouve la durée d'exécution moyenne des tâches terminées sans ping et convertit le résultat de millisecondes en minutes. executionDuration représente le temps nécessaire à l'exécution du travail sur l'hôte.

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

5. Trouver la période moyenne du moniteur lourd (P_avg,mP\_avg,m) : si la file d'attente jobManagerHeavyweightJobs du site privé augmente, il n'est pas précis de calculer la période moyenne du moniteur à partir des résultats existants. Cela devra être estimé à partir de la liste des moniteurs sur la page des 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.

Considérations de dimensionnement pour 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. 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.

Comment dimensionner votre déploiement : un guide étape par étape

Votre objectif est de configurer un parallélisme suffisant pour gérer votre charge de travail sans dépasser la limite de débit de votre instance SJM.

Étape 1 : Estimez votre charge de travail requise

Terminaisons : ceci détermine le nombre de pods d’exécution qui doivent se terminer avant qu’un nouveau travail Kubernetes ne démarre.

Tout d'abord, déterminez la durée moyenne d'exécution des tâches et le taux de traitement des tâches de votre site privé. Utilisez executionDuration car cela reflète le plus précisément l'état d'exécution actif du pod.

-- Get average job execution duration (in seconds)
FROM SyntheticCheck
SELECT average(executionDuration / 60e3) AS 'D_avg_m'
WHERE typeLabel != 'Ping' AND location = 'YOUR_PRIVATE_LOCATION'
FACET typeLabel SINCE 1 hour ago

$$ Achèvements = \frac5D_avg,m $$

Où D_avg,mD\_avg,m représente la durée moyenne d'exécution de votre tâche en secondes.

Parallélisme requis : cela détermine le nombre de travailleurs (pods) dont vous avez besoin pour gérer votre charge de travail de 5 minutes.

-- Get jobs per 5 minutes
FROM SyntheticCheck
SELECT rate(uniqueCount(id), 5 minutes) AS 'N_m'
WHERE typeLabel != 'Ping' AND location = 'YOUR_PRIVATE_LOCATION'
FACET typeLabel SINCE 1 hour ago

$$ P_req = \fracN_mCompletions $$

Où N_mN\_m représente votre nombre de tâches par 5 minutes. Cette valeur P_reqP\_req correspond à votre parallélisme total cible.

Étape 2 : Vérifier la limite de débit d'un seul SJM

Parallélisme maximal : ceci détermine le nombre de travailleurs (pods) que votre SJM peut utiliser efficacement.

$$ P_max ≈ 15 × D_avg,m $$

Cette valeur P_maxP\_max représente la limite de votre système pour un déploiement SJM Helm.

Conseil

Les requêtes ci-dessus sont basées sur les résultats actuels. Si votre site privé ne donne 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, commencez par les exemples du tableau ci-dessous et ajustez-les jusqu'à ce que votre file d'attente soit stable.

Conseil

Un élément clé à prendre en compte est qu'une seule instance SJM a un débit maximal d'environ 15 tâches lourdes par minute. Vous pouvez calculer le parallélisme effectif maximal (P_maxP\_max) qu'un seul SJM peut supporter avant d'atteindre ce plafond.

Étape 3 : Comparer, configurer et mettre à l’échelle

Comparez votre parallélisme requis (P_reqP\_req) de l'étape 1 au parallélisme maximal (P_maxP\_max) de l'étape 2.

Scenario A: P_req≤P_maxP\_req \le P\_max

  • Diagnostic : Votre charge de travail est inférieure à la limite d'une seule instance SJM.

  • Action:

    1. Vous déployerez une sortie du SJM Helm.
    2. Dans votre graphique Helm values.yaml, définissez parallelism sur votre P_reqP\_req calculé.
    3. Définissez completions sur vos Completions calculées. Pour une efficacité accrue, cette valeur devrait généralement être 6 à 10 fois supérieure à votre paramètre parallelism.

Scenario B: P\_req > P\_max

  • Diagnostic : Votre charge de travail dépasse la limite d'environ 15 tâches/minute d'un seul SJM.

  • Action:

    1. Vous devez évoluer en déployant plusieurs sorties SJM Helm distinctes.
    2. Consultez la section « Mise à l’échelle avec plusieurs déploiements SJM » ci-dessous pour connaître la procédure correcte.
    3. N'augmentez pas la valeur replicaCount dans votre graphique Helm.

Étape 4 : Monitorez votre file d’attente

Après avoir appliqué vos modifications, vous devez vérifier que votre file d'attente de tâches est stable et ne s'allonge pas. Une file d'attente qui ne cesse de s'allonger signifie que votre site est encore sous-approvisionné.

Exécutez cette requête pour vérifier le taux de croissance de la file d'attente :

-- Check for queue growth (a positive value means the queue is growing)
SELECT derivative(jobManagerHeavyweightJobs, 1 minute) AS 'Heavyweight Queue Growth Rate (per min)'
FROM SyntheticsPrivateLocationStatus
WHERE name = 'YOUR_PRIVATE_LOCATION'
SINCE 1 hour ago TIMESERIES

Si le « taux de croissance de la file d'attente » est constamment positif, vous devez installer davantage de déploiements SJM Helm (scénario B) ou revérifier vos paramètres parallelism (scénario A).

Exemples de configuration et de réglage

Le paramètre parallelism affecte directement le nombre de tâches Synthetics pouvant être exécutées par minute. Une valeur trop faible et la file d'attente risque de s'allonger. Une valeur trop élevée peut entraîner une limitation des ressources au niveau des nœuds.

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

L'environnement d'exécution exécutera une tâche Synthetics à la fois. Une fois le travail terminé, un nouveau travail commencera immédiatement. Une fois 6 tâches terminées, la configuration CronJob démarrera une nouvelle tâche Kubernetes. Throughput will be limited. Une seule tâche Synthetics de longue durée bloquera le traitement de toute autre tâche Synthetics de ce type.

parallelism=3 completions=24

L'environnement d'exécution exécutera 3 tâches Synthetics simultanément. Une fois chacune de ces tâches terminée, une nouvelle tâche commencera immédiatement. Une fois 24 tâches terminées, la configuration CronJob lancera une nouvelle tâche Kubernetes. Throughput is much better with this or similar configurations.

Si votre paramètre parallelism fonctionne correctement (en maintenant la file d'attente à zéro), l'augmentation de la valeur completions (par exemple, 6 à 10 fois parallelism) peut améliorer l'efficacité en :

  • S’adapter à la variabilité de la durée des missions.
  • Réduire le nombre de cycles d'achèvement afin de minimiser l'inefficacité liée à la « fin imminente des achèvements », où le lot suivant ne peut démarrer que lorsque la dernière tâche du lot actuel est 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 :

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

Conseil

New Relic n'est pas responsable des modifications que vous apportez aux fichiers du gestionnaire de tâches Synthetics.

Évolutivité avec plusieurs déploiements SJM

Pour dépasser le débit d'environ 15 tâches/minute d'un seul SJM, vous devez installer plusieurs sorties SJM Helm distinctes.

Important

N’utilisez pas replicaCount pour dimensionner le pod du gestionnaire de tâches. Vous ne pouvez pas augmenter la valeur de replicaCount pour une seule sortie Helm. L'architecture SJM requiert une relation 1:1 entre un pod d'exécution et son pod SJM parent. Si le pod d'exécution renvoie les résultats à la mauvaise réplique SJM (par exemple, via un service Kubernetes), ces résultats seront perdus.

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 simplifiée

En supposant que P\_req > P\_max et que vous ayez besoin d'augmenter la capacité, vous pouvez simplifier la maintenance en traitant chaque déploiement SJM comme une unité à capacité fixe.

  1. Définir le parallélisme maximal : pour chaque SJM, définissez parallelism sur la même valeur P_maxP\_max. Cela maximise le débit potentiel de chaque SJM.

  2. Saisie des ensembles : Pour chaque SJM, définissez également completions sur une valeur fixe. La formule P_reqP\_req de l'étape 1 peut être modifiée pour estimer les complétions en remplaçant la valeur par P_maxP\_max :

    $$ Achèvements = \fracN_mP_max $$

    Où N_mN\_m représente votre nombre de tâches par 5 minutes. Ajustez au besoin après le déploiement pour cibler une durée d'exécution de 5 minutes pour chaque tâche Kubernetes, c'est-à-dire node-browser-runtime et node-api-runtime.

  3. Installation de sortie : Installez autant de sorties Helm distinctes que nécessaire pour gérer votre total P_reqP\_req. Par exemple, si votre P_reqP\_req total est de 60 et que vous avez fixé parallelism de chaque SJM à 20 (P_maxP\_max de l'étape 2), vous auriez besoin de trois déploiements Helm distincts pour répondre à la demande de travail requise.

  4. Monitorez et ajoutez : monitorez votre file d'attente de tâches (voir l'étape 4). Si elle commence à se développer, installez simplement une autre sortie Helm (par exemple, sjm-delta) en utilisant la même configuration fixe.

En fixant le parallélisme et les complétions à des valeurs statiques basées sur P_maxP\_max, l'augmentation ou la diminution de la capacité devient un processus plus simple d' ajout ou de suppression de sortie Helm . Cela permet d'éviter de gaspiller les ressources du cluster pour 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
$
# 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
$
# 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.

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

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