Transfert de journaux log-forwarding

Les clients disposant d’une licence avec un fournisseur de journalisation ou hébergeant un produit de journalisation peuvent avoir AEM journaux (y compris Apache/Dispatcher) et des journaux CDN transférés vers la destination de journalisation associée. AEM as a Cloud Service prend en charge les destinations de journalisation suivantes :

Le transfert de journal est configuré en libre-service en déclarant une configuration dans Git et en la déployant via le pipeline de configuration Cloud Manager vers les types d’environnements de production (hors environnements de test), de développement, d’évaluation et de production RDE.

Il existe une option pour que les journaux d’AEM et Apache/Dispatcher soient acheminés par le biais d’AEM infrastructure de mise en réseau avancée, telle qu’une adresse IP de sortie dédiée.

Notez que la bande passante réseau associée aux journaux envoyés à la destination de journalisation est considérée comme faisant partie de l’utilisation des E/S réseau de votre entreprise.

Organisation de cet article how-organized

Cet article est organisé de la manière suivante :

Configuration setup

Les jetons dans la configuration (tels que ${{SPLUNK_TOKEN}}) représentent des secrets, qui ne doivent pas être stockés dans Git. À la place, déclarez-les en tant que variables d’environnement secrètes Cloud Manager. Veillez à sélectionner Tous comme valeur de liste déroulante pour le champ Service appliqué, de sorte que les journaux puissent être transférés vers les niveaux d’auteur, de publication et d’aperçu.

Il est possible de définir des valeurs différentes entre les journaux CDN et les journaux d’AEM (y compris Apache/Dispatcher), en incluant un bloc supplémentaire cdn et/ou aem après le bloc default, où les propriétés peuvent remplacer celles définies dans le bloc default ; seule la propriété activée est requise. Un cas d’utilisation possible peut être l’utilisation d’un index Splunk différent pour les journaux CDN, comme l’exemple ci-dessous.

   kind: "LogForwarding"
   version: "1"
   metadata:
     envTypes: ["dev"]
   data:
     splunk:
       default:
         enabled: true
         host: "splunk-host.example.com"
         token: "${{SPLUNK_TOKEN}}"
         index: "AEMaaCS"
       cdn:
         enabled: true
         token: "${{SPLUNK_TOKEN_CDN}}"
         index: "AEMaaCS_CDN"

Un autre scénario consiste à désactiver le transfert des journaux CDN ou AEM journaux (y compris Apache/Dispatcher). Par exemple, pour ne transférer que les journaux CDN, vous pouvez configurer les éléments suivants :

   kind: "LogForwarding"
   version: "1"
   metadata:
     envTypes: ["dev"]
   data:
     splunk:
       default:
         enabled: true
         host: "splunk-host.example.com"
         token: "${{SPLUNK_TOKEN}}"
         index: "AEMaaCS"
       aem:
         enabled: false

Configuration de la destination de journalisation logging-destinations

Les configurations pour les destinations de journalisation prises en charge sont répertoriées ci-dessous, ainsi que toute considération spécifique.

Stockage Azure Blob azureblob

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  azureBlob:
    default:
      enabled: true
      storageAccountName: "example_acc"
      container: "aem_logs"
      sasToken: "${{AZURE_BLOB_SAS_TOKEN}}

Un jeton SAS doit être utilisé pour l’authentification. Elle doit être créée à partir de la page de signature Accès partagé, plutôt que sur la page Jeton d’accès partagé , et doit être configurée avec les paramètres suivants :

Voici une capture d’écran d’un exemple de configuration de jeton SAS :

Si les logs ont cessé d’être diffusés après avoir fonctionné correctement, vérifiez si le jeton SAS que vous avez configuré est toujours valide, car il a peut-être expiré.

Journaux CDN Azure Blob Storage azureblob-cdn

Chacun des serveurs de journalisation répartis dans le monde produira un nouveau fichier toutes les quelques secondes, sous le dossier aemcdn. Une fois créé, le fichier ne sera plus annexé au fichier. Le format du nom de fichier est AAAA-MM-DDThhss.sss-uniqueid.log. Par exemple, 2024-03-04T10:00:00.000-WnFWYN9BpOUs2aOVn4ee.log.

Par exemple, à un moment donné :

aemcdn/
   2024-03-04T10:00:00.000-abc.log
   2024-03-04T10:00:00.000-def.log

Et puis 30 secondes plus tard :

aemcdn/
   2024-03-04T10:00:00.000-abc.log
   2024-03-04T10:00:00.000-def.log
   2024-03-04T10:00:30.000-ghi.log
   2024-03-04T10:00:30.000-jkl.log
   2024-03-04T10:00:30.000-mno.log

Chaque fichier contient plusieurs entrées de journal json, chacune sur une ligne distincte. Les formats d’entrée de journal sont décrits sous Journalisation pour AEM as a Cloud Service, et chaque entrée de journal inclut également les propriétés supplémentaires mentionnées dans la section Formats d’entrée de journal ci-dessous.

Journaux Azure Blob Storage AEM azureblob-aem

Les journaux d’AEM (y compris Apache/Dispatcher) apparaissent sous un dossier avec la convention d’affectation des noms suivante :

