Noms des champs API condition d'alerte

Les points de terminaison d'APIREST vous permettent de créer des conditions pour vos politiques. Ce glossaire contient les noms et les descriptions de chacun des champs que vous pouvez utiliser pour définir ou mettre à jour une condition.

Avant d'utiliser l'API REST

L'API REST n'est plus le moyen privilégié pour gérer vos alertes par programmation. Pour plus de contexte, lisez l'introduction aux API pour .

Champs obligatoires et facultatifs

L'API comprend quatre types de conditions d'alerte :

APM
Services externes
NRQL
Monitoring synthétique

Tous les champs utilisés avec un type de condition spécifique sont obligatoires, à l'exception de ces champs facultatifs :

enabled (par défaut false)
runbook_url
user_defined

Définitions des champs

Tous les champs répertoriés dans ce glossaire ne sont pas obligatoires pour chaque type de condition. Le type de condition pour lequel un champ doit être utilisé est répertorié dans chaque description.

Il s'agit d'un ensemble d'identifiants d'entités identifiant les objets qui seront monitorés avec votre condition. Il peut s'agir d'identifiants d'application, d'ID de navigateur, d'ID de clé de transaction, d'ID de service externe, etc.

Ceux-ci sont saisis sous la forme d'une série d'entiers séparés par des virgules s'il y en a plusieurs.

Utilisé pour :

Conditions
Conditions de service externes

Le champ metric est utilisé pour trois catégories d’alertes. Les paramètres exacts disponibles pour l'utilisation dépendent du paramètre dans le champ type . Ceux-ci sont répertoriés ci-dessous en fonction de leur champ de type d'alerte.

La valeur spécifiée dans le champ type contrôle quel paramètre peut être spécifié. Le champ de type et les noms parameter disponibles correspondants sont répertoriés dans le tableau suivant. Un seul peut être spécifié.

`type`	paramètres
apm_app_metric	indice ap. error_percentage response_time_web response_time_background throughput_web throughput_background user_defined
apm_kt_metric	indice ap. error_percentage error_count response_time débit
browser_metric	end_user_apdex total_page_load page_rendering web_application réseau dom_processing request_queuing ajax_response_time page_views_with_js_errors page_view_throughput ajax_throughput user_defined
browser_metric_baseline	page_view_throughput average_response_time ajax_response_time ajax_application_time
mobile_metric	base de données images json, réseau view_loading network_error_percentage status_error_percentage user_defined

`type`	paramètres
apm_external_service	indice ap. error_percentage response_time_web response_time_background throughput_web throughput_background user_defined
apm_app_metric_baseline	external_service_transaction_time error_count database_transaction_time throughput_web response_time_web non_web_transaction_time web_transaction_database_time non_web_transaction_database_time
mobile_external_service	response_time_average response_time_minimum response_time_maximum débit network_failure_percentage http_status_error_percentage

New Relic regroupe les données dans des fenêtres et doit déterminer quand la fenêtre actuelle se termine et quand la suivante commence. Le aggregation_method est la logique qui nous indique quand nous avons toutes les données pour une fenêtre d’agrégation donnée. Une fois la fenêtre fermée, les données sont agrégées en un seul point et évaluées par rapport au seuil.

Ce champ est facultatif. L'une des trois valeurs suivantes peut être spécifiée :

