Quando um site WordPress apresenta problemas em uma sexta-feira à tarde, o cronômetro começa para dois problemas distintos: corrigir o site e descobrir quem causou o problema.
O segundo problema quase sempre leva mais tempo. O desenvolvedor aponta para a campanha que acabou de entrar no ar. O profissional de marketing aponta para o servidor. A agência recebe ligações de ambos os lados e não tem dados próprios para analisar. Quando todos finalmente concordam sobre onde investigar, a indisponibilidade já gerou prejuízo financeiro, assim como a discussão.
A causa do problema não é o fato de as equipes discordarem. É que cada equipe trabalha com uma parte diferente dos dados. O desenvolvedor vê o código. O profissional de marketing vê o tráfego. A agência vê a fila de tickets de suporte. Ninguém vê as mesmas informações ao mesmo tempo e, por isso, ninguém consegue descartar nenhuma hipótese.
A abordagem da Kinsta é colocar todas as equipes no mesmo nível de diagnóstico. Os dados que os engenheiros de suporte da Kinsta usam para investigar um problema, como códigos de resposta, desempenho do PHP, taxas de cache e registros de solicitações, são os mesmos dados disponíveis para todos os usuários do MyKinsta com acesso às Análises. Quando todos interpretam os mesmos indicadores, um site com problemas passa a ser algo que a equipe diagnostica em conjunto, em vez de discutir sobre quem é o culpado.
Isso também muda a forma como as equipes interagem com o suporte. Este guia apresenta as ferramentas de diagnóstico disponíveis no MyKinsta, o que cada uma mostra, quando utilizá-las e como incorporá-las a um fluxo de trabalho compartilhado, em vez de uma sessão individual de depuração.
Por que problemas de desempenho se transformam em discussões sobre responsabilidade
Um site WordPress moderno raramente deixa toda a responsabilidade nas mãos de uma única pessoa. Os desenvolvedores gerenciam a base de código. Os profissionais de marketing executam campanhas. Agências ou freelancers administram o relacionamento com o provedor de hospedagem. Cada equipe está fazendo seu trabalho; o problema é que a visibilidade entre elas não se sobrepõe.
Quando um site apresenta problemas, essa falta de visibilidade transforma silenciosamente um problema técnico em um problema pessoal:
- Os desenvolvedores inspecionam o código, mas não o servidor. A visão deles termina na camada da aplicação, portanto, uma causa relacionada ao servidor permanece invisível.
- Os profissionais de marketing veem o tráfego, mas não o banco de dados. Um pico causado por uma campanha parece ser a causa mais provável porque é a única variável que conseguem medir.
- As agências recebem a reclamação, mas não possuem nenhum dos dados. Elas acabam atuando como intermediárias entre as partes, em vez de serem a fonte das respostas.
Sem um ponto de referência compartilhado, cada parte presume que a causa está com outra pessoa. Muitas plataformas de hospedagem reforçam esse comportamento ao manter os dados de diagnóstico restritos à equipe de suporte. Você abre um ticket e espera enquanto outra pessoa analisa os registros aos quais você não tem acesso.
A Kinsta adota a abordagem oposta. Agora vamos ver quais ferramentas usar primeiro e como utilizá-las como parte de um fluxo de trabalho compartilhado, e não individual.
O que o painel de Análises do MyKinsta mostra quando algo dá errado
Quando um site começa a apresentar problemas, a primeira tarefa é determinar que tipo de problema você está enfrentando. Um site lento, um site com erros e um site sobrecarregado exigem respostas diferentes. Errar esse diagnóstico, como tratar um problema de cache como um problema de servidor ou um aumento de erros como um problema de tráfego, desperdiça o tempo de toda a equipe.
A seção Análises do MyKinsta é onde esse diagnóstico começa.
Há dados em nível de empresa na seção Análises do MyKinsta. Para um site específico, acesse Sites > nome do site > Análises. Em ambos os casos, os mesmos relatórios ficam disponíveis para todos os usuários com acesso às Análises.
Confirme se o site realmente está retornando erros
Antes de qualquer coisa, confirme se o site realmente está falhando ou apenas está lento. Esses problemas têm causas e soluções diferentes, e confundi-los é exatamente o que dá início à troca de acusações.
A aba Response responde a essa pergunta. Seu gráfico principal, Response code breakdown, mostra a distribuição dos códigos de status HTTP retornados pelo seu site durante o período selecionado.
Assim, um agrupamento de códigos 5xx aponta para um problema no servidor ou no aplicativo, enquanto códigos 4xx indicam problemas de acesso a recursos. Outros dois gráficos permitem aprofundar ainda mais a análise:
- 500 error breakdown separa um erro 500 genérico de erros como 502 Bad Gateway e 503 Service Unavailable, que indicam causas diferentes.
- 400 error breakdown separa os códigos do lado do cliente, diferenciando um grande volume de erros 404 de outras respostas que indicam problemas de autenticação, permissões ou limitação por taxa.
Como todos os usuários com acesso às Análises consultam o mesmo detalhamento, a equipe pode começar a trabalhar diretamente na falha específica, em vez de perder tempo debatendo possíveis causas.
Diferencie um site lento de um site com falhas
Um site que leva seis segundos para carregar e outro que retorna erros 500 causam uma experiência igualmente ruim para um visitante frustrado, mas têm causas completamente diferentes. É na aba Desempenho que você faz essa distinção.
Há vários relatórios nessa seção que valem a pena verificar em qualquer investigação sobre lentidão:
- Tempo médio de resposta PHP + MySQL mostra quanto tempo a aplicação leva para processar e consultar cada solicitação sem cache. Um aumento repentino costuma ser o primeiro sinal de degradação do desempenho, e não de um problema de infraestrutura.
- Taxa de transferência PHP mostra quantas solicitações foram processadas durante o período. Se a lentidão coincide com um aumento na taxa de transferência, e não com uma alteração no código, a causa mais provável é a carga, e não um bug.
- Uso de AJAX revela aumentos na atividade de admin-ajax.php, uma fonte comum e frequentemente negligenciada de consumo de recursos do backend, geralmente causada por plugins e usuários autenticados executando tarefas em segundo plano.
- Maior tempo máximo de upstream lista os caminhos individuais mais lentos, permitindo identificar diretamente a página ou o endpoint que está elevando o tempo médio do site, em vez de depender de suposições.
Em conjunto, esses relatórios mostram se o próximo passo deve ser otimizar o aplicativo ou escalar um incidente.
Verifique quanto do site está sendo atendido pelo cache
Um site pode parecer lento por motivos que não têm relação com o código ou a infraestrutura: uma parte muito pequena dele está sendo atendida pelo cache. Quando a taxa de cache diminui, o servidor passa a processar solicitações que não deveria processar, aumentando os tempos de resposta. Essa é uma das causas mais comuns da discussão “será que o problema é a hospedagem?” e quase nunca a hospedagem é a responsável.
A seção Cache mostra como as solicitações são tratadas nas diferentes camadas de cache da Kinsta.
Cada solicitação é classificada em um de três estados:
HITsignifica que a Kinsta atende a solicitação a partir do cache, que é o comportamento esperado para a maior parte do tráfego.BYPASSsignifica que uma regra ou um conflito impede que a solicitação utilize o cache.MISSsignifica que o conteúdo ainda não está em cache, mas ficará armazenado após a primeira solicitação.
O gráfico Cache de um site saudável é composto principalmente por Acertos (HITs). Quando a taxa de Ignorados (BYPASS) aumenta, o relatório Principais desvios do cache do servidor identifica os caminhos específicos que estão ignorando o cache.
Alguns desvios não representam um problema, como a página de login do WordPress, que nunca é armazenada em cache. No entanto, quando uma página que pode ser armazenada em cache aparece nessa lista, isso indica um conflito com um plugin ou um problema em uma regra de cache. Consultar esses relatórios enquanto analisa uma página lenta permite verificar se ela está armazenada em cache, em vez de presumir que o problema está na hospedagem.
Identifique o que está consumindo recursos
Se um site não está retornando erros, mas consome mais largura de banda ou capacidade do que deveria, você pode encontrar a origem no relatório Principais solicitações. Problemas relacionados a recursos são os mais difíceis de identificar: um excedente de largura de banda ou uma lentidão sob carga normalmente não apresenta nenhum código de erro.
Três relatórios eliminam as suposições e identificam a origem do problema:
- Largura de banda do servidor mostra quais URLs transferem mais dados diretamente do seu servidor de origem.
- Largura de banda total inclui os dados fornecidos pelo CDN e pelo Edge Caching, permitindo visualizar o consumo total de cada solicitação.
- Visualizações mostra os recursos mais solicitados, independentemente do tamanho, revelando um endpoint sob carga constante, em vez de apenas um arquivo pesado.
Em conjunto, esses relatórios revelam se um aumento no consumo de recursos foi causado por um arquivo de mídia muito grande, um endpoint fora de controle ou um crawler acessando o mesmo caminho milhares de vezes. A partir daí, a solução normalmente consiste em otimizar o recurso, fornecê-lo por meio de um CDN ou corrigir o endpoint.
Se o aumento estiver sendo causado pelo tráfego de crawlers ou bots, a Proteção contra bots da Kinsta permite identificar, classificar e bloquear tráfego não humano diretamente no MyKinsta, sem alterar nenhum plugin nem abrir um ticket de suporte.
Como o APM rastreia um problema de desempenho até sua origem
Os relatórios de Análises mostram o que está acontecendo em um site. A ferramenta APM da Kinsta mostra por que isso está acontecendo. Enquanto as Análises mostram que o tempo de resposta do PHP aumentou às 14h, o APM mostra qual função de plugin, consulta ao banco de dados ou chamada para uma API externa causou esse aumento.
O APM está incluído em todos os planos da Kinsta e funciona no MyKinsta.
Execute o APM em uma sessão, não continuamente
Ao contrário do painel de Análises, que registra dados continuamente em segundo plano, o agente do APM aumenta o consumo de CPU e memória do servidor enquanto coleta os dados. A Kinsta recomenda executá-lo apenas durante a investigação ativa de um problema.
Para iniciar uma sessão, acesse Sites > nome do site > APM, clique em Habilitar APM e selecione um período de monitoramento de 2, 4, 12 ou 24 horas. O APM é desabilitado automaticamente ao final do período.
Isso permite seguir um fluxo de trabalho simples:
- Inicie o APM quando suspeitar de um problema ou conseguir reproduzi-lo, para evitar essa sobrecarga no site durante a operação normal.
- Escolha um período que cubra o problema e, em seguida, reproduza a falha ou aguarde que ela ocorra novamente para que a ferramenta a registre com dados em tempo real.
- Analise os resultados depois que os dados forem coletados e desabilite o APM quando terminar.
Como interpretar os resultados do APM
O APM organiza os dados coletados em quatro abas: Transações, WordPress, Banco de dados e Externo.
Comece pela aba Transações para localizar as solicitações mais lentas. Ao clicar em qualquer transação, uma linha do tempo é aberta com todos os processos envolvidos na solicitação e destaca os trechos que consumiram mais recursos. Isso mostra se o esforço de otimização deve se concentrar em uma consulta lenta ao banco de dados, em uma função específica de um plugin ou em uma API de terceiros.
A aba Externo é especialmente útil para descartar a hospedagem como causa do problema. Se a lentidão de uma transação for causada por uma chamada para uma API externa, os dados do APM mostram isso de forma explícita. Essa é a diferença entre um ticket de suporte que diz “o site está lento” e outro que diz “a lentidão está na API do nosso provedor de serviços de e-mail, não no servidor”.
Como o Visualizador de registros e o Registro de atividades reconstroem uma linha do tempo
Resolver um incidente normalmente depende de saber o que aconteceu e em que ordem. Dois recursos do MyKinsta ajudam a reconstruir essa linha do tempo: o Visualizador de registros mostra o que o site registra, enquanto o Log de atividades mostra o que as pessoas fizeram.
O visualizador de logs mostra o que o site registra, e não como ele se comporta em termos de desempenho. Há três arquivos disponíveis na tela Registros de qualquer site no MyKinsta:
error.logregistra erros e avisos do PHP e é o primeiro lugar onde você deve procurar a causa de uma página com problema.kinsta-cache-perf.logregistra o desempenho do cache e mostra se as páginas foram atendidas pelo cache ou o ignoraram.access.logregistra todas as solicitações HTTP que chegam ao site e é onde você acompanha padrões de tráfego e erros 404 recorrentes.
O visualizador integrado carrega até 20.000 linhas e inclui um campo de pesquisa para filtrar qualquer sequência de texto. Os registros também podem ser baixados pelo Gerenciador de Arquivos do MyKinsta caso você precise analisá-los em uma ferramenta externa.
O Registro de atividades: o que as pessoas fizeram
O Registro de atividades no MyKinsta mostrando ações com data e hora, o usuário responsável e um ícone de status.
Você encontra os registros de atividades em Sites > nome do site > Atividade do usuário. Cada entrada permite que você veja a ação descrita em linguagem simples, o usuário, a data e hora e um ícone de status. Aqui, uma marca de seleção verde indica sucesso e um ponto de exclamação vermelho indica falha.
Essa ferramenta se torna ainda mais útil quando utilizada em conjunto com outros registros. Por exemplo, se o arquivo error.log contiver registros relevantes, você pode abrir o registro de atividades, limitar a visualização ao mesmo intervalo de tempo e identificar as ações relacionadas.
Como o monitoramento do site cria uma visão compartilhada
As ferramentas anteriores são reativas. O Monitoramento do site torna a detecção proativa: em vez de descobrir um problema por meio da reclamação de um cliente, você e a Kinsta tomam conhecimento dele ao mesmo tempo.
A Kinsta monitora todos os sites da plataforma cerca de 480 vezes por dia. Com as notificações de monitoramento habilitadas em Configurações de usuário > Notificações, você recebe um e-mail para eventos que exigem atenção crítica:
- Erros do site alertam sobre um problema detectado no próprio site.
- Erros de SSL alertam sobre um problema no certificado SSL ou na configuração antes que ele afete os visitantes.
- Expiração do domínio alerta quando um domínio está prestes a expirar, antes que ele deixe de funcionar.
Os e-mails são enviados somente após três verificações consecutivas com falha, e não após a primeira. Isso elimina falhas momentâneas que, de outra forma, gerariam uma grande quantidade de alertas falsos.
A SIX15 Solutions monitora mais de 30 sites de clientes com esse sistema, onde o maior benefício não está na verificação em si, mas no fato de que muitos problemas são resolvidos antes mesmo que os clientes percebam.
Atualmente, hospedo mais de 30 sites de clientes no meu plano Agency, desde pequenos sites de marketing até sites completos de associação com milhares de usuários, sem nenhum problema ou tempo de inatividade.
No entanto, nem todo alerta indica uma falha. Os alertas de limite do plano notificam quando você está se aproximando dos limites de uso do seu plano e funcionam como uma camada eficaz de alerta antecipado. Assim, você pode usar as Análises para identificar por que está atingindo um limite, seja por uma campanha que gerou mais tráfego do que o previsto ou pela atividade de crawlers ou bots.
Dados compartilhados são o que encerram as discussões sobre responsabilidade
O que mais consome tempo quando um site apresenta problemas não é a correção em si, mas descobrir quem é o responsável. As Análises do MyKinsta mostram se um site está lento, com falhas ou sobrecarregado. Em conjunto com o APM, o Visualizador de registros, o Log de atividades, o Monitoramento do site e outras ferramentas, elas garantem que todos sejam informados sobre um problema e possam começar a trabalhar imediatamente, sem precisar aguardar em uma fila de tickets.
O objetivo é utilizar essas ferramentas como parte de um fluxo de trabalho compartilhado. Quando todos os membros da equipe têm o acesso adequado às Análises, é possível definir antecipadamente quais relatórios serão utilizados antes mesmo de abrir um ticket. Dessa forma, a conversa permanece focada no diagnóstico, em vez de se transformar em uma discussão.
Se você gerencia sites em que várias equipes compartilham responsabilidades, a hospedagem gerenciada para WordPress da Kinsta oferece a todas elas acesso às mesmas ferramentas de diagnóstico. Já para quem administra sites de clientes em grande escala, vale a pena conhecer o Programa de Agência Parceira da Kinsta, que oferece recursos de acesso compartilhado e gerenciamento compartilhado.
