Quels sont les modèles de configuration dans le processeur de données ?
Important
Opérations Azure IoT (préversion) – activé parc Azure Arc est actuellement en PRÉVERSION. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.
Vous devrez déployer une nouvelle installation d’Azure IoT Operations lorsqu’une version en disponibilité générale est mise à disposition, vous ne pourrez pas mettre à niveau une installation en préversion.
Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.
Plusieurs types de configuration sont communs à plusieurs phases de pipeline. Cet article décrit les modèles de configuration chemin, lot, modèles, nouvelles tentatives et durée.
Chemin d’accès
Plusieurs étapes de pipeline utilisent un chemin d’accès pour identifier un emplacement dans le message dans lequel les données doivent être lues ou écrites. Pour définir ces emplacements, vous utilisez un champ Path
qui utilise la syntaxe jq :
- Un chemin d’accès est défini comme une chaîne dans l’interface utilisateur et utilise la syntaxe jq.
- Un chemin d’accès est défini par rapport à la racine du message du processeur de données. Le chemin
.
fait référence à l’intégralité du message. - Tous les chemins commencent par
.
. - Chaque segment de chemin peut être :
.<identifier>
pour une clé d’objet alphanumérique telle que.topic
.."<identifier>"
pour une clé d’objet arbitraire telle que."asset-id"
.["<identifier>"]
pour une clé d’objet arbitraire telle que["asset-id"]
.[<index>]
pour un index de tableau tel que[2]
.
- Les segments peuvent être chaînés pour former des chemins complexes.
Les segments de chemin d’accès individuels doivent être conformes aux expressions régulières suivantes :
Modèle | Regex | Exemple |
---|---|---|
.<identifier> |
\.[a-zA-Z_][a-zA-Z0-9_]* |
.topic |
."<identifier>" |
\."(\\"\|[^"])*" |
."asset-id" |
["<identifier>"] |
\["(\\"\|[^"])*"\] |
["asset-id"] |
[<index>] |
\[-?[0-9]+\] |
[2] |
Pour en savoir plus, consultez Chemins d’accès dans le guide jq.
Exemples de chemins d’accès
Les chemins d'accès suivants sont des exemples basés sur la structure standard du message du processeur de données :
.systemProperties
retourne :{ "partitionKey": "foo", "partitionId": 5, "timestamp": "2023-01-11T10:02:07Z" }
.payload.humidity
retourne :10
.userProperties[0]
retourne :{ "key": "prop1", "value": "value1" }
.userProperties[0].value
retourne :value1
Durée
Plusieurs étapes nécessitent la définition d'une durée. Par exemple, les fenêtres d’une phase d’agrégation et des délais d’attente dans une phase d’appel. Ces étapes utilisent un champ Duration
pour représenter cette valeur.
Plusieurs étapes du pipeline utilisent une durée. Par exemple, l’étape d’agrégation a une propriété Windows et les étapes de légende ont une propriété de délai d’attente. Pour définir ces intervalles de temps, vous utilisez un champ Duration
:
La durée est une valeur de chaîne au format suivant <number><char><number><char>
où « char » peut être :
h
: heurem
: minutes
: secondems
: millisecondeus
,µs
: microsecondens
: nanoseconde
Exemples de durée
2h
1h10m30s
3m9ms400ns
Modèles
Plusieurs étapes vous obligent à définir une chaîne avec une combinaison de valeurs dynamiques et statiques. Ces étapes utilisent des valeurs de modèle.
Les modèles de processeur de données utilisent la syntaxe Mustache pour définir des valeurs dynamiques dans des chaînes.
Les valeurs système dynamiques disponibles pour une utilisation dans les modèles sont les suivantes :
instanceId
: ID d’instance du processeur de données.pipelineId
: ID de pipeline dont fait partie l’étape.YYYY
: année en cours.MM
: mois en cours.DD
: date actuelle.HH
: heure actuelle.mm
: minute actuelle.
Actuellement, vous pouvez utiliser des modèles pour définir des chemins de fichier dans une phase de destination.
Champs statiques et dynamiques
Certaines étapes nécessitent la définition de valeurs qui peuvent être des chaînes statiques ou une valeur dynamique dérivée d’un Path
dans un Message. Pour définir ces valeurs, vous pouvez utiliser des champs statiques ou dynamiques.
Un champ statique ou dynamique est toujours écrit en tant qu’objet avec un champ type
qui a l’une des deux valeurs suivantes : static
ou dynamic
. Le schéma varie en fonction de type
.
Champs statiques
La définition statique est une valeur fixe pour type
est static
. La valeur réelle est conservée dans value
.
Champ | Type | Description | Obligatoire | Par défaut | Exemple |
---|---|---|---|---|---|
type | chaîne const | Type du champ. | Oui | - | static |
value | tous | Valeur statique à utiliser pour la configuration (généralement une chaîne). | Oui | - | "static" |
Les exemples suivants illustrent certaines définitions de champs statiques :
{
"some-field": {
"type": "static",
"value": "some-static-value"
}
}
{
"some-boolean-field": {
"type": "static",
"value": true
}
}
{
"some-complex-field": {
"type": "static",
"value": {
"some": [
"nested",
"data"
]
}
}
}
Champs dynamiques
La valeur fixe pour type
est dynamic
. La valeur est un chemin jq.
Champ | Type | Description | Obligatoire | Par défaut | Exemple |
---|---|---|---|---|---|
type | chaîne const | Type du champ | Oui | - | dynamic |
value | Chemin d’accès | Chemin d’accès dans chaque message où une valeur pour le champ peut être récupérée dynamiquement. | Oui | - | .systemProperties.partitionKey |
L’exemple suivant montre une définition de champ dynamique :
{
"some-field": {
"type": "dynamic",
"value": ".systemProperties.topic"
}
}
Réessayer
Les étapes qui appellent des services externes peuvent utiliser des nouvelles tentatives pour gérer les défaillances temporaires et améliorer la fiabilité. Vous pouvez remplacer la stratégie de nouvelle tentative par défaut lorsque vous configurez une étape.
Il existe quatre stratégies de nouvelle tentative possibles :
default
: la stratégie de nouvelle tentative par défaut consiste à utiliser une nouvelle tentative d’interruption exponentielle avec trois nouvelles tentatives et un intervalle de nouvelle tentative initial de 500 ms.none
: aucune nouvelle tentative n’est effectuée.fixed
: une stratégie de nouvelle tentative fixe retente un nombre fixe de tentatives avec un intervalle fixe entre chaque nouvelle tentative.exponential
: une stratégie de nouvelle tentative exponentielle retente un nombre fixe de tentatives avec un intervalle croissant de manière exponentielle entre chaque nouvelle tentative.
Si vous choisissez default
ou none
, vous n’avez pas besoin de fournir plus de configuration. Si vous choisissez fixed
ou exponential
, vous devez fournir plus de configuration :
Fixe
Champ | Type | Description | Requis ? | Par défaut | Exemple |
---|---|---|---|---|---|
type |
string | Nom du type de nouvelle tentative : fixed |
Oui | S/O | fixed |
interval |
Durée | Période initiale entre chaque nouvelle tentative. | Non | 500ms |
2s |
maxRetries |
int | Nombre de nouvelles tentatives, de 1 à 20 |
Non | 3 |
20 |
Exponentielle
Champ | Type | Description | Requis ? | Par défaut | Exemple |
---|---|---|---|---|---|
type |
string | Nom du type de nouvelle tentative : exponential |
Oui | S/O | exponential |
interval |
Durée | Période initiale entre chaque nouvelle tentative. | Non | 500ms |
2s |
maxRetries |
int | Nombre de nouvelles tentatives, de 1 à 20 |
Non | 3 |
20 |
maxInterval |
Durée | Période maximale entre chaque nouvelle tentative. | Non | Aucun | 100s |
Les temps de nouvelle tentative exponentielle sont calculés comme suit : si l’intervalle commence par 500ms
, les intervalles de nouvelle tentative suivants sont randInt(500ms, 500ms * 2^1)
, randInt(500ms, 500ms * 2^2)
... randInt(500ms, 500ms * 2^maxRetries)
.
Batch
Plusieurs destinations dans l’étape de sortie vous permettent de traiter les messages par lots avant qu’ils n’écrivent dans la destination. Ces destinations utilisent lot pour définir les paramètres de traitement par lots.
Actuellement, vous pouvez définir lot en fonction du temps. Pour définir le traitement par lots, vous devez spécifier l’intervalle de temps et un chemin d’accès. Path
définit la partie du message entrant à inclure dans la sortie par lots.
Champ | Type | Description | Obligatoire | Par défaut | Exemple |
---|---|---|---|---|---|
Heure | Durée | Durée de traitement par lots des données | Non | 60s (Dans les destinations où le traitement par lots est appliqué) |
120s |
Chemin d’accès | Chemin d’accès | Chemin d’accès à la valeur dans chaque message à inclure dans la sortie. | Non | .payload |
.payload.output |