EVENT_FLOW: (Par défaut) Chaque fenêtre d'agrégation attendra jusqu'à ce qu'elle commence à voir arriver les horodatages qui ont dépassé son propre paramètre de délai. Une fois que cela se produit, les données sont publiées. S'appuie sur l'horodatage des données arrivant, donc le temps horloge n'est plus pertinent. Fonctionne mieux pour les sources qui arrivent fréquemment et avec une faible propagation d'événements (métriques à débit élevé).
CADENCE:Logique New Relic classique où chaque fenêtre d'évaluation attend exactement aussi longtemps que le paramètre aggregation_delay, en utilisant l'horloge de temps comme minuterie. aggregation_delay est requis lors de l'utilisation de cette option. Les données arrivant trop tard seront abandonnées, ce qui peut provoquer de fausses alertes.
EVENT_TIMER:Chaque fenêtre d'agrégation dispose d'un minuteur défini sur la valeur aggregation_timer . Le minuteur commence à s'exécuter dès que le premier point de données apparaît pour cette fenêtre d'agrégation (en fonction de l'horodatage du point de données). Le aggregation_timer est réinitialisé pour chaque nouveau point de données qui arrive pour cette fenêtre. Une fois que le aggregation_timer atteint 0, la fenêtre d’agrégation est publiée. Idéal pour les données éparses et groupées, telles que l'intégration cloud et les logs des erreurs peu fréquentes.
La valeur par défaut est Event flow.
Utilisé pour :
Conditions NRQL

Les alertes en streaming rassemblent les données dans des délais spécifiques avant d'exécuter la fonction dans la requête NRQL. Ces fenêtres de temps sont personnalisables.

Les points de données sont collectés ensemble en fonction de leur horodatage et signalés sous forme de lot. La fenêtre d'agrégation personnalisable offre une plus grande flexibilité et moins de faux incidents lors des alertes sur des points de données irréguliers ou moins fréquents.

Dans l'UI, sous Advanced signal settings, il s'agit du champ Aggregation window.

La valeur par défaut est 60 seconds. Le maximum est de 6 heures.

Utilisé pour :

Conditions NRQL

Par défaut, les fenêtres d’agrégation sont regroupées de manière séquentielle. Cela peut conduire à des graphiques irréguliers à chaque fois qu'une fenêtre démarre et qu'une autre commence.

Utilisez slide_by pour créer des fenêtres coulissantes. Les fenêtres agrégées coulissantes se chevauchent, créant des graphiques plus fluides. L'intervalle slide_by définit la durée du chevauchement.

Dans l'UI, sous Advanced signal settings, cliquez sur le bouton bascule Use sliding window aggregation pour activer les fenêtres coulissantes.

La valeur par défaut est basée sur la durée de la fenêtre actuelle. L'intervalle slide_by doit être divisé uniformément dans la durée de votre fenêtre d'agrégation. L'intervalle slide_by doit également être inférieur à la durée de la fenêtre.

Pour les données sporadiques, vous pouvez éviter les fausses alertes en remplissant les trous (fenêtres vides) avec des données Synthétique.

none: (Par défaut) Utilisez ceci si vous ne souhaitez effectuer aucune action sur les fenêtres d'agrégation vides. Lors de l'évaluation, une fenêtre d'agrégation vide réinitialisera le minuteur de durée du seuil. Par exemple, si une condition indique que toutes les fenêtres d'agrégation doivent avoir des points de données au-dessus du seuil pendant 5 minutes et qu'une des 5 fenêtres d'agrégation est vide, la condition n'ouvrira pas d'incident.
static:Utilisez ceci si vous souhaitez insérer une valeur statique personnalisée dans les fenêtres d’agrégation vides avant qu’elles ne soient évaluées. Cette option possède un paramètre supplémentaire obligatoire de fillValue qui spécifie quelle valeur statique doit être utilisée. La valeur par défaut est 0.
last_value:Utilisez ceci pour insérer la dernière valeur vue avant que l'évaluation ne se produise. Nous maintenons l'état de la dernière valeur vue pendant 2 heures.
Dans l'UI, sous Advanced signal settings, il s'agit du champ Fill data gaps with.
Utilisé pour :
Conditions NRQL

Cela détermine quelle comparaison sera utilisée entre les valeurs value_function et terms[threshold] pour déclencher un événement. Cela correspond à l'opération sélectionnée lors de l'ajout d'un seuil dans l'UI. Il doit s'agir de l'une des chaînes suivantes :

au-dessus de
above_or_equals (conditions NRQL uniquement)
ci-dessous
below_or_equals (conditions NRQL uniquement)
égal
not_equals (conditions NRQL uniquement)
Utilisé pour :
Conditions
Conditions de service externes
Conditions NRQL

Ceci définit le type de métrique qui sera utilisé pour l'alerte. Le contenu autorisé pour le champ métrique dépend de la valeur type choisie.

Il existe deux catégories de produits :

Pour cette catégorie, type est défini sur l’une des chaînes suivantes indiquant le type de condition d’alerte.

`type`	Utiliser
apm_app_metric	la métrique d'application déclenchera une alerte.
apm_app_metric_baseline	La métrique d'application APM déclenchera une alerte (en utilisant un seuil d'anomalie).
apm_kt_metric	APM transaction clé métrique déclenchera une alerte.
browser_metric	La métrique du navigateur déclenchera une alerte.
browser_metric_baseline	La métrique du navigateur déclenchera une alerte (en utilisant un seuil d'anomalie).
mobile_metric	La métrique mobile déclenchera une alerte.

Utilisé pour :

Conditions

Pour cette catégorie, type est défini sur l’une des chaînes suivantes indiquant le type de condition de service externe.

`type`	Utiliser
apm_external_service	La métrique externe APM déclenchera une alerte.
mobile_external_service	La métrique externe mobile déclenchera une alerte.

Utilisé pour :

Conditions de service externes

Il s’agit du nom d’un metric personnalisé défini par l’utilisateur à utiliser pour déterminer si un événement doit être déclenché.

Le user_defined[value_function] associé à la métrique est comparé à la valeur terms[threshold] lors de l'évaluation si un incident doit être déclenché. La comparaison est effectuée à l'aide de l'opérateur défini par terms[operator].

Utilisé pour :

Conditions
Conditions de service externes
Conditions monitoring synthétique

Il s'agit de la valeur numérique obtenue à partir des métriques personnalisées spécifiées par user_defined[metric].

Elle est comparée à la valeur terms[threshold] lors de l’évaluation si un incident doit être déclenché. La comparaison est effectuée à l'aide de l'opérateur défini par terms[operator].

Une de ces fonctions de valeur doit être spécifiée :

moyenne
min
max
total
sample_size
Utilisé pour :
Conditions

Cette traduction automatique est fournie pour votre commodité.

Avant d'utiliser l'API REST .css-21sua1{background:none;border:none;width:0;padding:0;}

Champs obligatoires et facultatifs

Définitions des champs

activé

entité

expiration[expiration_duration]

expiration[close_violations_on_expiration]

expiration[open_violation_on_expiration]

external_service_url

métrique

monitor_id

nom

nrql[query]

nrql[since_value]

runbook_url

signal[aggregation_delay]

signal[aggregation_method]

signal[aggregation_timer]

signal[aggregation_window]

signal[slide_by]

signal[evaluation_offset]

signal[fill_option]

signal[fill_value]

terms[duration]

terms[operator]

terms[priority]

terms[threshold]

terms[time_function]

type

user_defined[metric] (optional)

user_defined[value_function] (optional)

value_function

violation_time_limit_seconds

violation_close_timer

Avant d'utiliser l'API REST