Esse artigo mostra alguns problemas comuns que você poderá encontrar ao usar o Gateway de Dados Local.

OBSERVAÇÃO: se você tiver um problema que não esteja listado abaixo, poderá pedir assistência adicional nos locais a seguir.

Atualize para a versão mais recente

Muitos problemas podem surgir quando a versão de gateway estiver desatualizada. É uma boa prática geral ter certeza que você está na última versão. Se não tiver atualizado o gateway por um mês ou mais, considere a possibilidade de instalar a última versão do gateway e tentar reproduzir o problema.

Problemas comuns

Aqui estão algumas resoluções e problemas comuns que ajudaram um número de clientes em ambientes com acesso restrito à Internet.

Autenticação com o servidor proxy

Seu proxy pode exigir autenticação de uma conta de usuário do domínio. Por padrão, o gateway usa um SID de Serviço para o log de serviço Windows no usuário. Alterar o usuário de logon para um usuário de domínio pode ajudar com isso. Para obter mais informações, veja Alterando a conta de serviço do gateway para um usuário de domínio.

Seu proxy permite apenas tráfego pelas portas 80 e 443

Alguns proxies restringem o tráfego exclusivamente para as portas 80 e 443. Por padrão, a comunicação com o Barramento de Serviço do Azure ocorrerá em outras portas que não a 443.

Você pode forçar o gateway para se comunicar com o Barramento de Serviço do Azure usando HTTPS em vez de TCP direto. No entanto, isso reduzirá o desempenho significativamente. Você precisará modificar o arquivo Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config. Altere o valor de AutoDetect para Https. Este arquivo está localizado, por padrão, em C:\Arquivos de Programas\Gateway de dados local.

<setting name="ServiceBusSystemConnectivityModeString" serializeAs="String">
    <value>Https</value>
</setting>

Instalação

Erro: falha ao adicionar usuário ao grupo. (-2147463168 PBIEgwService Usuários de Log de Desempenho)

Você poderá receber esse erro se estiver tentando instalar o gateway em um controlador de domínio. Não há suporte para a implantação em um controlador de domínio. Você precisará implantar o gateway em um computador que não seja um controlador de domínio.

Configuração

Como reiniciar o gateway

O gateway é executado como um serviço Windows, então você pode iniciá-lo e pará-lo de várias maneiras. Por exemplo, você pode abrir um prompt de comando com permissões elevadas no computador em que o gateway está em execução e, em seguida, executar um destes comandos:

  • Para interromper o serviço, execute este comando:

    ''' net stop PBIEgwService '''

  • Para iniciar o serviço, execute este comando:

    ''' net start PBIEgwService '''

Erro: falha ao criar gateway. Tente novamente.

Todos os detalhes estão disponíveis, mas a chamada para o serviço do Power BI retornou um erro. O erro e uma ID de atividade serão exibidos. Isso pode acontecer por diferentes motivos. Você pode coletar e examinar os logs da maneira descrita abaixo para obter mais detalhes.

Isso também pode ser devido a problemas de configuração de proxy. A interface do usuário agora permite a configuração de proxy. Saiba mais sobre como fazer alterações da configuração de proxy

Erro: falha ao atualizar detalhes do gateway. Tente novamente.

As informações foram recebidas do serviço do Power BI para o gateway. As informações foram transmitidas para o serviço do Windows local, mas houve uma falha ao retornar. Ou então, uma falha de geração de chave simétrica. A exceção interna será exibida em Mostrar detalhes. Você pode coletar e examinar os logs da maneira descrita abaixo para obter mais detalhes.

Erro: o serviço do Power BI relatou o gateway local como inacessível. Reinicie o gateway e repita a operação.

No final da configuração, o serviço do Power BI será chamado novamente para validar o gateway. O serviço do Power BI não relata o gateway como dinâmico. Reiniciar o serviço do Windows pode permitir que a comunicação seja bem-sucedida. Você pode coletar e examinar os logs da maneira descrita abaixo para obter mais detalhes.

Erro de script durante a conexão no Power BI

