Exatamente @MARCOS STUMPF, não fizemos implementação neste card.

Bom dia@Renan Schroeder Apenas confirmando, ,que lendo os comentários entendo que não houve código implementado neste card correto?

Estou colocando uma tag NO_CODE_IMPLEMENTATION haja visto que o SP está 0.

@Gabriel DAmore Marciano @Renan Schroeder Conforme evidenciado de que a entrega voltado ao deploy de ontem reduziu as filas do Nats, estamos encerrando esse card.

Evidências:

https://totvscarol.slack.com/archives/C20SEQ867/p1710354876619139?thread_ts=1710353805.076729&cid=C20SEQ867

@Robson Thanael Poffo ,
@Renan Schroeder , @André Pereira de Oliveira

This issue was just linked to issue(s) https://totvslabs.atlassian.net/browse/CAPL-5178#icft=CAPL-5178, according to mention in a prior comment.

Após o alinhamento no dia 12/03 decidimos que:

1. Faremos o release do card https://totvslabs.atlassian.net/browse/CAPL-5178 em produção para permitir a geração de eventos de Summary de forma distribuída através de uma nova task na plataforma, deixando de represar eventos de observabilidade que já estejam prontos para serem enviados ao Smartlink (backend).

2. Alteraremos o priority do job do BigQuery que executa a query de agregação de distintos mdmIds para um batch + datamodel para o tipo INTERACTIVE, que visa utilizar os slots de forma ativa, concorrendo com os slots do reservation do projeto parametrizado na variável de ambiente BIGQUERY_OBSERVABILITY_PROJECT_ID (backend). Este passo deverá ser realizado antes mesmo da liberação do item 1.

3. Alteraremos o valor da variável de ambiente BIGQUERY_OBSERVABILITY_PROJECT_ID para labs-techfin-production (SRE).

Todos os itens acima já ocorreram, exceto o passo 3 que já foi alterado a variável de ambiente no chart do kubernetes do cluster worker (helm) e será liberado em produção na próxima janela de deploy.

Boa, obrigado Troquei uma ideia com o e falamos novamente sobre a ideia de termos um reservation dedicado para rodarmos as queries de consolidações do summary. Vou colocar um :triangular_flag_on_post: no card para falarmos sobre essa ideia nós 4.

Sent by Slack - platform-support - Gabriel D'Amore Marciano

Boa tarde pessoal!

Fazendo um deep dive tanto no código, quanto no banco Postgres e também nos jobs lançados para calculo de unicidade de registros processados pelo batch no BigQuery cheguei a seguinte conclusão:

1. O causador da lentidão é sem sombras de dúvidas a falta de slots do BigQuery. Os jobs que calculam a unicidade dos registros processados pelo batch ficam por muito tempo aguardando terem slots para processar em alguns períodos do dia (é intermitente).
2. Peguei agora mesmo mais um caso de exemplo que está ocorrendo atrasos na entrega de eventos para o Smartlink, onde o job do BigQuery que calcula a quantidade de registros processador por batch (para criar o evento de Summary) está enfileirando uma série de eventos em nossa esteira (tabela `observability_event` no Postgres) e enquanto o job do BigQuery não termina o job `ObservabilityEventSenderJob` não prossegue tentando enviar os demais eventos prontos.
3. O card definitivamente pode ajudar a melhorar o tempo de entrega dos eventos para o Smartlink, uma vez que o job que calcula os registros processados pelo batch será executado de forma assíncrona em uma nova task na tenant que recebeu os intakes, `não travando a thread` do job de envio de eventos para o Smartlink.
.

Sent by Slack - platform-support - Renan Schroeder

O último pacote enviado com confirmação de recebimento do Smartlink foi às 8:28 BRT. O job ObservabilityEventSenderJob não parou de processar o que entrava na fila, mas desde o último pacote ficamos “acumulando” eventos enviados para o Smartlink sem reposta. Até às 12:02 foram 3 horas e 30min de "atraso” na confirmação do request que a plataforma Carol fez para o Smartlink.

Às 12:01 começamos a receber as confirmações de mais de 700 eventos.

Criei esta visão por tipo de evento e status para ficar mais fácil de visualizarmos:

@Robson Thanael Poffo ,
@Pedro Buzzi ,
@Geny Isam Hamud Herrera ,
This issue was planned to be delivered until 2024-03-25. You can check that by consulting the issue in the Due Date field.

Dates already planned for this issue: 2024-03-25

If External Issue Link field is filled, customer was also informed on JIRA TOTVS.