Criar um Parser

Ao criar um parser, você define como extrair entradas de log de um arquivo de log e também como extrair campos de uma entrada de log.

  1. Abra o menu de navegação e clique em Observabilidade e Gerenciamento. Em Log Analytics, clique em Administração.

  2. Os recursos administrativos são listados no painel esquerdo de navegação em Administração. Clique em Parsers.

  3. Na página Parsers, clique em Criar.
  4. Selecione nas opções Tipo de Regex, Tipo de JSON, Tipo de XML ou Tipo Delimitado.

    A página Criar Parser é exibida.

    No caso do Tipo de Regex, a página Criar Parser é aberta no modo Guiado, por padrão. Continue nesse modo se quiser que o Oracle Log Analytics gere a expressão regular para fazer parsing dos logs depois de selecionar os campos. Se você quiser gravar uma expressão regular para parsing, alterne para o modo Avançado.

Observação

Você também pode criar um parser usando um definido pela Oracle como modelo. Selecione um parser definido pela Oracle na página Parsers, clique em Duplicar e modifique os valores nos campos de acordo com sua necessidade.

O Oracle Log Analytics fornece muitos parsers definidos na Oracle para origens de log, como logs do Dump do Java Hotspot, vários sistemas, como Linux, Siebel, PeopleSoft etc., bem como para tipos de entidade, como Oracle Database, Oracle WebLogic Server e Oracle Enterprise Manager Cloud Control. Você pode acessar a lista completa de parsers e origens de log suportados na interface de usuário do Oracle Log Analytics.

Para executar outras ações no analisador, na página Parsers, selecione o Tipo de Criação do analisador e restrinja a pesquisa do analisador selecionando o Tipo de Analisador na barra de pesquisa. Depois de identificar o parser, clique no ícone Ações Ícone Ações na linha do parser:

  • Exibir Detalhes: A página de detalhes do parser é exibida. Exiba os detalhes do parser e edite, se necessário.

  • Editar: A caixa de diálogo Editar Parser é exibida. Você pode modificar as propriedades do parser aqui.

  • Duplicar: Clique nesta opção se quiser criar uma duplicata do parser existente, após o qual você pode modificar a duplicata para personalizá-la.

  • Exportar Definição: Se você estiver usando o Oracle Log Analytics em várias regiões, poderá exportar e reimportar seu conteúdo de configuração do parser. Você também poderá usá-lo se quiser armazenar uma cópia das suas definições fora do Oracle Log Analytics. Consulte Importar e Exportar Conteúdo de Configuração.
  • Excluir: Talvez você precise excluir alguns de seus parsers antigos ou não usados. Para excluir o parser, confirme na caixa de diálogo Excluir Parser. Você só poderá excluir um parser se ele não tiver origens dependentes.

Tratando o Tempo de Entrada de Log no Analisador

Há duas maneiras de fazer parsing do tempo de entrada de log de uma entrada de log. Para parsers de expressão regular, você pode fazer parsing dos componentes de tempo, como dia, mês, hora, minuto etc. Como alternativa, você pode usar a macro TIMEDATE que tenta detectar e fazer parsing automaticamente do formato de data e hora.

  • Parsing time using time components- Available for regular expression type parsers only:

    Para a coleta de logs baseada em agente, esse tipo de parsing é executado no lado da nuvem. Portanto, o uso da CPU é o menor em seu host.

    Os campos a seguir estão disponíveis como componentes de tempo para uso no analisador de tipo de expressão regular. Você pode extrair os campos relevantes de sua entrada de log e mapeá-los para cada um dos campos abaixo correspondentes:

    Nome do Campo Tipo de dados Descrição
    AM/PM String Indica se a hora é AM ou PM na hora de entrada do log
    Dia Longo Componente de dia do horário de entrada do log
    Hora (formato 12 horas) Longo Componente Hora (formato de 12 horas) da hora de entrada do log
    Hora (formato 24 horas) Longo Componente Hora (formato de 24 horas) da hora de entrada do log
    Milissegundos Longo Componente de milissegundos do horário de entrada do log
    Minuto Longo Componente de minuto do horário de entrada do log
    Mês (nome longo) String Componente de mês do horário de entrada do log como nome longo; Exemplo: January.
    Mês (Número) Longo Componente de mês do horário de entrada do log como um número de 1-12
    Mês (Nome Curto) String Componente de mês do tempo de entrada do log como nome curto; Exemplo, Jan.
    Second Longo Segundo componente do horário de entrada do log
    Hora Timestamp Hora e Data da entrada de log; Exemplo: Jan 1, 2000 13:01:01:000 UTC.
    Fuso horário String Valor de fuso horário armazenado no horário de entrada do log; Exemplos: PST, EST, UTC etc.
    Deslocamento do Fuso Horário String Deslocamento de fuso horário armazenado no horário de entrada do log; Exemplo: -8:00.
    Ano (2 dígitos) Longo Componente de ano da hora de entrada do log usando 2 dígitos
    Ano (4 dígitos) Longo Componente de ano da hora de entrada do log usando 4 dígitos
    • Quando o Oracle Log Analytics ingere e analisa os logs, um novo campo Time é criado e todos os valores dos componentes são acumulados juntos para criar o valor desse campo Time.

    • Se valores de granularidade inferior, como minuto, segundo ou milissegundo, estiverem ausentes na entrada de log, eles serão definidos como 0. Se estiverem faltando valores de granularidade maiores que sejam necessários para análise, como ano ou mês, o Oracle Log Analytics tentará determinar o valor mais provável possível usando as heurísticas disponíveis, como fuso horário do host, hora da última modificação do arquivo etc. Por exemplo, se o mês atual for Fevereiro de 2026 e um log for ingerido para Março sem um ano, o Oracle Log Analytics poderá determinar que o ano é 2025 na ausência de qualquer outra informação. O upload sob demanda permite que o usuário forneça informações para resolver datas ambíguas. Além disso, você pode usar a definição de substituição de fuso horário ao ingerir os logs usando o upload sob demanda ou o Agente de Gerenciamento. Consulte Fazer Upload de Logs sob Demanda e Configurar Coleta Contínua de Logs Usando o Agente de Gerenciamento.

    • Quando uma entrada de log não tem um timestamp, o parser cria e exibe o timestamp com base no horário em que os dados de log foram coletados.

    • Quando um registro de log contém um timestamp, mas o fuso horário não está definido, o parser usa o fuso horário do Management Agent.

      Ao usar o Agente de Gerenciamento, se o fuso horário não for detectado de forma adequada, você poderá definir manualmente o fuso horário nos arquivos de configuração do agente. Consulte Especificar Manualmente Fuso Horário e Codificação de Caracteres para Arquivos.

      Ao fazer upload de logs usando upload sob demanda, você pode especificar o fuso horário com seu upload para forçar o fuso horário se não pudermos detectá-lo adequadamente. Se você estiver usando o CLI, consulte Referência de Linha de Comandos: Log Analytics- Fazer Upload. Se você estiver usando REST API, consulte Log Analytics API- Upload.

    • Quando um arquivo de log tem registros de log com vários fusos horários, o parser pode suportar até 11 fusos horários.

    • Quando um arquivo de log exibe algumas entradas de log com um fuso horário e algumas sem, o parser usa o fuso horário localizado anteriormente para as que não têm um fuso horário.

    • Quando você ingere logs usando o Management Agent, se o fuso Horário ou a defasagem de fuso horário não for indicada nos registros de log, o Oracle Log Analytics comparará o horário da última modificação do SO com o timestamp da última entrada do log para determinar o fuso Horário adequado.

  • Usando a macro TIMEDATE para especificar a data e a hora:

    • O Oracle Log Analytics também oferece a opção de permitir que ele tente determinar automaticamente o tempo de entrada do log usando a macro TIMEDATE.

      Para usar a macro TIMEDATE, use-a em sua expressão regular, conforme mostrado no exemplo abaixo, em que você substitui o local inteiro de onde o tempo real, os dados e qualquer fuso horário, os detalhes de deslocamento de fuso horário estão localizados com {TIMEDATE}.

      Exemplo de entrada de log:

      2005-Aug-05 12:45:23,123 AM PST Host1 system:Sample log entry

      Exemplo de expressão regular:

      {TIMEDATE}\s+([^\s]+)\s+([^:]+):\s+(.*)

      Nesse caso, a expressão inicial da entrada é {TIMEDATE}\s+.

    • Para parsers de tipo JSON, XML e CSV, quando você atribui um campo em sua entrada de log a qualquer campo do Oracle Log Analytics que seja do tipo de dados timestamp, a macro TIMEDATE é usada automaticamente.

    • O campo Time é sempre usado para o horário de entrada do log.

    • Se algumas entradas de log não tiverem um ano designado no log, o Oracle Log Analytics tentará identificar o ano com base nas informações disponíveis, como fuso horário de host, horário da última modificação de arquivo etc. O upload on-demand permite que o usuário forneça informações para resolver datas ambíguas. Além disso, você pode usar a definição de substituição de fuso horário ao ingerir os logs usando o upload sob demanda ou o Agente de Gerenciamento. Consulte Fazer Upload de Logs sob Demanda e Configurar Coleta Contínua de Logs Usando o Agente de Gerenciamento.

    • Se, durante a coleta, não for possível estabelecer a hora e data de uma entrada do log, as entradas do log serão armazenadas com a data e hora que os logs foram ingeridos no Oracle Log Analytics.

    • Para coleta de logs baseada em agente, quando você usa a macro TIMEDATE para tempo de parsing, o parsing acontece no lado do agente. Então, ele usa mais CPU no lado do agente. Portanto, recomenda-se usar os componentes de tempo quando se sabe que o formato é sempre o mesmo. A macro TIMEDATE é melhor usada quando o formato de hora é alterado no arquivo de log ou quando o formato de hora é desconhecido antecipadamente quando o parser é gravado.