Você pode receber um erro de script ao entrar no Power BI como parte da configuração de gateway de dados local. Instalar a seguinte atualização de segurança deve resolver o problema. Isso pode ser instalado por meio do Windows Update.

MS16-051: atualização de segurança do Internet Explorer: 10 de maio de 2016 (KB 3154070)

Falha de configuração do gateway com uma exceção de referência nula

Você pode receber um erro semelhante a este:

    Failed to update gateway details.  Please try again.
    Error updating gateway configuration.

Isso incluirá um rastreamento de pilha, que poderá incluir o seguinte:

    Microsoft.PowerBI.DataMovement.Pipeline.Diagnostics.CouldNotUpdateGatewayConfigurationException: Error updating gateway configuration. ----> System.ArgumentNullException: Value cannot be null.
    Parameter name: serviceSection

Se você estiver atualizando um gateway mais antigo, o arquivo de configuração será preservado. Pode haver uma seção ausente. Quando o gateway tentar ler isso, obteremos a exceção de referência nula acima.

Para corrigir esse problema, faça o seguinte:

  1. Desinstale o gateway.

  2. Exclua a seguinte pasta:

    c:\Program Files\on-premises data gateway
    
  3. Reinstale o gateway.

  4. Se preferir, aplique a chave de recuperação para restaurar um gateway existente.

Fontes de dados

Erro: impossível conectar. Detalhes: "Credenciais de conexão inválidas"

Em Mostrar detalhes, deve ser exibida a mensagem de erro recebida da fonte de dados. Para o SQL Server, você verá algo semelhante ao seguinte.

Login failed for user 'username'.

Verifique se você tem o nome de usuário correto e a senha. Verifique também se essas credenciais podem se conectar à fonte de dados com êxito. Verifique se a conta que está sendo usada corresponde ao Método de Autenticação.

Erro: impossível conectar. Detalhes: "Não é possível se conectar ao banco de dados"

Conseguimos nos conectar ao servidor, mas não ao banco de dados fornecido. Verifique o nome do banco de dados e se as credenciais do usuário têm a permissão apropriada para acessar esse banco de dados.

Em Mostrar detalhes, deve ser exibida a mensagem de erro recebida da fonte de dados. Para o SQL Server, você verá algo semelhante ao seguinte.

Cannot open database "AdventureWorks" requested by the login. The login failed. Login failed for user 'username'.

Erro: impossível conectar. Detalhes: "Erro desconhecido no gateway de dados"

Esse erro pode ocorrer por diferentes motivos. Não se esqueça de validar que você pode se conectar à fonte de dados do computador que hospeda o gateway. Isso pode ocorrer devido ao fato de o servidor não estar acessível.

Em Mostrar detalhes, você verá um código de erro DM_GWPipeline_UnknownError.

Você também pode examinar os Logs de Eventos > Logs de Aplicativos e Serviços > Serviço do Gateway de Dados Local para obter mais detalhes.

Erro: encontramos um erro ao tentar conectar-se com . Detalhes: "Alcançamos o gateway de dados, mas o gateway não consegue acessar a fonte de dados local".

Não é possível se conectar à fonte de dados especificada. Certifique-se de validar as informações fornecidas para essa fonte de dados.

Em Mostrar detalhes, você encontrará um código de erro de DM_GWPipeline_Gateway_DataSourceAccessError.

Se a mensagem de erro subjacente for semelhante à seguinte, isso significa que a conta que você está usando para a fonte de dados não é um administrador do servidor para essa instância do Analysis Services. Saiba mais

The 'CONTOSO\account' value of the 'EffectiveUserName' XML for Analysis property is not valid.

Caso a mensagem de erro subjacente seja semelhante à seguinte, isso pode indicar que a conta de serviço do Analysis Services pode não ter o atributo de diretório TGGAU (token-groups-global-and-universal).

The user name or password is incorrect.

Domínios com acesso de compatibilidade de versões anteriores ao Windows 2000 terão o atributo TGGAU habilitado. No entanto, os domínios criados mais recentemente não habilitarão esse atributo por padrão. Leia mais sobre isso aqui.

