Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Envoi de journaux à l'aide du point de terminaison NDJSON (journaux ND-JSON)
Le point de terminaison ND-JSON Logs (`/ingest/bulk`) accepte les journaux au format [NDJSON (Newline Delimited JSON)](https://github.com/ndjson/ndjson-spec). Chaque ligne contient exactement une valeur JSON, séparée par des caractères de nouvelle ligne.
Si vous utilisez l'authentification par jeton porteur, suivez les étapes de configuration décrites [Configuration de l'authentification par jeton porteur](CWL_HTTP_Endpoints_BearerTokenAuth.md) avant de continuer.
## Format des demandes
Envoyez une valeur JSON par ligne, séparée par `\n` (LF) ou `\r\n` (CRLF). Les lignes vides sont ignorées en silence.
```
{"timestamp":1771007942000,"message":"event one","level":"INFO"}
{"timestamp":1771007943000,"message":"event two","level":"ERROR"}
{"timestamp":1771007944000,"message":"event three","level":"DEBUG"}
```
Les deux `application/json` `application/x-ndjson` sont acceptés en tant que type de contenu.
## Types de valeurs JSON acceptés
Selon la spécification NDJSON (RFC 8259), toute valeur JSON valide est acceptée sur chaque ligne.
**Objets JSON (les plus courants) :**
```
{"timestamp":1771007942000,"message":"User logged in","service":"auth"}
{"timestamp":1771007943000,"error":"Connection timeout","service":"api"}
```
**Tableaux JSON (aplatis en événements individuels) :**
```
[{"timestamp":1000,"message":"a"},{"timestamp":2000,"message":"b"}]
```
Cette seule ligne produit 2 événements. Chaque élément du tableau devient un événement de journal distinct.
**Valeurs primitives :**
```
"a plain string log message"
42
true
null
```
Chaque primitive devient son propre événement avec l'horodatage actuel du serveur.
**Types mixtes :**
```
{"timestamp":1771007942000,"message":"structured event"}
"unstructured string message"
42
{"timestamp":1771007943000,"error":"something failed"}
```
Les 4 lignes sont acceptées comme des événements valides.
| Contenu de la ligne | Comportement |
| --- | --- |
| Objet JSON | Accepté, horodatage extrait s'il est présent |
| un tableau JSON | Aplati : chaque élément devient un événement distinct |
| Tableau vide [] | Accepté, produit 0 événements |
| chaîne JSON | Accepté comme message d'événement |
| Numéro JSON | Accepté comme message d'événement |
| booléen JSON | Accepté comme message d'événement |
| JSON nul | Accepté comme message d'événement |
| JSON non valide | Ignoré (compté, le traitement continue) |
| Ligne vide | Ignoré (non compté comme ignoré) |
## Champ d'horodatage
Le `"timestamp"` champ est exprimé en millisecondes d'époque (et non en secondes).
| Format | Exemple | Interprété comme |
| --- | --- | --- |
| Numérique (millis) | "timestamp":1771007942000 | 1771007942000 ms |
| Manquant | (aucun champ d'horodatage) | Heure actuelle du serveur |
| Non numérique | "timestamp":"invalid" | Heure actuelle du serveur |
| Ligne sans objet | "hello", 42, true | Heure actuelle du serveur |
## Lignes non valides
Les lignes qui ne sont pas des JSON valides sont ignorées et comptées en silence. Le traitement se poursuit avec la ligne suivante.
```
{"message":"valid event"}
this is not valid json
{"message":"another valid event"}
```
Résultat : 2 événements ingérés, 1 ignoré. Renvoie `HTTP 200`.
Si toutes les lignes ne sont pas valides, renvoie `HTTP 400` avec`"All events were invalid"`.
## Exemple de demande
```
curl -X POST "https://logs..amazonaws.com/ingest/bulk?logGroup=MyLogGroup&logStream=MyStream" \
-H "Authorization: Bearer ACWL" \
-H "Content-Type: application/x-ndjson" \
-d '{"timestamp":1771007942000,"message":"User logged in","level":"INFO"}
{"timestamp":1771007943000,"message":"Query took 42ms","level":"DEBUG"}
{"timestamp":1771007944000,"error":"Connection refused","level":"ERROR"}'
```
## Réponses
**Succès (tous les événements sont acceptés) :**
```
HTTP 200 OK
{}
```
**Succès partiel (certains événements rejetés) :**
```
{
"partialSuccess": {
"rejectedLogRecords": 5,
"errorMessage": "{\"tooOldLogEventCount\": 3, \"tooNewLogEventCount\": 1, \"expiredLogEventCount\": 1}"
}
}
```
Le `rejectedLogRecords` champ indique le nombre total d'événements rejetés. Le `errorMessage` champ contient une ventilation codée en JSON par motif de rejet :
+ `tooOldLogEventCount`— Événements dont l'horodatage est antérieur à la période de conservation
+ `tooNewLogEventCount`— Événements dont l'horodatage est trop lointain dans le futur
+ `expiredLogEventCount`— Événements qui ont expiré pendant le traitement
## Bonnes pratiques
### Événements de mise en lots
Pour de meilleures performances et une meilleure efficacité :
+ Batch de plusieurs événements en une seule demande lorsque cela est possible
+ Taille de lot recommandée : 10 à 100 événements par demande
+ Taille maximale de la demande : 1 Mo
### Gestion des erreurs
Mettez en œuvre une gestion appropriée des erreurs dans votre application. Codes d'état HTTP courants :
+ `200 OK`— Logs correctement ingérés
+ `400 Bad Request`— Format ou paramètres de demande non valides
+ `401 Unauthorized`— Jeton porteur non valide ou expiré
+ `403 Forbidden`— Autorisations insuffisantes
+ `404 Not Found`— Le groupe de journaux ou le flux n'existe pas
+ `429 Too Many Requests`— Limite de débit dépassée
+ `500 Internal Server Error`— Erreur de service (nouvelle tentative avec retard exponentiel)
## Limitations
+ Taille maximale de l'événement : 256 Ko par événement
+ Taille maximale de la demande : 1 Mo
+ Nombre maximum d'événements par demande : 10 000
+ Les noms des groupes de journaux doivent respecter les conventions de dénomination des CloudWatch journaux
+ L'authentification par jeton porteur doit être activée sur le groupe de journaux si l'authentification par jeton porteur est utilisée.