KB2567261(pt).docx Práticas recomendadas para uso do campo Agent Correlator da Fila ECC

Práticas ServiceNow recomendadas para uso do campo Agent Correlator da Fila ECC

1. https://support.servicenow.com/kb?
id=kb_article_view&sysparm_article=KB2567261
KB2567261
Práticas recomendadas para uso do campo Agent Correlator da Fila ECC
31 Visualizações Última atualização: Oct 22, 2025 public Copy Permalink
Índice
Introdução
Por que isso precisa ser feito melhor
Por que não usar apenas o Tópico
Por que prefixar o sys_id
Alterar a regra de negócios Pedir ajuda
Suporte
Um bom exemplo - Orquestração
O pior exemplo - Discovery
Todo o resto
Isenção de responsabilidade: estes são os pensamentos e pontos de vista
de David Piper, um engenheiro de suporte. Isso não é 'oficial' (ainda?), mas
visa dar o pontapé inicial em direção a uma abordagem centralizada mais
formal para o processamento da Fila ECC.  Precisamos entender o
problema antes que uma solução possa ser projetada.
Introdução
A fila ECC e os servidores MID são recursos de plataforma compartilhados,
usados por muitos aplicativos diferentes e integrações personalizadas.
Um Sensor é uma regra de negócios que reage à inserção de uma Entrada
de Fila ECC (e às vezes Saída), para processar os dados/resultado. Eles são
específicos de recursos e sondagens, geralmente para um registro ou
processo específico na instância.

2. Agora há um grande desafio ao projetar uma regra de negócios do Sensor
condições para garantir que:
1.Ele tem uma condição que significa que ele é executado SOMENTE
para seus registros de fila ECC.
2.E que NÃO CORRE para os registros de nenhum outro recurso.
Isso é coisa diferente, mas um sistema bem projetado de valores do
Agente Correlacionador resolve 1 e ajuda a prevenir 2.
Se todos os recursos fizessem 1, 2 não seria um problema. Mas nem todos
os recursos o fazem.
Por que isso precisa ser feito melhor
Não deve ser necessário analisar o XML no campo de carga para responder
a qualquer um dos pontos acima até que a carga seja realmente
processada. Ou em seus próprios registros para confirmar que os possui,
ou em outros para confirmar que não os possui. Isso é ruim porque a
análise de muitos megabytes de XML Payload leva tempo da CPU e muita
memória do nó do aplicativo.
Se apenas um sys_id for colocado no campo Agent Correlacion e não
houver confirmação positiva do recurso ou tabela a que ele se refere, uma
consulta na tabela esperada deverá ser feita para confirmar se essa sys_id
é um registro nessa tabela ou não, para saber se o registro da Fila ECC
deve ser processado pelo sensor ou não. Isso é ruim porque essas
consultas podem ser em tabelas grandes ou lentas.
Isso significa que o código de um recurso está afetando o desempenho de
outro recurso, ao descobrir que um registro de fila ECC não é seu registro.
O outro problema principal com essa falta de padronização e consistência
é que os sensores errados são executados nos registros de outros
recursos.  Um sensor errado pode ser executado primeiro e, ao atualizar o
estado, pode impedir que o sensor adequado seja executado e causar
perda de dados no processo.
Os exemplos clássicos são os sensores de descoberta em execução para
uma entrada não descoberta e configurando-os para o estado de erro e
"Nenhum sensor definido". Ou para que o mesmo sensor de descoberta
use muito tempo e memória de appnode analisando uma carga útil XML

3. massiva para ver se é para descoberta, apenas para que seja uma resposta
de mensagem REST não relacionada de uma integração.
A maioria dos recursos teve que ter problemas abertos para adicionar
código para proteger seus registros dos sensores do Discovery, quando
idealmente todos os recursos deveriam saber quais registros são seus,
imediatamente, a partir dos valores de campo simples, sem ter que fazer
nenhuma análise cara ou consultas de banco de dados e, em seguida, não
tocar nos registros de mais ninguém.
Por que não usar apenas o Tópico
O campo Tópico é frequentemente usado em condições de regra de
negócios do sensor para vincular o registro de entrada da Fila ECC de volta
a um recurso específico, no entanto, isso só funciona quando:
Esse teste/tópico é usado apenas por esse recurso.
Esse teste/tópico é o único teste usado por esse recurso.
Quando o mesmo teste/tópico é usado por muitos recursos, ou um teste
inicialmente escrito para, por exemplo, Discovery é reutilizado por outro
recurso, como é o caso dos testes Powershell e SSHCommand, isso não
fornecerá uma confirmação positiva de qual recurso o registro se destina.
No entanto, isso pode ser útil para outros recursos que não têm nenhuma
confirmação positiva fácil de que o registro é para eles e precisam
descobrir se o registro definitivamente não é para eles. Eles podem excluir
todos os registros com uma lista de tópicos conhecidos por serem
específicos para outros recursos, no entanto, essa é obviamente uma lista
que continua crescendo e precisa de manutenção constante das condições
do sensor.
A lista a seguir são alguns recursos comuns que definitivamente têm sua
própria sonda e uma regra de negócios principal comum do sensor
especificamente para essa sonda.
Sonda de monitoramento
oIsso é usado apenas pelo Agent Client Collector. Há uma regra
de negócios comum "AgentNowResponseProcessor", que
passa a carga para as inclusões de script específicas para o
recurso de nível superior, usando o valor Tipo de Verificação

