Solucionando problemas de aplicativos

O AppFabric fornece recursos para Gerenciar os Serviços .NET Framework versão 4 WCF e WF hospedados no IIS. Esses recursos incluem mecanismos de confiabilidade para hospedar serviços de fluxo de trabalho durável, configuração de aplicativo simplificada e ferramentas para monitorar a integridade dos seus serviços .NET Framework 4 WCF e WF. Esta seção descreve como usar as ferramentas de monitoramento para solucionar problemas de serviços.

Use o Dashboard para começar a solucionar problemas de serviços WCF e WF. Clique no ícone Dashboard no grupo AppFabric dentro do Gerenciador do IIS para exibir a página Dashboard. Essa página composta oferece uma exibição de resumo da integridade dos aplicativos implantados em um escopo específico no ISS e fornece links para detalhar informações mais específicas de solução de problemas. Se as métricas exibidas pelo Dashboard e suas páginas relacionadas não fornecerem as informações necessárias para resolver seu problema, você poderá usar as ferramentas do AppFabric para habilitar o rastreamento System.Diagnostics para solucionar problemas de um aplicativo WCF ou WF.

Solução de problemas usando o Dashboard

Nos aplicativos distribuídos, isolar um problema não é tão simples quanto procurá-lo em um contador ou usar apenas uma ferramenta em isolamento. Em vez disso, resolver problemas em um ambiente de serviço distribuído geralmente envolve correlacionar dados de diferentes ferramentas ou contadores para criar uma imagem realista da causa real de um problema. O Dashboard contém três widgets, Instâncias WF Persistentes, Histórico de Chamadas de WCF e Histórico de Instâncias WF, que você pode usar para correlacionar informações para solucionar problemas de seus aplicativos. Os dois últimos são métricas históricas, isso significa que o que é exibido é afetado pelo seletor de tempo Período de tempo na parte superior do Dashboard (Último Minuto, Últimas 24 horas e assim por diante).

Ao abrir ou exibir pela primeira vez um dos três widgets, você vê uma exibição de resumo de alto nível do status de suas métricas. Você poderá ver rapidamente se houver um problema nesse nível. Por exemplo, o widget Instâncias WF Persistentes exibe inicialmente o status de instâncias de fluxo de trabalho durável ao vivo que salvaram seu estado no repositório de persistência. Ele oferece um status de resumo do número de instâncias persistentes que estão nos estados Ativo, Ocioso e Suspenso. Isso poderá informar rapidamente se há um problema no nível de fluxo de trabalho persistente. Você pode clicar em links na página de resumo para obter informações adicionais sobre esse contador de resumo específico.

Usando métricas de instâncias WF persistentes

O widget Instâncias WF Persistentes exibe o status de instâncias de fluxo de trabalho ao vivo que salvaram seu estado no repositório de persistência. Ele exibe o número de instâncias persistentes que estão nos estados Ativo, Ocioso e Suspenso. Cada cabeçalho, e o próprio contador de resumo, é um link para a página Instâncias WF Persistentes que contém os dados brutos.

Para entender melhor o problema ao solucionar problemas de instâncias suspensas, clique no link Instâncias Suspensas no Dashboard. A página Instâncias WF Persistentes exibe todas as instâncias suspensas. Selecionar uma delas preenche o painel Detalhes na parte inferior da tela com informações de resumo sobre a instância suspensa. A guia Erros exibe a razão pela qual a instância foi suspensa. Se você precisar de informações adicionais, clique com o botão direito do mouse em uma instância e selecione a opção Exibir Eventos Controlados. Essa ação leva você para a página Eventos Controlados, que exibe todos os eventos controlados da instância de fluxo de trabalho suspensa. Os eventos são classificados por padrão com os mais novos no início.

Usando métricas do Histórico de Chamadas de WCF