Confirme isso fazendo o seguinte:

  1. Conecte-se ao computador do Analysis Services no SQL Server Management Studio. Nas propriedades de conexão Avançada, inclua EffectiveUserName para o usuário em questão e veja se isso reproduz o erro.

  2. Você pode usar a ferramenta dsacls do Active Directory para validar se o atributo está listado. Essa é a ferramenta normalmente encontrada em um controlador de domínio. Você precisará saber qual é o nome diferenciado de domínio da conta e passá-lo para a ferramenta.

    dsacls "CN=John Doe,CN=UserAccounts,DC=contoso,DC=com"
    

    Você deseja ver algo semelhante ao mostrado a seguir nos resultados.

        Allow BUILTIN\Windows Authorization Access Group
                                      SPECIAL ACCESS for tokenGroupsGlobalAndUniversal
                                      READ PROPERTY
    

Para corrigir esse problema, você precisará habilitar o TGGAU na conta usada para o serviço Windows do Analysis Services.

Outra possibilidade de nome de usuário ou senha incorretos

Esse erro também poderá ser causado se o servidor do Analysis Services estiver em um domínio diferente dos usuários e não houver uma relação de confiança bidirecional estabelecida.

Você precisará trabalhar com seus administradores de domínio para verificar a relação de confiança entre os domínios.

Não é possível ver as fontes de dados do gateway de dados na experiência "Obter Dados" do Analysis Services por meio do serviço do Power BI

Confira se sua conta está listada na guia Usuários da fonte de dados na configuração do gateway. Se não tiver acesso ao gateway, verifique com o administrador do gateway e solicite a verificação. Somente as contas na lista Usuários verão a fonte de dados relacionada na lista do Analysis Services.

Conjuntos de dados

Erro: não há espaço suficiente para esta linha.

Isso ocorrerá se você tiver uma única linha com um tamanho maior que 4 MB. Você precisará determinar qual linha é proveniente da fonte de dados e tentar filtrá-la ou reduzir o tamanho desta linha.

Erro: O nome fornecido para o servidor não corresponde ao nome do servidor no certificado SSL do SQL Server.

Isso pode ocorrer quando o certificado CN é para o nome de domínio totalmente qualificado (FQDN) do servidor, mas você somente forneceu o nome NetBIOS para o servidor. Isso causará uma incompatibilidade para o certificado. Para resolver esse problema, você precisará criar o nome do servidor e do arquivo PBIX na fonte de dados do gateway, para usar o FQDN do servidor.

Não consigo ver o Gateway de Dados Local presente ao configurar a atualização agendada.

Isso pode ser devido a alguns cenários diferentes.

  1. O nome do servidor e do banco de dados não corresponde entre o que foi inserido no Power BI Desktop e a fonte de dados configurada para o gateway. Eles precisam ter os mesmos valores. Eles não diferenciam maiúsculas de minúsculas.

  2. Sua conta não está listada na guia Usuários da fonte de dados na configuração do gateway. Você precisará solicitar ao administrador do gateway para ser adicionado à lista.

  3. O arquivo do Power BI Desktop contém dados de várias fontes e nem todas as fontes de dados estão configuradas com o gateway. Você precisará ter cada fonte de dados definida com o gateway para que o gateway apareça na Atualização Agendada.

Aviso:

Se uma das suas fontes de dados exige autenticação OAuth, você não poderá configurá-la com o Gateway de Dados Local. Não há suporte para autenticação OAuth com o Gateway de Dados Local no momento. Você precisará remover do Power BI Desktop a fonte de dados que requer autenticação OAuth para configurar a atualização agendada.

Relatórios

O relatório não pôde acessar a fonte de dados porque você não tem acesso à nossa fonte de dados por meio de um Gateway de Dados Local.

