Reenvío de registro log-forwarding
Los clientes con una licencia con un proveedor de registro o que alojen un producto de registro pueden hacer que los registros de AEM (incluido Apache/Dispatcher) y los registros de CDN se reenvíen al destino de registro asociado. AEM as a Cloud Service admite los siguientes destinos de registro:
El reenvío de registros de CDN [1] a Amazon S3, Dynatrace y New Relic está en la versión beta. Para solicitar acceso, envía un correo electrónico a aemcs-logforwarding-beta@adobe.com con tu identificador de programa. Una vez habilitado el acceso, también activa los registros de CDN para cada destino con cdn.enabled: true. Consulte Registros de CDN para Amazon S3, Dynatrace y New Relic (beta).
El reenvío de registros se configura en modo de autoservicio declarando una configuración en Git y se puede implementar mediante canalizaciones de configuración de Cloud Manager en los tipos de entorno de desarrollo, ensayo y producción. El archivo de configuración se puede implementar en Entornos de desarrollo rápido (RDE) mediante herramientas de línea de comandos.
Hay una opción para que los registros de AEM y Apache/Dispatcher se enruten a través de la infraestructura de red avanzada de AEM, como la IP de salida dedicada. Los registros de CDN siempre se envían directamente desde CDN y no utilizan redes avanzadas. Consulte Transporte y redes avanzadas.
Organización de este artículo how-organized
Este artículo está organizado de la siguiente manera:
- Configuración: común para todos los destinos de registro
- Transporte y redes avanzadas: se debe considerar la configuración de la red antes de crear la configuración de registro
- Autenticación mutua TLS (mTLS) (beta): autenticación en destinos Splunk, Elasticsearch/OpenSearch y HTTPS con un certificado de cliente
- Registro de configuraciones de destino: cada destino tiene un formato ligeramente diferente
- Registros de CDN para Amazon S3, Dynatrace y New Relic (beta): cómo solicitar acceso a los registros de CDN para estos destinos y habilitarlos
- Formatos de entrada de registro: información sobre los formatos de entrada de registro
- Migración del reenvío de registros heredado: cómo pasar del reenvío de registros configurado anteriormente por Adobe al enfoque de autoservicio
Configuración setup
-
Cree un archivo con el nombre
logForwarding.yaml. Debe contener metadatos, tal como se describe en el artículo Canalización de configuración (kind debe establecerse enLogForwardingy la versión debe establecerse en “1”), con una configuración similar a la siguiente (usamos Splunk como ejemplo).code language-yaml kind: "LogForwarding" version: "1" data: splunk: default: enabled: true host: "splunk-host.example.com" token: "${{SPLUNK_TOKEN}}" index: "AEMaaCS" -
Coloque el archivo en algún lugar bajo una carpeta de nivel superior llamada config o similar, como se describe en Uso de canalizaciones de configuración.
-
Para tipos de entorno distintos de RDE (que usa herramientas de línea de comandos), cree una canalización de configuración de implementación de destino en Cloud Manager, como se indica en esta sección; tenga en cuenta que las canalizaciones de pila completa y las canalizaciones de nivel web no implementan el archivo de configuración.
-
Implemente la configuración de.
Los tokens de la configuración (como ${{SPLUNK_TOKEN}}) representan secretos que no deberían almacenarse en Git. En su lugar, declárelos como Cloud Manager Variables de entorno secretas. Asegúrese de seleccionar Todos como valor desplegable para el campo Servicio aplicado, de modo que los registros se puedan reenviar a los niveles de creación, publicación y vista previa.
Es posible establecer diferentes valores entre los registros de CDN y los registros de AEM (incluido Apache/Dispatcher), incluyendo un bloque cdn o aem adicional después del bloque default, donde las propiedades pueden anular las definidas en el bloque default; solo se requiere la propiedad enabled. Un posible caso de uso podría ser utilizar un índice de Splunk diferente para los registros de CDN, como se ilustra en el ejemplo siguiente.
kind: "LogForwarding"
version: "1"
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"
cdn establece enabled: true. Consulte Registros de CDN para Amazon S3, Dynatrace y New Relic (beta).Otro escenario es deshabilitar el reenvío de los registros de CDN o de AEM (incluido Apache/Dispatcher). Por ejemplo, para reenviar solo los registros de CDN, se puede configurar lo siguiente:
kind: "LogForwarding"
version: "1"
data:
splunk:
default:
enabled: true
host: "splunk-host.example.com"
token: "${{SPLUNK_TOKEN}}"
index: "AEMaaCS"
aem:
enabled: false
Transporte y redes avanzadas transport-advancednetworking
Algunas organizaciones eligen restringir qué tráfico pueden recibir los destinos de registro, otras pueden requerir el uso de puertos que no sean HTTPS (443). Si es así, será necesario configurar Redes avanzadas antes de implementar la configuración del reenvío de registros.
Utilice la tabla siguiente para ver cuáles son los requisitos para la configuración de Red avanzada y Registro en función de si está utilizando el puerto 443 o no, y de si necesita que los registros aparezcan o no desde una dirección IP fija. La tabla se aplica a los registros de AEM (incluido Apache/Dispatcher). Para los registros de CDN, consulte registros de CDN y listas de permitidos de IP.
Para los registros de AEM (incluido Apache/Dispatcher), si ha configurado Redes avanzadas, puede usar la propiedad aem.advancedNetworking para reenviarlas desde una dirección IP de salida dedicada.
El ejemplo siguiente muestra cómo configurar el registro en un puerto HTTPS estándar con funciones de red avanzadas.
kind: "LogForwarding"
version: "1"
data:
splunk:
default:
enabled: true
host: "splunk-host.example.com"
port: 443
token: "${{SPLUNK_TOKEN}}"
index: "aemaacs"
aem:
advancedNetworking: true
Registros de CDN y listas de permitidos de IP cdn-ip-allowlist
Los registros de CDN se envían directamente desde CDN (Fastly), no desde AEM as a Cloud Service. Esto se aplica a todos los destinos de registro:
- Los registros de CDN se envían desde los intervalos de direcciones IP compartidos de Fastly, publicados en https://api.fastly.com/public-ip-list. Nunca se envían desde su dirección IP de salida dedicada.
- La propiedad
advancedNetworkingse aplica solamente a los registros de AEM (incluyendo Apache/Dispatcher). No afecta a los registros de CDN. Si se estableceadvancedNetworkingy el reenvío de registro de CDN está habilitado para el mismo destino, la configuración se implementa con una advertencia como recordatorio. - Si el destino de registro solo acepta tráfico de direcciones IP específicas, agregue todos los rangos IPv4 e IPv6 publicados de Fastly a su lista de permitidos, además de la dirección IP de salida dedicada para los registros de AEM. Un destino que solo permite la dirección IP de salida dedicada no recibe registros de CDN.
- Los rangos de direcciones IP de Fastly cambian con el tiempo, a veces en cuestión de semanas. Revise la lista publicada regularmente y mantenga las listas de permitidos actualizadas.
- Amazon S3 tiene consideraciones adicionales para los registros de CDN. Consulte Registros de CDN de Amazon S3.
Si la lista de direcciones IP compartidas es demasiado grande para la lista de permitidos, considere la posibilidad de enviar registros de CDN a un servidor https o a un almacén de blobs de Azure (que no sea de Adobe) donde se pueda escribir lógica para enviar los registros de una IP conocida a su destino final.
Autenticación TLS mutua (mTLS) (beta) mtls
Los destinos Splunk, Elasticsearch/OpenSearch y HTTPS admiten TLS mutuo (mTLS). Con mTLS, AEM as a Cloud Service presenta un certificado de cliente cuando se conecta al destino de registro, para que el destino pueda verificar que los registros provienen de su entorno. mTLS se aplica a los registros de AEM (incluido Apache/Dispatcher) y a los registros de CDN.
mTLS funciona junto con la autenticación existente del destino. Conservar las propiedades de autenticación existentes del destino, como token (Splunk) o user y password (Elasticsearch/OpenSearch). Para destinos HTTPS que reenvían registros CDN, se requieren authHeaderName y authHeaderValue.
Configuración mtls-configuration
Agregue un bloque mtls junto con las demás propiedades del destino:
cert- obligatorio. El certificado de cliente, en formato PEM. Puede ir seguido de certificados de CA intermedios, con el certificado de cliente primero.key- obligatorio. La clave privada del certificado de cliente, en formato PEM. Las claves RSA y EC son compatibles, no cifradas o cifradas. Consulte Formatos de clave admitidos.ca- opcional. El certificado de CA, en formato PEM, utilizado para verificar el certificado de servidor de destino. Puede contener más de un certificado, como una cadena de certificados. Configúrelo cuando el certificado del servidor lo emita una CA privada.keyPasswd- opcional. La contraseña de la clave privada. Configúrelo solo si la clave está cifrada.
El siguiente ejemplo reenvía registros de AEM y CDN a Splunk mediante mTLS:
kind: "LogForwarding"
version: "1"
data:
splunk:
default:
enabled: true
host: "splunk-host.example.com"
token: "${{SPLUNK_TOKEN}}"
index: "aemaacs"
mtls:
cert: "${{SPLUNK_MTLS_CERT}}"
key: "${{SPLUNK_MTLS_KEY}}"
ca: "${{SPLUNK_MTLS_CA}}"
Se aplican las siguientes reglas:
certykeydeben proporcionarse juntos. Se rechaza un bloquemtlsque contenga solamentecaokeyPasswd.- Cada propiedad de
mtlsdebe ser una referencia secreta, como${{SPLUNK_MTLS_CERT}}, y nada más. Se rechaza el certificado o el texto de clave colocado directamente en el archivo. - Declare cada secreto como una variable de entorno secreta de Cloud Manager, tal como se describe en Configuración. Pegue el texto PEM completo, incluidas las líneas
-----BEGINy-----END. Si se eliminan los saltos de línea al pegar el valor en Cloud Manager, se restaurarán automáticamente. Para proporcionar más de un certificado, péguelos uno tras otro en el mismo secreto. - El certificado de cliente se comprueba al implementar. Debe ser un PEM válido y dentro de su periodo de validez. Si
certcontiene más de un certificado, el certificado de cliente debe ser el primero y los certificados deben formar una cadena válida. Si una comprobación falla, la implementación falla.
Formatos de clave admitidos mtls-key-formats
La primera línea del texto PEM de la clave muestra su formato:
-----BEGIN RSA PRIVATE KEY----------BEGIN EC PRIVATE KEY----------BEGIN PRIVATE KEY----------BEGIN ENCRYPTED PRIVATE KEY-----DES-EDE3-CBC)-----BEGIN RSA PRIVATE KEY----- o -----BEGIN EC PRIVATE KEY-----, seguidos de Proc-Type: 4,ENCRYPTED y DEK-Info líneasPara una clave cifrada, establezca también keyPasswd en su contraseña.
Se recomienda PKCS#8 cifrado para claves cifradas. Para convertir una clave en el formato antiguo, utilice el siguiente comando, que solicita la contraseña actual y, a continuación, la contraseña de la nueva clave:
openssl pkcs8 -topk8 -v2 aes-256-cbc -in client.key -out client-pkcs8.key
Almacene el contenido de client-pkcs8.key en el secreto al que hace referencia key y su contraseña en el secreto al que hace referencia keyPasswd.
Registros de CDN mtls-cdn
Al igual que otras propiedades, un bloque mtls en default se aplica tanto a los registros de AEM como a los de CDN. Para usar un certificado diferente para los registros de CDN, establezca las propiedades mtls en un bloque cdn. Para usar mTLS solo para registros de AEM o solo para registros de CDN, coloque el bloque mtls en el bloque aem o cdn en lugar de default.
Después de implementar una configuración que habilita el reenvío de registros de CDN a un destino, pueden pasar varios minutos antes de que lleguen los primeros registros de CDN. Para destinos HTTPS, la entrega de registros de CDN también se inicia solamente después de que el servidor complete el desafío único descrito en HTTPS. La solicitud de desafío se envía con el mismo certificado de cliente, por lo que el servidor debe aceptar también ese certificado en la ruta de desafío.
Rotación y caducidad del certificado mtls-rotation
Para rotar un certificado, actualice las variables de entorno secreto de Cloud Manager que contienen el certificado (y la clave, si ha cambiado) y, a continuación, vuelva a ejecutar la canalización de configuración. Si el archivo de configuración del reenvío de registros no se ha modificado, realice también un cambio en él para que se vuelva a aplicar la configuración. Por ejemplo, almacene los nuevos valores en nuevas variables de entorno secretas y haga referencia a esos nombres en el bloque mtls.
También puede recibir una notificación proactiva de Centro de acciones unos 21 días antes de la caducidad del certificado de cliente. Rastree las fechas de caducidad de los certificados usted mismo en lugar de depender de esta notificación.
Configuración de destino de registro logging-destinations
A continuación se enumeran las configuraciones para los destinos de registro admitidos, junto con cualquier consideración específica.
Amazon S3 amazons3
Los registros de CDN en Amazon S3 están en versión beta. Para solicitar acceso, envía un correo electrónico a aemcs-logforwarding-beta@adobe.com con tu identificador de programa. Consulte Registros de CDN para Amazon S3, Dynatrace y New Relic (versión beta) para saber cómo habilitarlos y Registros de CDN de Amazon S3 para ver el diseño del archivo y las consideraciones.
kind: "LogForwarding"
version: "1"
data:
awsS3:
default:
enabled: true
region: "your-bucket-region"
bucket: "your-bucket-name"
accessKey: "${{AWS_S3_ACCESS_KEY}}"
secretAccessKey: "${{AWS_S3_SECRET_ACCESS_KEY}}"
Para reenviar tanto los registros de AEM como los registros de CDN (los registros de CDN en la versión beta):
kind: "LogForwarding"
version: "1"
data:
awsS3:
default:
enabled: true
region: "us-east-1"
bucket: "your-bucket-name"
accessKey: "${{AWS_S3_ACCESS_KEY}}"
secretAccessKey: "${{AWS_S3_SECRET_ACCESS_KEY}}"
cdn:
enabled: true
Para reenviar solo los registros de CDN (en la versión beta):
kind: "LogForwarding"
version: "1"
data:
awsS3:
default:
enabled: true
region: "us-east-1"
bucket: "your-bucket-name"
accessKey: "${{AWS_S3_ACCESS_KEY}}"
secretAccessKey: "${{AWS_S3_SECRET_ACCESS_KEY}}"
aem:
enabled: false
cdn:
enabled: true
Para utilizar el S3 Log Forwarder, deberá preconfigurar un usuario de AWS IAM con la política adecuada para acceder a su bloque S3. Consulte Documentación del usuario de AWS IAM para ver cómo crear las credenciales de usuario de IAM.
La directiva IAM debe permitir al usuario utilizar s3:PutObject. Para reenviar los registros de CDN (en la versión beta), permita también s3:AbortMultipartUpload. No se necesitan otros permisos: el usuario no necesita leer ni enumerar el contenedor. Por ejemplo:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:AbortMultipartUpload"
],
"Resource": "arn:aws:s3:::your-bucket-name/*"
}]
}
Si el bloque solo recibe registros de CDN, puede limitar Resource a arn:aws:s3:::your-bucket-name/aemcdn/*.
Consulte la Documentación de la directiva de compartimento de AWS para obtener más información sobre cómo implementar.
Registros de CDN de Amazon S3 (beta) amazons3-cdn
Los registros de CDN en Amazon S3 están en versión beta. Necesitan acceso para su programa y cdn.enabled: true. Consulte Registros de CDN para Amazon S3, Dynatrace y New Relic (beta).
Los registros de CDN se escriben debajo de la carpeta aemcdn/ del bloque. El formato de nombre de archivo es YYYY-MM-DDThh:mm:ss.000-<uniqueid>.log.gz. Por ejemplo:
aemcdn/
2026-03-04T10:00:00.000-WnFWYN9BpOUs2aOVn4ee.log.gz
2026-03-04T10:00:00.000-0pX8ub2yQcAmLs7rT1kd.log.gz
2026-03-04T10:05:00.000-h3JkVv9ZqN2wE5sXyR0a.log.gz
- Los archivos están comprimidos en gzip. Cada archivo contiene varias entradas de registro, un objeto JSON por línea. Las entradas tienen las mismas propiedades que los registros de CDN escritos en el almacenamiento del blob de Azure. El formato de entrada de registro se describe en Registro para AEM as a Cloud Service, y cada entrada también incluye las propiedades adicionales que se mencionan en la sección Formatos de entrada de registro a continuación.
- Se escribe un nuevo conjunto de archivos cada 5 minutos. La CDN tiene muchos servidores y cada servidor que gestiona el tráfico escribe su propio archivo, por lo que espere muchos archivos para cada periodo de 5 minutos, incluso con poco tráfico. Por ejemplo, un entorno de prueba de poco tráfico producía unos 50 archivos cada 5 minutos.
- Las entradas de registro suelen aparecer en el bloque de 1 a 6 minutos después de la solicitud.
- La hora del nombre de archivo no es una ventana de tiempo exacta, y los archivos se superponen. Por ejemplo, un archivo de nombre
…T16:00:00.000-….log.gzpuede contener entradas de 15:55 a 16:04. Utilice la propiedadtimestampde cada entrada para buscar cuándo se produjo una solicitud. - Los archivos no se cambian una vez escritos.
Los clientes son responsables de procesar y administrar estos archivos, por ejemplo, con una regla de ciclo de vida S3 en el prefijo aemcdn/.
Consideraciones para los registros de CDN (beta):
-
La autenticación utiliza la clave de acceso de un usuario de IAM. Los roles de IAM no son compatibles.
-
El usuario de IAM solo necesita
s3:PutObjectys3:AbortMultipartUpload. No necesita permiso para leer o enumerar el contenedor. -
Se admite el cifrado en bloque predeterminado con claves administradas de Amazon S3 (SSE-S3) y, a continuación, los archivos de registro de CDN se cifran en reposo.
-
Solo se admiten bloques en regiones comerciales de AWS estándar. No se admiten las regiones de AWS GovCloud (EE. UU.) y AWS China. La propiedad
regiondebe ser la región del bloque. -
No se reintentaron las cargas rechazadas. Si la política de compartimento o los permisos del usuario de IAM rechazan una carga de registros de CDN, las entradas de registro de esa carga se pierden sin previo aviso. Esto es diferente a los registros de AEM, donde se vuelven a intentar las cargas fallidas. Asegúrese de que los cambios en la política de compartimento o en el usuario de IAM no bloqueen las cargas desde la CDN.
-
Recomendamos un usuario de IAM al que solo se permita
s3:PutObjectys3:AbortMultipartUploaden el bloque (o solo en el prefijoaemcdn/, si el bloque solo recibe registros de CDN) y una política de bloque sin condiciones de dirección IP. -
Si la política de compartimento restringe el acceso por dirección IP, agregue todos los intervalos de IPv4 e IPv6 publicados de Fastly a la condición
aws:SourceIpy manténgalos actualizados. Consulte Registros de CDN y listas de permitidos de IP. -
Los contenedores que solo aceptan solicitudes a través de un extremo de VPC (por ejemplo, una política de contenedores con una condición
aws:SourceVpce) no pueden recibir registros de CDN. -
Para detectar registros de CDN perdidos, tenga en cuenta lo siguiente:
- Eventos de datos de AWS CloudTrail o registros de acceso del servidor S3. Registran solicitudes rechazadas
PutObject(estado HTTP 403) de las direcciones IP de Fastly. - Alarma que se activa cuando no llegan objetos nuevos por debajo de
aemcdn/durante más de lo esperado. Los archivos se escriben cada 5 minutos.
- Eventos de datos de AWS CloudTrail o registros de acceso del servidor S3. Registran solicitudes rechazadas
Azure Blob Storage azureblob
kind: "LogForwarding"
version: "1"
data:
azureBlob:
default:
enabled: true
storageAccountName: "example_acc"
container: "aem_logs"
sasToken: "${{AZURE_BLOB_SAS_TOKEN}}
Se debe utilizar un token SAS para la autenticación. Debe crearse desde la página de firma de acceso compartido, en lugar de desde la página de token de acceso compartido, y debe configurarse con esta configuración:
- Servicios permitidos: se debe seleccionar un blob.
- Recursos permitidos: el objeto y el contenedor deben estar seleccionados.
- Permisos permitidos: Leer, Escribir, Agregar, Lista, Crear deben estar seleccionados.
- Una fecha/hora de inicio y de caducidad válidas. La caducidad debe ser de al menos tres meses en el futuro en el momento de implementar la configuración.
Esta es una captura de pantalla de un ejemplo de configuración de token SAS:
Si los registros han dejado de entregarse después de funcionar correctamente anteriormente, compruebe si el token SAS que configuró sigue siendo válido, ya que puede haber caducado.
Registros de CDN de almacenamiento de Azure Blob azureblob-cdn
Cada uno de los servidores de registro distribuidos globalmente producirá un nuevo archivo cada pocos segundos, en la carpeta aemcdn. Una vez creado, el archivo ya no se anexará a. El formato del nombre de archivo es AAAA-MM-DDThhss.ss-uniqueid.log. Por ejemplo, 2024-03-04T10:00:00.000-WnFWYN9BpOUs2aOVn4ee.log.
Por ejemplo, en algún momento:
aemcdn/
2024-03-04T10:00:00.000-abc.log
2024-03-04T10:00:00.000-def.log
Y luego 30 segundos después:
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
Cada archivo contiene varias entradas de registro json, cada una en una línea independiente. Los formatos de entrada de registro se describen en Registro para AEM as a Cloud Service, y cada entrada de registro también incluye las propiedades adicionales que se mencionan en la sección Formatos de entrada de registro a continuación.
Registros de AEM de almacenamiento de Azure Blob azureblob-aem
Los registros de AEM (incluido Apache/Dispatcher) aparecen debajo de una carpeta con la siguiente convención de nombres:
- aemaccess
- aemerror
- aemrequest
- aemdispatcher
- aemhttpdaccess
- aemhttpderror
En cada carpeta, se crea un solo archivo y se anexa a. Los clientes son responsables de procesar y administrar este archivo para que no crezca demasiado.
Consulte los formatos de entrada de registro en Registro para AEM as a Cloud Service. Las entradas de registro también incluirán las propiedades adicionales mencionadas en la sección Formatos de entrada de registro a continuación.
Datadog datadog
kind: "LogForwarding"
version: "1"
data:
datadog:
default:
enabled: true
host: "http-intake.logs.datadoghq.eu"
token: "${{DATADOG_API_KEY}}"
tags:
tag1: value1
tag2: value2
Consideraciones
- Cree una clave de API sin ninguna integración con un proveedor de nube específico.
- La propiedad tags es opcional
- Para los registros de AEM, la etiqueta de origen Datadog está establecida en
aemaccess,aemerror,aemrequest,aemdispatcher,aemhttpdaccessoaemhttpderror - Para los registros de CDN, la etiqueta de origen Datadog está establecida en
aemcdn - La etiqueta de servicio Datadog está establecida en
adobeaemcloud, pero puede sobrescribirla en la sección de etiquetas - Si la canalización de ingesta utiliza etiquetas Datadog para determinar el índice adecuado para los registros de reenvío, compruebe que estas etiquetas estén correctamente configuradas en el archivo YAML de reenvío de registros. Las etiquetas que faltan pueden impedir la ingesta correcta del registro si la canalización depende de ellas.
Elasticsearch y OpenSearch elastic
kind: "LogForwarding"
version: "1"
data:
elasticsearch:
default:
enabled: true
host: "example.com"
user: "${{ELASTICSEARCH_USER}}"
password: "${{ELASTICSEARCH_PASSWORD}}"
pipeline: "ingest pipeline name"
Consideraciones
- el puerto predeterminado es 443. Opcionalmente, se puede sobrescribir con una propiedad denominada
port - Para las credenciales, asegúrese de utilizar credenciales de implementación en lugar de credenciales de cuenta. Estas son las credenciales que se generan en una pantalla que puede parecerse a esta imagen:
- Para los registros de AEM,
indexse ha establecido enaemaccess,aemerror,aemrequest,aemdispatcher,aemhttpdaccessoaemhttpderror - La propiedad de canalización opcional debe establecerse en el nombre de la canalización de ingesta de Elasticsearch u OpenSearch, que puede configurarse para enrutar la entrada de registro al índice adecuado. El tipo de procesador de la canalización debe establecerse en script y el idioma del script debe establecerse en sin dolor. Este es un ejemplo de fragmento de script para enrutar las entradas de registro a un índice como aemaccess_dev_26_06_2024:
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"
data:
https:
default:
enabled: true
url: "https://example.com/aem_logs/aem"
authHeaderName: "X-AEMaaCS-Log-Forwarding-Token"
authHeaderValue: "${{HTTPS_LOG_FORWARDING_TOKEN}}"
Consideraciones
- La cadena de dirección URL debe incluir https://; de lo contrario, la validación fallará.
- La dirección URL puede incluir un puerto. Por ejemplo,
https://example.com:8443/aem_logs/aem. Si no se incluye ningún puerto en la cadena URL, se asume el puerto 443 (el puerto HTTPS predeterminado).
Registros de CDN HTTPS https-cdn
Las solicitudes web (POST) se enviarán de manera continua, con una carga útil json que es una matriz de entradas de registro, con el formato de entrada de registro descrito en Registro para AEM as a Cloud Service. A continuación se mencionan propiedades adicionales en la sección Formatos de entrada de registro.
También debe haber una propiedad denominada sourcetype, que se ha establecido en el valor aemcdn.
/.well-known/fastly/logging/challenge debe responder con un asterisco * en el cuerpo y el código de estado 200.Registros de AEM HTTPS https-aem
Para los registros de AEM (incluido apache/dispatcher), las solicitudes web (POST) se enviarán continuamente, con una carga útil json que es una matriz de entradas de registro, con los distintos formatos de entrada de registro como se describe en Registro para AEM as a Cloud Service. A continuación se mencionan propiedades adicionales en la sección Formatos de entrada de registro.
También debe existir una propiedad denominada Source-Type, que se establezca en uno de estos valores:
- aemaccess
- aemerror
- aemrequest
- aemdispatcher
- aemhttpdaccess
- aemhttpderror
API de registro de New Relic newrelic-https
El reenvío de registros a New Relic aprovecha la API de registro HTTPS de New Relic para su ingesta. Los registros de CDN en New Relic están en versión beta. Para solicitar acceso, envía un correo electrónico a aemcs-logforwarding-beta@adobe.com con tu identificador de programa. Consulte Registros de CDN para Amazon S3, Dynatrace y New Relic (beta) para saber cómo habilitarlos.
kind: "LogForwarding"
version: "1"
data:
newRelic:
default:
enabled: true
uri: "https://log-api.newrelic.com/log/v1"
apiKey: "${{NR_API_KEY}}"
Para reenviar tanto los registros de AEM como los registros de CDN (los registros de CDN en la versión beta):
kind: "LogForwarding"
version: "1"
data:
newRelic:
default:
enabled: true
uri: "https://log-api.newrelic.com/log/v1"
apiKey: "${{NR_API_KEY}}"
cdn:
enabled: true
Para reenviar solo los registros de CDN (en la versión beta):
kind: "LogForwarding"
version: "1"
data:
newRelic:
default:
enabled: true
uri: "https://log-api.newrelic.com/log/v1"
apiKey: "${{NR_API_KEY}}"
aem:
enabled: false
cdn:
enabled: true
Consideraciones
- New Relic proporciona puntos finales específicos de la región en función de dónde se aprovisione su cuenta de New Relic. Establezca
urien el punto final de la API de registro para la región de su cuenta; por ejemplo,https://log-api.newrelic.com/log/v1para las cuentas de la región de EE. UU. Consulte Documentación de New Relic para obtener más información. - Para
apiKey, use una clave de licencia de New Relic (tipo de clave INGESTA - LICENCIA) de la cuenta que recibe los registros. Se utiliza la misma clave para los registros de AEM y los registros de CDN. - Para los registros de AEM, el atributo
sourceestá establecido en uno deaemaccess,aemerror,aemrequest,aemdispatcher,aemhttpdaccessoaemhttpderror. Para los registros de CDN (beta),sourcese establece enaemcdny cada registro lleva todas las propiedades de registro de CDN. Por ejemplo, para consultar los registros de CDN:FROM Log SELECT * WHERE source = 'aemcdn' SINCE 1 hour ago. - En las entradas de registro de CDN (beta) enviadas a New Relic,
timestampes un número: el tiempo de inicio de la solicitud en milisegundos desde la época de Unix. Otros destinos de registro recibentimestampcomo una cadena ISO 8601. - Los registros de CDN (beta) pueden agregar un volumen significativo a la ingesta de New Relic. Consulte Registros de CDN para Amazon S3, Dynatrace y New Relic (beta).
API de registro de Dynatrace dynatrace-https
El reenvío de registros a Dynatrace aprovecha la API HTTPS de Dynatrace para su ingesta. Los registros de CDN en Dynatrace están en versión beta. Para solicitar acceso, envía un correo electrónico a aemcs-logforwarding-beta@adobe.com con tu identificador de programa. Consulte Registros de CDN para Amazon S3, Dynatrace y New Relic (beta) para saber cómo habilitarlos.
El token requiere el ámbito Registros de ingesta (logs.ingest). Se utiliza el mismo token para los registros de AEM y los registros de CDN.
kind: "LogForwarding"
version: "1"
data:
dynatrace:
default:
enabled: true
environmentId: "${{DYNATRACE_ENVID}}"
token: "${{DYNATRACE_TOKEN}}"
Para reenviar tanto los registros de AEM como los registros de CDN (los registros de CDN en la versión beta):
kind: "LogForwarding"
version: "1"
data:
dynatrace:
default:
enabled: true
environmentId: "${{DYNATRACE_ENVID}}"
token: "${{DYNATRACE_TOKEN}}"
cdn:
enabled: true
Para reenviar solo los registros de CDN (en la versión beta):
kind: "LogForwarding"
version: "1"
data:
dynatrace:
default:
enabled: true
environmentId: "${{DYNATRACE_ENVID}}"
token: "${{DYNATRACE_TOKEN}}"
aem:
enabled: false
cdn:
enabled: true
Consideraciones
- Solo se admiten entornos SaaS de Dynatrace.
environmentIdes el identificador en la dirección URL de su entorno,https://<environmentId>.live.dynatrace.com. Utilice solo el ID, no una dirección URL ni un nombre de host: para los registros de CDN, no puede contener puntos. Los extremos administrados y ActiveGate de Dynatrace no son compatibles. - Cada entrada de registro incluye una propiedad
source. Para los registros de AEM es uno deaemaccess,aemerror,aemrequest,aemdispatcher,aemhttpdaccessoaemhttpderror. Para los registros de CDN (beta) esaemcdn. - Los registros de CDN (beta) pueden agregar un volumen significativo a la ingesta de Dynatrace. Consulte Registros de CDN para Amazon S3, Dynatrace y New Relic (beta).
Búsqueda de registros de CDN en Dynatrace (beta) dynatrace-cdn
Dynatrace almacena cada entrada de registro de CDN, como texto JSON, en content de un registro y usa timestamp de la entrada como hora de registro. Las propiedades de registro de CDN, como source, url y status, no son atributos de registro independientes. Lo mismo se aplica a los registros de AEM reenviados a Dynatrace. Como resultado:
- Los filtros en el modo simple del visor de registro clásico no funcionan en estas propiedades. Se ignora un filtro en un atributo que no existe, por lo que se devuelven todos los registros.
- El registro
statusde estos registros muestraNONE, porque la propiedad CDNstatuses el código de estado HTTP, no un nivel de registro.
En su lugar, utilice el modo avanzado (DQL). Para buscar registros de CDN de la última hora:
fetch logs, from: now() - 1h
| filter matchesPhrase(content, "aemcdn")
Para analizar las propiedades de registro de CDN y mostrar algunas de ellas:
fetch logs, from: now() - 1h
| parse content, "JSON:cdn"
| filter cdn[source] == "aemcdn"
| fields timestamp, cdn[url], cdn[status], cdn[pop], cdn[cache], cdn[aem_tier]
Splunk splunk
kind: "LogForwarding"
version: "1"
data:
splunk:
default:
enabled: true
host: "splunk-host.example.com"
token: "${{SPLUNK_TOKEN}}"
index: "aemaacs"
Consideraciones
- El puerto predeterminado es 443. Opcionalmente, se puede sobrescribir con una propiedad denominada
port. - El campo sourcetype tendrá uno de los siguientes valores, según el registro específico: aemaccess, aemerror,
aemrequest, aemdispatcher, aemhttpdaccess, aemhttpderror, aemcdn - Si las IP requeridas se han incluido en la lista de permitidos y los registros siguen sin entregarse, compruebe que no haya reglas de firewall que apliquen la validación de tokens de Splunk. Realiza rápidamente un paso de validación inicial al enviar intencionadamente un token de Splunk no válido. Si el cortafuegos está configurado para finalizar conexiones con tokens de Splunk no válidos, el proceso de validación fallará, lo que impide que Fastly envíe registros a la instancia de Splunk.
sourcetype enviados a su índice de Splunk hayan cambiado, por lo que debe ajustarlos en consecuencia.Lógica de sumo sumologic
Al configurar Sumo Logic para la ingesta de datos, se le mostrará una “Dirección HTTP Source” que proporciona el host, el URI del receptor y la clave privada en una sola cadena. Por ejemplo:
https://collectors.de.sumologic.com/receiver/v1/http/ZaVnC...
Deberá copiar la última sección de la dirección URL (sin la anterior /) y agregarla como Variable de entorno secreto de CloudManager, tal como se describe en la sección Configuración anterior, y luego hacer referencia a esa variable en la configuración. A continuación se proporciona un ejemplo.
kind: "LogForwarding"
version: "1"
data:
sumoLogic:
default:
enabled: true
collectorURL: "https://collectors.de.sumologic.com/receiver/v1/http"
privateKey: "${{SUMOLOGIC_PRIVATE_KEY}}"
index: "aem-logs"
index depende del tipo de registro:- Registros de AEM (incluido Apache/Dispatcher): enrutado a la partición especificada por
index, siempre que tenga una suscripción de Sumo Logic Enterprise. Las suscripciones que no son de empresa se dirigen a la particiónsumologic_defaulten su lugar. - Registros de CDN: el campo
indexse omite, ya que la indexación no es técnicamente compatible con los registros de CDN reenviados a Sumo Logic. Los registros de CDN siempre se enrutan a la particiónsumologic_default.
Registros de CDN para Amazon S3, Dynatrace y New Relic (beta) cdn-opt-in
El reenvío de registros de CDN a Amazon S3, Dynatrace y New Relic está en versión beta. El reenvío de registros de AEM (incluido Apache/Dispatcher) a estos destinos no se ve afectado y no necesita una solicitud.
Para reenviar registros de CDN a uno de estos destinos, complete ambos pasos:
- Solicite acceso para su programa. Envíe un correo electrónico a aemcs-logforwarding-beta@adobe.com con su ID de programa y los destinos que desea utilizar. Adobe responde cuando el acceso está habilitado para el programa.
- Habilitar registros de CDN para cada destino. Una vez habilitado el acceso, establezca
enabled: trueen el bloquecdndel destino en la configuración de Reenvío de registro y ejecute la canalización de configuración. Consulte el ejemplo siguiente.
Ambos pasos son necesarios:
- Access por sí solo no reenvía ningún registro de CDN. Para la mayoría de los destinos de registro, un bloque
defaulthabilitado reenvía tanto los registros de AEM como los registros de CDN. Para Amazon S3 (awsS3), Dynatrace (dynatrace) y New Relic (newRelic), los registros de CDN se reenvían solo cuando el bloquecdnestablece explícitamenteenabled: true. - Si establece
cdn.enabled: trueantes de habilitar el acceso para el programa, la configuración se implementa sin errores, pero no se reenvían registros de CDN a estos destinos.
El bloque cdn hereda todas las demás propiedades del bloque default, incluidas las credenciales, por lo que enabled: true es la única propiedad que necesita agregar:
kind: "LogForwarding"
version: "1"
data:
newRelic:
default:
enabled: true
uri: "https://log-api.newrelic.com/log/v1"
apiKey: "${{NR_API_KEY}}"
cdn:
enabled: true
Para un programa con acceso de, la configuración funciona de la siguiente manera:
default.enabled: truedefault.enabled: true y cdn.enabled: truedefault.enabled: true y cdn.enabled: falsedefault.enabled: true, aem.enabled: false y cdn.enabled: trueAl igual que con otros destinos, las propiedades establecidas en el bloque cdn anulan los valores de default. Para reenviar solo los registros de CDN, establezca aem.enabled: false, como en la última fila.
Para detener el reenvío de registros de CDN, establezca cdn.enabled: false y ejecute la canalización de configuración. El reenvío de registros de CDN a ese destino se detiene cuando se implementa la configuración. Los registros de AEM no se ven afectados.
cdn.enabled: true por ahora significa que las configuraciones existentes solo siguen reenviando registros de AEM, sin costos de ingesta ni tráfico inesperados, y le da tiempo de decidir.default habilitado también reenvía registros de CDN. Para seguir reenviando solo los registros de AEM a uno de estos destinos, establezca cdn.enabled: false para él. Puede configurarlo ahora; tiene el mismo efecto antes y después de esa fecha.Antes de habilitar los registros de CDN, estime el volumen adicional. Los proveedores de registro que facturan por volumen ingerido, como Dynatrace y New Relic, cobran por los registros de CDN del mismo modo que por los registros de AEM.
Para proporcionar comentarios sobre la versión beta, envíe un correo electrónico a aemcs-logforwarding-beta@adobe.com.
Formatos de entrada de registro log-formats
Consulte Registro para AEM as a Cloud Service para ver el formato de cada tipo de registro respectivo (registros de CDN y registros de AEM, incluido Apache/Dispatcher). Algunos destinos de registro agregan o cambian propiedades en las entradas de registro de CDN; por ejemplo, el formato de timestamp para New Relic. Ver entradas de registro de CDN por destino de registro.
Dado que los registros de varios programas y entornos se pueden reenviar al mismo destino de registro, además de la salida descrita en el artículo de registro, se incluirán las siguientes propiedades en cada entrada de registro:
- aem_env_id
- aem_env_type
- aem_program_id
- aem_tier
Por ejemplo, las propiedades podrían tener los siguientes valores:
aem_env_id: 1242
aem_env_type: dev
aem_program_id: 12314
aem_tier: author
Migración desde el reenvío de registros heredado legacy-migration
Antes de que se lograra la configuración del reenvío de registros mediante un modelo de autoservicio, se solicitaba a los clientes que abrieran vales de soporte, donde Adobe iniciaría la integración.
Los clientes que Adobe haya configurado de esta manera pueden adaptarse al modelo de autoservicio según les convenga. Hay varias razones para realizar esta transición:
- Se ha aprovisionado un nuevo entorno (por ejemplo, un nuevo entorno de desarrollo o RDE).
- Cambios en las credenciales o el punto de conexión de Splunk existentes.
- Adobe ha configurado el reenvío de registros antes de que los registros de CDN estuvieran disponibles y desea recibir los registros de CDN.
- Una decisión consciente de adaptarse proactivamente al modelo de autoservicio para que su organización tenga el conocimiento incluso antes de que sea necesario un cambio con distinción de tiempo.
Cuando esté listo para migrar, simplemente configure el archivo YAML como se describe en las secciones anteriores. Utilice la canalización de configuración de Cloud Manager para implementar en cada uno de los entornos donde se debe aplicar la configuración.
Se recomienda, pero no es obligatorio, que se implemente una configuración en todos los entornos para que todos estén bajo control de autoservicio. Si no es así, es posible que olvide qué entornos ha configurado Adobe frente a los configurados de forma automática.
sourcetype enviados a su índice de Splunk pueden haber cambiado, así que ajústelos en consecuencia.