O que é APM (Gerenciamento de Performance de Aplicações)?
O Gerenciamento de Performance de Aplicações (APM) é essencial para qualquer estratégia de TI, oferecendo muitos benefícios além do simples monitoramento de desempenho.
Última atualização: 07 de setembro de 2026
O que significa APM?
São duas coisas, por isso o termo causa tanta confusão. Gerenciamento é o significado mais antigo e mais amplo. Monitoramento é o que a maioria dos fornecedores vende, portanto é o significado que domina páginas de produtos e resultados de busca. A metade do gerenciamento é um trabalho que alguém ocupa. Alguém decide o que “rápido o suficiente” significa para cada aplicação, documenta isso e é responsável quando não é cumprido. Essa pessoa também decide quanto gastar — com ferramentas, tempo de engenharia, infraestrutura — para manter o nível. Na prática, a disciplina de gerenciamento cobre quatro coisas:- Metas. Qual tempo de resposta, taxa de erro e disponibilidade cada aplicação deve aos seus usuários, e quais dessas metas são contratuais.
- Propriedade. Qual equipe é responsável por cada meta e quem é acionado quando ela não é cumprida.
- Investimento. Quanto custa o trabalho e as ferramentas de performance e o que o negócio recupera disso.
- Provas. Os relatórios que comprovam para clientes, auditores e executivos que as metas foram atingidas.
Gerenciamento de Performance de Aplicações vs. Monitoramento de Performance de Aplicações
O monitoramento informa que o checkout levou 840 milissegundos no percentil 95 na última terça-feira. O gerenciamento decide se 840 milissegundos é aceitável, quem é responsável por reduzir esse tempo e se esse trabalho tem prioridade sobre as três funcionalidades que aguardam na fila. Um produz dados. O outro produz decisões.A pergunta | Respondido por |
|---|---|
O fluxo de checkout está mais lento do que no mês passado? | Monitoramento |
“Mais lento que no mês passado” é ruim o suficiente para agir? | Gerenciamento |
Qual serviço está adicionando latência? | Monitoramento |
Qual equipe é responsável por corrigir isso, e em quanto tempo? | Gerenciamento |
Ultrapassamos a meta de 99,9% de disponibilidade no segundo trimestre? | Monitoramento |
O que devemos ao cliente, e precisamos renegociar o SLA? | Gerenciamento |
Uma Decisão Que o Monitoramento Não Pode Tomar
Nos dados da plataforma Dotcom-Monitor, aproximadamente 38% das falhas detectadas se resolvem sozinhas em até cinco minutos. Uma rota oscila, um nó reinicia, um failover é concluído. O monitoramento relata cada um deles com precisão.
O que o monitoramento não pode dizer é o que fazer a respeito. Três decisões se seguem, todas elas chamadas do gerenciamento:
- Um pico de quatro minutos que se resolve sozinho deve acordar um engenheiro às 3 da manhã ou esperar pelo relatório da manhã?
- Contabiliza contra o número de disponibilidade do contrato que assinamos? Isso depende se o acordo estabelece uma duração mínima para falhas, e muitos não estabelecem.
- O trabalho de engenharia para remover essa classe de falha vale mais do que o que está na próxima prioridade do roadmap?
Onde uma ferramenta se encaixa: O Dotcom-Monitor pode aplicar a primeira decisão depois que você a definiu. Os filtros de alerta seguram uma notificação até que um monitor falhe N vezes consecutivas, ou falhe em M de N locais, para que um ponto flutuante não acorde ninguém. O que a plataforma não pode fazer é escolher N. Se definir muito alto, perde falhas reais; se muito baixo, a equipe para de ler alertas. Esse limite é uma decisão de gerenciamento sobre quanto risco trocar por noites de sono.
Os Cinco Componentes de uma Estratégia APM
A classificação padrão do APM tem cinco partes, e vem sendo o modelo de referência da categoria há mais de uma década. Cada parte corresponde a uma pergunta que sua equipe pode responder com sim, não ou uma pausa incômoda — e a uma resposta clara sobre se uma plataforma externa como a nossa cobre isso.
1. Monitoramento da Experiência do Usuário Final
O que seus clientes realmente recebem: carregamento de páginas, conclusão de transações e erros, medidos de onde eles estão, e não de dentro da sua rede. É o componente que inclui seu CDN, seu provedor DNS e o gateway de pagamento que você não controla dentro da medição, em vez de fora.
Pergunte à sua equipe: quais jornadas dos usuários medimos fora da nossa própria infraestrutura, e com que frequência? Se a resposta é “uma verificação de uptime na página inicial a cada cinco minutos”, você está medindo muito menos do que pensa. O monitoramento real de aplicações web acompanha toda a jornada — login, busca, carrinho, checkout — não apenas se a porta da frente abre.
O Dotcom-Monitor cobre isso completamente. As jornadas são executadas em navegadores reais a partir de checkpoints tier-3 em seis continentes, em mais de 40 combinações de navegadores e dispositivos desktop e móveis, com condições de rede simuladas de 2G a 4G para que você veja o que um cliente com conexão lenta vê. O que não faz: dizer o que seus usuários reais realmente fizeram. São jornadas roteirizadas e agendadas, não monitoramento real do usuário. Saber qual das seis variantes de checkout as pessoas abandonam é uma questão de RUM, que é uma categoria de produto diferente.
2. Descoberta da Arquitetura da Aplicação em Tempo de Execução
Um mapa preciso e atual do que se conecta a o quê. Não o diagrama que alguém fez quando o sistema foi desenhado — mas o que realmente está rodando hoje de manhã, inclusive o serviço que um contratado adicionou em março.
Pergunte à sua equipe: podemos gerar um mapa atual de dependências sem que uma pessoa o desenhe? Se alguém tem que reconstruí-lo de memória, sua resposta a incidentes começa tentando entender como o sistema realmente é.
O Dotcom-Monitor não faz isso, e essa é a maior lacuna da abordagem sem agente. A descoberta automática do grafico de serviços internos exige um agente rodando no runtime. O que cobrimos é a superfície de dependência externa: resolução DNS, expiração de certificados, endpoints de APIs de terceiros e traceroute de múltiplas regiões para detectar mudanças de roteamento no nível do ISP. Essa é a metade do mapa que vive fora do seu código, e a que as ferramentas baseadas em agentes veem pior.
3. Perfilagem de Transações Definidas pelo Usuário
Acompanhamento das transações de negócio específicas que importam — proposta a fechamento, adicionar ao carrinho a confirmação do pedido, login a painel carregado — em vez de fazer médias de todas as requisições juntas. Médias ocultam a única transação que está quebrada.
Pergunte à sua equipe: nomeie as cinco transações que nos custam dinheiro quando param de funcionar. Todas as cinco estão instrumentadas e alertando separadamente? A maioria das equipes consegue nomeá-las mais rápido do que provar que todas as cinco estão cobertas.
O Dotcom-Monitor cobre isso completamente. O gravador EveryStep captura uma jornada ao percorrê-la uma vez, depois a reproduz em uma programação com tempos por passo, capturas de tela e exportações HAR. Logins roteirizados passam de ponta a ponta por Okta, Auth0, Azure AD e Ping, pegando a falha que só ocorre no passo 4 de 6 quando o token da sessão expira. O que não faz: perfilar o caminho de código dentro da transação. Você saberá que o passo 4 levou nove segundos; não saberá qual função consumiu esse tempo.
4. Monitoramento Profundo de Componentes
Detalhes de dentro da aplicação — chamadas ao banco de dados, filas, chamadas externas de API — ligados à transação que os disparou. Sem essa ligação, você tem um muro de métricas de componentes sem modo de conectar qualquer uma delas à reclamação do cliente.
Pergunte à sua equipe: quando uma transação chave está lenta, quantos minutos passam até sabermos qual componente é responsável? Esse número costuma ser o trecho mais longo de um incidente, e é o que vale a pena reduzir.
O Dotcom-Monitor cobre parte disso. Uma cascata de carregamento de página mostra o tempo de cada recurso, recursos que bloqueiam renderização e erros JS; monitores de API fazem encadeamento de requisições, passam tokens de autenticação e afirmam sobre cargas de resposta por endpoint; verificações de protocolo isolam certificado expirado ou provedores downstream falhando. O que não faz: apontar a consulta SQL lenta ou o método que segura o bloqueio. Isso é território genuinamente de agentes, e nenhuma medição externa substitui essa capacidade.
5. Análise de Aplicações
Transformar dados coletados em decisões: planejamento de capacidade, relatórios de tendência, evidências de SLA e o caso de negócios para a próxima rodada de trabalho em performance.
Pergunte à sua equipe: qual decisão tomamos no último trimestre por causa dos dados de APM? Se ninguém souber nomear uma, vocês estão pagando para coletar dados que não usam, o jeito mais comum de cortar orçamento de APM.
O Dotcom-Monitor cobre a metade de relatórios: relatórios de SLA para disponibilidade, tempo de resposta e taxa de erro contra seus próprios limites, exportáveis por agendamento e com marca branca se você for um MSP reportando a clientes. O que não faz: funcionar como repositório geral de análise. Você não pode juntar dados de monitoramento a dados de receita ou funil dentro da plataforma; isso pertence ao seu data warehouse.
Benefícios do Gerenciamento de Performance de Aplicações
A maioria das listas de benefícios de APM publicadas poderia ser escrita sem conhecer nada do seu negócio. Estas são as que valem ser declaradas em termos que um gerente pode checar, com o mecanismo que produz cada uma.
Melhoria da Experiência do Usuário
Performance medida do seu datacenter e performance medida do telefone de um cliente com conexão 4G em São Paulo são números diferentes. O segundo é o que impacta decisões. É onde scripts de terceiros, resolução DNS e comportamento regional do CDN aparecem, nenhum deles nas métricas do servidor. O mecanismo é geografia mais dispositivo: execute a mesma jornada das regiões onde seus clientes estão, nos navegadores e velocidades de rede que usam, e o problema regional aparece em um gráfico em vez de um chamado de suporte dois dias depois.
Eficiência Operacional Aprimorada
A parte mais longa da maioria dos incidentes não é a correção. É o intervalo entre “algo está errado” e “sabemos qual equipe é responsável.” O mecanismo que reduz isso é evidência capturada no momento da falha em vez de reconstruída depois. Uma execução falhada do Dotcom-Monitor entrega ao engenheiro de plantão o passo quebrado, uma captura de tela, um vídeo da sessão, o log do console e a cascata, antes que qualquer um precise reproduzir algo.
Otimização e Economia de Custos
O dinheiro aparece em dois lugares. Infraestrutura superdimensionada, porque equipes dimensionam para um pico que nunca mediram e os dados de APM dizem qual é o pico real. E a conta das ferramentas, que depende de como o fornecedor cobra. Plataformas baseadas em agentes tipicamente cobram por host ou por gigabyte ingerido, então a conta cresce com sua frota ou volume de logs. O Dotcom-Monitor cobra por quantidade de monitores, frequência de checagem e mix de plataforma — sem cobrança por host ou assento, nem linha por volume de ingestão. Nenhum modelo é universalmente mais barato. Eles transferem o custo para uma variável diferente, e a questão é qual variável você controla.
Toma de Decisão Informada
Planejamento de capacidade antes de um evento conhecido — lançamento de produto, pico de Black Friday, prazo para entrega — é tão bom quanto sua linha de base. Sem ela, “damos conta de 5x o tráfego?” é respondido por quem fala mais confiante na reunião. O mecanismo é simples: rode a mesma jornada roteirizada na mesma frequência por tempo suficiente para ter meses de números comparáveis antes de precisar deles.
Detecção Proativa e Resolução de Problemas
A versão mensurável desse benefício é um número: qual a parcela dos seus incidentes que você encontra antes do cliente reportar? Equipes que não sabem responder geralmente descobrem que sua detecção é pior do que julgavam. As checagens agendadas aumentam essa parcela porque rodam independentemente do uso da aplicação, o que explica como se detecta um checkout quebrado às 4 da manhã de um domingo. O limite vale ser declarado: elas cobrem apenas as jornadas que alguém roteirizou. Um caminho não roteirizado pode falhar sem ser notado.
Melhoria no Deployment de Aplicações
Regressões de performance são mais baratas de corrigir antes do lançamento. Uma equipe com linhas de base pode definir um limite no pipeline de deployment: se a transação de checkout fica 20% mais lenta no ambiente de staging, o build para. Sem linhas de base, a regressão é liberada e aparece em produção uma semana depois, quando ninguém lembra do código. A versão prática é apontar a mesma jornada gravada para staging e produção. Quando o staging está atrás de um VPN ou não tem endereço público, um Agente Privado na sua rede fará as checagens parecerem idênticas às públicas.
O Mercado de Gerenciamento de Performance de Aplicações e Como Avaliar Fornecedores
Por que os Tamanhos de Mercado Publicados Discordam
Pesquise “mercado de gerenciamento de performance de aplicações” e você terá uma página de firmas de analistas vendendo um número. Compare seus resumos lado a lado e as estimativas para o mesmo ano não concordam — não por arredondamento, mas por bilhões.
Essa diferença não é descuido, é decisão de limites. Algumas firmas contam plataformas completas de observabilidade; outras contam apenas o módulo de APM dentro delas; outras incluem ou excluem monitoramento de infraestrutura, gerenciamento de logs e monitoramento de experiência digital. E uma cifra que parece baixa é frequentemente uma previsão antiga circulando sem o ano-base indicado. Antes de colocar um número de mercado em um pedido de orçamento, confira três coisas: qual firma publicou, o que o relatório contou e a que ano se refere. Um número sem isso não é uma medição.
As Principais Categorias de Ferramentas APM
Plataformas full-stack baseadas em agentes. Ferramentas como Datadog, New Relic e Dynatrace instalam um agente junto à aplicação e a instrumentam internamente. Isso dá detalhes de código — a consulta SQL lenta, o método segurando o bloqueio — que nada mais oferece. O pulo do gato é o esforço de implantação e uma conta que cresce com sua infraestrutura. A precificação costuma ser por host, por gigabyte ingerido, por usuário, ou alguma combinação. O Dynatrace, por exemplo, publica seu tier full-stack a $58 por mês por host de 8 GiB, faturado a $0,01 por GiB-memória-hora, em agosto de 2026. Olhe a unidade: a conta acompanha quanta memória seus hosts têm, não quanto tráfego servem.
Monitoramento externo sem agente. Executa a aplicação de fora, do jeito que um cliente faz, sem nada instalado no seu código. Vê o que o cliente vê, incluindo SaaS de terceiros dos quais você depende mas que não controla nem instrumenta. O software de monitoramento de performance da Dotcom-Monitor é dessa categoria, reproduzindo jornadas roteirizadas em navegadores reais a partir de locais externos — uma abordagem geralmente chamada monitoramento sintético. Porque as checagens são externalizadas, o runtime interno pouco importa: bare metal, VMs, Kubernetes e serverless são monitorados da mesma forma.
Stacks open-source e baseadas em OpenTelemetry. Monte o seu próprio a partir da instrumentação OpenTelemetry e backend como Prometheus, Grafana, Tempo ou Jaeger. Sem taxa de licença e sem fornecedor controlando seu formato de dados. O custo vai para engenharia: alguém monta, alguém opera, alguém fica de plantão. Bom para equipes que já têm engenheiros de plataforma, ruim para equipes que tomam horas de desenvolvedores de produto.
SaaS vs auto hospedado. Isso cruza as três categorias acima. Auto hospedagem responde perguntas sobre residência e retenção de dados sob seus termos e entrega a responsabilidade operacional; SaaS é o contrário. Indústrias reguladas geralmente fecham essa decisão primeiro.
O Que o Monitoramento Externo Responde, E O Que Não Responde
A maioria das organizações acaba com ferramentas de mais de uma categoria, porque as categorias respondem a perguntas diferentes. Aqui está a divisão para uma plataforma sem agente como a nossa, declarada claramente para você ver qual metade de suas perguntas fica aberta:
A pergunta | Sem agente, de fora para dentro | O que você precisa em vez disso |
|---|---|---|
O checkout está funcionando agora para usuários em Frankfurt? | Sim—reproduza a jornada a partir de um ponto de verificação em Frankfurt | — |
O último lançamento desacelerou a renderização da página? | Sim—compare as cascatas antes e depois | — |
Qual dependência de terceiros quebrou? | Sim—verificações de DNS, certificado, API e protocolo | — |
Estamos cumprindo o SLA que assinamos? | Sim—relatórios de SLA contra seus limites | — |
Qual consulta ao banco de dados está lenta? | Não | Uma plataforma baseada em agente |
Qual serviço no nosso mesh adicionou a latência? | Não | Rastreamento distribuído |
O que os usuários reais fizeram antes de desistirem? | Não | Monitoramento de usuário real |
Quanto de carga podemos suportar antes de quebrar? | Não | Uma ferramenta de teste de carga |
O Que Verificar Além da Lista de Recursos
As listas de recursos convergem. A maioria das sérias ferramentas APM fazem a maioria das coisas. As diferenças que realmente importam aparecem depois que você assina:
- O que gera a fatura. Hosts, gigabytes ingeridos, assentos, monitores ou frequência de verificação? Escolha o modelo que corresponde à forma como seu sistema cresce. Preço por host pune uma equipe que executa muitos pequenos containers. Preço por gigabyte pune o registro verboso. Preço por monitor pune a amplitude da cobertura.
- Retenção padrão de dados. Pergunte o que está incluído e qual o custo para ampliar. A retenção é onde o preço cotado e a fatura real se separam.
- Por host versus por transação. Se o tráfego está estável e sua frota continua crescendo, por transação é mais amável. Se for o contrário, por host é melhor.
- Tempo até o primeiro sinal útil. Um rollout de agente precisa de aprovação da equipe de plataforma, uma janela de mudança e um plano de reversão. Um monitor externo precisa de uma URL ou uma jornada gravada. Pergunte a cada fornecedor quanto tempo até o primeiro alerta real, não quanto tempo até o contrato começar.
- Formato do contrato. Duração do termo, compromissos anuais de aumento, taxas de excedente e o que acontece se você usar menos do que se comprometeu.
- Custo de saída. Se você sair, o que vem com você? Instrumentação nativa OpenTelemetry é portátil. Agentes proprietários não são; re-instrumentar é um projeto, não uma tarefa.
APM Para Equipes Menores
Uma equipe sem uma função dedicada de observabilidade não deveria executar uma cópia reduzida de um programa empresarial de APM. Quatro prioridades cobrem a maior parte do valor.
Comece de fora para dentro. Se você medir uma coisa, meça se suas três principais jornadas de usuário são completadas, das regiões onde seus clientes estão. Isso captura as falhas que custam receita, e o software de monitoramento de desempenho de aplicação sem agente faz isso sem mudanças de código ou projeto de implantação. Na prática, isso significa gravar uma jornada uma vez e reproduzi-la em um cronograma, o que é minutos de trabalho em vez de uma sprint.
Pule o tracing distribuído até você estar distribuído. O tracing vale a pena quando uma requisição atravessa muitos serviços. Em um monólito e um banco de dados, é custo e complexidade para detalhes que seus logs já carregam.
Um canal de alerta, um responsável. Alertas divididos em quatro ferramentas viram alertas que ninguém lê. Escolha o canal onde a equipe já habita—PagerDuty, Slack, Teams, SMS ou um webhook para o que você usa—e envie tudo para lá.
Compre retenção que você realmente irá consultar. Treze meses de dados em alta resolução parece prudente. Se ninguém consultou nada mais antigo que duas semanas, você está pagando por tranquilidade.
A ressalva: verificações externas dizem que o checkout quebrou e em qual etapa, não por que no código. Nesse tamanho geralmente é o trade-off certo, porque o problema caro é não saber nada. Deixa de ser o trade-off certo quando “qual serviço?” vira uma pergunta genuína.
Construindo uma Prática de APM em Cinco Estágios
Equipes raramente saltam do nada para maduras. Elas avançam por estágios reconhecíveis, e saber em qual você está indica o que fazer a seguir.
Estágio 1—Reativo
Você descobre pelos clientes, ou por uma fila de suporte que de repente fica ocupada. Sem bases de referência, sem metas, sem responsável. Você está aqui se seus últimos três incidentes foram relatados para você, não por você.
Estágio 2—Monitorado
Existem verificações de disponibilidade e alertas básicos. Você sabe quando algo está fora do ar. Você não sabe por quê, ou quão lento estava antes de cair. Você está aqui se pode dizer “o site ficou fora do ar por 22 minutos” mas não “o checkout estava falhando por duas horas antes disso.” A próxima etapa para o estágio 3 é parar de checar URLs e começar a checar jornadas.
Estágio 3—Mensurado
Transações-chave são instrumentadas separadamente, existem bases de referência, e cada uma tem um responsável nomeado. O desempenho é discutido com números em vez de impressões. Você está aqui se alguém pode responder “o checkout está mais lento que no mês passado?” sem abrir um ticket. A próxima etapa para o estágio 4 é registrar os números em um documento de metas e atribuir um nome para cada um.
Estágio 4—Governado
Metas são escritas, mapeadas aos SLAs assinados, revisadas periodicamente, e vinculadas a uma linha de orçamento. O trabalho de desempenho compete por vagas no roadmap em termos declarados e não por quem escalar mais alto. Você está aqui se uma meta de desempenho já alterou uma data de lançamento. É o estágio onde os relatórios periódicos de SLA deixam de ser um luxo, porque alguém fora da engenharia agora os lê.
Estágio 5—Aplicado
Orçamentos de desempenho funcionam no pipeline de implantação. Um build que torna uma transação-chave significativamente mais lenta não é liberado. Você está aqui se um deploy foi bloqueado por uma checagem de desempenho no último trimestre.
O estágio 4 é onde a maior parte do valor de negócio se concretiza, e é o estágio que não precisa de novas ferramentas—apenas acordo sobre quem é responsável pelo quê.
Perguntas Frequentes
O que significa APM?
APM significa Gerenciamento de Desempenho de Aplicações, a disciplina empresarial de definir, possuir e pagar por metas de desempenho de aplicações. A mesma sigla também é usada para Monitoramento de Desempenho de Aplicações, a prática técnica subjacente. Fora do software, APM também pode significar gerenciamento de desempenho de ativos na manufatura e utilidades.
Qual é a diferença entre gerenciamento de desempenho de aplicações e monitoramento de desempenho de aplicações?
Gerenciamento é a disciplina de negócios: definir metas de desempenho, atribuir responsabilidade, decidir o valor do desempenho, e reportar contra contratos. Monitoramento é a prática técnica de instrumentar aplicações e coletar os dados. Monitoramento diz que uma transação leva 840 milissegundos. Gerenciamento decide se isso é aceitável e quem corrige.
O que é uma ferramenta APM?
Software que coleta dados de desempenho sobre aplicações e apresenta para diagnóstico e relatórios. Ferramentas APM se dividem em três grupos: plataformas baseadas em agentes que instrumentam código internamente, ferramentas sem agente como o software de monitoramento de desempenho de aplicação da Dotcom-Monitor que medem externamente da forma que um usuário faz, e stacks open-source baseados em OpenTelemetry.
O APM requer instalação de agentes na sua aplicação?
Depende de qual parte da imagem você precisa. Detalhes em nível de código—consultas lentas, tempo no nível de método, traces distribuídos—requerem agente ou SDK dentro do runtime. Tudo que é medido do lado do usuário não requer isso: Dotcom-Monitor roda totalmente fora da sua aplicação, sem SDK para manter e nada implantado nos seus servidores. Para aplicações internas sem endereço público, um Agente Privado roda dentro da sua rede como um único binário, que é infraestrutura para instalar em vez de instrumentação adicionada ao seu código.
Como você mede o sucesso do APM?
Não está relacionado à quantidade de dados coletados. Medidas úteis: a parcela de incidentes que você detecta antes de um cliente reportar, o tempo entre alerta e saber o componente culpado, se você atingiu as metas de disponibilidade e tempo de resposta nos contratos, e se dados de desempenho mudaram uma decisão de roadmap ou capacidade no último trimestre. Se nenhum deles mudou, o programa não está funcionando independentemente da quantidade de dashboards.
Quais são os benefícios comerciais do APM?
Incidentes mais curtos, porque menos tempo é gasto decidindo qual equipe é responsável pelo problema. Menor gasto com infraestrutura, porque decisões de capacidade baseiam-se em picos medidos e não em suposições. Evidências para relatórios SLA. E menos regressões de desempenho chegando aos clientes, porque você as detecta contra uma linha de base antes do lançamento.
O que impulsiona o custo de uma ferramenta APM?
A unidade de cobrança, mais que o fornecedor. Plataformas baseadas em agentes geralmente cobram por host ou por gigabyte de dados ingeridos, então a conta acompanha o tamanho da sua frota e o volume de logs, enquanto plataformas sem agente cobram por quantidade de monitores e frequência das verificações, acompanhando sua cobertura; nosso guia para ferramentas APM compara as opções.
Equipes pequenas precisam de APM?
Precisam da parte de gerenciamento, alguém que seja responsável pelas metas de desempenho, mais do que de uma plataforma completa. Comece medindo suas principais jornadas de usuário de fora da sua rede e nomeando um responsável para cada uma. Adicione profundidade quando a arquitetura ficar complexa o suficiente para justificar.
Experimente Dotcom-Monitor Grátis por 30 Dias
Seja qual for sua estratégia de APM no papel, ela se baseia em uma medida: se suas jornadas críticas de usuário funcionam agora, de onde estão seus clientes. Dotcom-Monitor reproduz essas jornadas por navegadores reais a partir de checkpoints tier-3 em seis continentes, sem agentes e sem mudanças de código. Não fará profiling do seu código—para isso existem as ferramentas baseadas em agente—mas dirá o que seus clientes estão vivenciando enquanto você decide o que fazer.
Não é necessário cartão de crédito, todas as quatro plataformas incluídas. Ou veja planos e preços primeiro.