4. incluído na carga.
Observação: essa ideia geral pode ser uma boa base para um
futuro Sensor Framework na plataforma, onde os tipos e recursos
de teste são registrados em uma tabela central, o que permite
identificar positivamente o teste/recurso e define qual código é
executado como o sensor.
Sonda de Ação IPaaSA
oIsso é usado apenas pelos Fluxos do Hub de Integração, que
tem um conjunto de regras de negócios comuns.
Eles não usam nenhum prefixo de correlador de agente ou outras pistas
nos campos principais de registro ecc_queue. Eles dependem do Topic e,
portanto, qualquer recurso futuro que reutilize essas sondas pode causar
problemas nos sensores existentes.
Adicionar uma trilha ao Agent Correlator também os protegeria para o
futuro e também ajudaria outras sondas de recursos a ignorar os valores
do agente correlacionador que não são simplesmente sys_ids de 32
caracteres ou seu próprio prefixo. Isso também significaria uma redução
na mudança do recurso de outra pessoa quebrando o seu.
VerKB0727132 Como vincular um registro de Fila ECC de volta a um
Recurso ou Trabalho específicopara outros valores de Tópico que você
pode excluir nas condições do sensor, para garantir que o sensor não
esteja em execução para esses outros recursos.
Por que prefixar o sys_id
Um sys_id geralmente se refere a um registro. Mas não nos diz nada sobre
em qual tabela ela está, ou de qual recurso essa tabela é. A regra de
negócios do sensor precisa saber disso, sem ter que adivinhar ou verificar
novamente.
Não há realmente nenhum outro campo para usar, exceto Agente
Correlacionador. Concatenar vários valores em um campo é simples e
igualmente simples de dividir novamente com algumas linhas de javascript
em uma condição de regra de negócios do sensor.
Os campos Nome/Origem geralmente são usados para entrada na sonda,
geralmente relacionados à URL ou endereço IP do endpoint ou ao registro

5. de origem na instância. Mais detalhes podem ser colocados no XML de
carga útil, mas a análise disso é cara para o desempenho, como sabemos
pelo sensor do Discovery pesquisando cargas úteis para o parâmetro
skip_sensor.
Para obter mais detalhes sobre cada um dos campos da Fila ECC e sua
finalidade, consulte:
KB0855595 Como os registros da tabela da Fila ECC são processados: da
saída pronta à entrada processada 
Alterar a regra de negócios Pedir ajuda
Sim, se você conseguir que seu sensor funcione primeiro, antes que outros
possam interferir.
Se um Sensor bom puder ser executado antes de um sensor defeituoso e
puder definir o Status como Processando (ou Processado/Erro) durante a
inserção, antes que outras regras de negócios do sensor sejam executadas,
essas outras regras de negócios geralmente ignorarão o registro porque
ele não está mais no estado Pronto.
No entanto, a entrada real geralmente não é processada como parte da
transação de inserção de entrada ecc_queue, pois isso bloquearia os
poucos threads de semáforos API_INT disponíveis na instância e
potencialmente bloquearia ou interromperia outras integrações e até
mesmo impediria que os servidores MID se conectassem à instância.
Portanto, definir o status na inserção só é possível se o processamento da
entrada for realmente rápido e houver poucos deles, ou se o estado for
definido como Processado pela regra de negócios de inserção, antes de
mover o processamento real do sensor e dos dados para um thread de
trabalho do agendador (como Discovery) ou por meio de um evento do
sistema (como DEX).
A regra de negócios Discovery sensors é executada na ordem padrão 100 e
talvez não deva. Correr na ordem 99 permitiria que você chegasse ao
registro primeiro.
Suporte
A falha em ter um valor exclusivo para permitir que clientes e engenheiros
de suporte vinculem facilmente tarefas/registros de um recurso a registros

