Todos os produtos
Search
Central de documentação

Application Real-Time Monitoring Service:Integração de alertas personalizados

Última atualização: Jul 09, 2026

A API de gerenciamento de alertas do ARMS permite ingerir alertas de qualquer origem no ARMS para processamento centralizado.

Etapa 1: Criar uma integração personalizada

  1. Faça login no ARMS console. No painel de navegação à esquerda, escolha Alert Management > Integrations.

  2. Na aba Alert Integration, clique em Custom Integration.

  3. Na caixa de diálogo Create Custom Event Integration, insira um nome para a integração, defina o tempo de autorrecuperação do alerta, adicione uma descrição conforme necessário e clique em Save and Configure.

    Nota

    Tempo de recuperação automática após timeout: se um evento de alerta não for acionado novamente dentro do período especificado, o sistema limpará o evento automaticamente.

Etapa 2: Configurar o endpoint da API

Envie alertas da sua origem de terceiros para o gerenciamento de alertas do ARMS usando a URL do endpoint da API fornecida.

  1. Na página Edit Integration, na seção API Configuration, copie a URL do endpoint e a chave da API.

  2. Na sua origem de alertas de terceiros, use a URL do endpoint para relatar o conteúdo do alerta.

    Exemplo:

    curl -k -H "Content-Type: application/json" -d '{
      "trigger-type": "network",
      "trigger-location": "cn-hangzhou",
      "trigger-severity": "MAX",
      "trigger-policy": "package errors > 5%",
      "trigger-event": "inbound tcp package errors is 20%",
      "trigger-check": "tcp package error percentage",
      "trigger-value": "20",
      "trigger-time": "1629702922000",
      "metadata": [
        {
          "agent": "SERVER",
          "ip": "141.219.XX.XX",
          "fqdn": "websrv1.damenport.org",
          "microServiceId": "ms-login-2251",
          "accountId": "1504000433993",
          "service": "login-0"
        },
        {
          "agent": "CONTAINER",
          "ip": "172.1.XX.XX",
          "fqdn": "websrv2.damenport.org",
          "microServiceId": "ms-login-2252",
          "accountId": "129930302939",
          "service": "login-1"
        }
      ],
      "equipments": [
        {
          "equipmentId": "112"
        },
        {
          "equipmentId": "113"
        }
      ]
    }' "https://alerts.aliyuncs.com/api/v1/integrations/custom/ymQBN******"

    Ao executar o comando curl pela primeira vez, espera-se o retorno do seguinte erro:

    { "requestId":null,"traceId":"0bc3b4a********71e4aa7","code":601,"data":{},"success":false,"errorCode":"Invalid incident, labels.alertname is required","message":"Invalid incident, labels.alertname is required","httpStatusCode":601,"errorCodeParams":null,"dynamicMessage":null

    Após concluir o mapeamento na

    Etapa 3

    e executar o comando novamente, os dados corretos serão retornados.

    Também é possível relatar alertas enviando dados de teste. Na primeira execução, uma mensagem solicitará a conclusão do mapeamento na Etapa 3.

    Na janela pop-up

    Send Test Data

    , após clicar em

    Send

    pela primeira vez, a página exibirá a mensagem

    Upload successful, but no event was generated. Please configure event mapping rules based on the raw data!

    Siga esta instrução para concluir o mapeamento na Etapa 3.

Etapa 3: Configurar o mapeamento de campos de alerta

Na seção Event Mapping, mapeie os campos da origem de alertas de terceiros para os campos de eventos de alerta do ARMS.

Esta seção usa um exemplo para ilustrar o processo.

Cenário: ocorreu um erro de pacote TCP na rede da máquina.

Conteúdo do alerta de terceiros:

{
  "trigger-type": "network",    // Event type: network.
  "trigger-location": "cn-hangzhou",    // Region where the event occurred.
  "trigger-severity": "MAX",    // Custom event severity level, such as MAX, MID, or LOW.
  "trigger-policy": "package errors > 5%",     // Trigger policy.
  "trigger-event": "inbound tcp package errors is 20%",    // Event content: The inbound TCP package error rate for the service is 20%.
  "trigger-check": "tcp package error percentage",    // Event check item: TCP package error rate.
  "trigger-value": "20",    // Alert sample value.
  "trigger-time": "1629702922000",    // Alert start time.
  "metadata": [
    {
      "agent": "SERVER",    // Agent type: server.
      "ip": "141.219.XX.XX",   // IP address.
      "fqdn": "websrv1.damenport.org",    // Service domain name information.
      "microServiceId": "ms-login-2251",    // Microservice ID. If 'agent' is 'CONTAINER', this field is conditionally mapped to the ARMS 'service' field.
      "accountId": "1504000433993",    // User ID. Not included in the alert notification.
      "service": "login-0" // Service ID. If 'agent' is 'SERVER', this field is conditionally mapped to the ARMS 'service' field.
    },
    {
      "agent": "CONTAINER",   // Agent type: container.
      "ip": "172.1.XX.XX",  // IP address.
      "fqdn": "websrv2.damenport.org",    // Service domain name information.
      "microServiceId": "ms-login-2252",   // Microservice ID. If 'agent' is 'CONTAINER', this field is conditionally mapped to the ARMS 'service' field.
      "accountId": "129930302939",  // User ID. Not included in the alert notification.
      "service": "login-1"    // Service ID. If 'agent' is 'SERVER', this field is conditionally mapped to the ARMS 'service' field.
    }
  ],
  "equipments": [  // Another array node.
    {
      "equipmentId": "112"
    },
    {
      "equipmentId": "113"
    }
  ]
}
  1. Na seção Event Mapping, clique em Send Test Data.

  2. Na caixa de diálogo Send Test Data, insira o conteúdo do alerta da sua origem de terceiros no formato JSON e clique em Send.

    Nota
    • Se a mensagem Uploaded. No events are generated. Configure mappings based on the original data. aparecer, significa que os campos da origem do alerta não estão mapeados para os campos dos eventos de alerta do ARMS. Os dados enviados são exibidos na caixa à esquerda, permitindo selecionar os campos de origem ao configurar os mapeamentos.

    • Se a mensagem Uploaded. aparecer, o conteúdo do alerta foi relatado na página Alert Event History. Para mais informações, consulte Visualizar histórico de eventos de alerta.

  3. Na caixa de diálogo Send Test Data, clique em Disable.

  4. Na parte esquerda da seção Event Mapping, clique nos registros de dados para os quais deseja configurar mapeamentos e visualize os detalhes.

  5. No painel direito da seção Event Mapping, configure o mapeamento entre os campos da origem do alerta e os campos de alerta do ARMS.

    Nota

    Caso não receba uma notificação ou e-mail de recuperação após a resolução de um alerta, verifique os seguintes itens:

    1. Confirme se o evento de recuperação e o evento de alerta original foram enviados pelo mesmo canal de integração personalizada.

    2. Verifique se o alerta original ainda está no estado Triggered — ou seja, se não foi recuperado automaticamente por timeout nem fechado manualmente.

    3. Certifique-se de que o valor alertname no evento de recuperação corresponde exatamente ao valor alertname do alerta original.

    1. Opcional: Na seção Select Root Node, especifique se deseja usar o processamento em lote.

      Se seus dados de alerta contiverem um array, você poderá especificá-lo como o nó raiz para processamento em lote.

      Após selecionar Use Batch Processing, selecione o nó de array que deseja processar em lote como o nó raiz.

      Nota

      Se os dados de alerta contiverem vários nós de array, o gerenciamento de alertas do ARMS permitirá selecionar apenas um nó de array para processamento em lote.

      Por exemplo, no alerta de amostra, o nó de array metadata contém dois campos service. Se você selecionar metadata como o nó raiz, os dois campos service sob este nó serão mapeados para o mesmo campo de alerta do ARMS especificado.

      • Ao selecionar um nó raiz, é possível mapear iterativamente os valores do atributo $.metadata[*].service de todos os elementos no array para o campo service do ARMS.

      • Caso não selecione um nó raiz, você pode mapear o valor de um elemento específico, como $.metadata[0].service ou $.metadata[1].service, para o campo service do ARMS.

    2. Opcional:Selecione Configure Alert Recovery Events e configure as condições de campo para limpar alertas.

      Após receber eventos, o ARMS busca alertas que contenham valores de campo especificados e limpa esses alertas. O campo especificado para limpar alertas deve ser equivalente à severidade do alerta no evento. Não é possível usar o campo $.severity para limpar alertas. Por exemplo, se o campo definido para limpeza for {$.eventType ="resolved"}, o sistema limpará automaticamente todos os alertas cujo valor de eventType seja resolved na integração.

    3. Na seção Map Source Fields to Target Fields, mapeie os campos da origem do alerta para os campos de alerta do ARMS.

      Clique no ícone de mapeamento para alterar o método de mapeamento de campos.

      • Direto: o campo da origem do alerta especificado é mapeado diretamente para o campo de alerta correspondente do ARMS.

      • Série: combina vários campos de origem em um só, separados por um delimitador, e mapeia o resultado para um campo de alerta do ARMS. Apenas caracteres especiais são suportados como delimitadores.

        Por exemplo, você pode usar um sublinhado (_) para concatenar os campos $.trigger-type e $.trigger-policy em $.trigger-type_$.trigger-policy, e então mapear o resultado para o campo alertname do ARMS.

      • Condição: mapeia um campo de origem para o campo de destino do ARMS somente quando uma condição especificada é atendida.

        Por exemplo, para o campo agent no nó de array metadata, você pode definir a seguinte condição: se o valor de agent for CONTAINER, mapeie o valor do atributo microServiceId para o campo service do ARMS (condição If). Se o valor de agent for SERVER, mapeie o valor do atributo service para o campo service do ARMS (condição Else If).

      • Tabela de mapeamento: estabelece uma correspondência entre os níveis de severidade do alerta na origem e os níveis de severidade no ARMS. Uma tabela de mapeamento é necessária apenas para o campo de severidade.

      A tabela a seguir descreve os campos de alerta do ARMS.

      Parâmetro Descrição Método de mapeamento de exemplo Campo de origem de exemplo
      alertname Nome do alerta personalizado. Série $.trigger-type, $.trigger-policy
      severity Campo para mapeamento dos níveis de severidade do alerta. É obrigatório configurar uma tabela de mapeamento para este campo, e o método de mapeamento deve ser definido como Direto. Método: Direto (obrigatório)

      Tabela de mapeamento:

      • MAX: P1
      • MID: P2
      • MIN: P3
      $.trigger-severity
      message Informações detalhadas sobre o evento de alerta, utilizadas nas notificações. Comprimento máximo: 15.000 caracteres. Direto $.trigger-event
      value Valor de amostra de uma métrica. Direto $.trigger-value
      imageUrl URL de um gráfico de linhas de métrica, usado para mapear gráficos de métricas do Grafana. Nenhum Nenhum
      check Item de verificação do alerta. Exemplos: CPU, JVM, Application Crash e Deployment. Direto $.trigger-check
      source Origem do evento de alerta. Direto $.metadata[*].ip
      class Tipo de objeto do evento de alerta, como um host. Direto $.trigger-type
      service Serviço de origem relacionado ao negócio, como logService. Condição
      • Se $.metadata[*].agent for CONTAINER, mapeie $.metadata[*].microServiceId para o campo service do ARMS.
      • Se $.metadata[*].agent for SERVER, mapeie $.metadata[*].service para o campo service do ARMS.
      startat Timestamp de início do evento. Direto $.trigger-time
      endat Timestamp de término do evento. Nenhum Nenhum
      generatorUrl URL para os detalhes do evento. Nenhum Nenhum
      Nota

      Se você utilizar o modo de alerta de múltiplas condições (onde uma única regra de alerta inclui várias condições) e observar que a previsão de contagem de alertas exibe 0 ou que o gráfico apresenta anomalias nos dados, verifique seus mapeamentos de campos. Certifique-se de que tanto o campo alertname quanto o campo severity estejam mapeados corretamente e que os rótulos do evento estejam completos. Mapeamentos incompletos ou incorretos no modo de alerta de múltiplas condições podem fazer com que a previsão de contagem de alertas retorne 0 ou que os dados do gráfico sejam exibidos incorretamente.

Etapa 4: Configurar a deduplicação de eventos

Para reduzir dados redundantes, o sistema utiliza campos especificados como base para a deduplicação de eventos. O gerenciamento de alertas do ARMS permite visualizar os resultados do agrupamento de deduplicação para os dados históricos de eventos na seção Event Mapping. Ajuste os campos de deduplicação conforme necessário.

Nota

A deduplicação só pode ser configurada para eventos que não foram limpos.

  1. Na seção Event Deduplication, selecione os campos a serem usados para deduplicação.

    Quando vários eventos possuem os mesmos valores para os campos selecionados, eles são mesclados em uma única notificação de alerta.

    Por exemplo, defina os campos source e check do ARMS como chaves de deduplicação. No cenário de exemplo, o campo $.metadata[*].ip da origem de alerta de terceiros é mapeado para o campo source do ARMS, e o campo $.trigger-check é mapeado para o campo check do ARMS. Como resultado, eventos com o mesmo endereço IP e item de verificação são mesclados em um único evento, enquanto eventos com endereços IP ou itens de verificação diferentes permanecem separados.

  2. Clique em Deduplication Test para visualizar os grupos de alertas após a deduplicação.

    Nota

    O teste de deduplicação aplica-se aos últimos 10 registros de dados de teste carregados no painel esquerdo da seção

    Event Mapping.

    Na área

    Select fields for deduplication

    , selecione

    source

    e

    check

    e clique em

    Deduplication Test

    . Os resultados do teste são agrupados pelos campos selecionados. Por exemplo, os eventos são divididos em dois grupos com base em endereços IP de origem diferentes (141.219.xxx e 172.1.xxx) e no mesmo item de verificação (tcp package error percentage). Os eventos de alerta dentro de cada grupo têm os mesmos valores para os campos source e check.

  3. Após concluir a configuração, clique em Save.

Resultados

Após a conclusão da configuração, a página Integrations exibe a integração personalizada criada.

A lista de integrações mostra informações como nome, URL do endpoint, tipo, hora de criação e status da integração personalizada. Clique em

Copy

ao lado da URL do endpoint para copiá-la. A coluna Actions oferece operações como

Edit

,

Delete

e

Disable

.

Gerenciar integrações

No painel de navegação à esquerda, escolha Alert Management > Integrations. Na aba Alert Integration, é possível realizar as seguintes operações nas integrações criadas:

  • Visualizar detalhes de uma integração: localize a integração e clique na linha correspondente. Na página Integration Details, visualize os detalhes da integração.

  • Atualizar a chave: na coluna Actions da integração desejada, escolha More > Update Key. Na caixa de diálogo exibida, clique em Confirm.

    Importante

    Após atualizar a chave, também é necessário atualizar a URL do endpoint na origem do alerta, conforme descrito na

    Etapa 2.

  • Modificar uma integração: localize a integração e clique em Edit na coluna Actions. Na página Integration Details, modifique as informações da integração e clique em Save.

  • Ativar ou desativar uma integração: localize a integração e clique em Disable ou Enable na coluna Actions.

  • Excluir uma integração: localize a integração e clique em Delete na coluna Actions. Na mensagem exibida, clique em OK.

  • Adicionar um fluxo de processamento de eventos a uma integração: localize a integração e clique em Add Event Processing Flow na coluna Actions. Para mais informações, consulte Fluxo de processamento de eventos.

  • Criar uma política de notificação: localize a integração para a qual deseja criar uma política de notificação e clique em More na coluna Actions. Na lista exibida, clique em Create Notification Policy. Para mais informações, consulte Políticas de notificação.

Próximos passos

Após criar uma política de notificação, o sistema gera alertas e envia notificações para os eventos de alerta relatados com base na política configurada. Para mais informações, consulte Políticas de notificação. Na página Alert Sending History, é possível visualizar os alertas gerados com base na política de notificação configurada. Para mais informações, consulte Visualizar histórico de envio de alertas.