Monitoramento do Microsoft 365: por que o Service Health não basta e o que monitorar
Autor: Pedro Tebaldi PM do KeepGreenO chamado chega sempre com a mesma frase: o Teams caiu. Em seguida, o analista abre o portal de administração, encontra todos os serviços marcados como saudáveis e fica sem resposta para dar. Ao mesmo tempo, a diretoria cobra uma posição e o usuário continua parado.
Esse desencontro tem uma explicação simples. O painel que a maioria das equipes consulta mostra o que a Microsoft enxerga do lado dela. No entanto, ele não mostra o que a sua empresa sente do lado de cá. Entre os dois pontos existe um caminho inteiro: link de internet, firewall, proxy, DNS, VPN e autenticação. Ou seja, qualquer um deles pode ser o culpado.
Por isso, acompanhar a suíte virou trabalho de engenharia, não consulta a dashboard. Neste guia, você vai ver o que medir em cada serviço e quais camadas montar. Além disso, verá quais limites a documentação oficial revela sobre o recurso nativo e como transformar tudo isso em alerta acionável.
O que é monitoramento de Microsoft 365
Monitoramento de Microsoft 365 é a prática de medir continuamente disponibilidade, desempenho e experiência de uso dos serviços da suíte. Ou seja, ele cobre Exchange Online, Teams, SharePoint, OneDrive e Entra ID.
Ele combina testes sintéticos, consultas às APIs da Microsoft e métricas de rede para responder a uma pergunta única: o usuário consegue trabalhar agora?
A diferença em relação ao monitoramento de TI tradicional está no que você controla. Por exemplo, em um servidor próprio, a equipe instala agente, coleta contador de CPU e age sobre a causa. Em contrapartida, na suíte da Microsoft, a infraestrutura pertence ao fornecedor.
Portanto, sobra uma responsabilidade diferente: provar. Provar que o serviço degradou, provar quando começou, provar se a falha está na nuvem ou no caminho até ela. Sem essa prova, o service desk vira refém do relato do usuário.
Por que o Service Health da Microsoft não é suficiente
O Service Health é o painel de integridade dentro do centro de administração. Ele mostra incidentes e avisos que a Microsoft já reconheceu publicamente. Serve bem para confirmar uma pane global. No entanto, ele falha justamente no caso mais comum do dia a dia: a degradação parcial que atinge só a sua empresa.
Vale destacar os limites que a própria Microsoft documenta. O histórico de incidentes resolvidos cobre apenas os últimos 30 dias. Somado a isso, as notificações por e-mail aceitam no máximo dois endereços por conta de administrador. Eventos de manutenção planejada sequer aparecem ali: eles ficam no Centro de Mensagens, em outra tela.
Além disso, existe um recurso mais profundo chamado Monitoramento do Microsoft 365, com telemetria quase em tempo real por cenário. Ele parece a solução ideal, mas o corte de elegibilidade elimina a maior parte do mercado.
Os requisitos publicados pelo fabricante exigem no mínimo 5.000 licenças. Elas podem ser de Office 365 E3, Microsoft 365 E3, Office 365 E5 ou Microsoft 365 E5.
Além disso, o tenant precisa de pelo menos 50 usuários ativos mensais. Por fim, o recurso ainda está em pré-visualização, sem data de disponibilidade geral.
Ou seja: a empresa brasileira de médio porte, com 300 ou 800 licenças, não tem acesso a nada disso. Ela enxerga apenas o semáforo agregado.
O atraso que ninguém conta
Ainda assim, mesmo quem é elegível convive com latência de informação. A documentação do recurso para o Teams traz um detalhe revelador.
Segundo a Microsoft, o recurso amostra abertura do aplicativo, chat e ingresso em reunião a cada 30 minutos.
Pior: a telemetria de Qualidade de Experiência, aquela que revela áudio picotado, pode chegar até 3 dias depois do fim da chamada. Como resultado, nenhuma operação consegue tratar um incidente de reunião com essa janela.
O que monitorar em cada serviço do Microsoft 365
Cada carga de trabalho falha de um jeito. Por isso, a matriz abaixo separa o sinal que você deve coletar da origem mais provável do problema quando esse sinal piora. Use-a como ponto de partida do seu plano de coleta.
| Serviço | O que monitorar | Origem provável quando degrada |
|---|---|---|
| Exchange Online | Tempo de envio e recebimento de uma mensagem de teste ponta a ponta, fila de entrega, latência de acesso à caixa via Graph API, cota de caixa postal |
Regra de transporte, filtro antispam de terceiros, quota estourada ou conector híbrido com certificado vencido |
| Microsoft Teams | Taxa de sucesso ao entrar em reunião, jitter, perda de pacotes, percentual de fluxos de áudio estabelecidos por UDP |
Firewall bloqueando UDP, banda saturada na filial, Wi-Fi congestionado ou tráfego forçado por VPN |
| SharePoint e OneDrive | Tempo de abertura de um site, upload e download de arquivo padronizado, erros de sincronização, consumo de armazenamento por site | Inspeção TLS no proxy, latência do caminho até a região do tenant ou biblioteca com excesso de itens |
| Entra ID | Sucesso e tempo de autenticação real, falhas de MFA, erros de token, saúde do conector de sincronização com o diretório local | Certificado de federação expirado, política de acesso condicional recém-alterada ou servidor de sincronização parado |
| Microsoft 365 Apps | Versão do canal de atualização por parque, falhas de ativação de licença, travamentos do Outlook, tempo de carga do perfil | Máquina fora do canal suportado, licença não atribuída ou arquivo de dados local corrompido |
Repare em um padrão: na maioria das linhas, a origem provável está do seu lado. Portanto, esse é exatamente o motivo pelo qual o painel do fornecedor não resolve o chamado.
Ebook: Como sobreviver à fatura cloud?
Nosso framework, Observability Maturity Index, mede a maturidade das operações em nuvem das empresas. Você encontrará: os quatro perfis de empresas, as métricas que você deveria estar medindo, um checklist de avaliação e um plano de ação para 90 dias.
Só o e-mail. Sem spam, e seus dados protegidos pela LGPD.
As quatro camadas de um monitoramento que funciona
Montar visibilidade sobre a suíte exige combinar quatro fontes de dado. Isoladas, cada uma mente por omissão. Por outro lado, juntas elas permitem apontar o culpado em minutos.
Camada 1: monitoração sintética
Um robô repete a jornada do usuário em intervalo fixo: faz login, envia um e-mail, abre um documento, entra em uma sala. Como o teste roda a partir das redes onde as pessoas realmente estão, ele detecta a degradação antes do primeiro chamado.
Ainda assim, vale escolher com cuidado o tipo de sonda. Os tipos de monitoração sintética variam entre checagem simples de disponibilidade, chamada de API e transação completa em navegador. Nesse sentido, a transação em navegador é o que reproduz a experiência de verdade.
Camada 2: APIs de status e de uso
Em seguida, a operação consome de forma programática o que a Microsoft publica. Por exemplo, a API de comunicações de serviço traz incidentes e avisos do tenant. A Graph API expõe dados de caixa postal, ativação de licença e atividade por serviço.
Essa camada é ótima para contexto e péssima para detecção. Isto é, ela responde “a Microsoft já admitiu o problema?”, nunca “meu usuário está sofrendo agora?”.
Camada 3: rede e identidade
Depois, entram os elementos que você administra. Latência e perda até os pontos de entrada da Microsoft, saúde do proxy, resolução de DNS, integridade dos túneis e estado do diretório. Inclusive, um Active Directory sincronizado com falha derruba a autenticação sem que nenhum serviço em nuvem apareça como indisponível.
Camada 4: experiência real do usuário
Por fim, colete o que acontece no dispositivo: tempo de carga, erros de cliente, qualidade de chamada percebida. Assim, essa é a camada que traduz métrica técnica em impacto de negócio. Uma estratégia de monitoração da experiência do usuário fecha a lacuna entre o gráfico verde e a reclamação real.
Onde os incidentes realmente nascem: o caminho até a Microsoft
A suíte é um serviço distribuído. O usuário não conversa com o datacenter que guarda o dado dele, mas com o ponto de entrada mais próximo da rede global do fornecedor. Portanto, o desenho da sua rede define boa parte do desempenho percebido.
A Microsoft é direta nesse ponto. Segundo os princípios de conectividade que ela publica, a recomendação é clara.
Ignore a descriptografia TLS, a interceptação de tráfego e a inspeção profunda de pacotes nos domínios da suíte. Além disso, ela orienta saída de internet local, DNS local e prioridade para os endpoints das categorias Otimizar e Permitir.
Nesse cenário, três desenhos derrubam a experiência com frequência. O primeiro é o backhaul: toda filial sai pela matriz, logo a conexão viaja centenas de quilômetros antes de chegar à nuvem. O segundo é a inspeção SSL aplicada ao tráfego da suíte, que adiciona latência a cada handshake.
O terceiro aparece no trabalho remoto. Quando a VPN corporativa força todo o tráfego pelo túnel, o colaborador em casa passa pelo escritório antes de alcançar o Teams. Nesses casos, o monitoramento precisa medir o caminho, não apenas o destino.
Como estruturar alertas e a rotina de operação
Coletar dado é a parte fácil. Transformar o dado em ação exige critério, senão a equipe se afoga em ruído. Antes de tudo, separe os alertas por consequência, não por métrica.
Alertas de indisponibilidade disparam quando a transação sintética falha em duas execuções consecutivas a partir de dois pontos distintos. Assim, a dupla confirmação evita acordar o plantão por causa de um teste isolado. Já os alertas de degradação comparam o tempo de resposta atual com a linha de base da mesma faixa de horário.
Outro ponto: mantenha alertas de pré-falha. Monitore certificado de federação a 30 dias do vencimento e cota de caixa próxima do teto. Vale destacar também o servidor de sincronização parado há mais de uma hora. Esses três avisos evitam a maior parte das paradas evitáveis.
No painel do dia a dia, um bloco resolve a pergunta política que sempre aparece. De um lado, o status que a Microsoft declara. Do outro, o resultado dos seus testes sintéticos. Quando os dois divergem, a equipe já sabe onde procurar.
Quem opera recursos na nuvem Azure em paralelo ganha ainda mais com essa correlação, porque identidade e rede costumam ser compartilhadas.
Seis erros comuns no monitoramento de Microsoft 365
1. Confiar apenas no semáforo do fornecedor. O painel dele descreve a infraestrutura dele. Ele não sabe que o seu proxy começou a inspecionar o tráfego do SharePoint ontem à noite.
2. Monitorar só o login do portal. Autenticar no portal prova pouco. O usuário quebra na reunião, no anexo grande, na sincronização de biblioteca. Teste as transações que geram chamado.
3. Testar a partir do datacenter. Uma sonda que roda no rack central mede o caminho do rack central. Portanto, distribua os pontos de teste pelas filiais e pelo perfil de acesso remoto.
4. Ignorar a camada de identidade. Grande parte dos incidentes percebidos como falha da suíte começa em política de acesso condicional, certificado vencido ou sincronização parada.
5. Alertar sem linha de base. Sem histórico, ninguém sabe se três segundos para abrir uma caixa postal é normal ou sintoma. Por isso, colete por semanas antes de definir limiar.
6. Não guardar a própria evidência. O painel do fornecedor descarta o histórico depois de 30 dias. Se a sua operação não arquiva medição própria, ela perde a base para renegociar contrato, cobrar o provedor de link ou justificar investimento. Em suma, guarde série histórica desde o primeiro dia.
Saiba como seu usuário experimenta sua aplicação antes que ele reclame.
Monitoração sintética, Core Web Vitals e análise de erros em frontend para correlacionar performance técnica com impacto real em conversão.
Conclusão
Monitorar a suíte da Microsoft não é acompanhar o semáforo de um fornecedor. É construir prova própria sobre uma plataforma que sustenta o trabalho de toda a empresa.
Vale destacar que o recurso nativo mais completo exige 5.000 licenças, amostra dados a cada 30 minutos e guarda apenas 30 dias de histórico. Ou seja, para a maioria das organizações brasileiras, essa conta não fecha.
A saída é combinar quatro camadas. Primeiro, teste sintético a partir de onde o usuário está. Depois, consulta às APIs oficiais e medição da rede e da identidade que você administra. Por fim, a experiência coletada no próprio dispositivo. Com esse conjunto, a TI para de discutir percepção e passa a apresentar evidência.
O ganho aparece rápido na operação. O service desk deixa de abrir chamado às cegas. Além disso, o gestor responde à diretoria com dado datado e a equipe de infraestrutura corrige a causa em vez de reiniciar máquinas. Quer estruturar essa visibilidade no seu ambiente com quem monitora infraestrutura híbrida há mais de 20 anos? Fale com um especialista da OpServices.
Perguntas Frequentes
Como verificar se o Microsoft 365 está fora do ar?
admin.microsoft.com e vá em Integridade, Integridade do serviço. Se não conseguir entrar no portal, use a página pública status.cloud.microsoft. Lembre-se de que esses painéis mostram apenas o que a Microsoft já reconheceu publicamente. Degradações que atingem somente a sua empresa, causadas por proxy, DNS, firewall ou VPN, não aparecem ali. Por isso, um teste sintético próprio, executado a partir das redes onde os usuários trabalham, é o único jeito de confirmar o problema em minutos.O Microsoft 365 tem monitoramento nativo?
Como saber se o problema é do Microsoft 365 ou da minha rede?
Monitoramento de Microsoft 365 precisa instalar agente?
Como monitorar a qualidade das chamadas do Microsoft Teams?
UDP. O bloqueio de UDP no firewall é uma das causas mais frequentes de áudio ruim, porque força o tráfego para TCP. Não dependa apenas da telemetria nativa de Qualidade de Experiência: segundo a documentação da Microsoft, ela pode chegar até 3 dias após o fim da chamada. Testes sintéticos de ingresso em reunião e medição contínua da rede entregam o sinal no mesmo minuto.