Sous chaque dossier, un seul fichier est créé et ajouté. Les clients sont responsables du traitement et de la gestion de ce fichier afin qu’il ne se développe pas trop.

Voir les formats d’entrée de journal sous Journalisation pour AEM as a Cloud Service. Les entrées de journal incluent également les propriétés supplémentaires mentionnées dans la section Formats de saisie de journal ci-dessous.

Datadog datadog

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  datadog:
    default:
      enabled: true
      host: "http-intake.logs.datadoghq.eu"
      token: "${{DATADOG_API_KEY}}"
      tags:
         tag1: value1
         tag2: value2

Considérations :

Elasticsearch et OpenSearch elastic

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  elasticsearch:
    default:
      enabled: true
      host: "example.com"
      user: "${{ELASTICSEARCH_USER}}"
      password: "${{ELASTICSEARCH_PASSWORD}}"
      pipeline: "ingest pipeline name"

Considérations :

def envType = ctx.aem_env_type != null ? ctx.aem_env_type : 'unknown';
def sourceType = ctx._index;
def date = new SimpleDateFormat('dd_MM_yyyy').format(new Date());
ctx._index = sourceType + "_" + envType + "_" + date;

HTTPS https

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  https:
    default:
      enabled: true
      url: "https://example.com/aem_logs/aem"
      authHeaderName: "X-AEMaaCS-Log-Forwarding-Token"
      authHeaderValue: "${{HTTPS_LOG_FORWARDING_TOKEN}}"

Considérations :

Logs CDN HTTPS https-cdn

Les requêtes Web (POST) seront envoyées en continu, avec une payload json qui est un tableau d’entrées de journal, avec le format d’entrée de journal décrit sous Journalisation pour AEM as a Cloud Service. Des propriétés supplémentaires sont mentionnées dans la section Formats de saisie de journal ci-dessous.

Il existe également une propriété nommée sourcetype, qui est définie sur la valeur aemcdn.

Journaux des AEM HTTPS https-aem

Pour les journaux d’AEM (y compris apache/dispatcher), les demandes web (POST) seront envoyées en continu, avec une payload json qui est un tableau d’entrées de journal, avec les différents formats d’entrée de journal comme décrit sous Journalisation pour AEM as a Cloud Service. Des propriétés supplémentaires sont mentionnées dans la section Formats de saisie de journal ci-dessous.

Il existe également une propriété nommée Source-Type, définie sur l’une de ces valeurs :

Splunk splunk

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "aemaacs"

Considérations :

Formats de saisie du journal log-formats

Voir Journalisation pour AEM as a Cloud Service pour le format de chaque type de journal respectif (journaux CDN et journaux d’AEM y compris Apache/Dispatcher).

Puisque les journaux de plusieurs programmes et environnements peuvent être transférés vers la même destination de journalisation, en plus de la sortie décrite dans l’article de journalisation, les propriétés suivantes seront incluses dans chaque entrée de journal :

Par exemple, les propriétés peuvent avoir les valeurs suivantes :

aem_env_id: 1242
aem_env_type: dev
aem_program_id: 12314
aem_tier: author

Mise en réseau avancée advanced-networking

Certaines organisations choisissent de restreindre le trafic qui peut être reçu par les destinations de journalisation.

Pour le journal du réseau de diffusion de contenu, vous pouvez ajouter des adresses IP aux listes autorisées, comme décrit dans la documentation rapide - Liste d’adresses IP publiques. Si cette liste d’adresses IP partagées est trop volumineuse, envisagez d’envoyer du trafic vers un serveur https ou (non Adobe) Azure Blob Store où une logique peut être écrite pour envoyer les journaux d’une adresse IP connue vers leur destination finale.

Pour les journaux d’AEM (y compris Apache/Dispatcher), si vous avez configuré la mise en réseau avancée, vous pouvez utiliser la propriété advancedNetworking pour les transférer à partir d’une adresse IP de sortie dédiée ou sur un VPN.

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      port: 443
      token: "${{SPLUNK_TOKEN}}"
      index: "aemaacs"
    aem:
      advancedNetworking: true

Migration à partir du transfert de journal hérité legacy-migration

Avant que la configuration du transfert du journal ne soit réalisée par le biais d’un modèle en libre-service, les clients étaient invités à ouvrir les tickets d’assistance, où l’Adobe lancerait l’intégration.

Les clients qui ont été configurés de cette manière par Adobe sont les bienvenus pour s’adapter au modèle en libre-service à leur convenance. Cette transition peut être effectuée pour plusieurs raisons :

Une fois prêt à migrer, configurez le fichier YAML comme décrit dans les sections précédentes. Utilisez le pipeline de configuration Cloud Manager pour effectuer le déploiement sur chacun des environnements dans lesquels la configuration doit être appliquée.

Il est recommandé, mais non obligatoire, qu’une configuration soit déployée dans tous les environnements afin qu’ils soient tous sous contrôle en libre-service. Dans le cas contraire, vous pouvez oublier les environnements qui ont été configurés par Adobe par rapport à ceux configurés en libre-service.