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

  • C_estC\_est = Cœurs de CPU estimés.
  • 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_est = N_mon \cdot D_avg,m \cdot \frac1P_avg,m $$

  • C_estC\_est = Cœurs de CPU estimés.
  • 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 type != 'SIMPLE'
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 type != 'SIMPLE'
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 type != 'SIMPLE'
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.

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

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

Où D_avg,mD\_avg,m est votre durée moyenne d'exécution de tâche 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

$$ P_est = \fracN_mCompletions $$

Où N_mN\_m est votre nombre de tâches par 5 minutes. Cette valeur P_estP\_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

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

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 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 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
$
# 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 © 2026 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.