Os registros atuam como linha de frente para depurar aplicativos AEM em AEM as a Cloud Service, mas dependem do logon adequado no aplicativo AEM implantado.
Toda atividade de log para um serviço de AEM de um ambiente específico (Autor, Publicar/Publicar Dispatcher) é consolidada em um único arquivo de log, mesmo se diferentes pods nesse serviço gerarem as declarações de log.
As IDs de pod são fornecidas em cada instrução de log e permitem a filtragem ou a coleta de declarações de log. As IDs de pod estão no formato de:
cm-p<PROGRAM ID>-e<ENVIRONMENT ID>-aem-<author|publish>-<POD NAME>
cm-p12345-e56789-aem-author-abcdefabde-98765
O AEM as a Cloud Services não oferece suporte a arquivos de log personalizados, no entanto, ele oferece suporte a logs personalizados.
Para logs Java disponíveis em AEM as a Cloud Service (via Cloud Manager ou Adobe I/O CLI), as declarações de log personalizadas devem ser gravadas na variável error.log
. Logs gravados em logs nomeados personalizados, como example.log
, não estará acessível AEM as a Cloud Service.
Os logs podem ser gravados no error.log
usando uma propriedade de configuração OSGi do Sling LogManager no org.apache.sling.commons.log.LogManager.factory.config~example.cfg.json
arquivos.
{
...
"org.apache.sling.commons.log.file": "logs/error.log"
...
}
Os serviços de Autor e Publicação do AEM fornecem AEM logs do servidor de tempo de execução:
aemerror
é o log de erros do Java (encontrado em /crx-quickstart/logs/error.log
no início rápido local do SDK AEM). Estas são as níveis de log recomendados para loggers personalizados por tipo de ambiente:
DEBUG
WARN
ERROR
aemaccess
lista solicitações HTTP para o serviço AEM com detalhesaemrequest
lista solicitações HTTP feitas para AEM serviço e sua resposta HTTP correspondenteSomente o AEM Publish Dispatcher fornece registros de servidor da Web Apache e Dispatcher, pois esses aspectos só existem no nível de Publicação AEM e não no nível de Autor do AEM.
httpdaccess
lista solicitações HTTP feitas no servidor Web Apache/Dispatcher do serviço AEM.httperror
lista mensagens de log do servidor da Web Apache e ajuda na depuração de módulos Apache suportados, como mod_rewrite
.
DEBUG
WARN
ERROR
aemdispatcher
lista mensagens de log dos módulos do Dispatcher, incluindo filtragem e veiculação de mensagens de cache.
DEBUG
WARN
ERROR
O Adobe Cloud Manager permite o download de logs, por dia, por meio de uma ação de Logs de download do ambiente.
Esses logs podem ser baixados e inspecionados por meio de qualquer ferramenta de análise de log.
O Adobe Cloud Manager oferece suporte ao acesso a AEM logs as a Cloud Service por meio do Adobe I/O CLI com o Plug-in do Cloud Manager para a CLI do Adobe I/O.
Primeiro, configurar o Adobe I/O com o plug-in do Cloud Manager.
Assegurar que a ID de programa e a ID de ambiente relevantes foram identificadas e utilizadas list-available-log-options para listar as opções de log usadas para tail ou download logs.
$ aio cloudmanager:list-programs
Program Id Name Enabled
14304 Program 1 true
11454 Program 2 true
11502 Program 3 true
$ aio config:set cloudmanager_programid <PROGRAM ID>
$ aio cloudmanager:list-environments
Environment Id Name Type Description
22295 program-3-dev dev
22310 program-3-prod prod
22294 program-3-stage stage
$ aio cloudmanager:list-available-log-options <ENVIRONMENT ID>
Environment Id Service Name
22295 author aemaccess
22295 author aemerror
22295 author aemrequest
22295 publish aemaccess
22295 publish aemerror
22295 publish aemrequest
22295 dispatcher httpdaccess
22295 dispatcher httpderror
22295 dispatcher aemdispatcher
A CLI do Adobe I/O fornece a capacidade de rastrear logs em tempo real de AEM as a Cloud Service usando o tail-logs comando. A unificação é útil para observar a atividade de log em tempo real, à medida que as ações são executadas no ambiente as a Cloud Service AEM.
$ aio config:set cloudmanager_programid <PROGRAM ID>
$ aio cloudmanager:tail-logs <ENVIRONMENT ID> <SERVICE> <NAME>
Outras ferramentas de linha de comando, como grep
pode ser usada em conjunto com tail-logs
para ajudar a isolar declarações de log de interesse, por exemplo:
$ aio cloudmanager:tail-logs 12345 author | grep com.example.MySlingModel
… exibe somente as declarações de log geradas a partir de com.example.MySlingModel
ou conter essa string neles.
A CLI do Adobe I/O fornece a capacidade de baixar logs de AEM as a Cloud Service usando o logs de download). Isso fornece o mesmo resultado final que o download dos logs da interface do usuário da Web do Cloud Manager, sendo a diferença a variável download-logs
consolida logs ao longo dos dias, com base em quantos dias de logs são solicitados.
$ aio config:set cloudmanager_programid <PROGRAM ID>
$ aio cloudmanager:download-logs <ENVIRONMENT> <SERVICE> <NAME> <DAYS>
Os registros em AEM as a Cloud Service têm vários pods gravando declarações de log neles. Como várias instâncias de AEM são gravadas no mesmo arquivo de log, é importante entender como analisar e reduzir o ruído durante a depuração. Para explicar, faça o seguinte aemerror
snippet de log é usado:
01.01.2020 12:00:00.000 [cm-p12345-e56789-aem-author-abcdefg-1111] *DEBUG* [qtp2078364989-269] com.example.components.impl.ExampleModelImpl Preparing to collect resources
01.01.2020 12:00:01.002 [cm-p12345-e56789-aem-author-abcdefg-2222] *WARN* [qtp40782847611-87] com.example.services.impl.ExampleServiceImpl Unable to resolve resource [ /content/example ] to a resource. Aborting.
01.01.2020 12:00:02.003 [cm-p12345-e56789-aem-author-abcdefg-1111] *ERROR* [qtp2078364989-269] com.example.components.impl.ExampleModelImpl Unable to collect any resources
Usando as IDs de pod, o ponto de dados após a data e a hora, os logs podem ser coletados pelo Pod ou AEM instância dentro do serviço, facilitando o rastreamento e o entendimento da execução do código.
Pod cm-p12345-e56789-aem-author-abcdefg-1111
01.01.2020 12:00:00.000 [cm-p12345-e56789-aem-author-abcdefg-1111] *DEBUG* [qtp2078364989-269] com.example.components.impl.ExampleModelImpl Preparing to collect resources
01.01.2020 12:00:02.003 [cm-p12345-e56789-aem-author-abcdefg-1111] *ERROR* [qtp2078364989-269] com.example.components.impl.ExampleModelImpl Unable to collect any resources
Pod cm-p12345-e56789-aem-author-abcdefg-2222
01.01.2020 12:00:01.002 [cm-p12345-e56789-aem-author-abcdefg-2222] *WARN* [qtp2078364989-269] com.example.services.impl.ExampleServiceImpl Unable to resolve resource [ /content/example ] to a resource. Aborting.
As orientações gerais de AEM são:
DEBUG
DEBUG
WARN
ERROR
Definir o nível de log mais apropriado para cada tipo de ambiente é com AEM as a Cloud Service, os níveis de log são mantidos no código
…e, portanto, requer uma implantação para alteração.
Uma alternativa para definir níveis de log Java estáticos bem conhecidos para cada ambiente é usar AEM como Cloud Service. variáveis específicas do ambiente para parametrizar os níveis de log, permitindo que os valores sejam alterados dinamicamente por meio do CLI do Adobe I/O com o plug-in do Cloud Manager.
Isso requer a atualização das configurações de log do OSGi para usar os espaços reservados da variável específica do ambiente. Valores padrão para níveis de log deve ser definido como de acordo Recomendações do Adobe. Por exemplo:
/apps/example/config/org.apache.sling.commons.log.LogManager.factory.config~example.cfg.json
{
...
"org.apache.sling.commons.log.names": ["com.example"],
"org.apache.sling.commons.log.level": "$[env:LOG_LEVEL;default=DEBUG]"
...
}
Esta abordagem tem desvantagens que devem ser tidas em conta:
As variáveis específicas do ambiente não funcionam para as configurações de log do Apache Web Server ou Dispatcher, pois não são configuradas por meio da configuração OSGi.