O widget Histórico de Chamadas de WCF exibe o número de chamadas WCF que foram recebidas e registradas no repositório de monitoramento. O cabeçalho exibe um contador de resumo de chamadas que foram concluídas, encontraram exceções ou o número de vezes que uma limitação ocorreu. A primeira coluna mostra os cinco principais serviços com o maior número de chamadas concluídas. A segunda coluna mostra uma divisão dos erros WCF agrupados por tipo de erro. A terceira coluna mostra os cinco principais serviços com a maioria das exceções de serviço. Cada métrica é associada à página Eventos Controlados, onde você pode ver os dados brutos que são resumidos no Dashboard.

Por exemplo, para obter mais informações sobre uma chamada com falha, clique no contador de resumo Chamadas com falhas e vá para a página Eventos Controlados. Essa página é preenchida com as chamadas WCF com falha mais recentes para o escopo selecionado na hierarquia do IIS. Selecionar um desses eventos preenche o painel Detalhes na parte inferior da tela. A guia Erros contém informações de exceção sobre a falha. Se você precisar de mais contexto sobre a chamada com falha, clique com o botão direito do mouse no evento e selecione a opção Exibir Todos os Eventos Relacionados. Isso atualiza a página Eventos Controlados e a preenche com todos os eventos relacionados ao primeiro.

Usando métricas do Histórico de Instâncias WF

O widget Histórico de Instâncias WF mostra o número de instâncias de fluxo de trabalho que foram ativadas, falharam e foram concluídas. A primeira coluna mostra os cinco principais serviços com a maioria das ativações. A segunda coluna mostra os cinco principais serviços com a maioria das instâncias com falha. A terceira coluna mostra quantas das instâncias com falha foram recuperadas. Por exemplo, se uma instância de fluxo de trabalho encontrou um erro que fez com que ela fosse suspensa e depois foi continuada e concluída com êxito, você verá ela contada uma vez em ambas as colunas Com Falha e Recuperada.

Solucionar problemas usando informações do widget Histórico de Instâncias WF é semelhante a usar o widget Instâncias WF Persistentes. Clique em um dos cabeçalhos para ir até a página Instâncias WF Controladas onde você pode exibir informações de resumo sobre a instância de fluxo de trabalho. Porém, como o widget Histórico de Instâncias WF exibe instâncias de fluxo de trabalho que já podem ter sido concluídas, você não verá as ações de controle da instância vistas na página Instâncias WF Persistentes. Na página Instâncias WF Controladas, você pode clicar com o botão direito do mouse em uma instância e exibir seus eventos controlados para ver dados controlados de nível baixo para a instância.

Solucionando problemas usando o rastreamento System.Diagnostics

O AppFabric aproveita as melhorias nos rastreamentos WCF e WF no .NET Framework 4 que emitem eventos para o subsistema do Rastreamento de Eventos para Windows (ETW). O ETW fornece uma infraestrutura rápida de rastreamento de eventos. Em alguns cenários, no entanto, você precisará ver todas as informações de diagnóstico disponíveis. No AppFabric, você pode habilitar o rastreamento System.Diagnostics no nível de aplicativo ou site. Essas informações de rastreamento são gravadas em arquivos no disco e podem ser exibidas com a ferramenta Visualizador de Rastreamento de Serviços.

Solucionando problemas de um aplicativo ASP.NT distribuído

Você pode usar a ID de atividade (conforme mencionado na seção Usando métricas do Histórico de Chamadas de WCF anterior) para procurar uma ID de instância durável e ajudar a solucionar problemas de um aplicativo ASP.NET que se comunica por várias máquinas de servidor AppFabric com serviços WCF. Para realizar isso, o nível de monitoramento deve estar deifnido como, pelo menos, Monitoramento Fim da Fim para configurar o rastreamento da atividade.  Vamos ver um exemplo de como isso pode ocorrer. 