Criar Parser de Tipo de Expressão Regular

A página Criar Parser é aberta no modo Guiado, por padrão. Continue nesse modo se quiser que o Oracle Log Analytics gere a expressão regular para fazer parsing dos logs depois de selecionar os campos. Para o modo Guiado, consulte ícone de reprodução Vídeo: Usando o Construtor de Parser RegEx. Se quiser gravar uma expressão regular para parsing, alterne para o modo Avançado e continue com as seguintes etapas:

  1. No campo Nome, digite o nome do parser. Por exemplo, digite Custom Audit Logs.

  2. Se preferir, forneça uma descrição adequada ao parser para facilitar a identificação.

  3. No campo Exemplo de Conteúdo de Log, cole o conteúdo de um arquivo de log que você deseja analisar, como o seguinte:

    Jun 20 2020 15:19:29 hostabc rpc.gssd: ERROR: can't open clnt5aa9: No such file or directory
    Jul 29 2020 11:26:28 hostabc kernel: FS-Cache: Loaded
    Jul 29 2020 11:26:28 hostxyz kernel: FS-Cache: Netfs 'nfs' registered for caching
    Aug 8 2020 03:20:01 slc08uvu rsyslogd-2068: could not load module '/lib64/rsyslog/lmnsd_gtls.so', rsyslog error -2078
    [try http://www.rsyslog.com/e/2068 ]
    Aug 8 2020 03:20:36 0064:ff9b:0000:0000:0000:0000:1234:5678 rsyslogd-2066: could not load module '/lib64/rsyslog/lmnsd_gtls.so', dlopen: /lib64/rsyslog/lmnsd_gtls.so: cannot open shared object file: Too many open files
    [try http://www.rsyslog.com/e/2066 ]
    Sep 13 2020 03:36:06 hostnam sendmail: uAD3a6o5009542: from=root, size=263, class=0, nrcpts=1, msgid=<201611130336.uAD3a6o5009542@hostname.example.com>, relay=root@localhost
    Sep 13 2020 03:36:06 hostnam sendmail: uAD3a6o5009542: to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30263, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (uAD3a6KW009543 Message accepted for delivery)
    Sep 20 2020 08:11:03 hostnam sendmail: STARTTLS=client, relay=userv0022.example.com, version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256]]>

    Esta é uma entrada de log de várias linhas porque as entradas 4 e 5 abrangem várias linhas.

  4. No campo Expressão Regular de Parsing, digite a expressão regular para fazer parsing dos campos. Cada par de parênteses indica a cláusula de expressão regular a ser extraída para um único campo.

    A expressão de parsing é exclusiva de cada tipo de log e depende do formato das entradas de log reais. Neste exemplo, digite:

    (\w+)\s+(\d+)\s+(\d+)\s+(\d+):(\d+):(\d+)\s+([^\s]+)\s+([^:]+):\s+(.*)
    Observação

    • Não inclua espaços antes ou depois do conteúdo.

    • A expressão regular deve corresponder ao texto completo do registro de log.

    • Se você tiver incluído caracteres ocultos na expressão de parsing, a interface Criar Parser emitirá uma mensagem de advertência:

      Parser expression has some hidden control characters.

      Para desativar essa resposta padrão, desmarque a caixa de seleção Mostrar caracteres de controle ocultos quando a mensagem de erro for exibida.

    Para saber mais sobre a criação de expressões de parsing, consulte Expressões de Parsing de Amostra.

  5. Selecione a Abrangência do Registro de Log apropriada.

    A entrada de log pode ser uma linha única ou várias linhas. Se você escolher várias linhas, digite a expressão inicial do registro de log.

    Defina a expressão regular para ser a regra mínima necessária para identificar com sucesso o início de uma nova entrada de log. No exemplo, a expressão inicial pode ser:
    (\w+)\s+(\d+)\s+(\d+)\s+

    Isso indica que o início de uma nova entrada de log ocorre sempre que uma nova linha começa com o texto que corresponde a essa expressão inicial de entrada.

    Você também pode digitar a expressão final. Use Expressão Final para indicar o fim do registro de log. Quando um registro de log fica gravado no arquivo por um longo período e você deseja garantir que a entrada de log inteira seja coletada, use a expressão regular final. O agente aguarda até que o padrão de regex final seja correspondido para coletar o registro de log. As mesmas regras de formato se aplicam à expressão final da Expressão Inicial da Entrada.

    Marque a caixa de seleção Tratar arquivo inteiro como uma única entrada de log, se necessário. Essa opção permite fazer parsing e armazenar um arquivo de log inteiro como uma única entrada de log. Isso é particularmente útil ao fazer parsing de origens de log, como logs de Dump do Java Hotspot, lista RPM de logs de pacotes e assim por diante. Se a entrada de log tiver muito texto que você deseja pesquisar, talvez você queira considerar marcar a caixa de seleção Ativar pesquisa de texto bruto neste conteúdo. Essa opção permite pesquisar os registros de log com o campo Texto Bruto. Quando ativado, você pode exibir o conteúdo do log original com o texto bruto.

  6. Na guia Campos, selecione o campo relevante para armazenar cada valor capturado da expressão regular.

    Para criar um novo campo, clique no ícone Ícone Criar Campo. A caixa de diálogo Criar Campo Definido pelo Usuário é aberta. Digite os valores para Nome, Tipo de Dados, Descrição e use a caixa de seleção Campo com Diversos Valores, conforme aplicável aos seus logs. Para obter informações sobre os valores a serem digitados, consulte Criar um Campo. Para remover o campo selecionado na linha, clique no ícone Ícone Limpar campo.

    Para cada valor capturado, selecione o campo no qual deseja armazenar os dados. O primeiro campo capturado no exemplo pode ser digitado da seguinte forma:

    • Nome do Campo: Mês (Nome Abreviado)

    • Tipo de Dados do Campo: STRING

    • Descrição do Campo: O componente de mês do tempo de entrada de log como nome abreviado, como Jan

    • Expressão do Campo: (\w{3})

    No exemplo de log anterior, você mapearia os campos na seguinte ordem:

    1. Mês (nome abreviado)
    2. Dia
    3. Ano (4 dígitos)
    4. Nome do Host (Servidor)
    5. Serviço
    6. Mensagem
  7. Na guia Funções, clique em Adicionar Função para opcionalmente adicionar uma função para pré-processar as entradas de log. Consulte Pré-processar Entradas de Log.

  8. Clique na guia Teste de Parser para ver como o parser recém-criado extrai valores do conteúdo do log.

    Você pode exibir as entradas de log do conteúdo de exemplo fornecido anteriormente. Use-o para determinar se o parser que você definiu funciona com sucesso.

    Se a expressão regular falhar em uma entrada de log, o status da correspondência mostrará qual parte da expressão funcionou em verde e a parte que falhou em vermelho. Isso ajuda a identificar qual parte da expressão regular precisa ser corrigida.

    Você pode exibir a lista de eventos que falharam no teste do parser e os detalhes da falha. Você também pode exibir a contagem de etapas que pode dar uma ideia do custo da expressão regular. O ideal é que esse valor seja o mais baixo possível. Qualquer valor abaixo de 1000 pode ser aceitável, mas às vezes é necessário um regex mais dispendioso. Se o regex tiver muitas etapas, poderá resultar em maior uso de CPU no host do agente e processamento mais lento dos logs. Isso atrasará a disponibilidade das entradas de log no Log Explorer. Em casos extremos em que a expressão regular é muito dispendiosa, nós vamos ignorar o parsing da entrada de log e de quaisquer outras entradas coletadas no mesmo período de coleta.

    Se a expressão regular falhar, o ícone Ícone AI do LoganAI será exibido ao lado do botão Executar teste. Observe que o ícone só será exibido se o administrador tiver ativado o LoganAI para a tenancy e a região atuais. Clique neste ícone para obter a recomendação do LoganAI para corrigir a expressão regular. LoganAI gera uma nova expressão regular que pode funcionar para você. Ele fornece uma comparação entre as expressões antigas e novas. Você pode selecionar Aceitar recomendação para usar a expressão regular sugerida pelo LoganAI, na qual a expressão regular antiga é substituída pela nova expressão regular e o teste do parser é executado automaticamente novamente. Caso contrário, você poderá clicar no ícone novamente para usar o LoganAI para gerar novamente a expressão regular. A nova expressão regular pode não ser a mesma sugerida pelo LoganAI anteriormente.

