Skip to main content
Utilisez CloudFront Standard Logging v2 avec Amazon Data Firehose pour livrer un jeu de données de requêtes JSON minimal à Analytics des crawlers.

​
Avant de commencer

Il vous faut :
  • une distribution CloudFront qui sert le nom d’hôte configuré pour la marque Qwairy ;
  • l’autorisation de configurer Standard Logging v2, Firehose, IAM, CloudWatch et un bucket S3 de sauvegarde des échecs ;
  • un accès à Measure > Analytics des crawlers > Paramètres ;
  • un endroit sûr pour conserver le secret du connecteur, affiché une seule fois.
CloudFront exige que sa destination de livraison de logs Firehose soit dans us-east-1.

​
Créer et protéger la clé

  1. Dans les paramètres d’Analytics des crawlers, sélectionnez AWS CloudFront.
  2. Sélectionnez Créer une clé.
  3. Saisissez un nom et le fuseau horaire IANA utilisé pour les instantanés quotidiens.
  4. Copiez le secret lorsqu’il apparaît. Qwairy n’en affiche ensuite que le préfixe.
  5. Enregistrez-le comme clé d’accès du point de terminaison HTTP de Firehose. Ne l’ajoutez ni à une URL, ni à un dépôt de code, ni à un message de log CloudWatch.
Pour renouveler la clé, créez une clé de remplacement, mettez à jour Firehose, confirmez la livraison, puis supprimez l’ancienne clé. Une intégration peut avoir jusqu’à cinq clés actives.

​
Configurer Firehose

  1. Dans us-east-1, créez un flux de livraison Amazon Data Firehose avec une destination HTTP endpoint.
  2. Définissez l’URL du point de terminaison sur :
  3. Utilisez le secret du connecteur Qwairy comme Access key de Firehose. Firehose ajoute l’en-tête X-Amz-Firehose-Access-Key requis.
  4. Définissez la taille du buffer HTTP sur 1 MiB et l’intervalle sur 60 secondes. Ce connecteur ne prend pas en charge des intervalles de livraison plus courts.
  5. Activez la sauvegarde S3 des livraisons HTTP en échec et la journalisation des erreurs Firehose dans CloudWatch.
  6. Donnez au rôle Firehose l’accès au bucket de sauvegarde et aux ressources de logs requises.

​
Configurer Standard Logging v2

  1. Dans CloudFront, créez ou modifiez une configuration Standard Logging v2 pour la distribution.
  2. Sélectionnez la sortie JSON.
  3. Sélectionnez le flux Firehose comme destination de livraison.
  4. Utilisez exactement cette liste de champs :
    Cette liste exclut l’adresse du client, la chaîne de requête, les cookies et le référent.
  5. Activez la configuration de journalisation.
Consultez CloudFront Standard Logging v2 et les réglages de sauvegarde HTTP de Firehose pour les réglages AWS actuels.

​
Tester la livraison

Après avoir activé les deux configurations, demandez un chemin sans risque sur le nom d’hôte de la distribution avec un User-Agent de crawler reconnu :
Vérifiez les indicateurs de livraison HTTP de Firehose et le log d’erreurs CloudWatch. Une réponse réussie de Qwairy inclut l’identifiant de requête Firehose. Le connecteur quitte l’état en attente dès qu’une ligne CloudFront acceptée atteint le pipeline d’agrégation. Les enregistrements de démonstration génériques de Firehose n’ont pas la forme de CloudFront Standard Logging v2 et ne prouvent donc pas que l’agrégation des crawlers est correctement configurée.

​
Limites, livraison et coût

  • Gardez le buffer HTTP à 1 MiB et 60 secondes. Cela maintient l’enveloppe base64 de Firehose sous la limite de 2 000 000 octets de Qwairy.
  • Une livraison peut contenir au plus 10 000 enregistrements Firehose ou occurrences analysées pour cette route.
  • Les exclusions en amont rendent les comptes de crawlers partiels. Ne comparez que des périmètres CloudFront et Qwairy équivalents.
  • La journalisation CloudFront, la livraison Firehose, les logs d’erreurs CloudWatch et la sauvegarde S3 peuvent chacun être facturés par AWS.
  • Les plafonds d’ingestion quotidienne partagés de Qwairy s’appliquent aussi.

​
Dépannage

  • 401 du point de terminaison HTTP : vérifiez que Firehose utilise le secret Qwairy actuel comme Access key.
  • 400 requête de livraison invalide : vérifiez que la source est CloudFront Standard Logging v2, que la sortie est en JSON, que la liste exacte de champs est sélectionnée et que l’identifiant de requête Firehose est conservé.
  • 413 payload trop volumineux : rétablissez le buffer Firehose de 1 MiB et vérifiez qu’aucune transformation n’agrandit les enregistrements.
  • 415 encodage non pris en charge : utilisez l’encodage de livraison HTTP Firehose pris en charge par la configuration et gardez le type de contenu de la destination en JSON.
  • Firehose réessaie ou écrit dans la sauvegarde S3 : examinez les erreurs de livraison CloudWatch, les autorisations IAM, les réglages du point de terminaison et les paramètres de buffer.
  • Qwairy reste en attente : vérifiez que la journalisation est activée sur la bonne distribution et générez une requête GET ou HEAD récente avec un User-Agent de crawler reconnu vers le nom d’hôte configuré.

​
Page associée