Ao monitorar o aplicativo da Web usando as ferramentas de monitoramento do ASP e do IIS, o administrador observa um aumento em erros de tempo limite do aplicativo ASP.NET durante a comunicação com um serviço.  Depois de verificar os erros, o administrador obtém a ID de atividade ativa no momento do erro.  Usando o AppFabric Dashboard, o administrador cria e executa uma consulta para essa mesma ID de atividade.  Um evento é retornado – um evento de recebimento na instância Y do serviço X.  O administrador visualiza o fluxo de mensagens associado a esse evento e observa um evento “Limitação Máxima de Chamadas Simultâneas Excedida”.  Verificando as páginas de resumo do serviço, o administrador observa que “Ocorrências de Limitação de WCF” está definido como 20.  Ele também verifica as exibições das chamadas durante as últimas 24 horas e aumenta os últimos 30 minutos. Ele exibe outros dias e faz as mesmas observações em cada dia.  Ele conclui que a carga aumenta nos mesmos horários todos os dias, e a definição de limitação máxima de chamadas simultâneas deve ser aumentada para 25.  Observando com atenção, o administrador verifica que a incidência de eventos de limitação diminui drasticamente com os erros de tempo limite para o aplicativo ASP.NET ao chamar os serviços WCF.

Trabalhos do serviço do SQL Server Agent Windows

O serviço do SQL Server Agent Windows monitora operações do SQL Server, automatiza tarefas administrativas, gera alertas conforme a necessidade e agenda e executa trabalhos. Um trabalho do SQL Server é uma série especificada de operações executadas sequencialmente pelo SQL Server Agent que cobre uma variedade de tarefas relacionadas ao banco de dados. Quando o AppFabric está configurado para usar o SQL Server, ele usa o SQL Server Agent para importar eventos no repositório de dados de Monitoramento e para limpar regularmente dados antigos do repositório.

Se o SQL Server Agent não estiver em execução, então os trabalhos agendados do AppFabric não poderão ser executados dentro da instalação do SQL Server.  Essas são algumas etapas para garantir que esses trabalhos sejam executados conforme agendados usando o serviço do SQL Server Agent Windows:

1. Garanta que o serviço do SQL Server Agent Windows esteja em execução verificando seu status. Clique em Ferramentas Administrativas, selecione Serviços, SQL Server Agent (MSSQLSVR) e garanta que seu Status exiba Iniciado no momento. Se não, inicie o serviço.

2. Quatro trabalhos do SQL Server são criados quando o repositório é inicializado:

   • Microsoft_ApplicationServer_Monitoring_AutoPurge_<monitoring DB name>

   • Microsoft_ApplicationServer_Monitoring_ImportWfEvents_<monitoring DB name>

   • Microsoft_ApplicationServer_Monitoring_ImportWcfEvents_<monitoring DB name>

   • Microsoft_ApplicationServer_Monitoring_ImportTransferEvents_<monitoring DB name>

   Se o serviço do SQL Server Agent Windows for iniciado e os trabalhos do AppFabric não estiverem em execução, verifique os erros encontrados quando o trabalho foi executado pela última vez.

3. Se as instâncias de trabalho foram terminadas com êxito, mas não houver eventos nas tabelas de eventos, verifique a tabela ASFailedStagingTable no repositório de dados de Monitoramento. Essa tabela contém determinadas colunas, tais como ErrorNumber e ErrorMessage, que podem ajudar você a descobrir a razão da falha. Se não houver erro, essa tabela ficará vazia.

A identidade (proprietário) do Windows usada para executar um trabalho do AppFabric SQL Server Agent não deve ser a do usuário conectado. Em vez disso, ele deve ser executado sob uma identidade da conta de segurança pré-configurada AS_MonitoringDbJobsAdmin do Windows. Essa conta deve ser uma conta de domínio. Essa conta recebe as permissões apropriadas no repositório de monitoramento quando o cmdlet Initialize-ASMonitoringDatabase é executado após a instalação.

O SQL Server Agent processa os diferentes proprietários de um trabalho do AppFabric Server enviado da seguinte forma:

• Se o proprietário de um trabalho do SQL Server Agent for uma conta de domínio, o SQL Server entrará em contato com o controlador de domínio para verificar se a conta é válida. Se sim, ele executará a conta de domínio. Se não, ele tentará executar em uma conta local.

