Ce produit n'est pas pris en charge par le
site Datadog que vous avez sélectionné. (
).
Aperçu
Utilisez le Worker des Pipelines d’Observabilité pour envoyer vos journaux et métriques traités (Aperçu) vers différentes destinations. La plupart des destinations des Pipelines d’Observabilité envoient des événements par lots à l’intégration en aval. Voir Regroupement d’événements pour plus d’informations. Certaines destinations des Pipelines d’Observabilité ont également des champs qui supportent la syntaxe de modèle, vous pouvez donc définir ces champs en fonction de champs spécifiques. Voir Syntaxe de modèle pour plus d’informations.
Sélectionnez une destination dans le menu de navigation à gauche pour voir plus d’informations à son sujet.
Destinations
Voici les destinations disponibles :
Syntaxe de modèle
Les journaux sont souvent stockés dans des index séparés en fonction des données de journal, telles que le service ou l’environnement d’où proviennent les journaux ou un autre attribut de journal. Dans les Pipelines d’Observabilité, vous pouvez utiliser la syntaxe de modèle pour acheminer vos journaux vers différents index en fonction de champs de journal spécifiques.
Lorsque le Worker des Pipelines d’Observabilité ne peut pas résoudre le champ avec la syntaxe de modèle, le Worker applique le comportement spécifié pour cette destination. Par exemple, si vous utilisez le modèle {{application_id}} for the Datadog Archives destination’s Prefix field, but there isn’t an application_id field in the log, the Worker creates a folder called OP_UNRESOLVED_TEMPLATE_LOGS/ et publie les journaux là-bas.
Le tableau suivant répertorie les destinations et les champs qui prennent en charge la syntaxe de modèle, ainsi que ce qui se passe lorsque le Worker ne peut pas résoudre le champ :
| Destination | Champs qui prennent en charge la syntaxe de modèle | Comportement lorsque le champ ne peut pas être résolu |
|---|
| Amazon Opensearch | Index | Le Worker écrit des journaux dans l’index datadog-op. |
| Datadog Archives | Préfixe | Le Worker crée un dossier nommé OP_UNRESOLVED_TEMPLATE_LOGS/ et y écrit les journaux. |
| Azure Blob | Préfixe | Le Worker crée un dossier nommé OP_UNRESOLVED_TEMPLATE_LOGS/ et y écrit les journaux. |
| Elasticsearch | Index | Le Worker écrit des journaux dans l’index datadog-op. |
| Google Chronicle | Type de journal | Par défaut, le type de journal est DATADOG. |
| Google Cloud | Préfixe | Le Worker crée un dossier nommé OP_UNRESOLVED_TEMPLATE_LOGS/ et y écrit les journaux. |
| Opensearch | Index | Le Worker écrit des journaux dans l’index datadog-op. |
| Splunk HEC | Index Type de source | Le Worker envoie les journaux à l’index par défaut configuré dans Splunk. Le Worker applique le type de source httpevent. |
Exemple
Si vous souhaitez acheminer les journaux en fonction du champ ID d’application du journal (par exemple, application_id) vers la destination Datadog Archives, utilisez la syntaxe des champs d’événements dans le champ Préfixe pour l’appliquer à toutes les clés d’objet.
Syntaxe
Champs d’événements
Utilisez {{ <field_name> }} pour accéder aux champs d’événements de journal individuels. Exemple :
Spécificateurs strftime
Utilisez les spécificateurs strftime pour la date et l’heure. Exemple :
Caractères d’échappement
Préfixez un caractère avec \ pour échapper au caractère. Cet exemple échappe à la syntaxe du champ d’événement :
Cet exemple échappe aux spécificateurs strftime :
year=\%Y/month=\%m/day=\%d/
Regroupement d’événements
Les destinations des Pipelines d’Observabilité envoient des événements par lots à l’intégration en aval. Un lot d’événements est vidé lorsque l’un des paramètres suivants est atteint :
- Nombre maximum d’événements
- Nombre maximum d’octets
- Délai d’attente (secondes)
Par exemple, si les paramètres d’une destination sont :
- Nombre maximum d’événements = 2
- Nombre maximum d’octets = 100 000
- Délai d’attente (secondes) = 5
Et si la destination reçoit 1 événement dans une fenêtre de 5 secondes, elle vide le lot au délai d’attente de 5 secondes.
Si la destination reçoit 3 événements en 2 secondes, elle vide un lot avec 2 événements puis vide un second lot avec l’événement restant après 5 secondes. Si la destination reçoit 1 événement qui dépasse 100 000 octets, elle vide ce lot avec 1 événement.
| Destination | Maximum Events | Maximum Size (MB) | Timeout (seconds) |
|---|
| Amazon OpenSearch | None | 10 | 1 |
| Amazon S3 (Datadog Log Archives) | None | 100 | 900 |
| Amazon Security Lake | None | 256 | 300 |
| Azure Storage (Datadog Log Archives) | None | 100 | 900 |
| CrowdStrike | None | 1 | 1 |
| Datadog BYOC Logs | 1,000 | 4.25 | 5 |
| Datadog Logs | 1,000 | 4.25 | 5 |
| Datadog Metrics | 100,000 | None | 2 |
| Elasticsearch | None | 10 | 1 |
| Google Chronicle | None | 1 | 15 |
| Google Cloud Storage (Datadog Log Archives) | None | 100 | 900 |
| Google Pub/Sub | 1,000 | 10 | 1 |
| HTTP Client | 1000 | 1 | 1 |
| Kafka | 10,000 | 1 | 1 |
| Microsoft Sentinel | None | 10 | 1 |
| New Relic | 100 | 1 | 1 |
| OpenSearch | None | 10 | 1 |
| SentinelOne | None | 1 | 1 |
| Socket* | N/A | N/A | N/A |
| Splunk HTTP Event Collector (HEC) | None | 1 | 1 |
| Sumo Logic Hosted Collector | None | 10 | 1 |
| Syslog* | N/A | N/A | N/A |
*Destination does not batch events.