Operar e Monitorar Fluxos de Dados

Monitoramento no lado GoldenGate

• Confirme se o recurso Fluxo de Dados está presente e disponível no Serviço de Distribuição.

• Monitore registros e bytes enviados, contagens de operações, contagens de DDL, atividade de tabela e estatísticas de rede onde expostas pela IU ou métricas de serviço.

• Revise os logs do Serviço de Distribuição para autenticação, pesquisa de trilha, pesquisa de posição, geração de esquema, truncamento de tamanho e erros de desconexão WebSocket.

• Monitore a extração de origem e a geração de trilha de forma independente. Um WebSocket íntegro não pode entregar dados que não estejam atingindo a trilha.

Métricas do consumidor

Métrica	Por que é importante
Estado da conexão e contagem de reconexões	Detecta a instabilidade de rede, autenticação, proxy e serviço.
Último recebimento e último commit pos	Separa a chegada de dados do processamento durável bem-sucedido. Registre um valor hash ou protegido se as posições forem consideradas confidenciais.
Registros e bytes por tipo/tabela	Identifica volume inesperado, erros de filtragem e distorção.
Latência de processamento	Tempo de op_ts para commit downstream durável. Conta para diferenças de relógio de origem e de consumidor.
Profundidade da fila interna e idade da fila mais antiga	Detecta a contrapressão antes do esgotamento da memória.
Alterações de versão do esquema/metadados	Detecta alterações de DDL e de contrato.
Contagens de conflitos de duplicidade e idempotência	Valida o comportamento de entrega e checkpoint.
Falhas de validação e deadletter	Mostra registros que exigem correção manual ou automatizada.

Planejamento de buffer e capacidade

bufferSize controla o limite de byte no qual o serviço libera sua fila de mensagens na memória para o cliente. Um valor maior pode melhorar a eficiência do batch, mas pode aumentar o uso e a latência da memória por mensagem. Um valor menor pode reduzir a latência, mas aumentar a sobrecarga de mensagens. Não é uma fila durável, não substitui a retenção de trilha e não remove a necessidade de controles de contrapressão do consumidor.

• Teste com tamanhos de transação representativos, LOBs, DDL, contagem de tabelas e throughput de pico.

• Defina WebSocket e tamanhos máximos de mensagens de proxy acima do batch esperado maior.

• Use filas delimitadas e falhe rapidamente em vez de permitir o crescimento ilimitado da memória.

• Recepção, validação, E/S downstream e commits de checkpoint de rede separados para que cada estágio possa ser medido.

Estratégia de reconexão

• Reconecte-se do último ponto de verificação durável, não do último registro meramente recebido.

• Use backoff exponencial com um máximo de atraso e jitter.

• Redefina o atraso após uma conexão estável.

• Classifique falhas não repetíveis, como credenciais inválidas ou uma posição salva indisponível, e gere um alerta do operador em vez de tentar novamente para sempre.

• Preservar o mesmo contrato de saída durante a recuperação. Se a configuração do fluxo for alterada, conclua a validação de compatibilidade antes de retomar.

Vários consumidores

O serviço Data Streams não fornece um grupo de consumidores no estilo Kafka ou um deslocamento por consumidor gerenciado pelo servidor. Cada cliente independente deve manter seu próprio checkpoint e receber registros de acordo com sua conexão e o valor begin. Não compartilhe um ponto de verificação entre consumidores ativos simultaneamente, a menos que um coordenador externo garanta propriedade única e atualizações de ponto de verificação solicitadas.

Gerenciamento de mudanças

• Controle a versão da configuração do Fluxo de Dados e gere AsyncAPI YAML com a release do consumidor.

• Teste a criação, conexão, processamento em estado estacionário, desconexão, reinicialização, falha na posição retida, DDL, registros grandes e rotação de credenciais.

• Implante código de consumidor compatível antes de ativar novos campos de payload ou alterações de esquema.

• Mantenha um plano de rollback que preserve o último checkpoint e a configuração em boas condições.