Clique em Salvar para salvar o novo parser que você acabou de criar.

Para interromper a criação do parser, clique em Cancelar. Quando você clicar em Cancelar, perderá qualquer progresso já feito na criação do parser do tipo Regex.

Criar Parser de Tipo JSON

Observação

Se cada uma das suas entradas de log não contiver os dados de log contextual/de cabeçalho, você poderá enriquecer as entradas de log com os dados de log de cabeçalho relevantes. Você pode pré-processar as entradas de log e enriquecer o conteúdo com informações de cabeçalho especificando uma função de detalhe de cabeçalho seguindo estas etapas:

  1. Primeiro crie um parser de conteúdo de cabeçalho fornecendo o conteúdo de log de exemplo usando o qual o caminho JSON pode ser identificado para selecionar as informações do cabeçalho.

  2. Defina um segundo parser para analisar o corpo restante da entrada de log.

  3. Para o parser de corpo, adicione uma instância da função Detalhes do Cabeçalho e selecione o parser de cabeçalho definido na etapa 1.

  4. Adicione o parser de corpo que você definiu na etapa 2 a uma origem de log e associe a origem de log a uma entidade para iniciar a coleta de logs.

Consulte o tópico adicional: Tratando Várias Formas JSON em um Único Parser JSON

Para criar um parser JSON:

  1. No campo Parser, digite o nome do parser. Por exemplo, digite Custom API Log.

  2. Selecione o tipo de parser como JSON.

  3. Se preferir, forneça uma descrição adequada ao parser para facilitar a identificação.

  4. No campo Exemplo de Conteúdo de Log, cole o conteúdo de um arquivo de log que você deseja analisar, como o seguinte:

    {
      "name": "helloapi",
      "hostname": "banana.local",
      "pid": 40442,
      "level": 30,
      "req": {
        "method": "GET",
    	"url": "/hello?name=paul",
    	"headers": {
    	  "user-agent": "curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1/2/3",
    	  "host": "0.0.0.0:8080",
    	  "accept": "*/*"
    	},
    	"remoteAddress": "127.0.0.1",
    	"remotePort": 59834
      },
      "msg": "start",
      "time": "2012-03-28T17:39:44.880Z",
      "v": 0
    }

    Com base no conteúdo do log de exemplo, os campos são selecionados e exibidos na guia Campos, como no seguinte exemplo:


    Guia Campos: As colunas exibidas na tabela são número do campo, caminho JSON, nome, tipo de dados e descrição

  5. Na guia Campos, para o caminho JSON específico, selecione o nome do campo nos campos definidos disponíveis.

    Para criar um novo campo, clique no ícone Ícone Criar Campo. A caixa de diálogo Criar Campo Definido pelo Usuário é aberta. Digite os valores para Nome, Tipo de Dados, Descrição e use a caixa de seleção Campo com Diversos Valores, conforme aplicável aos seus logs. Para obter informações sobre os valores a serem digitados, consulte Criar um Campo. Para remover o campo selecionado na linha, clique no ícone Ícone Limpar campo.

    O caminho raiz padrão selecionado é $. Se quiser alterar o caminho raiz JSON, expanda a seção Opções Avançadas e selecione o Caminho JSON de Entrada de Log no menu.

  6. Na guia Funções, clique em Adicionar Função para, opcionalmente, adicionar uma função a entradas do log de pré-processamento com a função do analisador de cabeçalho. Consulte Pré-processar Entradas de Log.
  7. Depois que os campos forem selecionados, vá para a guia Teste de Parser para exibir o status de correspondência e os campos selecionados no conteúdo do log de exemplo.
  8. Clique em Salvar para salvar o novo parser que você acabou de criar.

Para interromper a criação de um parser do tipo JSON e alternar para a criação de um parser do tipo regex, em Tipo, selecione Regex.

Tratando Várias Formas JSON em um Único Parser JSON

Se houver várias entradas de log JSON com o nó raiz como $ para a mesma origem, adicione todos os logs JSON de amostra ao Conteúdo de exemplo de um parser e mapeie a união dos campos contidos em todas as amostras.

Por exemplo, você pode ter um parser JSON e uma origem usando esse parser. Considere que esse log pode ter duas formas. Coloque os dois exemplos de entradas de log (formas) no campo Exemplo de conteúdo da seguinte forma:

{ "key_A":value1, "key_B":value2, "key_C":value3, "key_E":value4, "key_F",value5 } { "key_A":value6, "key_B":value7, "key_D":value8, "key_G":value9, "key_H":value10 }

Em seguida, na listagem de campos do parser, você pode ver as chaves key_A, key_B, key_C, key_D, key_E, key_F, key_G e key_H a serem mapeadas.

Você pode mapear essas chaves para campos como abaixo:

Tecla Campo
key_A Hora
key_B IP do Host (Cliente)
key_C Mensagem
key_D Mensagem
key_E Gravidade
key_F Nome do Usuário
key_G Componente
key_H Serviço

No exemplo acima, as chaves JSON key_C e key_D aparecem em logs diferentes. Estes são considerados mutuamente exclusivos. Geralmente, key_C e key_D não aparecem juntos em uma forma de log. Nesse caso, ambos podem ser mapeados para um único campo Mensagem. Quaisquer correspondências de chaves, são armazenadas no campo Message.

Se key_C e key_D não forem mutuamente exclusivos e, em uma terceira forma de entrada de log, key_C e key_D aparecerem juntas, a primeira a correspondência será armazenada no campo Message.