Isso geralmente é causado por um dos motivos a seguir.

  1. As informações da fonte de dados não correspondem as que estão no conjunto de dados subjacente. O servidor e o nome do banco de dados precisam corresponder à fonte de dados definida para o gateway de dados local e às informações fornecidas no Power BI Desktop. Se você usar um Endereço IP no Power BI Desktop, a fonte de dados do gateway de dados local também precisará usar um Endereço IP.

  2. Não há uma fonte de dados disponível em nenhum gateway de sua organização. É possível configurar a fonte de dados em um gateway de dados local novo ou existente.

Detalhes: erro de acesso à fonte de dados. Entre em contato com o administrador do gateway.

Se este relatório estiver usando uma conexão dinâmica do Analysis Services, você poderá ter problemas ao passar um valor para EffectiveUserName que não seja válido ou que não tenha permissões no computador do Analysis Services. Normalmente, um problema de autenticação ocorre devido ao fato de que o valor passado para EffectiveUserName não corresponde a um nome UPN local.

Para confirmar isso, faça o seguinte:

  1. Encontre o nome de usuário efetivo nos logs do gateway.

  2. Depois de obter o valor que está sendo passado, valide se ele está correto. Se ele for seu usuário, você poderá usar o comando a seguir em um prompt de comando para ver qual deve ser o UPN. O UPN será parecido com um endereço de email.

    whoami /upn
    

Se preferir, é possível ver o que o Power BI obtém do Azure Active Directory.

  1. Navegue até https://graphexplorer.cloudapp.net.

  2. Selecione Entrar no canto superior direito.

  3. Execute a consulta a seguir. Você verá uma resposta JSON bem grande.

    https://graph.windows.net/me?api-version=1.5
    
  4. Procure userPrincipalName.

Se o UPN do Azure Active Directory não corresponder ao UPN local do Active Directory, você poderá usar o recurso Mapear nomes de usuário para substituí-lo por um valor válido. Se preferir, você pode trabalhar com seu administrador de locatários, ou com o administrador local do Active Directory, para alterar o UPN.

Firewall ou proxy

Para obter informações sobre como fornecer informações de proxy para o gateway, veja Configuring proxy settings for the Power BI Gateways (Definindo as configurações de proxy dos Power BI Gateways).

É possível testar para ver se seu firewall, ou proxy, pode estar bloqueando as conexões, executando Test-NetConnection em um prompt do PowerShell. Isso testará a conectividade com o Barramento de Serviço do Azure. Isso apenas testa a conectividade de rede e não tem nenhuma relação com o serviço do servidor de nuvem nem com o gateway. Isso ajuda a determinar se seu computador pode realmente acessar a Internet.

Test-NetConnection -ComputerName watchdog.servicebus.windows.net -Port 9350
Observação:

Test-NetConnection só está disponível no Windows Server 2012 R2 e versões posteriores. Também está disponível no Windows 8.1 e versões posteriores. Em versões anteriores do sistema operacional, é possível usar o Telnet para testar a conectividade da porta.

Os resultados devem ser parecidos ao mostrado a seguir. A diferença será em TcpTestSucceeded. Se TcpTestSucceeded não for true, isso indica que você poderá estar sendo bloqueado por um firewall.

ComputerName           : watchdog.servicebus.windows.net
RemoteAddress          : 70.37.104.240
RemotePort             : 5672
InterfaceAlias         : vEthernet (Broadcom NetXtreme Gigabit Ethernet - Virtual Switch)
SourceAddress          : 10.120.60.105
PingSucceeded          : False
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded       : True

Se você quiser fazer uma verificação completa, substitua os valores de ComputerName e Port por aqueles listados para portas

O firewall também pode estar bloqueando as conexões que o Barramento de Serviço do Azure estabelece com os datacenters do Azure. Se este for o caso, será recomendável adicionar à lista branca (desbloquear) todos os endereços IP da sua região para os data centers. Você pode obter uma lista de endereços IP do Azure aqui.

É possível encontrar a região do datacenter em que você está fazendo o seguinte:

  1. Selecione ? na parte superior direita do serviço do Power BI.

  2. Selecione Sobre o Power BI.

  3. Sua região de dados será listada em Seus dados estão armazenados em.

