Gateway do Power BI caindo? Como achar a causa nos logs

Gateway do Power BI caindo? Como achar a causa nos logs

Quando o gateway de dados local do Power BI cai, as atualizações agendadas falham em cascata e os painéis amanhecem desatualizados. Os primeiros palpites costumam ser falta de memória no servidor ou alguma atualização do Windows. Às vezes é isso mesmo. Para ter certeza, vale seguir um roteiro que troca palpite por evidência.

1. Monte a linha do tempo da falha

Comece pelo histórico de atualização dos modelos semânticos no serviço do Power BI. Anote o horário da primeira e da última atualização que falhou e a mensagem de erro de cada uma. Em Gerenciar conexões e gateways, confira se o cluster tem mais de um membro e qual deles estava fora do ar.

Com essa janela em mãos, você sabe exatamente que trecho dos registros precisa olhar.

2. Reúna os registros do servidor

São três fontes, todas do mesmo intervalo:

  • Visualizador de Eventos do Windows, nos logs System e Application.
  • Logs do próprio gateway, exportados pelo aplicativo do gateway no servidor, na área de diagnóstico.
  • Uso de memória, CPU e disco no horário, pelo Monitor de Desempenho ou pela ferramenta de monitoramento que a empresa já usa.

3. Teste cada hipótese contra os dados

Cada suspeita comum deixa um rastro específico:

Hipótese Onde olhar
Falta de memória Evento 2004 do Resource-Exhaustion-Detector e os contadores de memória
Disco cheio Espaço livre no volume do gateway, inclusive na pasta temporária de spooling
Reinício ou desligamento Eventos 41 (Kernel-Power), 1074 e 6008 no log System
Serviço do gateway parou Eventos 7031 e 7034 do Service Control Manager
Instalação ou atualização de software Eventos do MsiInstaller e do Windows Update no período
Perda de conexão com a nuvem Erros de conexão com o Azure Relay nos logs do gateway

Quando uma hipótese não deixa rastro no horário da queda, ela sai da lista. Esse descarte é o que dá segurança na conclusão.

4. Procure padrões que se repetem

Algumas causas não aparecem como erro. O evento 1035 do MsiInstaller, por exemplo, registra que o Windows Installer reconfigurou um programa. Um ou outro é normal. Dezenas no mesmo minuto, repetindo em intervalos regulares, indicam que algo está disparando essas reconfigurações.

Este script em PowerShell conta os eventos 1035 por minuto nos últimos cinco dias:

$filtro = @{
  LogName      = 'Application'
  ProviderName = 'MsiInstaller'
  Id           = 1035
  StartTime    = (Get-Date).AddDays(-5)
}
Get-WinEvent -FilterHashtable $filtro |
  Group-Object { $_.TimeCreated.ToString('yyyy-MM-dd HH:mm') } |
  Sort-Object Name |
  Select-Object Name, Count

Um suspeito frequente são agentes de inventário de software que consultam a classe WMI Win32_Product. A própria Microsoft documenta que essa consulta faz o Windows Installer verificar e reconfigurar cada programa instalado, e o gateway entra nessa lista. Se as rajadas coincidem com o horário em que o agente roda, você encontrou o gatilho.

5. Compare os membros do cluster

Os logs do gateway trazem muitas exceções, e a maioria é benigna. Antes de concluir que um membro está com problema por causa do volume de erros, compare com um membro saudável no mesmo período. Se os dois têm o mesmo perfil de exceções, o volume não explica a queda.

Depois de achar a causa

  • Ajuste o gatilho com quem é dono dele. No caso do inventário, dá para reduzir a frequência para uma vez por dia, de madrugada, ou trocar a consulta à Win32_Product pela leitura do registro do Windows.
  • Mantenha o gateway em cluster com pelo menos dois membros em servidores diferentes, para que a queda de um não pare todas as atualizações.
  • Guarde os scripts de coleta. O próximo incidente fica mais rápido de investigar.

Aplicamos esse roteiro num caso real, descrito em Causa Raiz de Quedas no Gateway do Power BI.

Seu gateway está instável? Converse com a Dome.

« Voltar ao blog