• Se o proprietário de um trabalho do SQL Server Agent for uma conta sysadmin local, o SQL Server Agent honrará corretamente a identidade “RunAs” na etapa do trabalho e emitirá o comando "Executar usuário como AS_MonitoringDbJobsAdmin". Isso significa que o trabalho será executado sob a identidade da conta AS_MonitoringDbJobsAdmin.

  Observação

  Para exibir a identidade “RunAs” de um trabalho no SQL Server Management Studio, clique com o botão direito do mouse no trabalho, clique em Propriedades e clique na guia Avançadas. Esse valor deve ser definido para a conta AS_MonitoringDbJobsAdmin.

• Se o proprietário de um trabalho do SQL Server Agent for uma conta local, mas não sysadmin, a identidade ”RunAs” fornecida no trabalho será ignorada.  Neste caso, o serviço do SQL Server Agent executará o trabalho como o proprietário local.

• No cenário de domínio desconectado (um laptop, por exemplo), se a identidade de um trabalho de monitoramento do SQL Server for um usuário de domínio, o SQL Server Agent tentará validar a conta contatando o controlador de domínio. Se o computador que executa o trabalho do SQL Server Agent estiver desconectado do domínio, haverá falha. Para minimizar essa falha, há duas opções:

  1. A primeira e mais simples das duas opções é configurar o trabalho Initialize-ASMonitoringDatabase) usando uma conta de usuário local.

  2. A segunda opção é se um trabalho for configurado pelo proprietário usando uma conta de domínio, o usuário poderá atualizar o proprietário do trabalho mais tarde para uma conta de usuário local usando o procedimento armazenado sp_update_job do SQL Server.

Uma prática recomendada é configurar o serviço do SQL Server Agent Windows para executar em uma conta de logon local. Isso permitirá que o serviço seja executado em um computador AppFabric mesmo se sua conexão de rede tiver sido encerrada. Se esse serviço estiver sendo executado em uma conta de domínio e o domínio não puder ser acessado, o serviço do SQL Server Agent Windows não poderá obter credenciais. Isso significa que os eventos de Monitoramento não podem ser movidos corretamente em suas tabelas de destino final. O resultado é que nenhum novo dado será exibido no Dashboard.

Trabalhos do SQL Server Express

Embora as etapas para diagnosticar por que um trabalho falhou sejam muito semelhantes ao SQL Server, você precisará verificar a tabela ASJobsTable do SQL Server Express.  Essa tabela é específica para uma instalação do SQL Server Express e não está presente em uma instalação do SQL Server. Dentro dessa tabela, você pode exibir os valores das colunas LastRunOn e LastRunSuccess em uma linha de trabalho específica para determinar se um trabalho foi executado com êxito ou falhou.

O SQL Server Express não usa o serviço do SQL Server Agent Windows. Em vez disso, ele aproveita o SQL Service Broker. Há um recurso de tempo dentro do Service Broker que tem um valor de tempo limite definido como o intervalo no qual o trabalho Microsoft_ApplicationServer_Monitoring_AutoPurge_<monitoring DB name> é configurado para execução. Quando esse intervalo de tempo limite ocorre, uma mensagem é enviada para a fila de trabalhos do SQL Server. Essa mensagem ativa o procedimento armazenado executado como parte do trabalho Microsoft_ApplicationServer_Monitoring_AutoPurge_<monitoring DB name>. Por sua vez, ele executa a funcionalidade de limpeza automática em um repositório do SQL Server Express.

Essas são algumas consultas T-SQL que você pode executar para ajudar a monitorar o progresso da funcionalidade de limpeza de repositório automática:

• Exibe os trabalhos agendados atualmente: SELECT * FROM ASJobsTable

• Verifica a coluna dialog_timer (na hora UTC) para ver quando será a próxima execução do trabalho: SELECT * FROM sys.conversation_endpoints

• Exibe o número de procedimentos de ativação em execução no momento: SELECT * FROM sys.dm_broker_activated_tasks

• Descobre quantas mensagens ainda estão na fila. Quando nenhum trabalho estiver em execução, isso retornará 0: SELECT * FROM ASScheduledJobQueue

Consulte também

Referência

Página Windows Server AppFabric Dashboard
Página Instâncias WF Persistentes
Página Instâncias WF Rastreadas
Página Eventos Rastreados

  2011-12-05