6. específicos da Fila ECC para essa tarefa é um problema. Se o registro de
saída correto da Fila ECC para um recurso/integração não puder ser
encontrado rapidamente, ou de forma alguma entre todos os outros
registros semelhantes ao mesmo tempo, o sys_id da saída não poderá ser
usado para encontrar os logs do thread no Servidor MID que realmente
executou a sonda, que pode ser o único lugar onde os erros completos
podem ser vistos. Isso retarda o processo de depuração quando as coisas
estão dando errado.
Por exemplo, esse problema existe por ter as únicas informações de
identificação ocultas em um parâmetro codificado em base64 no campo de
carga, impossibilitando a pesquisa na Fila ECC pelos registros relacionados
a um URL de verificação específico.
PRB1950919 verificações de monitoramento sintético por meio de
locais de servidor MID não definem um valor no Agent Correlacion
de registros ecc_queue
O registro na instância também pode ajudar com isso. Um bom exemplo
seriam os Logs de Descoberta, em que os registros de log fazem referência
diretamente ao registro de saída ecc_queue. Os trabalhos agendados do
sensor incluem o registro ecc_queue sys_id no nome do trabalho e também
são registrados nos logs do host local do appnode à medida que o sensor é
executado. Isso simplifica a vinculação do código/logs/jobs do lado da
instância a essa coisa específica em execução nos logs do lado do servidor
intermediário.
Um bom exemplo - Orquestração
As atividades de orquestração em fluxos de trabalho herdados têm um
bom sistema em que o valor do correlacionador do agente é o prefixo
"rba." para automação de runbook e uma sys_id do contexto de fluxo de
trabalho ao qual o registro da fila ECC se relaciona.
Os registros que não são para orquestração nunca terão um prefixo "rba."
no correlacionador do agente, portanto, a regra de negócios 'Automação -
Sensores' nunca será executada para eles.
O pior exemplo - Discovery

7. Em primeiro lugar, o recurso Discovery não está completamente em falta
aqui. Ele projetou o servidor MID para descoberta. Ele escreveu a maioria
das principais sondas. Em seguida, outros aplicativos e recursos surgiram e
também o usaram e reutilizaram muitos desses Probes.
A solução para permitir que outros recursos usem o MID Server do
Discovery foi o parâmetro skip_sensor. No entanto, isso está enterrado nos
campos de carga útil XML, que podem ser enormes, dependendo do
recurso. Carregar, analisar e extrair o parâmetro skip_sensor disso
consome muita CPU e memória no appnode, atrasando o recurso de quem
realmente é o trabalho.
O script de condição do sensor é capaz de filtrar alguns com base no nome
do tópico ou onde os prefixos no agent_correlator são conhecidos, mas
geralmente precisa criar um trabalho agendado para executar o sensor de
qualquer maneira para dar uma olhada mais de perto.
A regra de negócios Descoberta - Sensores tem um script de condição,
chama uma função de descoberta no script include
'AutomationEccSensorConditions', que usa
uma função '_commonSkipConditions', que lista alguns valores de
Tópico que definitivamente não são Descoberta, no entanto, não é
uma lista longa. (Zurique acaba de : HeartbeatProbe, config.file,
SystemCommand, ConnectorProbe, IPaaSActionProbe,
MonitoringProbe, Syslog, DataInputMarkerUpdate,
DataInputConnectorPortCheckProbe, DataInputExamplesProbe)
Essa função também verifica se o registro já está processado, não é
um registro relacionado ao servidor MID, não é uma entrada
queue.stats/queue.processing, não é para um MIDExtension
exclui qualquer coisa com um Agent Correlacion começando com o
prefixo do Orchestration e do IntegrationHub.
Descriptografa todo o campo Payload é necessário.
Atualiza as contagens de status de descoberta
Consulta o registro de saída ecc_queue em que essa entrada está em
response_to
e verifique se é uma entrada de estado pronto