Criar Parser de Tipo XML

  1. No campo Parser, digite o nome do parser. Por exemplo, digite Custom Database Audit Log.

  2. Selecione o tipo de parser como XML.

  3. Se preferir, forneça uma descrição adequada ao parser para facilitar a identificação.

  4. No campo Exemplo de Conteúdo de Log, cole o conteúdo de um arquivo de log que você deseja fazer parsing, como o seguinte ExampleA:

    <AuditRecord><Audit_Type>1</Audit_Type><Session_ld>201073</Session_ld><Statementid>13</Statementid><Entryld>6</Entryld>
    <Extended_Timestamp>2016-09-09T01:26:07.832814Z</Extended_Timestamp><DB_User>SYSTEM</DB_User><OS_User>UserA</OS_User><Userhost>host1</Userhost>
    <OS_Process>25839</OS_Process><Terminal>pts/4</Terminal><Instance_Number>0</Instance_Number><Object_Schema>HR</Object_Schema>
    <Object_Name>EMPLOYEES</Object_Name><Action>17</Action>
    <Returncode>0</Returncode><Sen>§703187</Sen><AuthPrivileges>--------¥-----</AuthPrivileges>
    <Grantee>SUMON</Grantee>
    <Priv_Used>244</Priv_Used><DBID>2791516383</DBID><Sql_Text>GRANT SELECT ON hr.employees TO sumon</Sql_Text></AuditRecord>

    Com base no conteúdo do log de exemplo, o Oracle Log Analytics identifica automaticamente a lista de elementos XML que representam os registros de log.

  5. Opcionalmente, ative a caixa de seleção Ignorar namespace para ignorar o namespace no caminho XML.

  6. Opcionalmente, ative a caixa de seleção Ativar reconhecimento posicional para detectar vários valores de um elemento em um caminho XML, como no caso de array de elementos. Por exemplo, para o seguinte exemplo de conteúdo de log ExampleB:

    <ListOfTrackingFields>
        <TrackingField>
            <Name>NameA</Name>
        </TrackingField>
        <TrackingField>
            <Name>NameB</Name>
        </TrackingField>
        <TrackingField>
            <Name>NameC</Name>
        </TrackingField>
        <TrackingField>
            <Name>NameD</Name>
        </TrackingField>
        <TrackingField>
            <Name>NameE</Name>
        </TrackingField>
    </ListOfTrackingFields>

    Se o reconhecimento posicional não estiver ativado, você ficará restrito ao caminho XML /ListOfTrackingFields/TrackingField/Name, que detectaria apenas o primeiro valor de Name. Se você ativar a conscientização posicional, os seguintes 5 valores de Name no elemento TrackingField serão detectados: NameA, NameB, NameC, NameD, NameE, se todos os caminhos XML correspondentes forem configurados.

  7. No menu Caminho XML de Entrada de Log, selecione o elemento XML adequado aos registros de log de interesse. Para o exemplo acima de conteúdo de log ExampleA, selecione /AuditRecord.

    Com base na seleção do caminho XML, os campos são selecionados e exibidos na guia Campos. No conteúdo do log de exemplo anterior, os elementos destacados são qualificados para os campos. Para o caminho XML/AuditRecord de exemplo, o caminho XML do campo seria /AuditRecord/<highlighted_element>, por exemplo, /AuditRecord/Audit_Type.

  8. Na guia Campos, para o caminho XML específico, selecione o nome do campo nos campos definidos disponíveis.

    Para criar um novo campo, clique no ícone Ícone Criar Campo. A caixa de diálogo Criar Campo Definido pelo Usuário é aberta. Digite os valores para Nome, Tipo de Dados, Descrição e use a caixa de seleção Campo com Diversos Valores, conforme aplicável aos seus logs. Para obter informações sobre os valores a serem digitados, consulte Criar um Campo. Para remover o campo selecionado na linha, clique no ícone Ícone Limpar campo.

  9. Depois que os campos forem selecionados, vá para a guia Teste de Parser para exibir o status de correspondência.


    Caixa de diálogo de criação do parser: A guia de teste do parser e o status de correspondência do teste

  10. Clique em Salvar para salvar o novo parser que você acabou de criar.

Para interromper a criação de um parser do tipo XML e alternar para a criação de um parser do tipo regex, em Tipo, selecione Regex.

