Abra o dispositivo de destino na lista para editar. Na barra de endereços do navegador você verá algo como:
https://user.dotcom-monitor.com/ClientID/DeviceEdit?pid=dc7f4ff2ca944dekjh1078b96707002& deviceId=63698 & taskId=132834
O dispositivoId=63698 é o ID do dispositivo.
O taskId=132834 é o ID da tarefa.
Um ID de conta fornecido na página inicial de Selecionar uma conta na lista de contas disponíveis.
Depois de iniciar sessão, localize o ID da sua conta ao apontar para o menu Conta na barra lateral esquerda.
Uma vez logado em uma conta-mestre, você pode encontrar seus IDs de departamento em > Departamentos de Configurações de Conta > .
Each test in LoadView has a unique ID. Using the test ID you can call a specific scenario while configuring LoadView integration (e.g., for Jenkins or CircleCl builds).
The Test ID can be found on the test page.
The approach provides the ability to carefully define how Dotcom-Monitor interprets responses as either “Up” or “Down” responses. This is accomplished using filters.
Incidentally, a filter can also both be applied to a device (cutting false triggering) and to any type of reporting.
Filtering defines the Up/Down states using the following adjustable criteria:
All filters and their settings are available at Configure > Filters. After a filter is applied to a device all of the device’s notifications are based on the filter’s criteria. “Default Filter” is assigned to all new devices. The default filter has a balanced configuration and is suitable for most monitoring devices.
The formula for the Downtime calculation is as follows:
1. Downtime Duration is tied directly to the configurations within the filter:
2. Duration of “Undefined” state. An Undefined state can be set when the status of each agent involved in monitoring becomes Undefined. An agent status is considered as Undefined if the agent does NOT provide any response (error or success) in a certain amount of time:
Response Wait Time Duration = (the overall agents number+1) × monitoring frequency + 15 min
For example, we use three monitoring agents and a monitoring frequency of 5 minutes. Each agent will wait for a response for Response Wait Time Duration = (3+1)×5+15 min = 35 min. Once the time expired and no response received, an agent reports Undefined.
3. Duration of “Postponed” state. Postponing a device at any moment will stop any monitoring activity until it is re-enabled.
4. Duration Excluded by Schedule. Another entity that can significantly affect Uptime/Downtime calculations is Schedules. This is an option for managing your monitoring during routine maintenance. Monitoring can be postponed for specific days of the week as well as specific hours and minutes during a day. To set up a schedule, follow the instruction.
Any change in a device settings (including device restart) during the Down state will reset the state so no uptime alert will be sent.
EXAMPLE:
Let’s say we have device monitored from 7 locations and filter set that 3 locations must report an error for Downtime condition. First, monitoring node (agent 1) detects an error while the rest are still reporting success, then the second (agent 2) and at last third one (agent 4) detects an error at T4 which triggers filter to set Downtime beginning right from this moment. The Down state will remain until you set hypothetical Postpone at T5 because of the number of agent reporting errors higher than adjusted 3 throughout all this time. The time gap between T6 and T7 is an illustration of the fact we get the first response with a delay (monitoring session processing time includes network transfer delays and the execution itself), so “Postponed” time is being calculated as ∆ (T7–T5) (Postponed 2nd). Again, we fall into Downtime only on 3rd error from Agent 3 and get in the Up state only on the T9 response, when the number of failing agents becomes less than adjusted in the filter. Here comes the final downtime % calculation formula for this case:
LoadView usa servidores injetores de carga dos Serviços Web da Amazon (AWS) e serviçosde nuvem do Azure . O Dotcom-Monitor possui 17 regiões geográficas Servidores injetores de carga podem ser declarados e a carga pode ser gerada. Em cada região, cerca de 500 injetores de carga podem ser instantâneos.
Os limites de capacidade dependem do tipo de plataforma de monitoramento devido à diferença nos algoritmos de execução de teste:
O limite para um determinado tipo de teste de carga é calculado usando a seguinte fórmula:
500 x 16 x Número de Usuários Simultâneos por Injetor de Carga = Carga máxima do usuário
Encontre os limites de capacidade de carga resultantes abaixo:
| Teste de carga HTTP(S) (ServerView) | Teste de carga da página da Web (BrowserView) | Teste de carga do aplicativo web (UserView) |
| 8.000.000 usuários | 225.000 usuários | 225.000 usuários |
O agente de monitoramento "Xangai" (China), está localizado atrás do Grande Firewall da China,que é administrado diretamente pelo governo chinês. O governo chinês tem uma regra de filtragem em vigor para todo o tráfego da Internet e não é pública. Essas regras de filtragem são modificadas com frequência, o que, por sua vez, afeta os resultados de monitoramento do Agente de Xangai, China.
https://youtu.be/4py8zE5EtFc?si=LnpflrvFK1ESWYWQ
Você pode editar os locais do agente de monitoramento para vários dispositivos ao mesmo tempo na tela
Gerenciador de dispositivos
.
Em suma, as tarefas do UserView e do BrowserView Platforms carregam uma página da Web em um navegador real e executam todos os componentes da página, enquanto a Tarefa HTTP(S) usa o navegador "sintético" emulado " e só baixa o elemento de página que foi solicitado sem renderização.
Para obter mais detalhes, consulte Diferenças entre o monitoramento via HTTP(S) e via BrowserView/UserView e diferenças na medição de tempo entre http(S) e BrowserView/UserView Tasks.
Por padrão, os servidores de troca reconhecem se um endereço de e-mail é local. Se esse for o caso, o servidor não envia o e-mail pela internet pública. Este é um padrão da maioria dos servidores de e-mail.
Se você deseja testar o envio e o recebimento através da internet pública, recomendamos usar nosso monitor de e-mail de ida e volta + uma conta de e-mail de 3partes, como o Gmail.
Nosso monitoramento de e-mail de ida e volta requer o uso de protocolos POP3 ou IMAP, seja em sua localização ou na3ª parte (gmail).
Existem três maneiras de testar isso com ida e volta:
O protocolo ActiveSync também realiza uma ida e volta. A sincronização ativa FAZ a capacidade de enviar um e-mail de um dispositivo remoto (nossos locais de monitoramento) e recuperar um e-mail do servidor por esse dispositivo remoto. Mas ele não envia o e-mail de um servidor de sincronização ativo para outro porque a conta de envio e recebimento é a mesma conta no mesmo servidor, por isso encontra a rota mais curta para um endereço local não requer o envio da mensagem para a internet pública até que a mensagem seja recuperada de um dispositivo remoto (nossos locais de monitoramento).
Aqui está a diferença entre O Round Trip e o ActiveSync- você pode ver o movimento de e-mail entre vários servidores usando um provedor de e-mail de terceiros, como o gmail, enquanto o e-mail reside em 1 servidor usando activesync:
A API é bloqueada por um endereço IP para permitir apenas o acesso de usuários autorizados. Ao configurar uma Integração de API da Web (Gerenciar > Integrações > Nova Integração), você deve habilitar o acesso a dados além de sua conta do Dotcom-Monitor por meio da API da Web. Visite Como colocar IPs na lista de permissões para acesso à API da Web para obter detalhes.
Para obter mais informações sobre como usar a API, visite a página de introdução da API.
O Dotcom-Monitor elimina automaticamente os dados do sistema de acordo com o cronograma a seguir.
Para contas ativas:
Esta política de retenção se aplica a todos os tipos de tarefas.
Os dados da conta de teste não são retidos de acordo com este cronograma e podem ser excluídos a qualquer momento após o término do teste.
Os dados da conta fechada podem ser retirados do sistema no prazo de 60 dias após o último login do usuário para a conta.
Depois de configurar tarefas com alertas e elas começarem a ser executados, você pode se encontrar recebendo vários alertas, mas quando você verifica o serviço ou site, tudo parece bem. É importante prestar atenção ao conteúdo dos alertas para descobrir o que está causando o erro. Alguns erros podem conter códigos de erro personalizados do Dotcom-Monitor,enquanto outros podem conter códigos de status http que podem ajudá-lo a decifrar a causa do erro.
Devido à natureza detalhada dos recursos de monitoramento do Dotcom-Monitor, você pode querer ajustar seus alertas, relatórios ou seus scripts gravados para excluir certos elementos ou erros para eliminar falsos positivos. Algumas dessas razões incluem:
Você pode ajustar para esses falsos positivos criando Filtros e aplicando o filtro aos alertas e relatórios do dispositivoofensivo .
Você também pode ativar o False Positive Check em seus dispositivos. Isso desencadeará uma cascata de verificações de um local que descobre uma falha de monitoramento, a fim de confirmar que o dispositivo está errando mais de uma vez
A maneira mais fácil de criar um grande número de itens de objetos (dispositivos / tarefas / filtros / horários / etc.) no sistema Dotcom-Monitor é abrir um bilhete de suporte e pedir ajuda à equipe de suporte.
Esteja preparado para fornecer uma planilha com uma lista de todos os objetos que você deseja criar. Se necessário, a planilha deve ser anexada ao ticket de suporte, para que o suporte possa fazer as alterações necessárias para você.
Depois de criar um painel, você pode visualizá-lo a qualquer momento copiando e colando a url em uma nova janela do navegador. Você não precisa estar logado no sistema para visualizar um painel.
Para localizar a URL do painel,
Agora você pode salvar a URL em um arquivo, enviar a URL por e-mail para outras pessoas ou colá-la em uma janela do navegador e marcar o endereço para acessá-la facilmente no futuro.
Você pode silenciar alertas individuais do dispositivo por até 24 horas do Gerenciador de Dispositivos clicando em ações ao lado do dispositivo, selecionando o Silêncio alertae silenciando para o período desejado.
Para silenciar vários dispositivos de uma só vez, clique na caixa de seleção ao lado de cada dispositivo que você deseja silenciar e, em seguida, clique no botão Silenciar de alerta na parte superior da lista e selecione o período desejado.
Você também pode usar a API para silenciar alertas por mais de 24 horas. Para obter informações sobre como fazer isso, aDE de checkout: Desativar alertas para um dispositivo.
Os sistemas Dotcom-Monitor oferecem um conjunto robusto de ferramentas de monitoramento que devem ser cuidadosamente ajustadas para detectar o nível de desempenho necessário para cada alvo monitorado. Devido ao número e variedade de fatores de alerta, você pode precisar ajustar algumas das configurações em seus monitores, a fim de eliminar falsos positivos.
Para determinar se os alertas que você está recebendo são válidos, confira este artigo sobre a identificação de falsos positivos.
Se você ainda não deseja receber alertas da maneira como eles estão configurados atualmente, executar um relatório on-line do Gerenciador de Dispositivos para o tempo durante o qual você recebeu os alertas lhe dará mais informações sobre o que está desencadeando os alertas.
Se o erro no relatório on-line afirmar "(300) tarefa O tempo limite máximo expirou" isso significa que a tarefa demorou mais tempo para ser concluída do que o tempo limite máximo especificado para a tarefa. Isso pode apontar para um problema legítimo, mas cabe a você determinar em que ponto você precisa receber alertas. Se você sentir que está recebendo muitos alertas, você pode editar a tarefa e aumentar o limite máximo de tempo limite.
Se você está monitorando de vários locais, mas está apenas enfrentando problemas a partir de um único local, há várias coisas que você pode verificar.
Se o acesso ao servidor for limitado via endereço IP, você deve ter certeza de que adicionou os endereços ip de todos os locais de monitoramento à sua lista de acesso ao endereço IP.
Se o servidor precisar de um certificado para acessar o conteúdo, você deve abrir um bilhete de suporte para carregar o certificado em cada local de monitoramento.
Se você está enfrentando problemas de um local na China, você pode estar vendo os resultados do "Grande Firewall da China". Como o governo chinês mantém um controle rigoroso sobre o conteúdo acessível de dentro do país, às vezes o conteúdo é filtrado como inacessível ou largura de banda para determinados sites são estrangulados para que os elementos do site se afastem. Nestes casos, muitas vezes há pouco que você pode fazer, uma vez que o governo chinês está no controle da rede.
Se você estiver enfrentando problemas de um ou alguns locais específicos, você pode abrir um bilhete de suporte e nossa equipe de suporte trabalhará com você para identificar outros possíveis problemas. Às vezes, pode haver problemas com um roteamento de servidor DNS incorretamente, pesquisa DNS reversa ou um problema específico para o local de monitoramento.
Se você estiver executando um script UserView, talvez seja necessário adicionar um atraso ao script para dar ao site mais tempo para carregar todos os elementos corretamente. Você também pode repetir a etapa, como clicar em um href após adicionar um atraso, então, caso o link não tenha sido renderizado na página da primeira vez, ele tentará clicar nele novamente.
Há uma série de fatores que determinam se uma mensagem de alerta será enviada e para quem ela será enviada.
Quando você cria um dispositivo, um filtro padrão é aplicado automaticamente a todos os dispositivos. O filtro padrão requer que mais de um local (a menos que você selecione apenas um local) receba o erro antes que um alerta seja acionado. Isso é feito para eliminar falsos alertas positivos quando um local sofre de um pequeno soluço de rede. Você pode criar um filtro que não exija mais de um local, mas esteja ciente de que você provavelmente receberá muitos falsos alertas positivos devido à natureza descontrolada do tráfego na internet.
Se você tiver aplicado um cronograma a um dispositivo, o dispositivo não será monitorado durante períodos não programados, portanto, nenhum dado será registrado para disparar um alerta. Recomendamos que você não aplique um cronograma diretamente aos seus dispositivos para que o sistema seja monitorado 24 horas por dia, 7 dias por semana, mesmo que você não deseje receber alertas 24 horas por dia. Você pode aplicar horários em diferentes grupos de alerta para que diferentes grupos recebam apenas alertas durante seus turnos de trabalho, por exemplo.
Ao configurar alertas de grupo, você pode especificar se o grupo deve receber uma notificação imediatamente quando o erro é detectado ou se deve haver um atraso entre quando o erro é detectado pela primeira vez e quando um erro é enviado. Por exemplo, talvez você tenha um grupo de suporte de segundo nível que só é notificado quando um erro continua a ocorrer 30 minutos após o suporte ao primeiro nível receber um alerta.
Por padrão, a verificação falsa positiva está ligada. Isso significa que, se um local de monitoramento sofre um erro, ele tenta recriar o erro antes de enviar uma mensagem de erro. Não recomendamos desabilitar isso porque aumentará o risco de receber falsos alertas positivos, no entanto, se sua tarefa demorar muito tempo para concluir uma iteração, você pode querer desligar a verificação falsa positiva para que você receba erros imediatamente em vez de 10 minutos após o primeiro erro ter sido detectado (5 minutos para completar a primeira tarefa , em seguida, quando o erro é detectado, mais 5 minutos para confirmar o erro)
Observe que os grupos alert podem ser configurais e usados para vários dispositivos. Se você notar que alguém não está recebendo um alerta, certifique-se de que suas informações de contato existem em todos os grupos necessários. Tenha cuidado ao editar ou remover pessoas de grupos porque esse grupo pode ser usado para dispositivos adicionais.
Existem muitos erros diferentes que podem ocorrer enquanto um site ainda está parcial ou totalmente acessível. Alguns dos erros mais comuns que podem ocorrer enquanto seu site ainda parece estar disponível incluem:
Se o erro especificar que ocorreu um tempo limite, edite os detalhes da tarefa de monitoramento e procure um valor máximo de tempo limite. Se você está recebendo muitos erros de tempo limite, você pode querer considerar aumentar o valor máximo do tempo limite ou removê-lo completamente. Alternativamente, você pode executar atualizações em seu site para melhorar a velocidade de carga ou hospedar elementos individuais em uma rede de distribuição de conteúdo (CDN). Se você não especificou um valor máximo de tempo limite, então o tempo limite padrão para uma tarefa é de 120 segundos.
Se a tarefa incluir a validação de uma determinada palavra-chave ou imagem for encontrada na página, o resto do conteúdo ainda poderá ser carregado corretamente enquanto o elemento esperado estiver faltando.
Alguma validação pode falhar se a tarefa procurar um elemento antes que o elemento esteja completamente carregado. Se a tarefa for um script UserView, talvez seja necessário adicionar um atraso de tempo antes de validar esse elemento em particular.
Às vezes, devido a vários problemas de rede na internet ou provedores de serviços locais, um dos servidores DNS especificados ou de alto nível pode ser incapaz de qualificar totalmente a resolução DNS para o seu site. Neste caso, a maioria dos navegadores continua consultando o próximo servidor DNS disponível e completando a resolução, mas dependendo de como seu monitoramento é configurado, você ainda pode receber alertas. Para obter mais informações sobre como solucionar erros do DNS, visite nosso artigo de base de conhecimento aqui.
No relatório Online, quando expando uma sessão de monitoramento individual para visualizar detalhes granulares das etapas, por que estamos vendo erros, mas a tarefa geral de monitoramento está conseguindo?
Há uma série de casos em que um elemento individual ou chamada para um servidor que está sendo monitorado resultará em uma resposta sinalizada ou de erro. Essas respostas são tipicamente notadas por um ponto de exclamação vermelho e o texto pode ser ligeiramente acinzentado.