8. Portanto, mesmo antes de o script da regra de negócios ser executado,
muita coisa aconteceu, para registros que provavelmente nem são para o
Discovery.
Mas, a essa altura, ele ainda pode não conseguir saber se um registro é
para descoberta ou não, portanto, executa o script de regra de negócios,
que agenda um trabalho 'ASYNC: Discovery - Sensors' em sys_trigger de
qualquer maneira.
Esse trabalho agendado, definido para ser executado uma vez,
agora, chama o script include DiscoverySensorJob, runSensor
function, que executa SensorProcessor Java.
Quando SensorProcessor é inicializado, ele consulta a tabela
discovery_status para ver se o valor agent_correlator é um registro
discovery_status sys_id. Se for, então isso é uma confirmação, esta é
uma entrada de descoberta.
Em seguida, ele obtém a carga útil, seja do campo ou de um anexo
grande (>500k, até ~ 50 MB), descriptografa-o se necessário e
procura um parâmetro skip_sensor=false. Se ele encontrou, sabe
que o registro NÃO é para Discovery.
Se ele passar por tudo isso, ele começará a executar o código real do
sensor Discovery
A partir disso, você pode ver que muito processamento pode ter que ser
feito para descobrir se um trabalho NÃO é para Discovery, e envolveu a
execução de um trabalho agendado para fazer isso.
Quando o ACC inicia um Padrão de Descoberta, ele usa o PatternLauncher
do Discovery, como um padrão sem servidor, mas não preenche o Agent
Correlacion, porque não há registro de Status de Descoberta. Em vez disso,
ele foi acionado a partir de classificadores de processo após uma
verificação de descoberta aprimorada do ACC. Dentro do Discovery, não é
consistente.
E muitas vezes isso ainda não acertou. É por isso que chamo isso de pior
exemplo.
Os seguintes problemas conhecidos tiveram que ser abertos para recursos
que não eram do Discovery, para que o parâmetro skip_sensor pudesse ser

9. adicionado para evitar que os sensores do Discovery fossem executados
para seus registros. Em um mundo justo, eles nunca deveriam ter
precisado fazer isso.
PRB1918478 os testes Employee Document
ManagementEmployeeFileImport/StreamPipeline não incluem o
parâmetro skip_sensor=true na carga de saída, causando o erro
Nenhum sensor definido
PRB1855384 API de Integração Contínua/Entrega Contínua (CI/CD)
'Discovery - Sensors' BR pode processar ecc_queue registro antes de
'Source Control Response' BR
PRB1821920 Controle do Código-Fonte
EngineApplyChangesVCSHandler encerra o processo após um erro
ecc_queue
PRB1579551 Software Asset ManagementSAMSoapHandler falha ao
impedir a execução de sensores de descoberta para suas entradas
ecc_queue, perdendo o parâmetro de solicitação skip_sensor=true
RESTMessagev2/SOAPMessagev2 (Erro: nenhum sensor definido)
PRB1507976 Integração do Security Incident Response com o
McAfee ePO 'Nenhum sensor definido' para McAfee EPO
PRB1507964 Resposta a incidentes de segurança 'Nenhum sensor
definido' para o bloco de configuração do Splunk Sighting
PRB1434384 Erro "Nenhum sensor definido" dos conjuntos de
exportação do sistema para os registros de entrada da fila ECC do
conjunto de exportação ExportSetResult
PRB1379065 Mapeamento de ServiçoO sysauto_script de
Mapeamento de Serviços de Serviço "Atualizar Serviços Baseados em
Consulta" gera RESTProbes que recebem erros "Nenhum sensor
definido"
PRB1418114 ExtrahopVemos uma entrada com o estado "Erro" na
Fila ECC para chamada 'GET'. Ao clicar no registro, vemos a
mensagem de erro: "Nenhum sensor definido".
e muitos mais

10. Outros problemas tiveram que ser abertos com o Discovery para restringir
essas condições:
PRB1456619 O erro "Nenhum sensor definido" e Status=Erro nas
entradas da fila ECC é enganoso, levando a confusão e atraso
PRB1113671 Discovery - A regra de negócios Sensors é executada
para entradas de ecc_queue não Discovery.
... e haverá mais à medida que os nomes dos tópicos forem
adicionados à lista de exclusão
Todo o resto
A maioria dos recursos valoriza sys_id, mas apenas isso. Nenhuma
indicação é dada para qual tabela ou recurso se refere.
Quando uma sonda/tópico é usada apenas por um único recurso, as
condições do sensor geralmente dependem inteiramente disso.
Os sensores REST/SOAP tendem a confiar primeiro no URL no campo Nome
na condição e, em seguida, usar o Agente Correlacionador para vincular a
registros específicos.
Como a maioria dos recursos preenche o campo Agent Correlacion está
documentado aqui:
KB0727132 Como vincular um registro de fila ECC a um recurso ou trabalho
específico