Criar Parser de Tipo Delimitado

  1. Informe o Nome do parser. Por exemplo, digite Comma Separated Custom App Log.

  2. Se preferir, forneça uma descrição adequada ao parser para facilitar a identificação.

  3. Selecione o tipo de parser como Delimitado.

  4. Em Delimitador, selecione o tipo de delimitador usado nos logs para separar os campos. Por exemplo, vírgula, ponto e vírgula, espaço ou guia. Caso seja diferente das opções listadas, selecione Outros e especifique o caractere delimitador no espaço fornecido.

    Considere o seguinte exemplo de conteúdo de log:

    helloapi,"host,local", 65427, 29, start, 2021-08-28T17:39:44.880Z

    No exemplo acima, vírgula (,) é o delimitador.

    Certifique-se de que o caractere Delimitador especificado seja diferente do Qualificador selecionado a seguir.

  5. Opcionalmente, selecione o Qualificador usado para encapsular o texto de um campo em seus logs. Selecione Cota Dupla ou Cota Única.

    O qualificador de texto é usado quando os delimitadores estão contidos nos dados do campo. Considere um cenário em que field1 tenha o valor host,local que contém um caractere delimitador (,) e um qualificador de texto não seja usado. Em seguida, os dados que ocorrem após o delimitador (local) serão considerados como o valor do próximo campo.

    No conteúdo do log de exemplo da etapa anterior, aspas duplas (") é o qualificador.

    Observação

    Para os valores dos campos da string de tipo de dados, o caractere de espaço antes e depois do qualificador também será considerado como parte da string. Verifique se o qualificador está posicionado ao lado do delimitador para que o valor da string corresponda. Por exemplo, no ,"host,local",, o caractere de espaço após o primeiro delimitador é removido. Além disso, o caractere de espaço antes do último delimitador é removido. Portanto, o valor efetivo do campo de string correspondente é host,local, como pode ser visto no resultado do teste do parser posteriormente.
  6. Opcionalmente, em Cabeçalho, cole a linha de cabeçalho do seu log que poderá ser mapeada para a Coluna de Cabeçalho na guia Campos. Por exemplo,

    name, hostname, pid, level, msg, time

    Quando você especifica um Cabeçalho, todas as linhas de log nos logs reais que correspondem exatamente ao cabeçalho são filtradas.

  7. No campo Exemplo de Conteúdo de Log, cole o conteúdo de um arquivo de log que você deseja analisar, como o seguinte:

    helloapi,"host,local", 65427, 29, start, 2021-08-28T17:39:44.880Z

    Com base no conteúdo do log de exemplo, os campos são selecionados e exibidos na guia Campos, como no seguinte exemplo:

  8. Na guia Campos, para a coluna do cabeçalho, selecione o nome do campo entre os campos definidos disponíveis. No entanto, você pode mapear seletivamente apenas as colunas de cabeçalho preferidas, e não é necessário mapear o campo para cada coluna de cabeçalho.
    A guia Campos no fluxo da IU de criação do parser delimitado

    Para criar um novo campo, clique no ícone Ícone Criar Campo. A caixa de diálogo Criar Campo Definido pelo Usuário é aberta. Digite os valores para Nome, Tipo de Dados, Descrição e use a caixa de seleção Campo com Diversos Valores, conforme aplicável aos seus logs. Para obter informações sobre os valores a serem digitados, consulte Criar um Campo. Para remover o campo selecionado na linha, clique no ícone Ícone Limpar campo.

  9. Depois que os campos forem selecionados, vá para a guia Teste de Parser para exibir o status de correspondência e os campos selecionados no conteúdo do log de exemplo.
    A guia de teste do parser no fluxo da IU de criação do parser de tipo delimitado

  10. Clique em Criar Parser para salvar o novo parser que você acabou de criar.

Para abortar a criação de um parser do tipo Delimitado e alternar para criar outro tipo de parser, selecione-o em Tipo.

Mapear o Campo Base para um Parser

Se o conteúdo do log original for encapsulado com informações adicionais, você poderá mapear o campo base que contém o conteúdo do log original para um parser e extrair os campos nesse registro de log original.

Vamos considerar que o seu conteúdo de log original é como mostrado abaixo:

####<Feb 01, 2021 10:28:27 AM PST> <Info> <Diagnostics> <soaapps.example.com> <excstg_soa> <[ACTIVE] ExecuteThread: '34' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <kernel_version> <123456> <[severity-value:64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-320145> <Size based data retirement operation completed on archive HarvestedDataArchive. Retired 9,720 records in 11,242 ms.>

Quando o mesmo conteúdo de log é enviado pela primeira vez ao OCI Logging e, por meio do Connector Hub enviado ao Oracle Log Analytics, um wrapper JSON é adicionado ao conteúdo de log original. Por exemplo,

{
  "data": {
    "Labels": "LogPath:/u01/APPLTOP/instance/wlslogs/FADomain/servers/ServiceServer_1/logs/ServiceServer_1.log;ServiceName:Host;ServiceType:Oracle_Host;LogSet:TEST_POD;HostName:examplehost.oraclecloud.com;IP:192.0.2.1;WLS:NA;Domain:NA;AppName:myApp;Customer:CompanyA, (U.S.) Corp;CustomerType:NonHypercare;PODType:TEST;PODSize:S0;DC:CDC;Version:11.13.20.10.0;",
    "action": "ACTION",
    "msg": "####<Feb 01, 2021 10:28:27 AM PST> <Info> <Diagnostics> <soaapps.example.com> <excstg_soa> <[ACTIVE] ExecuteThread: '34' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <kernel_version> <123456> <[severity-value:64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-320145> <Size based data retirement operation completed on archive HarvestedDataArchive. Retired 9,720 records in 11,242 ms.>"
  },
  "id": "123123123",
  "oracle": {
    "compartmentid": "ocid1.compartment.oc1..aaaaaaaauniqueID",
    "ingestedtime": "2021-02-01T18:32:49.204Z",
    "loggroupid": "ocid1.loggroup.oc1.iad.amaaaaaauniqueID",
    "logid": "ocid1.log.oc1.iad.amaaaaaayuniqueID",
    "tenantid": "ocid1.tenancy.oc1..aaaaaaaaetuniqueID"
  },
  "source": "FA-APPS",
  "specversion": "1.0",
  "time": "2021-02-01T11:48:43.091Z",
  "type": "FA Unified Apps Logs"
}

No exemplo acima, o conteúdo do log original está presente no campo base $.data.msg.

Observe que no exemplo discutido, o conteúdo do log tem um wrapper JSON. No entanto, você pode seguir essas etapas mesmo se o conteúdo do log original e os wrappers estiverem em qualquer formato de parser suportado e os logs forem ingeridos em qualquer método suportado.

Para extrair os campos no conteúdo do log original, siga estas etapas:

  1. Com base no tipo de conteúdo de log original, identifique ou crie um analisador para selecionar os campos relevantes do conteúdo de log original. Consulte Criar um Parser.

    Este parser será usado como um parser mapeado dentro do parser wrapper que você criará a seguir.

  2. Com base no tipo de conteúdo do encapsulador, crie o parser para ele seguindo as etapas em Criar um Parser.

    Esse parser será chamado de parser wrapper nas etapas a seguir.

  3. Para o analisador do encapsulador, forneça um exemplo de conteúdo de log que tenha um encapsulador sobre o conteúdo de log original.

    No caso do parser JSON, o caminho raiz padrão selecionado é $. Se quiser alterar o caminho raiz JSON, expanda a seção Opções Avançadas e selecione o Caminho JSON de Entrada de Log no menu.

  4. Na guia Campos, correspondente ao campo base que tem o conteúdo do log original, clique no menu Ações Menu Ações e selecione Mapear campos por meio de um parser. A caixa de diálogo em que é possível selecionar o analisador é aberta.

    No exemplo acima, a linha para a qual um parser mapeado deve ser adicionado é $.data.msg.

    Em um analisador wrapper, você pode mapear apenas um campo base para um analisador mapeado.

  5. Na caixa de diálogo Mapear campos por meio de um parser, selecione o parser usando o qual os campos do campo base devem ser extraídos.

    Opcionalmente, selecione uma das ações Base64 decode and unzip ou Base64 decode a serem executadas no campo:

    • Base64 decodificar e descompactar: Selecione esta opção se o campo base for um arquivo zip codificado em Base64. O campo base é decodificado e descompactado antes da aplicação do analisador mapeado. Como o campo base é um arquivo zip codificado, a aplicação do analisador mapeado resulta na identificação de um ou mais registros de log. Esses registros de log são exibidos como Conteúdo do Log Original no Log Explorer. No entanto, o conteúdo do log do encapsulador não é exibido. Se o analisador do encapsulador contiver mapeamentos de campo, esses campos também serão exibidos.

      Esta ação só pode ser executada em logs coletados usando o Management Agent.

    • Base64 decode: Selecione esta opção se o campo base for Base64 codificado no conteúdo do log original. O campo base é decodificado antes da aplicação do analisador mapeado. Além disso,
      • Use a opção Salvar no Campo para salvar a string decodificada em um campo.
      • Se quiser salvar o valor do campo base decodificado como Conteúdo do Log Original para que ele seja exibido como um registro de log no Log Explorer, selecione a opção Substituir Conteúdo do Log Original. Se essa opção for selecionada, o valor do campo base decodificado será salvo no campo Conteúdo do Log Original e o conteúdo do log do encapsulador será salvo no campo Texto Bruto.

    Clique em Campos do mapa. A guia Campos agora mostra que o campo base está mapeado para o analisador mapeado selecionado e a lista de campos extraídos.

    É possível que o parser mapeado selecionado também tenha um parser mapeado incluído nele. O Oracle Log Analytics suporta dois níveis de parsers mapeados aninhados, por exemplo, Wrapper-parser contém mapped-parser-1 contém mapped-parser-2.

  6. Depois que os campos restantes forem selecionados, na guia Teste do Analisador, execute o teste do analisador para verificar se o status de correspondência e os campos selecionados no conteúdo do log de exemplo.

Pré-processar Entradas de Log

O Oracle Log Analytics fornece as seguintes funções que permitem pré-processar entradas de log e enriquecer as entradas de log resultantes:

Para pré-processar entradas de log ao criar um parser, clique na guia Funções e, em seguida, clique no botão Adicionar Função.

Na caixa de diálogo Adicionar Função resultante, digite um nome para a função, selecione a função necessária e especifique os valores de campo relevantes.

Para testar o resultado da aplicação da função no conteúdo do log de exemplo, clique em Testar. Um resultado comparativo é exibido para ajudar a determinar a precisão dos valores de campo.

Função de Detalhes do Cabeçalho

Essa função permite enriquecer entradas de log com os campos do cabeçalho dos arquivos de log. Essa função é particularmente útil para logs que contêm um bloco de corpo como cabeçalho e, em seguida, entradas no corpo.

Essa função enriquece cada entrada de corpo de log com os campos da entrada de log de cabeçalho. Os Arquivos de Rastreamento de Banco de Dados são um dos exemplos desses logs.

Para capturar o cabeçalho e seus campos correspondentes para enriquecer as entradas de log de corpo baseadas em tempo, no momento da criação do parser, selecione o Parser de Conteúdo de Cabeçalho correspondente na caixa de diálogo Adicionar Função.

Exemplos de Parser de Conteúdo de Cabeçalho Regex:

  • Nesses tipos de logs, o cabeçalho aparece principalmente em algum lugar no início do arquivo de log, seguido de outras entradas. Veja o seguinte: 

    Trace file /scratch/emga/DB1212/diag/rdbms/lxr1212/lxr1212_1/trace/lxr1212_1_ora_5071.trc
    Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
    With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
    Advanced Analytics and Real Application Testing options
    ORACLE_HOME = /scratch/emga/DB1212/dbh
    System name:    Linux
    Node name:  slc00drj
    Release:    2.6.18-308.4.1.0.1.el5xen
    Version:    #1 SMP Tue Apr 17 16:41:30 EDT 2012
    Machine:    x86_64
    VM name:    Xen Version: 3.4 (PVM)
    Instance name: lxr1212_1
    Redo thread mounted by this instance: 1
    Oracle process number: 35
    Unix process pid: 5071, image: oracle@slc00drj (TNS V1-V3)
     
    *** 2020-10-12 21:12:06.169
    *** SESSION ID:(355.19953) 2020-10-12 21:12:06.169
    *** CLIENT ID:() 2020-10-12 21:12:06.169
    *** SERVICE NAME:(SYS$USERS) 2020-10-12 21:12:06.169
    *** MODULE NAME:(sqlplus@slc00drj (TNS V1-V3)) 2020-10-12 21:12:06.169
    *** CLIENT DRIVER:() 2020-10-12 21:12:06.169
    *** ACTION NAME:() 2020-10-12 21:12:06.169
      
    2020-10-12 21:12:06.169: [    GPNP]clsgpnp_dbmsGetItem_profile: [at clsgpnp_dbms.c:345] Result: (0) CLSGPNP_OK. (:GPNP00401:)got ASM-Profile.Mode='legacy'
    *** CLIENT DRIVER:(SQL*PLUS) 2020-10-12 21:12:06.290
      
    SERVER COMPONENT id=UTLRP_BGN: timestamp=2020-10-12 21:12:06
    *** 2020-10-12 21:12:10.078
    SERVER COMPONENT id=UTLRP_END: timestamp=2020-10-12 21:12:10
    *** 2020-10-12 21:12:39.209
    KJHA:2phase clscrs_flag:840 instSid:
    KJHA:2phase ctx 2 clscrs_flag:840 instSid:lxr1212_1
    KJHA:2phase clscrs_flag:840 dbname:
    KJHA:2phase ctx 2 clscrs_flag:840 dbname:lxr1212
    KJHA:2phase WARNING!!! Instance:lxr1212_1 of kspins type:1 does not support 2 phase CRS
    *** 2020-10-12 21:12:39.222
    Stopping background process SMCO
    *** 2020-10-12 21:12:40.220
    ksimdel: READY status 5
    *** 2020-10-12 21:12:47.628
    
    ...
    
    KJHA:2phase WARNING!!! Instance:lxr1212_1 of kspins type:1 does not support 2 phase CRS

    Para o exemplo anterior, usando a função Detalhes do Cabeçalho, o Oracle Log Analytics enriquece as entradas do log do corpo com base no tempo com os campos do conteúdo do cabeçalho.

  • Observe o seguinte exemplo de log:

    Server: prodsrv123
    Application: OrderAppA
     
    2020-08-01 23:02:43 INFO DataLifecycle Starting backup process
    2020-08-01 23:02:43 ERROR OrderModule Order failed due to transaction timeout
    2020-08-01 23:02:43 INFO DataLifecycle Backup process completed. Status=success
    2020-08-01 23:02:43 WARN OrderModule Order completed with warnings: inventory on backorder
    

    No exemplo anterior, temos quatro entradas de log que devem ser capturadas no Oracle Log Analytics. O nome do servidor e o nome do aplicativo só aparecem no início do arquivo de log. Para incluir o nome do servidor e o nome do aplicativo em cada entrada de log:

    1. Defina um parser para o cabeçalho que fará parsing dos campos do servidor e do aplicativo: Server:\s*(\S+).*?Application:\s*(\S+)

    2. Defina um segundo parser para fazer parsing do corpo restante do log: {TIMEDATE}\s(\S+)\s(\S+)\s(.*)

    3. Para o parser de corpo, adicione uma instância da função Detalhes do Cabeçalho e selecione o parser de cabeçalho definido na etapa 1.

    4. Adicione o parser de corpo que você definiu na etapa 2 a uma origem de log e associe a origem de log a uma entidade para iniciar a coleta de logs.

    Você então poderá obter quatro entradas de log com o nome do servidor e o nome do aplicativo adicionados a cada entrada.

Exemplos de Parser de Conteúdo de Cabeçalho JSON:

A seguir estão exemplos de vários casos para Cabeçalho-Detalhe. As entradas de log de detalhes são aprimoradas com campos das entradas de log de cabeçalho. Os campos destacados na entrada de log de detalhes aprimorados são os campos copiados da entrada de log de cabeçalho.

  • PATH JSON: Cabeçalho = $, Detalhes = $.data

    {
      "id" : "id_ERROR1",
      "data": {
      "id" : "id_data_ERROR1",
       "childblock0": {
          "src": "127.0.0.1"
        },
        "childblocks": [
          {
            "childblock": {
              "srchost1": "host1_ERROR1"
            }
          },
          {
            "childblock": {
              "srchost2": "host2_ERROR1"
            }
          }
        ],
        "hdr": {
          "time_ms": "2021-05-21T04:27:18.89714589Z",
          "error": "hdr_ERROR1"
        }
      },
      "compartmentName": "comp_name_ERROR1",
      "eventName": "GetBucket_ERROR1"
    }

    Entradas de log extraídas e aprimoradas:

    Entrada de log do cabeçalho: {"id":"id_ERROR1","compartmentName":"comp_name_ERROR1","eventName":"GetBucket_ERROR1"}

    Entrada de log de detalhes: {"compartmentName":"comp_name_ERROR1","eventName":"GetBucket_ERROR1", "id": "id_data_ERROR1", "childblock0":{"src":"127.0.0.1"},"childblocks":[{"childblock":{"srchost1":"host1_ERROR1"}},{"childblock":{"srchost2":"host2_ERROR1"}}],"hdr":{"time_ms":"2021-05-21T04:27:18.89714589Z","error":"hdr_ERROR1"}}

    O campo id está disponível no cabeçalho e nos detalhes. O campo de detalhes é selecionado neste caso.

  • PATH JSON: Cabeçalho = $.metadata, Detalhes = $.datapoints[*]

    Neste exemplo, o primeiro bloco tem cabeçalho e detalhes, mas o segundo bloco tem apenas entrada de log de detalhes.

    {
       "namespace":"oci_streaming",
       "resourceGroup":null,
       "name":"GetMessagesThroughput.Count1",
       "dimensions":{
          "region":"phx1",
          "resourceId":"ocid1.stream.oc1.phx.1"
       },
       "datapoints":[
          {
             "timestamp":1652942170000,
             "value":1.1,
             "count":11
          },
          {
             "timestamp":1652942171001,
             "value":1.2,
             "count":12
          }
       ],
       "metadata":{
          "displayName":"Get Messages 1",
          "unit":"count1"
       }
    }
    {
       "namespace":"oci_streaming",
       "resourceGroup":null,
       "name":"GetMessagesThroughput.Count1",
       "dimensions":{
          "region":"phx1",
          "resourceId":"ocid1.stream.oc1.phx.1"
       },
       "datapoints":[
          {
             "timestamp":1652942170002,
             "value":2.1,
             "count":21
          },
          {
             "timestamp":1652942171003,
             "value":3.2,
             "count":32
          }
       ]
    }

    Entradas de log extraídas e aprimoradas:

    Entrada de log do cabeçalho: {"displayName":"Get Messages 1","unit":"count1"}

    Entrada de log de detalhes: {"displayName":"Get Messages 1","unit":"count1", "timestamp":1652942170000,"value":1.1,"count":11}

    Entrada de log de detalhes: {"displayName":"Get Messages 1","unit":"count1", "timestamp":1652942171001,"value":1.2,"count":12}

    Entrada de log de detalhes: {"timestamp":1652942170002,"value":2.1,"count":21}

    Entrada de log de detalhes: {"timestamp":1652942171003,"value":3.2,"count":32}

  • PATH JSON: Cabeçalho = $.instanceHealths:[*], Detalhes = $.instanceHealths[*].instanceHealthChecks[*]

    {
      "reportType": "Health Status Report 1",
      "instanceHealths": [
        {
          "instanceHealthChecks": [
            {
              "HealthCheckName": "Check-A1",
              "Result": "Passed",
              "time": "2022-11-17T06:05:01Z"
            },
            {
              "HealthCheckName": "Check-A2",
              "Result": "Passed",
              "time": "2022-11-17T06:05:01Z"
            }
          ],
          "Datacenter-A" : "Remote A"
        }
      ]
    }

    Entradas de log extraídas e aprimoradas:

    Entrada de log do cabeçalho: {"Datacenter-A":"Remote A"}

    Entrada de log de detalhes: {"Datacenter-A":"Remote A", "HealthCheckName":"Check-A1","Result":"Passed","time":"2022-11-17T06:05:01Z"}

    Entrada de log de detalhes: {"Datacenter-A":"Remote A", "HealthCheckName":"Check-A2","Result":"Passed","time":"2022-11-17T06:05:01Z"}

  • PATH JSON: Header1 = $.dimensions, Header2 = $.metadata, Detalhes = $.datapoints[*]

    Neste exemplo, dois cabeçalhos diferentes são aplicados.

    {
       "namespace":"oci_streaming",
       "resourceGroup":null,
       "name":"GetMessagesThroughput.Count1",
       "dimensions":{
          "region":"phx1",
          "resourceId":"ocid1.stream.oc1.phx.1"
       },
       "datapoints":[
          {
             "timestamp":1652942170000,
             "value":1.1,
             "count":11
          },
          {
             "timestamp":1652942171001,
             "value":1.2,
             "count":12
          }
       ],
       "metadata":{
          "displayName":"Get Messages 1",
          "unit":"count1"
       }
    }

    Entradas de log extraídas e aprimoradas:

    Entrada de log Header1: {"region":"phx1","resourceId":"ocid1.stream.oc1.phx.1"}

    Entrada de log Header2: {"displayName":"Get Messages 1","unit":"count1"}

    Entrada de log de detalhes: {"region":"phx1","resourceId":"ocid1.stream.oc1.phx.1", displayName":"Get Messages 1","unit":"count1", "timestamp":1652942170000,"value":1.1,"count":11}

    Entrada de log de detalhes: {"region":"phx1","resourceId":"ocid1.stream.oc1.phx.1", displayName":"Get Messages 1","unit":"count1", "timestamp":1652942171001,"value":1.2,"count":12}

  • PATH JSON: Header1 = $.hdr1, Header2 = $.hdr2, Detalhes = $.body

    Nesse caso, a entrada de log do cabeçalho será associada à entrada de log de detalhes se ambos estiverem no mesmo bloco.

    {
        "hdr1": {
            "module": "mod1",
             "error": "hdr1_error1"
        }
    }
    {
        "body": {        
            "id": "data_id_ERROR2",
             "error": "body_ERROR2"
        }
    }
    {
        "hdr2": {
    
            "module": "mod3",
            "error": "hdr2_error3"
        }
        "body": {        
            "id": "data_id_ERROR4",
            "error": "body_ERROR4"
        }
    }

    Entradas de log extraídas e aprimoradas:

    Entrada de log do cabeçalho: {"id":"data_id_ERROR1","error":"hdr1_error1"}

    Entrada de log de detalhes: {"id":"data_id_ERROR2","error":"body_ERROR2"}

    Entrada de log do cabeçalho: {"module":"mod3","error":"hdr2_error3"}

    Entrada de log de detalhes: {"module":"mod3", "id":"data_id_ERROR4","error":"body_ERROR4"}

    Observe que na segunda entrada de log Detalhes, o valor de error é selecionado nos detalhes quando o mesmo elemento está disponível no cabeçalho, bem como nos detalhes.

  • PATH JSON: Cabeçalho = $, Details1 = $.JDBC, Details2 = $.THREADS

    Nesse caso, uma única entrada de log de cabeçalho é associada a várias entradas de log de detalhes:

    {
      "time": "2024-09-10T00:20:00",
      "instance": "GBOSBMXR1PR",
      "name": "gbosbmxr1pr_server_2",
      "JDBC": [
        {  "name":"XXAlsGoldXADS",
    	"Status": "Running",
    	"Url": "jdbc:oracle:thin:@PSOAPR1"
        }
      ],
      "THREADS": [
        {  "name": "[HOGGING][ACTIVE] ExecuteThread 56 ",
    	"WORKMGR": "OneWayJTACoordinatorWM",
    	"CATEGORY": "Internal", "APPNAME": "None"
        }
      ]
    }

    Entradas de log extraídas e aprimoradas:

    Entrada de log de cabeçalho (aplicada abaixo das entradas de log de detalhes): { "time": "2024-09-10T00:20:00", "instance": "GBOSBMXR1PR", "name": "gbosbmxr1pr_server_2" }

    Entrada de log de detalhes: { "name":"XXAlsGoldXADS", "Status": "Running", "Url": "jdbc:oracle:thin:@PSOAPR1" }

    Entrada de log de detalhes: { "name": "[HOGGING][ACTIVE] ExecuteThread 56 ", "WORKMGR": "OneWayJTACoordinatorWM", "CATEGORY": "Internal", "APPNAME": "None" }

Localizar Função de Substituição

Essa função permite extrair texto de uma linha de log e adicioná-lo a outras linhas de log condicionalmente com base em determinados padrões. Por exemplo, você pode usar esse recurso para adicionar timestamps ausentes aos logs de consulta geral e lenta do MySQL.

A função find-replace tem os seguintes atributos:

  • Expressão Regular de Captura: A expressão regular correspondente a cada linha de log e a expressão regular correspondente denominada texto de grupo é salva na memória a ser usada na Expressão de Substituição.

    • Se a expressão de captura corresponder a uma linha completa, a expressão de substituição não será aplicada à linha de log subsequente. Isso evita ter a mesma linha duas vezes nos casos em que você deseja pré-anexar uma linha ausente.

    • Uma linha correspondente à expressão de captura catch não será processada para a expressão de localização. Portanto, uma operação de localização e substituição não pode ser executada na mesma linha de log.

    • Você pode especificar vários grupos com diferentes nomes.

  • Expressão Regular de Localização: Essa expressão regular especifica o texto a ser substituído pelo texto correspondente aos grupos nomeados na Expressão de Captura das linhas de log.

    • O padrão para correspondência deve ser agrupado.

    • A expressão de localização não é executada nas linhas que corresponderam à expressão de captura. Portanto, uma operação de pesquisa e substituição não pode ser executada na mesma linha de log.

    • A expressão de localização pode ter vários grupos. O texto correspondente em cada grupo será substituído pelo texto criado pela expressão de substituição.

  • Expressão Regular de Substituição: Essa notação personalizada indica o texto para substituir grupos encontrados na Expressão de Localização. Os nomes de grupo devem ser colocados entre parênteses.

    • O nome do grupo deve ser colocado entre colchetes.

    • Você pode incluir o texto estático.

    • O texto criado pela expressão de substituição vai substituir o texto correspondente em todos os grupos na expressão de localização.

Clique no ícone Ajuda ao lado dos campos Expressão Regular de Captura, Expressão Regular de Localização e Expressão Regular de Substituição para exibir a descrição do campo, a expressão de amostra, o conteúdo de amostra e a ação executada. Para adicionar mais expressões de captura, clique em Adicionar Expressão em Expressão Regular de Captura.

Exemplos:

  • O objetivo desse exemplo é obter o timestamp da linha de log que contém o texto # Time: e adicioná-lo às linhas de log que aparecem com # User@Host que não têm timestamp.

    Considere os seguintes dados de log:

    # Time: 160201 1:55:58 
    # User@Host: root[root] @ localhost [] Id: 1
    # Query_time: 0.001320 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1
    select @@version_comment limit 1;
    # User@Host: root[root] @ localhost [] Id: 2
    # Query_time: 0.000138 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 2
    SET timestamp=1454579783;
    SELECT DATABASE();

    Os valores dos atributos Expressão Regular de Captura, Expressão Regular de Localização e Expressão Regular de Substituição podem ser:

    • O valor Expressão Regular de Captura para corresponder à linha de log de timestamp e salvá-la na memória com o nome timestr é ^(?<timestr>^# Time:.*).

    • O valor Expressão Regular de Localização para localizar as linhas às quais a linha de log de timestamp deve ser anexada é (^)# User@Host:.*.

    • O valor Expressão Regular de Substituição para substituir o início das linhas de log que têm o timestamp ausente nelas é (timestr).

    Depois de adicionar a função find-replace, você observará a seguinte alteração nas linhas de log:

    # Time: 160201 1:55:58 
    # User@Host: root[root] @ localhost [] Id: 1
    # Query_time: 0.001320 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1
    select @@version_comment limit 1;
    # Time: 160201 1:55:58 
    # User@Host: root[root] @ localhost [] Id: 2
    # Query_time: 0.000138 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 2
    SET timestamp=1454579783;
    SELECT DATABASE();

    No resultado anterior do exemplo, você pode observar que a função find-replace inseriu o timestamp antes da entrada User@host em cada linha de log que ela encontrou ao pré-processar o log.

  • O objetivo desse exemplo é capturar vários parâmetros e substituir em vários locais nos dados de log.

    Considere os seguintes dados de log:

    160203 21:23:54 Child process "proc1", owner foo, SUCCESS, parent init 
    160203 21:23:54 Child process "proc2" - 
    160203 21:23:54 Child process "proc3" -

    Nas linhas de log anteriores, a segunda e a terceira linhas não contêm os dados do usuário. Portanto, a função find-replace deve selecionar os valores na primeira linha do log e substituir os valores na segunda e terceira linhas.

    Os valores dos atributos Expressão Regular de Captura, Expressão Regular de Localização e Expressão Regular de Substituição podem ser:

    • O valor Expressão Regular de Captura para obter as informações dos usuários foo e init na primeira linha de log e salvá-las na memória com os parâmetrosuser1 e user2 é ^.*?owner\s+(?<user1>\w+)\s*,\s*.*?parent\s+(?<user2>\w+).*.

    • O valor Expressão Regular de Localização para localizar as linhas que têm o caractere de hífen (-) é .*?(-).*.

    • O valor Expressão Regular de Substituição é , owner (user1), UNKNOWN, parent (user2).

    Depois de adicionar a função find-replace, você observará a seguinte alteração nas linhas de log:

    160203 21:23:54 Child process "proc1", owner foo, SUCCESS, parent init 
    160203 21:23:54 Child process "proc2", owner foo, UNKNOWN, parent init 
    160203 21:23:54 Child process "proc3", owner foo, UNKNOWN, parent init

    No resultado anterior do exemplo, você pode observar que a função find-replace inseriu as informações user1 e user2 no lugar da entrada de caractere de hífen (-) em cada linha de log que ela encontrou ao pré-processar o log.

Função de Deslocamento de Tempo

Alguns dos registros de log terão o timestamp ausente, alguns só terão o deslocamento de tempo e outros não terão nenhum dos dois. O Oracle Log Analytics extrai as informações necessárias e designa o carimbo de data/hora a cada registro de log.

Estes são alguns dos cenários e as soluções correspondentes para designar o timestamp usando a função de deslocamento de tempo:

Conteúdo de Log de Exemplo Cenário Solução
Process started May 5, 2020 12:34:53 AM
0.0 host1 debug services started
0.5 host1 debug cache populated 
1.4 host1 info connected to cluster
2.7 host1 error cache failure
Process started May 6, 2020 12:36:54 AM
0.1 host1 debug services started
0.4 host1 debug cache populated 
2.1 host1 info connected to cluster
3.4 host1 error cache failure

O arquivo de log tem um timestamp nos logs iniciais e deslocamentos posteriormente.

Selecione o timestamp dos registros de log iniciais e designe-o aos registros de log posteriores ajustados com deslocamentos de tempo.

1 [Startup] Timestamp=0, 
   PName=USER_START, ProcessID=11961, 
   ClientIP=xx.xx.xx.xx, 
   Date=20-MAR-2020 03:35:17, ServerName=host2, 
   Tracegroup=debug    
10 [CLIENT_TIME] Timestamp=1370, Milliseconds=328   
100 [Local_PU.END,6] Timestamp=16000, 
   StartEvent=99, Duration=0

O arquivo de log tem logs iniciais com deslocamentos de tempo e nenhum log de timestamp anterior.

Selecione o timestamp dos registros de log posteriores e designe-o aos registros de log anteriores ajustados com deslocamentos de tempo.

Quando o deslocamento de tempo é redefinido, ou seja, um deslocamento de tempo menor ocorre em um registro de log, ele é corrigido considerando o timestamp do registro de log anterior como referência.

0.0 host1 debug services started
0.5 host1 debug cache populated
1.4 host1 info connected to cluster
2.7 host1 error cache failure 

O arquivo de log tem registros de log com apenas deslocamentos de tempo e nenhum timestamp.

timestamp do horário da última modificação do arquivo: Depois que todos os registros de log são percorridos, o timestamp é calculado subtraindo o deslocamento de tempo calculado do horário da última modificação do arquivo.

timestamp do nome do arquivo: Quando essa opção é selecionada na IU, o timestamp é selecionado no nome do arquivo, com o formato especificado pela expressão de timestamp.

Os deslocamentos de tempo das entradas de log serão relativos ao timestamp correspondido anteriormente. Nós nos referimos a esse timestamp como base neste documento.

Use a função de deslocamento de tempo do parser para extrair o timestamp e o deslocamento de timestamp dos registros de log. Na caixa de diálogo Adicionar Função:

  1. Onde encontrar o timestamp?: Para especificar de onde o timestamp deve ser obtido, selecione Nome do Arquivo, Horário da Última Modificação do Arquivo e Entrada de Log. Por padrão, Nome do filme é selecionado.

    Se isso não for especificado, a pesquisa do timestamp será executada na seguinte ordem:

    • Percorra os registros de log e procure uma correspondência com o parser de timestamp, que você especificará na próxima etapa.
    • Selecione o horário da última modificação do arquivo como timestamp.
    • Se o horário da última modificação não estiver disponível para o arquivo, selecione o horário do sistema como timestamp.
    • Procure uma correspondência com a expressão de timestamp no nome do arquivo, que você especificará na próxima etapa.
  2. Com base na seleção da origem do timestamp, especifique os seguintes valores:

    • Se você selecionou Nome do Arquivo na etapa 1:

      Expressão de Timestamp: Especifique o regex para localizar o timestamp no nome do arquivo. Por padrão, ele usa a diretiva {TIMEDATE}.

      Nome do Arquivo de Amostra: Especifique o nome do arquivo de um log de amostra que pode ser usado para testar as definições anteriores.

    • Se você selecionou Horário da Última Modificação do Arquivo na etapa 1, selecione o Horário da Última Modificação do Arquivo de Amostra.

    • Se você selecionou Entrada de Log na etapa 1, selecione o parser no menu Parser de Timestamp para especificar o formato de timestamp.

  3. Expressão de Deslocamento de Timestamp: Especifique o regex para extrair o deslocamento de tempo em segundos e milissegundos para designar o timestamp a um registro de log. Somente os grupos sec e msec são suportados. Por exemplo, considere o seguinte registro de log:

    15 25 hostA debug services started

    Você pode usar a expressão (?<sec>\d+)\s+(?<msec>\d+) para extrair segundos (15) e milissegundos (25) e adicioná-los como deslocamento de tempo ao timestamp base para definir o timestamp do registro de log.

    Considere outro registro de log de exemplo:

    15.25 hostA debug services started

    Você pode usar a expressão (?<sec>\d+.\d+) para extrair 15.25 como segundos, que representa 15 segundos e 250 milissegundos, e adicioná-los como deslocamento de tempo ao timestamp base para definir o timestamp do registro de log.

  4. Após as seleções feitas nas etapas anteriores, o conteúdo de log é exibido no campo Exemplo de Log.

    Clique em Testar para testar as definições.

    Você pode exibir a comparação entre o conteúdo do log original e o tempo calculado com base nas suas especificações.

  5. Para salvar a função de deslocamento de tempo anterior, clique em Adicionar.