Monitoramento e Observabilidade das Integrações do ADMS¶
Projeto: DSB26201 — Avaliação de arquitetura de integração ADMS (Energisa) Fonte: Reuniao-Monitoramento-Observabilidade — "Transcrição Completa Detalhada — Reunião de Observabilidade ADMS" (PDF, 27/07/2026, 10h02–11h08) + screenshot "Monitoração Zabbix ADMS.png" + Ata 11 (Assessment_Consolidado) Status: Rascunho para validação Elaborado por: Consultoria Syntropy
Por que este artefato existe¶
Esta sessão reuniu, pela primeira vez no ciclo de levantamentos, as áreas que observam todos os fluxos já mapeados nas sessões anteriores — monitoração de infraestrutura (Zabbix), observabilidade de aplicações (Datadog) e telemetria de logs (ELK) — em vez de uma área dona de um fluxo específico. Participaram Norberto (contextualização e ambiente multicloud), Fernando (Datadog), Gabriel (monitoração/NOC), Éder Xavier (ELK) e, chegando ao final da sessão, Willians e Nicolas.
A Ata 11 que documenta esta reunião é, das quatorze Atas do Assessment_Consolidado revisadas até aqui, a mais disciplinada metodologicamente: ela reconhece explicitamente que a associação automática entre rótulo de falante e pessoa não se manteve estável ao longo da gravação e, por isso, atribui toda a fala por papel funcional em seu Anexo A, além de reservar um Anexo B inteiro para termos foneticamente incertos que exigem confirmação antes de qualquer decisão de arquitetura. Isso contrasta com a Ata 06 (que fabricou o nome de vendor "Insight") e com os nomes fabricados identificados no artefato de GIS-ADMS.
Diagrama 1 — Panorama de observabilidade: mosaico de ferramentas por domínio¶
O cenário atual não é falta de ferramentas — é excesso não coordenado delas. Zabbix cobre infraestrutura em duas instâncias segregadas (OT e TI, refletindo a própria segregação de rede em que o ADMS nasceu). Datadog cobre aplicações via APM, mas alcança apenas 3 das 9 unidades de negócio, com ~85% das APIs instrumentadas nessas três — e nunca foi viabilizado no lado OT, o que por si só impede visão ponta a ponta. ELK é o ambiente de telemetria e logs, mas é anterior ao OpenShift, roda fora do cluster, compete por storage compartilhado com outros ambientes e está no meio de uma reconstrução total. Ao lado desses três "pilares pretendidos" convivem Prometheus/Grafana, CloudWatch/X-Ray, recursos nativos do Databricks/Azure, PRTG, Oracle Enterprise Manager e o mecanismo próprio do API Gateway — entre 6 e 8 ferramentas no total, por admissão da própria equipe, sem projeto formal de centralização.
O achado mais grave aqui não é técnico, é de governança: o ambiente ELK, que é a fonte de telemetria e investigação para incidentes do ADMS, teve seu backup suspenso porque compartilha storage com ambientes não relacionados — qualquer necessidade de expansão de disco nesse storage arrisca repetir o incidente que motivou a suspensão original.
Diagrama 2 — A lacuna central da sessão: linhagem de transformação de eventos¶
A própria Ata 11 classifica este ponto como "o de maior densidade técnica da sessão", e a leitura da transcrição confirma o peso disso. A distinção levantada é entre conhecer a relação estática entre produtor, tópico e consumidor — o que já é possível hoje via Datadog nas aplicações instrumentadas — e conseguir rastrear a transformação da informação ao longo da cadeia quando um componente intermediário aplica uma regra de negócio equivocada. Sem essa linhagem, a investigação parte do sintoma (o consumidor final quebrado) e não do ponto real de quebra.
A instrumentação do Confluent Kafka no Datadog (módulo de data streaming) promete resolver a visibilidade de produtor/consumidor/latência/profundidade de fila, mas está em homologação — ainda não em produção — e mesmo quando concluída, opera sobre metadado e inferência, não expõe o conteúdo do payload. Isso é relevante para o assessment mais amplo: a própria Ata reconhece que "falhas silenciosas de publicação, consumidores que param de consumir, eventos transformados de maneira incorreta e divergência de status entre sistemas" — problemas já registrados em sessões anteriores deste engajamento (Sustentação, WFM) — são exatamente as classes de problema que dependem desta linhagem para serem detectadas a tempo. A conclusão da instrumentação do Kafka deixa de ser uma iniciativa de infraestrutura e passa a ser pré-condição para operar as integrações do ADMS com segurança.
Diagrama 3 — Como o storage compartilhado do ELK levou à suspensão do backup¶
Este é o único incidente concreto e datável relatado na sessão (em vez de um risco hipotético): a necessidade de adicionar discos ao storage compartilhado do ambiente ELK causou um rebalanceamento que afetou outros serviços usando o mesmo armazenamento, levando Valéria (área responsável, citada na Ata apenas como "citada sem participação direta na sessão") a determinar a suspensão do backup do ambiente de logs. Essa sequência de eventos é explicitamente registrada como a origem da decisão de reconstruir o ambiente ELK "do zero" — hoje avaliando instalação própria, híbrida ou em nuvem, conforme custo, com apoio da Elastic e de seu parceiro oficial.
O ponto crítico a destacar: enquanto essa reestruturação não avança, o ambiente que serve de fonte de telemetria e investigação para incidentes do ADMS permanece sem proteção de backup — um risco operacional silencioso que só veio à tona porque a consultoria perguntou diretamente sobre retenção e resiliência.
Achados de fidelidade¶
1. Ata 11 é a mais disciplinada do engajamento até aqui. Diferente de Atas anteriores que atribuíam falas nominalmente (e, em pelo menos um caso, fabricaram um nome de vendor — "Insight" na Ata 06), esta Ata reconhece explicitamente a instabilidade da associação falante↔pessoa e responde com dois mecanismos de controle: atribuição por papel funcional em todo o Anexo A cronológico, e um Anexo B dedicado inteiramente a termos foneticamente incertos ("ELK/LK/LKC/LKK", "sigla da equipe interna", "camada de correlação multifonte/MCP", nomes de parceiros de prova de conceito) que ela mesma marca como pendentes de confirmação antes de qualquer decisão de arquitetura. Isso deveria ser o padrão para as Atas restantes deste Assessment.
2. "Cassiano" reaparece, ainda sem identificação. Falante 2 menciona "o Cassiano" aos 01:00:47 do PDF, imediatamente após a discussão sobre Douglas Maldonado, Thales e Lavínia (equipe de dados responsável por Databricks/Azure) — sugerindo que Cassiano pertence ao mesmo círculo, mas a Ata não o lista nem entre os participantes confirmados nem entre os citados sem participação. Este é o terceiro artefato deste engajamento (depois de GIS-ADMS e WFM-ADMS) em que o nome "Cassiano" aparece de forma pontual e nunca é plenamente resolvido por nenhuma Ata. Recomenda-se tratar isso como um item único a esclarecer com o cliente, e não repetir a mesma pergunta em cada sessão isoladamente.
3. Willians e Nicolas: janela de participação provavelmente muito menor do que "confirmada" sugere. Aos 01:02:55, a fala de encerramento ("Gabriel, Williams também que chegou aí, desculpa, não te conhecia, tá? Nicholas, Fernando") tem tom de apresentação recém-feita, compatível com entrada tardia na chamada — nos últimos ~3 minutos de uma sessão de 66. A Ata os lista como participantes com "Participação confirmada" no mesmo nível dos demais, sem qualificar essa janela. Não é uma fabricação, mas merece nuance ao ser citada como fonte de algum achado específico atribuído a eles.
4. Screenshot do Zabbix introduz escopo (Citrix/VDI) ausente do áudio. A captura "Monitoração Zabbix ADMS.png" documenta uma categoria de ativo monitorado — Citrix, com itens como usuários conectados, VDIs, recursos de VDI e performance de login — que não aparece em nenhum momento nos 66 minutos de transcrição nem no texto da Ata 11. Isso não contradiz a Ata (ela documenta o que foi dito, não o inventário completo de ativos), mas expõe que a descrição verbal da cobertura do Zabbix (rede/bancos/servidores) é incompleta frente ao que de fato está monitorado — reforçando a própria recomendação da Ata de formalizar um inventário oficial de ferramentas e ativos.
5. Corroboração cruzada positiva com sessões anteriores. A dor de "caixa preta" na integração WFM↔DMS (Ata 11, seção 1.12.18) referencia explicitamente a Ata 08 e bate com o que já documentamos no artefato Integracao_WFM_ADMS.md. O componente Java citado nesta sessão como "iQoS" quase certamente corresponde ao motor de cálculo "IQS" tratado no artefato de Sustentação e no de WFM. Ambos os casos reforçam a confiabilidade das duas Atas de forma cruzada, em vez de introduzir contradição.
6. Números conferem sem discrepância. Duração da sessão (~1h06, 10h02–11h08), cobertura de instrumentação (3 de 9 unidades, ~85% das APIs), retenção (15 dias no ELK, 15 meses no Datadog após virar métrica) e o caso dos 151 aplicações publicando no mesmo tópico de telemetria são consistentes entre o PDF e a Ata, sem nenhuma divergência numérica encontrada — diferente do padrão de pequenos mismatches de duração observado em sessões anteriores.
Próximo passo¶
Consolidar, num único item de ação transversal (não mais um por sessão), a identificação definitiva de "Cassiano" — nome que já apareceu em três sessões distintas sem nunca ser plenamente resolvido. Em paralelo, solicitar à Energisa o inventário formal de ferramentas e ativos monitorados (já recomendado como ação nº 1 no próprio plano de ação da Ata 11), que serviria tanto para fechar a lacuna do Citrix/VDI identificada no screenshot quanto para servir de base de verificação às próximas Atas deste Assessment.