Se você ainda não conseguiu descobri-la, tente obter um rastreamento de rede usando uma ferramenta como fiddler ou netsh, embora esses sejam métodos de coleta avançados e você possa precisar de assistência para analisar os dados coletados. Entre em contato com o suporte para obter assistência.

Desempenho

Contadores de desempenho

Existem inúmeros contadores de desempenho que podem ser usados para medir as atividades do gateway. Eles podem ser úteis para entender quando há uma grande carga de atividade e talvez seja necessário criar um novo gateway. Esses contadores não refletirão a duração de algo.

Eles podem ser acessados por meio da ferramenta Monitor de Desempenho do Windows.

Há agrupamentos gerais desses contadores.

Tipo de contador Descrição
ADO.NET É usado para qualquer conexão de DirectQuery.
ADOMD É usado para o Analysis Services 2014 e anterior.
OLEDB É usado por determinadas fontes de dados. Inclui o SAP HANA e o Analysis Service 2016 ou posterior.
Mashup Inclui qualquer fonte de dados importados. Se estiver agendando uma atualização ou fazendo uma atualização sob demanda, esse processo passará pelo mecanismo de mashup.

Aqui está uma lista de contadores de desempenho disponíveis.

Contador Descrição
# de conexões abertas do ADO.NET executadas por segundo Número de ações de conexões abertas do ADO.NET executadas por segundo (com êxito ou falha).
# de conexões abertas do ADO.NET com falha por segundo Número de ações de conexões abertas do ADO.NET com falha por segundo.
# de consultas do ADO.NET executadas por segundo Número de consultas do ADO.NET executadas por segundo (com êxito ou falha).
# de consultas do ADO.NET com falha por segundo Número de consultas do ADO.NET com falha executadas por segundo.
# de conexões abertas do ADOMD executadas por segundo Número de ações de conexões abertas do ADOMD executadas por segundo (com êxito ou falha).
# de conexões abertas do ADOMD com falha por segundo Número de ações de conexões abertas do ADOMD com falha por segundo.
# de consultas do ADOMD executadas por segundo Número de consultas do ADOMD executadas por segundo (com êxito ou falha).
# de consultas do ADOMD com falha por segundo Número de consultas do ADOMD com falha executadas por segundo.
# de todas as conexões abertas executadas por segundo Número de ações de conexões abertas executadas por segundo (com êxito ou falha).
# de todas as conexões abertas com falha por segundo Número de ações de conexões abertas com falha executadas por segundo.
# de todas as consultas executadas por segundo Número de consultas executadas por segundo (com êxito ou falha).
# de itens no pool de conexões do ADO.NET Número de itens no pool de conexões do ADO.NET.
# de itens no pool de conexões do OLEDB Número de itens no pool de conexões do OLEDB.
# de itens no pool de Barramentos de Serviço Número de itens no pool de Barramentos de Serviço.
# de conexões abertas do Mashup executadas por segundo Número de ações de conexões abertas do Mashup executadas por segundo (com êxito ou falha).
# de conexões abertas do Mashup com falha por segundo Número de ações de conexões abertas do Mashup com falha por segundo.
# de consultas do Mashup executadas por segundo Número de consultas do Mashup executadas por segundo (com êxito ou falha).
# de consultas do Mashup com falha por segundo Número de consultas do Mashup com falha executadas por segundo
# de consultas do OLEDB de vários conjuntos de resultados com falha por segundo Número de consultas do OLEDB de vários conjuntos de resultados com falha por segundo.
# de consultas do OLEDB de vários conjuntos de resultados por segundo Número de consultas do OLEDB de vários conjuntos de resultados executadas por segundo (com êxito ou falha).
# de conexões abertas executadas por segundo Número de ações de conexões abertas do OLEDB executadas por segundo (com êxito ou falha).
# de conexões abertas do OLEDB com falha por segundo Número de ações de conexões abertas do OLEDB com falha por segundo.
# de consultas do OLEDB executadas por segundo Número de consultas do OLEDB de vários conjuntos de resultados executadas por segundo (com êxito ou falha).
# de consultas do OLEDB com falha por segundo Número de consultas do OLEDB de vários conjuntos de resultados com falha executadas por segundo.
# de consultas do OLEDB de conjunto de resultados único por segundo Número de consultas do OLEDB de conjunto de resultados único executadas por segundo (com êxito ou falha).
# de consultas com falha por segundo Número de consultas com falha executadas por segundo.
# de consultas do OLEDB de conjunto de resultados único com falha por segundo Número de consultas do OLEDB de conjunto de resultados único com falha executadas por segundo.

