Aqui está como a maioria das interrupções do SharePoint é descoberta: um ticket de help desk. Alguém no financeiro não consegue abrir uma biblioteca de documentos, três tickets a mais aparecem, e quando a equipe de administração confirma o problema, metade da empresa já foi afetada.
Os servidores da fazenda provavelmente estavam “no ar” o tempo todo. Essa é a armadilha com o SharePoint Server. Um único carregamento de página atravessa as front ends do IIS, a cadeia de autenticação, os aplicativos de serviço e o SQL Server. Qualquer uma dessas camadas pode se degradar enquanto toda verificação básica de uptime permanece verde.
Este guia cobre o que realmente monitorar em uma fazenda SharePoint, onde as ferramentas integradas param, como configurar alertas que disparam antes do primeiro ticket, e como transformar dados de monitoramento em um relatório SLA que sua gerência aceitará.
Por que os Problemas do SharePoint Chegam ao Help Desk Antes de Chegarem até Você
Verificações de ping e porta respondem a uma pergunta: o servidor é acessível? O SharePoint falha de maneiras que essa pergunta nunca alcança.
Considere uma tempestade de logins numa segunda-feira de manhã. Centenas de funcionários autenticam às 9h, os servidores ADFS ficam sobrecarregados e os logins que normalmente levam dois segundos passam a levar quarenta. Todo servidor responde ao ping. O IIS retorna 200s. Mas ninguém consegue acessar a intranet, e os tickets começam.
Ou a versão mais lenta: a latência do disco no volume SQL que hospeda seu maior banco de dados de conteúdo sobe gradualmente durante um mês. Os carregamentos de página passam de um segundo para quatro. Nenhum limite dispara, porque ninguém monitorava o número que mudou.
O padrão é o mesmo em ambos os casos. A camada que falha fica entre “servidor está ativo” e “usuário conseguiu seu documento”, e esse território intermediário é exatamente o que o monitoramento do servidor SharePoint deve cobrir.
Um carregamento de página SharePoint atravessa cinco camadas. Uma verificação básica de uptime vê apenas a primeira.
O que Monitorar em uma Fazenda SharePoint Server
Você não precisa de centenas de contadores. Você precisa da lista curta que prevê a dor do usuário, monitorada consistentemente.
| Camada | O que Monitorar | Por quê |
|---|---|---|
| Front ends IIS | Comprimento da fila de solicitações, taxa 5xx, CPU e memória, reciclagem do pool de aplicativos | Solicitações enfileiradas são o primeiro sinal de que a fazenda não consegue acompanhar a carga. |
| SQL Server | Latência de leitura/gravação de disco nos volumes do banco de conteúdo, bloqueios, crescimento do log de transações | Quase toda operação SharePoint termina no SQL. Discos lentos aqui desaceleram tudo. |
| Pesquisa | Atualização da crawl, acúmulo da fila de crawl, latência da consulta | Pesquisa desatualizada ou lenta é uma das reclamações mais frequentes no SharePoint e se degrada silenciosamente. |
| Jobs de Timer | Contagem de jobs falhados, último tempo de execução dos jobs críticos | Jobs de timer falhados quebram silenciosamente fluxos de trabalho, sincronizações de perfil e relatórios de uso. |
| Cache Distribuído | Status do host do cache em cada servidor que o executa, saúde do serviço AppFabric | Tokens de login e feeds vivem aqui, e um host de cache ruim causa sintomas em toda a fazenda que são difíceis de rastrear. |
| Autenticação | Tempo do round-trip de login pelo AD, ADFS ou Entra ID | A autenticação é um ponto único de falha em toda a fazenda que os contadores do servidor mal refletem. |
| Experiência do usuário | Tempo de login, carregamento de página em coleções de sites chave, resposta de busca, upload/download de documento | Esses são os aspectos que os usuários sentem, e os termos em que seu SLA é escrito. |
A última linha é a que a maioria das configurações de monitoramento SharePoint ignora. Contadores do servidor indicam que um componente está sobrecarregado. Apenas uma verificação que se comporta como um usuário, fazendo login, abrindo uma biblioteca, executando uma busca, informa se a fazenda está realmente entregando. Dependendo da fazenda, monitore também pools de aplicativos de serviço e, se fluxos de trabalho legados ainda estiverem em uso, Workflow Manager.
Defina uma linha de base para cada métrica durante uma semana normal antes de configurar limites. Uma leitura de CPU de 70% não significa nada até você saber se o normal é 40% ou 65%.
O que as Ferramentas Integradas Capturam (E O que Elas Perdem)
O SharePoint Server vem com uma verdadeira maquinaria de monitoramento, e você deve usá-la. A documentação de monitoramento da Microsoft cobre três partes principais:
- Health Analyzer executa verificações baseadas em regras contra a configuração da fazenda e condições conhecidas de falha, podendo até auto-reparar algumas.
- Logging Diagnóstico (ULS) grava logs detalhados de rastreamento que você vai querer durante qualquer investigação de causa raiz.
- Coleta de dados de uso e saúde reúne estatísticas de requisição e serviço no banco de dados de uso e logs.
Equipes que usam System Center podem adicionar o management pack do SharePoint e obter alertas baseados em eventos.
Mas repare o que todos têm em comum: rodam dentro da fazenda e reportam sobre ela. Nenhum deles pode dizer que o balanceador de carga está enviando usuários para um nó morto, que o certificado no endpoint ADFS expirou, ou que os carregamentos de página levam nove segundos a partir do escritório remoto. As regras do Health Analyzer também rodam em agendas, algumas diárias ou semanais, então um problema pode permanecer não detectado entre execuções.
As ferramentas embutidas são a metade interna de uma estratégia de monitoramento. A metade externa precisa vir de verificações que abordem o SharePoint como os usuários fazem.
Como Monitorar o que os Usuários Realmente Experimentam
A metade externa é o monitoramento sintético: verificações roteirizadas que rodam em agenda e realizam tarefas reais do SharePoint. Um script útil para uma fazenda SharePoint faz quatro coisas:
- Passo 1: Logar. Use uma conta dedicada de monitoramento com acesso mínimo necessário. Meça o tempo do round-trip completo de autenticação, incluindo quaisquer redirecionamentos SSO.
- Passo 2: Carregar uma página. Abra sua coleção de sites mais movimentada ou a página inicial da intranet e registre o tempo de carregamento em um navegador real, não só a resposta HTML.
- Passo 3: Fazer uma busca. Pesquise um termo que deva retornar um documento conhecido, e falhe a verificação se não retornar. Isso captura atraso de índice que uma visão do lado servidor não sinalizaria como problema de usuário.
- Passo 4: Tocar um documento. Abra ou baixe um arquivo de teste de uma biblioteca para validar o caminho completo pelo IIS, permissões e SQL.
Com Dotcom-Monitor, isso é uma tarefa de monitoramento de aplicação web gravada uma vez com EveryStep scripting e reproduzida de onde seus usuários estiverem. Para uma implantação acessível pela internet ou híbrida, isso significa nós externos nas regiões dos seus usuários. Para uma fazenda exclusiva de intranet atrás do firewall, agentes privados executam as mesmas verificações roteirizadas de dentro da sua rede, então uma implantação on-premises não isenta a fazenda do monitoramento em nível de usuário.
A autenticação merece planejamento em vez de evitamento. Se você usa Entra ID (antigo Azure AD), dê à conta de monitoramento sua própria política de acesso condicional que substitui MFA por um intervalo IP de monitoramento autorizado. Onde quer que a conta esteja, armazene suas credenciais em um cofre e roteie-as no seu cronograma habitual. Se sua fazenda autentica via ADFS ou Entra ID, o passo de login também serve como verificação de saúde nessa cadeia toda. Cobrimos os detalhes da configuração em monitoramento de aplicações que usam ADFS.
E se parte do seu ambiente estiver no Microsoft 365, a mesma abordagem roteirizada se aplica lá. Nosso guia para monitoramento sintético do Office 365 percorre isso. Você não pode ver os servidores da Microsoft, o que torna a verificação em nível usuário a única medição do SharePoint Online que você possui.
Como Configurar Alertas que Chegam Antes do Primeiro Ticket
O objetivo é uma corrida específica: seu alerta tem que chegar antes do primeiro ticket do help desk. Três práticas decidem isso.
Alerta no número percebido pelo usuário, diagnostique com o número do servidor. Acione o responsável quando o tempo de login triplicar ou a verificação de busca falhar, porque é isso que gera tickets. Deixe que as métricas de CPU e disco anotem o alerta em vez de direcioná-lo. Alerta baseado em contadores de servidor é como times acabam ignorando seus próprios alertas. Duas regras iniciais que funcionam: acione quando o tempo de login dobrar sua linha de base por duas verificações consecutivas, e acione quando a verificação de busca não encontrar o resultado conhecido.
Verifique antes de acordar alguém. Uma verificação que falha uma vez em um local pode ser uma falha momentânea de rede. Uma verificação que falha em dois locais, ou duas vezes seguidas, é um incidente. A maior parte da fadiga por alertas vem de pular essa etapa. O Dotcom-Monitor faz a re-verificação de um segundo local automaticamente antes de um alerta ser enviado.
Ajuste a frequência à matemática do SLA. Se você é responsável por 99,9% de uptime, isso corresponde a cerca de 43 minutos de downtime por mês. Uma verificação que roda a cada 15 minutos pode queimar um terço desse orçamento antes de disparar uma vez. Execute verificações em nível usuário a cada um a cinco minutos nos fluxos que importam, e agende janelas de manutenção na ferramenta de monitoramento para que noites de patch não acordem ninguém nem poluam o registro de uptime.
Como Reportar o Uptime do SharePoint Contra seu SLA
A maioria das equipes SharePoint responde a um SLA, seja um compromisso contratual ou uma promessa interna à empresa. A configuração de monitoramento acima produz as evidências: um registro com timestamp de cada verificação, cada falha e cada tempo de resposta, independente dos próprios logs da fazenda.
Essa independência importa. Quando os logs da fazenda dizem “saudável” e os usuários dizem “lento”, um terceiro registro medido do lado do usuário resolve a discussão. Também te oferece algo que os dashboards de serviço da Microsoft nunca darão em ambientes híbridos: um único número contínuo de uptime cobrindo on-premises e nuvem.
Um relatório SLA mensal precisa de três coisas: uptime medido contra a meta, tendências de tempo de resposta nos fluxos de usuário que você roteirizou, e uma lista de incidentes com duração e causa raiz. Relatórios de uptime e SLA geram os dois primeiros diretamente a partir do histórico de verificações, agendados para quem precisar. A linha de tendência justifica seu valor entre incidentes. Um carregamento de página que sobe de um segundo para três durante um trimestre é um aviso precoce de capacidade no qual você pode agir antes que vire uma enxurrada de tickets.
Qual Ferramenta de Monitoramento SharePoint se Encaixa em Seu Ambiente
Ferramentas diferentes monitoram metades diferentes do problema, então a comparação honesta é pelo ponto de vista.
Ferramentas integradas (gratuitas). Health Analyzer, logs ULS e coleta de dados de uso. Use-as independentemente do que mais comprar. Elas configuram a fazenda corretamente e apoiam investigações de causa raiz, mas não alertam em tempo real nem medem experiência do usuário.
Monitores de infraestrutura baseados em agente. ManageEngine Applications Manager e SolarWinds Server & Application Monitor fornecem templates SharePoint que coletam contadores da fazenda: tamanhos de banco de dados, falhas de timer jobs, saúde do IIS e SQL, requisições por segundo. O PRTG cobre terreno similar com sensores pré-construídos para Windows, IIS e SQL, extensíveis com scripts customizados. Boas escolhas para as linhas de servidor da tabela acima, e se você já usa um para seu ambiente Windows, direcione-o à fazenda. Em ambientes System Center, o SCOM com management pack do SharePoint cobre o mesmo terreno.
Plataformas de monitoramento sintético. Dotcom-Monitor trabalha do lado do usuário: logins roteirizados, carregamentos de página, buscas e transações de documento de nós externos ou agentes privados, com alertas e relatórios SLA baseados nessas verificações. Essa é a camada que vence a corrida contra o primeiro ticket, captura o que ferramentas baseadas em agente estruturalmente não conseguem, e para SharePoint Online é a única camada disponível.
A maioria dos times que consegue isso combina uma ferramenta interna com uma externa. O que importa é que ambas as metades existam, porque o ponto cego de uma é a cobertura central da outra.
A Conclusão
O monitoramento do servidor SharePoint funciona quando cobre ambas as metades: métricas da fazenda que explicam problemas, e verificações em nível usuário que os detectam. Monitore a lista curta de contadores que prevêem dores, roteirize as quatro ações do usuário que importam, alerte no que os usuários sentem com verificação embutida, e deixe o histórico de verificações também servir como seu relatório SLA.
