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.
# Ingestion de journaux via des points de terminaison HTTP
Amazon CloudWatch Logs fournit des points de terminaison HTTP qui vous permettent d'envoyer des journaux directement à CloudWatch Logs à l'aide de simples requêtes HTTP POST. Ces points de terminaison prennent en charge à la fois l'authentification SigV4 et l'authentification par jeton porteur.
**Important**
Nous recommandons d'utiliser l'authentification SigV4 pour toutes les charges de travail de production où l'intégration du AWS SDK est possible. Le SigV4 utilise des informations d'identification à court terme et fournit la meilleure posture de sécurité. L'authentification par jeton porteur (clé API) est destinée aux scénarios dans lesquels SigV4 n'est pas réalisable, tels que les redirecteurs de journaux tiers qui ne prennent pas en charge AWS l'intégration du SDK. Pour plus d'informations, consultez la section [Alternatives aux clés d'accès longue durée](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles) dans le *guide de l'utilisateur IAM*.
CloudWatch Logs prend en charge les points de terminaison d'ingestion HTTP suivants :
| Endpoint | Chemin | Content-Type | Format |
| --- | --- | --- | --- |
| [OpenTelemetry Logs](CWL_HTTP_Endpoints_OTLP.md) | /v1/logs | application/json ou application/x-protobuf | OTLP JSON ou Protobuf |
| [HLC Logs](CWL_HLC_Endpoint.md) | /services/collector/event | application/json | Format HLC |
| [ND-JSON Logs](CWL_HTTP_Endpoints_NDJSON.md) | /ingest/bulk | application/json ou application/x-ndjson | JSON délimité par un caractère de saut de ligne |
| [Structured JSON Logs](CWL_HTTP_Endpoints_StructuredJSON.md) | /ingest/json | application/json | Objet ou tableau JSON |
## Comportement courant
Tous les points de terminaison d'ingestion HTTP partagent le comportement suivant :
**Authentification**
Tous les points de terminaison prennent en charge à la fois l'authentification SigV4 et l'authentification par jeton porteur :
+ **SigV4 (recommandé)** — AWS Signature standard version 4. Utilisez SigV4 chaque fois que votre application ou infrastructure prend en charge le AWS SDK ou peut signer des demandes. SigV4 utilise des informations d'identification à court terme et constitue la méthode d'authentification la plus sécurisée.
+ **Jeton porteur** — Utilisez l'`Authorization: Bearer `en-tête.
+ Le jeton doit être un jeton porteur ACWL valide. Pour les instructions de configuration, voir[Configuration de l'authentification par jeton porteur](CWL_HTTP_Endpoints_BearerTokenAuth.md).
+ Nécessite les autorisations `logs:PutLogEvents` et `logs:CallWithBearerToken` IAM.
**Groupe de journaux et flux de journaux**
+ Fourni via des en-têtes : `x-aws-log-group` et `x-aws-log-stream`
+ `?logGroup=&logStream=`Les paramètres de requête sont également pris en charge sur tous les points de terminaison, à l'exception de l'OTLP.
+ Vous ne pouvez pas utiliser à la fois les paramètres de requête et les en-têtes pour le même paramètre.
+ Le groupe de journaux et le flux de journaux sont requis.
**Réponse**
+ Succès : `HTTP 200` avec le corps `{}`
+ Erreurs de validation : `HTTP 400`
+ Défaillances d'authentification : `HTTP 401`
# Configuration de l'authentification par jeton porteur
Avant de pouvoir envoyer des journaux à l'aide de l'authentification par jeton porteur avec l'un des points de terminaison d'ingestion HTTP, vous devez :
+ Création d'un utilisateur IAM avec des autorisations CloudWatch Logs
+ Générer des informations d'identification spécifiques au service (jeton porteur)
+ Création d'un groupe de journaux et d'un flux de journaux
+ Activer l'authentification par jeton porteur sur le groupe de journaux
**Important**
Nous recommandons d'utiliser l'authentification SigV4 avec des informations d'identification à court terme pour toutes les charges de travail lorsque cela est possible. Le SigV4 fournit la meilleure posture de sécurité. Limitez l'utilisation de clés d'API (jetons porteurs) aux scénarios dans lesquels l'authentification à court terme basée sur les informations d'identification n'est pas possible. Lorsque vous êtes prêt à intégrer les CloudWatch journaux dans des applications présentant des exigences de sécurité plus strictes, vous devez passer aux informations d'identification à court terme. Pour plus d'informations, consultez la section [Alternatives aux clés d'accès longue durée](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles) dans le *guide de l'utilisateur IAM*.
## Option 1 : démarrage rapide à l'aide de la AWS console
La console AWS de gestion fournit un flux de travail rationalisé pour générer des clés d'API pour l'accès aux points de terminaison HTTP.
**Pour configurer l'accès au point de terminaison HTTP à l'aide de la console**
1. Connectez-vous à la console AWS de gestion.
1. Accédez à **CloudWatch**> **Paramètres** > **Journaux**.
1. Dans la section Clés d'API, choisissez **Générer une clé d'API**.
1. Pour **Epiration de la clé d’API**, effectuez l’une des actions suivantes :
+ Sélectionnez une durée d'expiration de la clé d'API de **1**, **5**, **30**, **90** ou **365** jours.
+ Choisissez **Durée personnalisée** pour spécifier une date d’expiration personnalisée pour la clé d’API.
+ Sélectionnez **Ne jamais expirer** (non recommandé).
1. Choisissez **Générer une clé d’API**.
La console :
+ Crée un nouvel utilisateur IAM doté des autorisations appropriées
+ Joint la politique [CloudWatchLogsAPIKeyd'accès](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLogsAPIKeyAccess.html) géré (`logs:PutLogEvents`inclusions et `logs:CallWithBearerToken` autorisations)
+ Génère des informations d'identification spécifiques au service (clé API)
1. Copiez et enregistrez en toute sécurité les informations d'identification affichées :
+ ID de **clé d'API (ID** d'identification spécifique au service)
+ **Secret de la clé API** (jeton porteur)
**Important**
Enregistrez immédiatement le secret de la clé API. Vous ne pourrez pas la récupérer ultérieurement. Si vous la perdez, vous devrez générer une nouvelle clé d'API.
1. Créez le groupe de journaux et le flux de journaux dans lesquels vos journaux seront stockés :
```
# Create the log group
aws logs create-log-group \
--log-group-name /aws/hlc-logs/my-application \
--region us-east-1
# Create the log stream
aws logs create-log-stream \
--log-group-name /aws/hlc-logs/my-application \
--log-stream-name application-stream-001 \
--region us-east-1
```
1. Activez l'authentification par jeton porteur sur le groupe de journaux :
```
aws logs put-bearer-token-authentication \
--log-group-identifier /aws/hlc-logs/my-application \
--bearer-token-authentication-enabled \
--region us-east-1
```
Vérifiez la configuration :
```
aws logs describe-log-groups \
--log-group-name-prefix /aws/hlc-logs/my-application \
--region us-east-1
```
**Autorisations incluses :** L'utilisateur IAM créé automatiquement disposera des autorisations suivantes :
+ `logs:PutLogEvents`— Envoie les événements du journal à CloudWatch Logs
+ `logs:CallWithBearerToken`— Authentifiez-vous à l'aide d'un jeton porteur
+ `kms:Describe*`,`kms:GenerateDataKey*`, `kms:Decrypt` — Accédez à des groupes de journaux chiffrés par KMS (avec une condition se limitant au service de journaux)
## Option 2 : Configuration manuelle
Si vous préférez mieux contrôler la configuration IAM ou si vous avez besoin de personnaliser les autorisations, vous pouvez configurer manuellement l'accès au point de terminaison HTTP.
### Étape 1 : créer un utilisateur IAM
Créez un utilisateur IAM qui sera utilisé pour l'ingestion des journaux :
1. Connectez-vous à la console AWS de gestion et accédez à IAM.
1. Dans le volet de navigation de gauche, choisissez **Utilisateurs**.
1. Choisissez **Create user (Créer un utilisateur)**.
1. Entrez un nom d'utilisateur (par exemple,`cloudwatch-logs-hlc-user`).
1. Choisissez **Suivant**.
1. Joignez l'une des politiques IAM suivantes :
**Option A : utiliser la politique gérée (recommandée)**
Joignez la politique de gestion des [CloudWatchLogsAPIKeyaccès](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLogsAPIKeyAccess.html).
**Option B : créer une politique personnalisée**
Créez et attachez la politique IAM suivante :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "LogsAPIs",
"Effect": "Allow",
"Action": [
"logs:CallWithBearerToken",
"logs:PutLogEvents"
],
"Resource": "*"
},
{
"Sid": "KMSAPIs",
"Effect": "Allow",
"Action": [
"kms:Describe*",
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Condition": {
"StringEquals": {
"kms:ViaService": [
"logs.*.amazonaws.com"
]
}
},
"Resource": "arn:aws:kms:*:*:key/*"
}
]
}
```
1. Choisissez **Suivant**, puis **Créer un utilisateur**.
**Note**
Les autorisations KMS sont requises si vous prévoyez d'envoyer des journaux à des groupes de journaux chiffrés par KMS. La condition limite l'accès KMS aux seules clés utilisées via le service CloudWatch Logs.
### Étape 2 : générer des informations d'identification spécifiques au service (clé API)
Générez la clé CloudWatch d'API Logs à l'aide de l'[CreateServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html)API. Vous pouvez également utiliser la commande [create-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-service-specific-credential.html)CLI. Pour l'âge des informations d'identification, vous pouvez spécifier une valeur comprise entre 1 et 36 600 jours. Si vous ne spécifiez pas de durée de validité, la clé d’API n’expirera pas.
Pour générer une clé d'API dont l'expiration est de 30 jours, procédez comme suit :
```
aws iam create-service-specific-credential \
--user-name cloudwatch-logs-hlc-user \
--service-name logs.amazonaws.com \
--credential-age-days 30
```
La réponse est un [ServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ServiceSpecificCredential.html)objet. La `ServiceCredentialSecret` valeur est votre clé CloudWatch d'API Logs (jeton porteur).
**Important**
Stockez la valeur `ServiceCredentialSecret` en toute sécurité, car vous ne pourrez pas la récupérer ultérieurement. Si vous la perdez, vous devrez générer une nouvelle clé d'API.
### Étape 3 : créer un groupe de journaux et un flux de journaux
Créez le groupe de journaux et le flux de journaux dans lesquels vos journaux seront stockés :
```
# Create the log group
aws logs create-log-group \
--log-group-name /aws/hlc-logs/my-application \
--region us-east-1
# Create the log stream
aws logs create-log-stream \
--log-group-name /aws/hlc-logs/my-application \
--log-stream-name application-stream-001 \
--region us-east-1
```
### Étape 4 : activer l'authentification par jeton porteur
Activez l'authentification par jeton porteur sur le groupe de journaux :
```
aws logs put-bearer-token-authentication \
--log-group-identifier /aws/hlc-logs/my-application \
--bearer-token-authentication-enabled \
--region us-east-1
```
Vérifiez la configuration :
```
aws logs describe-log-groups \
--log-group-name-prefix /aws/hlc-logs/my-application \
--region us-east-1
```
## Autorisations de contrôle pour la génération et l'utilisation CloudWatch des clés d'API Logs
La génération et l'utilisation des clés d'API CloudWatch Logs sont contrôlées par des actions et des clés de condition dans les services CloudWatch Logs et IAM.
### Contrôle de la génération des clés d'API CloudWatch Logs
L'CreateServiceSpecificCredentialaction [iam :](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html#awsidentityandaccessmanagementiam-actions-as-permissions) contrôle la génération d'une clé spécifique au service (telle qu'une clé d'API CloudWatch Logs). Vous pouvez étendre cette action aux utilisateurs IAM en tant que ressource afin de limiter le nombre d’utilisateurs pour lesquels une clé peut être générée.
Vous pouvez utilisez les clés de condition suivantes pour imposer des conditions à l’autorisation pour l’action `iam:CreateServiceSpecificCredential` :
+ [iam : ServiceSpecificCredentialAgeDays](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_ServiceSpecificCredentialAgeDays) — Permet de spécifier, dans la condition, le délai d'expiration de la clé en jours. Par exemple, vous pouvez utiliser cette clé de condition pour autoriser uniquement des clés API qui expirent au terme d’un délai de 90 jours.
+ [iam : ServiceSpecificCredentialServiceName](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_ServiceSpecificCredentialAgeDays) — Permet de spécifier, dans la condition, le nom d'un service. Par exemple, vous pouvez utiliser cette clé de condition pour autoriser uniquement la création de clés d'API pour les CloudWatch journaux et non pour d'autres services.
### Contrôle de l'utilisation des clés d'API CloudWatch Logs
L'`logs:CallWithBearerToken`action contrôle l'utilisation d'une clé d'API CloudWatch Logs. Pour empêcher une identité d'utiliser CloudWatch les clés de l'API Logs, associez une politique qui refuse l'`logs:CallWithBearerToken`action à l'utilisateur IAM associé à la clé.
### Exemples de politiques
#### Empêcher une identité de générer et d'utiliser CloudWatch les clés d'API Logs
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCWLAPIKeys",
"Effect": "Deny",
"Action": [
"iam:CreateServiceSpecificCredential",
"logs:CallWithBearerToken"
],
"Resource": "*"
}
]
}
```
**Avertissement**
Cette politique empêchera la création d'informations d'identification pour tous les AWS services qui prennent en charge la création d'informations d'identification spécifiques à un service. Pour plus d’informations, consultez [Informations d’identification spécifiques au service pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_service-specific-creds.html).
#### Empêcher une identité d'utiliser CloudWatch les clés de l'API Logs
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "logs:CallWithBearerToken",
"Resource": "*"
}
]
}
```
#### Autoriser la création de clés CloudWatch Logs uniquement si elles expirent dans les 90 jours
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateServiceSpecificCredential",
"Resource": "arn:aws:iam::123456789012:user/username",
"Condition": {
"StringEquals": {
"iam:ServiceSpecificCredentialServiceName": "logs.amazonaws.com"
},
"NumericLessThanEquals": {
"iam:ServiceSpecificCredentialAgeDays": "90"
}
}
}
]
}
```
## Rotation des clés API
La rotation régulière de vos clés d'API réduit le risque d'accès non autorisé. Nous vous recommandons d'établir un calendrier de rotation conforme aux politiques de sécurité de votre organisation.
### Processus de rotation
Pour faire pivoter une clé d'API sans interrompre la livraison du journal, procédez comme suit :
1. Créez un nouvel identifiant (secondaire) pour l'utilisateur IAM :
```
aws iam create-service-specific-credential \
--user-name cloudwatch-logs-hlc-user \
--service-name logs.amazonaws.com \
--credential-age-days 90
```
1. (Facultatif) Stockez les nouvelles informations d'identification AWS Secrets Manager pour une récupération sécurisée et une rotation automatique.
1. Importez les nouvelles informations d'identification dans le portail de votre fournisseur ou mettez à jour la configuration de votre application pour utiliser la nouvelle clé d'API.
1. Définissez les informations d'identification d'origine sur inactive :
```
aws iam update-service-specific-credential \
--user-name cloudwatch-logs-hlc-user \
--service-specific-credential-id ACCA1234EXAMPLE1234 \
--status Inactive
```
1. Vérifiez que la livraison des journaux n'est pas affectée en surveillant la `IncomingBytes` métrique relative à votre groupe de connexions CloudWatch. Pour plus d'informations, consultez la section [Surveillance à l'aide de CloudWatch métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch-Logs-Monitoring-CloudWatch-Metrics.html).
1. Après avoir confirmé la livraison réussie avec la nouvelle clé, supprimez les informations d'identification précédentes :
```
aws iam delete-service-specific-credential \
--service-specific-credential-id ACCA1234EXAMPLE1234
```
### Surveillance de l'expiration des clés
Pour vérifier la date de création et le statut de vos clés d'API existantes, utilisez la [list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html)commande :
```
aws iam list-service-specific-credentials \
--user-name cloudwatch-logs-hlc-user \
--service-name logs.amazonaws.com
```
La réponse inclut `CreateDate` et `Status` pour chaque identifiant. Utilisez ces informations pour identifier les clés qui arrivent à expiration ou qui sont actives depuis plus longtemps que ne le permet votre politique de rotation.
## Répondre à une clé d'API compromise
Si vous pensez qu'une clé d'API a été compromise, prenez immédiatement les mesures suivantes :
1. **Désactivez immédiatement la clé** pour empêcher toute nouvelle utilisation non autorisée :
```
aws iam update-service-specific-credential \
--user-name cloudwatch-logs-hlc-user \
--service-specific-credential-id ACCA1234EXAMPLE1234 \
--status Inactive
```
1. Passez en **revue les CloudTrail journaux** pour déterminer l'étendue des accès non autorisés. Découvrez [Enregistrement de l'utilisation des clés d'API avec CloudTrail](#CWL_HTTP_Endpoints_CloudTrail_Logging) comment activer l'audit de l'utilisation des clés d'API.
1. **Créez une clé de remplacement** en suivant le processus de rotation décrit dans[Processus de rotation](#CWL_HTTP_Endpoints_Rotation_Process).
1. **Supprimez la clé compromise** une fois que la clé de remplacement est en place :
```
aws iam delete-service-specific-credential \
--service-specific-credential-id ACCA1234EXAMPLE1234
```
1. **Ajoutez une politique de refus** si vous devez immédiatement bloquer l'accès à tout jeton porteur pour l'utilisateur IAM pendant que vous étudiez :
```
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "logs:CallWithBearerToken",
"Resource": "*"
}
}
```
**Note**
Pour effectuer ces actions via l'API, vous devez vous authentifier à l'aide AWS d'informations d'identification et non à l'aide d'une clé d'API CloudWatch Logs.
Vous pouvez également utiliser les opérations d'API IAM suivantes pour gérer les clés compromises :
+ [ResetServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html)— Réinitialisez la clé pour générer un nouveau mot de passe sans supprimer les informations d'identification. La clé ne doit pas avoir expiré.
## Bonnes pratiques de sécurité pour les clés d'API
Suivez ces bonnes pratiques pour protéger vos clés CloudWatch d'API Logs :
+ **N'intégrez jamais de clés d'API dans le code source.** Ne codez pas en dur les clés d'API dans le code de l'application et ne les validez pas dans les systèmes de contrôle de version. Si une clé est accidentellement validée dans un dépôt public, le scan AWS automatique peut la signaler et vous devez immédiatement faire pivoter la clé.
+ **Utilisez un gestionnaire de secrets.** Stockez les clés d'API dans une solution de gestion des secrets [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)ou dans une solution équivalente. Cela permet un contrôle d'accès centralisé, un enregistrement des audits et une rotation automatique.
+ **Définissez une date d'expiration pour toutes les clés.** Spécifiez toujours une `--credential-age-days` valeur lors de la création de clés d'API. Pour appliquer une durée de vie maximale des clés au sein de votre organisation, utilisez la clé de condition `iam:ServiceSpecificCredentialAgeDays` IAM. Pour obtenir un exemple, consultez [Autoriser la création de clés CloudWatch Logs uniquement si elles expirent dans les 90 jours](#CWL_HTTP_Endpoints_Allow_Expire_90).
+ **Appliquez les autorisations du moindre privilège.** Étendez les autorisations de l'utilisateur IAM uniquement aux groupes de journaux et aux actions requises. Utilisez la politique [CloudWatchLogsAPIKeyd'accès](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLogsAPIKeyAccess.html) géré comme point de départ et limitez davantage selon les besoins.
+ **Activez la CloudTrail journalisation.** Auditez l'utilisation des clés d'API en activant CloudTrail les événements de données pour`AWS::Logs::LogGroupAuthorization`. Consultez [Enregistrement de l'utilisation des clés d'API avec CloudTrail](#CWL_HTTP_Endpoints_CloudTrail_Logging).
+ **Surveillez avec IAM Access Analyzer.** Utilisez [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) pour identifier les informations d'identification non utilisées et les politiques trop permissives associées aux utilisateurs IAM de votre clé d'API.
+ **Faites pivoter les touches régulièrement.** Établissez un calendrier de rotation et suivez le processus décrit dans[Rotation des clés API](#CWL_HTTP_Endpoints_Rotating_Keys).
## Enregistrement de l'utilisation des clés d'API avec CloudTrail
Vous pouvez l'utiliser AWS CloudTrail pour enregistrer les événements de données liés à l'utilisation des clés de l'API CloudWatch Logs. CloudWatch Logs émet `AWS::Logs::LogGroupAuthorization` des événements de données pour les `CallWithBearerToken` appels, ce qui vous permet de vérifier quand et comment les clés d'API sont utilisées pour envoyer des journaux.
Pour activer la CloudTrail journalisation pour l'utilisation des clés de l'API CloudWatch Logs :
**Note**
Le compartiment S3 que vous spécifiez pour le suivi doit disposer d'une politique de compartiment qui CloudTrail permet d'y écrire des fichiers journaux. Pour plus d'informations, consultez la [politique relative aux compartiments Amazon S3 pour CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-s3-bucket-policy-for-cloudtrail.html).
1. Créez un parcours :
```
aws cloudtrail create-trail \
--name cloudwatch-logs-api-key-audit \
--s3-bucket-name my-cloudtrail-bucket \
--region us-east-1
```
1. Configurez des sélecteurs d'événements avancés pour capturer CloudWatch les événements d'autorisation des groupes de journaux journaux :
```
aws cloudtrail put-event-selectors \
--region us-east-1 \
--trail-name cloudwatch-logs-api-key-audit \
--advanced-event-selectors '[{
"Name": "CloudWatch Logs API key authorization events",
"FieldSelectors": [
{ "Field": "eventCategory", "Equals": ["Data"] },
{ "Field": "resources.type", "Equals": ["AWS::Logs::LogGroupAuthorization"] }
]
}]'
```
1. Commencez à enregistrer les sentiers :
```
aws cloudtrail start-logging \
--name cloudwatch-logs-api-key-audit \
--region us-east-1
```
# Envoi de journaux à l'aide du point de terminaison OTLP (OpenTelemetry Logs)
Le point de terminaison OpenTelemetry Logs (`/v1/logs`) accepte les données du journal OpenTelemetry du protocole (OTLP) au format JSON ou Protobuf. Pour obtenir des informations détaillées sur le point de terminaison OTLP, notamment sa configuration et son utilisation, voir [Envoyer des métriques et des traces à CloudWatch with OpenTelemetry](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-OTLPEndpoint.html).
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
+ Méthode : `POST`
+ Type de contenu : ou `application/json` `application/x-protobuf`
+ Groupe de journaux : `x-aws-log-group` en-tête uniquement (paramètre de requête non pris en charge)
+ Flux du journal : `x-aws-log-stream` en-tête
## Exemple de demande
```
curl -X POST "https://logs..amazonaws.com/v1/logs" \
-H "Authorization: Bearer ACWL" \
-H "Content-Type: application/json" \
-H "x-aws-log-group: MyLogGroup" \
-H "x-aws-log-stream: MyLogStream" \
-d '{
"resourceLogs": [
{
"resource": {
"attributes": [
{
"key": "service.name",
"value": { "stringValue": "my-service" }
}
]
},
"scopeLogs": [
{
"scope": {
"name": "my-library",
"version": "1.0.0"
},
"logRecords": [
{
"timeUnixNano": "1741900000000000000",
"severityNumber": 9,
"severityText": "INFO",
"body": {
"stringValue": "User logged in successfully"
},
"attributes": [
{
"key": "user.id",
"value": { "stringValue": "12345" }
}
]
}
]
}
]
}
]
}'
```
## 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}"
}
}
```
Lorsque le type de contenu de la demande est défini`application/x-protobuf`, la réponse est renvoyée sous forme de message `ExportLogsServiceResponse` protobuf sérialisé avec les mêmes champs.
## Comportements spécifiques à l'OTLP
Les comportements suivants sont spécifiques au point de terminaison OTLP et ne sont pas présents sur les autres points de terminaison d'ingestion HTTP :
+ **En-tête Retry-After** : inclus dans les réponses 503 et 429 pour indiquer à quel moment le client doit réessayer.
# Envoi de journaux à l'aide du point de terminaison HLC (HLC Logs)
Le point de terminaison HLC Logs (`/services/collector/event`) est basé sur le format HTTP Log Collector (HLC).
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.
## Modes d'entrée
Chaque événement est un objet JSON avec un `"event"` champ obligatoire. Champs de métadonnées facultatifs : `"time"``"host"`,`"source"`,`"sourcetype"`,,`"index"`.
**Événement unique :**
```
{"event":"Hello world!","time":1486683865.0}
```
**Tableau d'événements JSON :**
```
[
{"event":"msg1","time":1486683865.0},
{"event":"msg2","time":1486683866.0}
]
```
**Événements concaténés/groupés (aucun encapsuleur de tableau) :**
```
{"event":"msg1","time":1486683865.0}{"event":"msg2","time":1486683866.0}
```
## Champ de l'événement (obligatoire)
Ce `"event"` champ est obligatoire. Sa valeur peut être de n'importe quel type JSON :
```
{"event":"a string message"}
{"event":{"message":"structured data","severity":"INFO"}}
{"event":42}
{"event":true}
```
Les objets sans `"event"` champ sont ignorés en silence :
```
{"message":"this is skipped — no event field"}
```
## Champ horaire (facultatif)
Le `"time"` champ est exprimé en secondes d'époque (et non en millisecondes), avec une décimale facultative pour une précision inférieure à la seconde.
| Format | Exemple | Interprété comme |
| --- | --- | --- |
| Float | "time":1486683865.500 | 1486683865500 ms |
| Entier | "time":1486683865 | 1486683865000 ms |
| Chaîne (flottante) | "time":"1486683865.500" | 1486683865500 ms |
| Chaîne (entier) | "time":"1486683865" | 1486683865000 ms |
| Manquant | (aucun champ horaire) | Heure actuelle du serveur |
| Non valide | "time":"invalid" | Heure actuelle du serveur |
## Content-Type
Seul `application/json` est accepté.
## Types de valeurs JSON acceptés
| Type de haut niveau | Comportement |
| --- | --- |
| Objet avec "event" | Acceptée |
| Objet sans "event" | Ignoré |
| Tableau d’objets | Chaque élément est traité individuellement |
| Objets concaténés | Chaque objet est traité individuellement |
| Primitif (chaîne, nombre, booléen, nul) | Ignoré |
## Format du point de terminaison
L'URL du point de terminaison HLC suit le format suivant :
```
https://logs..amazonaws.com/services/collector/event?logGroup=&logStream=[&entityName=&entityEnvironment=]
```
**Paramètres requis :**
+ ``— AWS Région (par exemple`us-east-1`,`eu-west-1`)
+ `logGroup`— Nom du groupe de logs codé en URL
+ `logStream`— Nom du flux de journal codé en URL
**Paramètres facultatifs :**
Vous pouvez éventuellement associer les événements de votre journal à une `Service` entité en incluant les paramètres de requête suivants. Les journaux envoyés via le point de terminaison HLC étant de la télémétrie personnalisée, ils ne sont pas automatiquement associés à une entité. En fournissant ces paramètres, CloudWatch Logs crée une entité `KeyAttributes.Type` définie sur `Service` et l'associe à vos événements de journal. Cela permet à la fonctionnalité **associée CloudWatch à Explore** de corréler ces journaux avec d'autres données de télémétrie (métriques, traces et journaux) du même service, ce qui facilite le dépannage et la surveillance de vos applications sur différents types de signaux. Pour plus d'informations sur les entités et la télémétrie associée, voir [Ajout d'informations connexes à la télémétrie personnalisée](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/adding-your-own-related-telemetry.html).
+ `entityName`— Nom de l'entité de service à associer aux événements du journal. Cette valeur est stockée en tant qu'entité `KeyAttributes.Name` (par exemple, `my-application` ou`api.myservice.com`).
+ `entityEnvironment`— L'environnement dans lequel le service est hébergé ou à quoi il appartient. Cette valeur est stockée en tant qu'entité `KeyAttributes.Environment` (par exemple`production`,`ec2:default`, ou`eks:my-cluster/default`).
## Format des demandes
Envoyez les journaux à l'aide du protocole HTTP POST avec les en-têtes et le corps suivants :
**En-têtes :**
+ `Authorization: Bearer `
+ `Content-Type: application/json`
**Format du boîtier :**
Le corps de la requête doit être au format JSON avec un tableau d'événements :
```
{
"event": [
{
"time": 1730141374.001,
"event": "Application started successfully",
"host": "web-server-1",
"source": "application.log",
"severity": "info"
},
{
"time": 1730141374.457,
"event": "User login successful",
"host": "web-server-1",
"source": "auth.log",
"user": "john.doe"
}
]
}
```
**Descriptions des champs :**
+ `time`— Horodatage de l'époque Unix en secondes, avec décimal optionnel pour une précision inférieure à la seconde (facultatif)
+ `event`— Le message du journal ou les données de l'événement (obligatoire)
+ `host`— Nom d'hôte ou identifiant source (facultatif)
+ `source`— Identifiant de la source du journal (facultatif)
Des champs personnalisés supplémentaires peuvent être inclus selon les besoins.
## Exemple de demande
```
curl -X POST "https://logs..amazonaws.com/services/collector/event?logGroup=MyLogGroup&logStream=MyStream" \
-H "Authorization: Bearer ACWL" \
-H "Content-Type: application/json" \
-d '{"event":{"message":"User logged in","user_id":"u-123"},"time":1486683865.0,"host":"web-01","source":"auth-service"}'
```
## 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
Implémentez 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.
# 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.
# Envoi de journaux à l'aide du point de terminaison JSON structuré (journaux JSON structurés)
Le point de terminaison Structured JSON Logs (`/ingest/json`) accepte le JSON standard, qu'il s'agisse d'un seul objet JSON ou d'un tableau d'objets JSON. Ce point de terminaison est conçu pour les données de journal structurées où chaque événement est un objet JSON.
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
Seul `application/json` est accepté comme type de contenu.
**Objet JSON unique :**
```
{"timestamp":1771007942000,"message":"single event","level":"INFO"}
```
**Tableau d'objets JSON :**
```
[
{"timestamp":1771007942000,"message":"event one","level":"INFO"},
{"timestamp":1771007943000,"message":"event two","level":"ERROR"}
]
```
## Types de valeurs JSON acceptés
Ce point de terminaison est strict : seuls les objets JSON sont acceptés en tant qu'événements.
| Input | Comportement |
| --- | --- |
| Objet JSON unique | Accepté comme un seul événement |
| Tableau d'objets JSON | Chaque objet devient un événement distinct |
| Tableau vide [] | Accepté, produit 0 événements |
| Non-objet dans le tableau (chaîne, nombre, etc.) | Ignoré |
| Primitive de haut niveau ("hello",42) | Ignoré |
| Objets concaténés \$1...\$1\$1...\$1 | Seul le premier objet est analysé |
**Exemple — tableau de types mixtes :**
```
[
{"timestamp":1771007942000,"message":"valid object"},
"just a string",
42,
{"timestamp":1771007943000,"message":"another valid object"}
]
```
Résultat : 2 événements ingérés (les objets), 2 ignorés (la chaîne et le chiffre).
## Champ d'horodatage
Le `"timestamp"` champ est exprimé en millisecondes d'époque, comme le point de terminaison NDJSON.
| 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 |
## Exemple de demande
```
curl -X POST "https://logs..amazonaws.com/ingest/json?logGroup=MyLogGroup&logStream=MyStream" \
-H "Authorization: Bearer ACWL" \
-H "Content-Type: application/json" \
-d '[{"timestamp":1771007942000,"message":"User logged in","user_id":"u-123"},{"timestamp":1771007943000,"message":"Order placed","order_id":"o-456"}]'
```
## 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
Implémentez 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.
## Comparaison des points de terminaison d'ingestion HTTP
| Fonctionnalité | Journaux HLC | Journaux ND-JSON | Journaux JSON structurés | OpenTelemetry Journaux |
| --- | --- | --- | --- | --- |
| Chemin | /services/collector/event | /ingest/bulk | /ingest/json | /v1/logs |
| Content-Type | application/json | application/json ou application/x-ndjson | application/json | application/json ou application/x-protobuf |
| Champ d'horodatage | "time"(secondes) | "timestamp"(millisecondes) | "timestamp"(millisecondes) | "timeUnixNano"(nanosecondes) |
| Champs obligatoires | "event" | Aucune | Aucune | Structure OTLP () "resourceLogs" |
| Réponse de réussite partielle | Non | Oui | Oui | Oui |
| Support des paramètres de requête | Oui | Oui | Oui | Non (en-têtes uniquement) |
| Métadonnées de l'entité | Oui | Oui | Oui | Non |
| Accepte les primitives | Non | Oui | Non | Non |
| Analyse syntaxique basée sur les lignes | Non | Oui | Non | Non |
| Support Protobuf | Non | Non | Non | Oui |
| En-tête Retry-After | Non | Non | Non | Oui |
## Choix d'un point de terminaison
+ **Vous utilisez le format HLC ?** Utilisez les journaux HLC. Vos charges utiles HLC existantes fonctionnent avec un minimum de modifications.
+ **Des line-by-line journaux de streaming ?** Utilisez les journaux ND-JSON. Idéal pour les pipelines de logs qui émettent un événement par ligne. Très flexible : accepte n'importe quel type de valeur JSON.
+ **Vous envoyez des charges utiles JSON structurées ?** Utilisez des journaux JSON structurés. Idéal pour les applications qui produisent des objets ou des tableaux JSON bien formés.
+ **Vous l'utilisez déjà OpenTelemetry ?** Utilisez OpenTelemetry les journaux. Accepte le format OTLP JSON ou Protobuf et prend en charge les réponses de réussite partielles avec une sémantique de nouvelle tentative.