Examinando consultas com desempenho lento

Você pode achar que a resposta pelo gateway está lenta. Isso pode ser em consultas DirectQuery ou ao atualizar o conjunto de dados importado. Você pode habilitar um registro em log adicional para emitir as consultas e seus tempos para ajudar a entender o que está com desempenho lento. Ao encontrar alguma consulta de execução longa, poderá ser necessário fazer modificações adicionais na fonte de dados para ajustar o desempenho da consulta. Por exemplo, ajustando os índices para uma consulta do SQL Server.

Você precisará modificar dois arquivos de configuração para determinar a duração de uma consulta.

Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config

No arquivo Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config, altere o valor de EmitQueryTraces de False para True. Este arquivo está localizado, por padrão, em C:\Arquivos de Programas\Gateway de dados local. Ao habilitar EmitQueryTraces, começarão ser registradas em log as consultas enviadas do gateway para uma fonte de dados.

Importante:

Habilitar EmitQueryTraces pode aumentar o tamanho do log significativamente, dependendo do uso de gateway. Depois de examinar os logs, você desejará definir EmitQueryTraces como False. Não é recomendável deixar esta configuração habilitada a longo prazo.

<setting name="EmitQueryTraces" serializeAs="String">
    <value>True</value>
</setting>

Exemplo de entrada de consulta

DM.EnterpriseGateway Information: 0 : 2016-09-15T16:09:27.2664967Z DM.EnterpriseGateway    4af2c279-1f91-4c33-ae5e-b3c863946c41    d1c77e9e-3858-4b21-3e62-1b6eaf28b176    MGEQ    c32f15e3-699c-4360-9e61-2cc03e8c8f4c    FF59BC20 [DM.GatewayCore] Executing query (timeout=224) "<pi>
SELECT
TOP (1000001) [t0].[ProductCategoryName],[t0].[FiscalYear],SUM([t0].[Amount])
 AS [a0]
FROM
(
(select [$Table].[ProductCategoryName] as [ProductCategoryName],
    [$Table].[ProductSubcategory] as [ProductSubcategory],
    [$Table].[Product] as [Product],
    [$Table].[CustomerKey] as [CustomerKey],
    [$Table].[Region] as [Region],
    [$Table].[Age] as [Age],
    [$Table].[IncomeGroup] as [IncomeGroup],
    [$Table].[CalendarYear] as [CalendarYear],
    [$Table].[FiscalYear] as [FiscalYear],
    [$Table].[Month] as [Month],
    [$Table].[OrderNumber] as [OrderNumber],
    [$Table].[LineNumber] as [LineNumber],
    [$Table].[Quantity] as [Quantity],
    [$Table].[Amount] as [Amount]
from [dbo].[V_CustomerOrders] as [$Table])
)
 AS [t0]
GROUP BY [t0].[ProductCategoryName],[t0].[FiscalYear] </pi>"

Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config

No arquivo Microsoft.PowerBI.DataMovement.Pipeline.Diagnostics.dll.config, altere o valor de TraceVerbosity de 4 para 5. Este arquivo está localizado, por padrão, em C:\Arquivos de Programas\Gateway de dados local. A alteração dessa configuração começará a registrar entradas detalhadas no log de gateway. Isso inclui entradas que mostram a duração.

Importante:

Habilitar o TraceVerbosity para 5 pode aumentar o tamanho do log significativamente, dependendo do uso do gateway. Depois de examinar os logs, você poderá definir TraceVerbosity como 4. Não é recomendável deixar esta configuração habilitada a longo prazo.

<setting name="TracingVerbosity" serializeAs="String">
    <value>5</value>
</setting>

Tipos de atividade

Tipo de atividade Descrição
MGEQ Consultas executadas no ADO.NET. Estão inclusas outras fontes de dados do DirectQuery.
MGEO Consultas executadas no OLEDB. Inclui o SAP HANA e o Analysis Service 2016.
MGEM Consultas executadas do mecanismo de Mashup. Usadas com conjuntos de dados importados que usam a atualização agendada ou a atualização sob demanda.

Determinar a duração de uma consulta

Para determinar o tempo necessário para consultar a fonte de dados, você pode fazer o seguinte.

  1. Abra o log de gateway.

  2. Pesquise um Tipo de Atividade para localizar a consulta. Um exemplo seria MGEQ.

  3. Anote o segundo GUID, que é a ID de solicitação.

  4. Continue a pesquisar o MGEQ até encontrar a entrada FireActivityCompletedSuccessfullyEvent com a duração. Você pode verificar se a entrada tem a mesma ID de solicitação. A duração estará em milissegundos.

    DM.EnterpriseGateway Verbose: 0 : 2016-09-26T23:08:56.7940067Z DM.EnterpriseGateway    baf40f21-2eb4-4af1-9c59-0950ef11ec4a    5f99f566-106d-c8ac-c864-c0808c41a606    MGEQ    21f96cc4-7496-bfdd-748c-b4915cb4b70c    B8DFCF12 [DM.Pipeline.Common.TracingTelemetryService] Event: FireActivityCompletedSuccessfullyEvent (duration=5004)
    
    Observação:

    FireActivityCompletedSuccessfullyEvent é uma entrada detalhada. Essa entrada apenas será registrada se o TraceVerbosity estiver no nível 5.

Ferramentas para solução de problemas

Coletando logs do configurador do gateway

Existem vários logs que podem ser coletados para o gateway. Sempre comece com os logs!

Logs do instalador

%localappdata%\Temp\On-premises_data_gateway_*.log

Logs de configuração

%localappdata%\Microsoft\on-premises data gateway\GatewayConfigurator*.log

Logs de serviço do gateway de dados local

C:\Users\PBIEgwService\AppData\Local\Microsoft\on-premises data gateway\Gateway*.log

Logs de eventos

Os logs de eventos do serviço do gateway de dados local estão presentes nos Logs de Aplicativos e Serviços.

on-prem-data-gateway-event-logs

Rastreamento do Fiddler

Fiddler é uma ferramenta gratuita da Telerik que monitora o tráfego HTTP. Você pode ver a parte de trás e frente com o serviço do Power BI do computador cliente. Isso pode mostrar erros e outras informações relacionadas.

Histórico de atualização

Ao usar o gateway para atualização agendada, o Histórico de Atualização pode ajudá-lo a ver quais erros ocorreram, além de fornecer dados úteis caso precise criar uma solicitação de suporte. Você pode exibir as atualizações programadas ou sob demanda. Aqui está como você pode acessar o Histórico de atualização.

  1. No painel de navegação do Power BI, em Conjuntos de Dados, selecione um conjunto de dados > Abrir Menu > Agendar Atualização.

  2. Em Configurações de... > Agendar Atualização, selecione Histórico de Atualização.

Para obter informações adicionais sobre como solucionar problemas de cenários de atualização, examine o artigo Solução de problemas de cenários de atualização.

Consulte também

Definição das configurações de proxy para Gateways do Power BI
Gateway de dados local
Detalhes sobre o Gateway de dados local
Gerenciar sua fonte de dados – Analysis Services
Gerenciar sua fonte de dados – SAP HANA
Gerenciar sua fonte de dados – SQL Server
Gerenciar sua fonte de dados – Importar/Atualização agendada
Mais perguntas? Experimente a Comunidade do Power BI