Откройте целевое устройство в списке для редактирования. В адресной строке браузера вы увидите что-то вроде:
https://user.dotcom-monitor.com/ClientID/DeviceEdit?pid=dc7f4ff2ca944dekjh1078b96707002& deviceId=63698 & taskId=132834
УстройствоId'63698 является идентификатором устройства.
ЗадачейId'132834 является идентификатор задачи.
Идентификатор учетной записи, предоставленный на стартовой странице Select an Account в списке доступных учетных записей.
После вошли в систему, найдите идентификатор учетной записи в меню учетной записи в списке выпадают.
Кроме того, идентификатор учетной записи отображается в настройках > учетной записи учетнойзаписи.
После вошли в мастер-аккаунт, вы можете найти свои ID-данные Департамента в отделах > настройки учетной > записи.
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 использует инъекционные серверы load от Amazon Web Services (AWS) и Azure Cloud Services. Dotcom-Monitor имеет 17 географических регионов Загрузочных инжекторных серверов могут быть заявлены и нагрузка может быть получена от. В каждом регионе, около 500 загрузочных инжекторов могут быть мгновенно.
Ограничения емкости зависят от типа платформы мониторинга из-за разницы в алгоритмах выполнения теста:
Лимит для определенного типа тестирования нагрузки рассчитывается по следующей формуле:
500 x 16 x Количество одновременных пользователей на инжектор нагрузки - Максимальная пользовательная нагрузка
Найдите полученные ограничения грузоподъемности ниже:
| ТЕСТ нагрузки HTTP (S) (ServerView) | Тест нагрузки на веб-страницу (BrowserView) | Тест загрузки веб-приложений (UserView) |
| 8 000 000 пользователей | 225 000 пользователей | 225 000 пользователей |
"Шанхай" (Китай) агент по мониторингу, находится за Великий брандмауэр Китая, который находится в ведении непосредственно китайского правительства. Китайское правительство имеет правило фильтрации в месте для всего интернет-трафика, и это не является публичным. Эти правила фильтрации часто модифицируются, что, в свою очередь, влияет на результаты мониторинга из Шанхая, Китай агент.
Вы можете редактировать местоположение агента для нескольких устройств одновременно на
экране менеджера
устройства.
для платформы, которую вы хотите обновить.Короче говоря, задачи платформ UserView и BrowserView загружают веб-страницу в реальный браузер и выполняют все компоненты страницы, в то время как http (S) Task использует эмулированную « синтетический» браузер и загружает только элемент страницы, который был запрошен без рендеринга.
Для получения более подробной информации см. Различия между мониторингом через HTTP (S) и через BrowserView/UserView и различия во времени измерения между HTTP (S) и BrowserView / UserView задач.
По умолчанию серверы обмена распознают, является ли адрес электронной почты локальным. Если это так, сервер не отправляет электронную почту через общедоступный Интернет. Это по умолчанию большинства серверов электронной почты.
Если вы хотите проверить отправку и получение через общественный интернет, мы рекомендуем использовать наш монитор электронной почты туда и обратно и 3-й учетной записи электронной почты партии, такие как Gmail.
Наш мониторинг электронной почты в раунде требует использования протоколов POP3 или IMAP либо в вашем местоположении, либо на3-й вечеринке (gmail).
Есть три способа проверить это с поездкой туда и обратно:
Протокол ActiveSync также выполняет поездку туда и обратно. Активная синхронизация делает проверить возможность отправлять электронное письмо с удаленного устройства (наши места мониторинга) и получить электронную почту с сервера с помощью этого удаленного устройства. Но он не отправляет электронное письмо с одного активного сервера синхронизации на другой, потому что отправка и получение учетной записи являются одной учетной записью на том же сервере, поэтому он находит кратчайший путь к локальному адресу, не требует отправки сообщения в общедоступный Интернет до тех пор, пока сообщение не будет получено с удаленного устройства (наши места мониторинга).
Вот разница между Round Trip и ActiveSync-вы можете увидеть электронную почту двигаться через несколько серверов с помощью третьей стороны поставщика электронной почты, таких как Gmail, в то время как электронная почта находится на 1 сервере с использованием activesync:
API заблокирован IP-адресом, чтобы разрешить доступ только авторизованным пользователям. Перед использованием API вы должны связаться с поддержкой и предоставить им IP-адреса мест, где вы будете иметь доступ к API.
Для получения дополнительной информации о том, как использовать API, посетите страницу НАЧАЛА работы API.
Dotcom-Monitor автоматически удаляет данные из системы в соответствии со следующим графиком.
Для активных учетных записей:
Эта политика удержания применяется ко всем типам задач.
Данные пробной учетной записи не сохраняются в соответствии с этим графиком и могут быть удалены в любое время после истечения срока действия пробной версии.
Данные закрытого счета могут быть удалены из системы в течение 60 дней с последнего входа пользователя для учетной записи.
После настройки задач с оповещениями, и они начинают работать, вы можете найти себе получать несколько предупреждений, но когда вы проверяете службу или веб-сайт, все выглядит хорошо. Важно обратить внимание на содержимое оповещений, чтобы выяснить, что является причиной ошибки. Некоторые ошибки могут содержать пользовательские коды ошибок Dotcom-Monitor,в то время как другие могут содержать коды статуса http, которые могут помочь вам расшифровать причину ошибки.
Из-за детального характера возможностей мониторинга Dotcom-Monitor, вы можете настроить оповещения, отчеты или записанные скрипты, чтобы исключить определенные элементы или ошибки для устранения ложных срабатываний. Некоторые из этих причин включают в себя:
Вы можете настроить для этих ложных срабатываний, создавая фильтры и применяя фильтр к предупреждениям и отчетам об оскорблении устройства.
Вы также можете включить ложную положительную проверку на ваших устройствах. Это вызовет каскад проверок из места, которое обнаруживает сбой мониторинга, чтобы подтвердить, что устройство ошибки более одного раза
Самый простой способ создать большое количество элементов объектов (устройства / задачи / фильтры / графики / и т.д..) в системе Dotcom-Monitor является открытие билета поддержки и обратиться за помощью к команде поддержки. Они могут направить вас на ввод всех объектов, которые вы хотите создать в электронную таблицу с столбец для каждого соответствующего поля.
Как только ваша электронная таблица будет завершена, вы можете прикрепить ее к билету поддержки или отправить его по электронной почте, чтобы поддержать, и они заселят изменения для вас.
После создания панели мониторинга его можно просмотреть в любое время, копируя и вставить URL в новое окно браузера. Для просмотра панели мониторинга не нужно входили в систему.
Чтобы найти URL-адрес панели мониторинга, войдите в Dotcom-Monitor и в меню навигации в верхней части веб-сайта Dotcom-Monitor, перейдите на Configure, Dashboards.
Расширьте аккордеонное меню, содержащее ваши панели мониторинга, и нажмите кнопку действия справа от панели мониторинга, к которой вы хотите получить доступ.
Выбор предварительного просмотра откроет панель мониторинга в новом окне, а при нажатии URL-адреса копии будет копировать URL панели мониторинга на буфер обмена.
Теперь вы можете сохранить URL в файл, отправить URL другим, или вставить URL в окно браузера и закладку адрес, чтобы легко получить к нему доступ в будущем.
Вы можете заглушить оповещения отдельных устройств на срок до 24 часов от менеджера устройства, нажав действия рядом с устройством, выбрав Alert Silenceи заглушив на нужный период.
Чтобы заставить замолчать несколько устройств одновременно, нажмите флажок рядом с каждым устройством, которое вы хотите заставить замолчать, а затем нажмите на синюю метку действий в верхней части стола, и выберите Alert Silence на период, который вы хотите.
Вы также можете использовать API, чтобы заглушить оповещения более чем на 24 часа. Для получения информации о том, как это сделать, проверить API: Отключить оповещения для устройства. Прежде чем использовать API, необходимо уведомить поддержку о том, с каких IP-адресов можно получить доступ к API.
Системы Dotcom-Monitor предлагают надежный набор инструментов мониторинга, которые должны быть тщательно скорректированы, чтобы определить уровень производительности, необходимый для каждой отслеживаемой цели. Из-за количества и разнообразия факторов оповещения, возможно, потребуется настроить некоторые настройки на мониторах, чтобы устранить ложные срабатывания.
Чтобы определить, действительны ли получаемые оповещения, ознакомьтесь с этой статьей об выявлении ложных срабатываний.
Если вы все еще не хотите получать оповещения так, как они настроены в настоящее время, запуск онлайн-отчета от менеджера устройств за время, в течение которого вы получили оповещения даст вам более глубокое представление о том, что вызывает оповещения.
Если ошибка в онлайн-отчете указывает "(300) задача Максимальный тайм-аут истек", это означает, что задача заняла больше времени, чем максимальный тайм-аут, указанный для задачи. Это может указывать на законную проблему, но это до вас, чтобы определить, в какой момент вам нужно получать оповещения. Если вы чувствуете, что получаете слишком много оповещений, вы можете отредактировать задачу и увеличить максимальный лимит тайм-аута.
Если вы следите из нескольких мест, но испытываете проблемы только из одного места, есть несколько вещей, которые вы можете проверить.
Если доступ к серверу ограничен с помощью IP-адреса, вы должны убедиться, что вы добавили IP-адреса всех мест мониторинга в список доступа к IP-адресу.
Если вашему серверу требуется сертификат для доступа к содержимому, вы должны открыть билет поддержки для загрузки сертификата в каждое место мониторинга.
Если вы испытываете проблемы из места в Китае, вы можете видеть результаты "Великий брандмауэр Китая". Поскольку китайское правительство поддерживает жесткий контроль над тем, какой контент доступен изнутри страны, иногда контент отфильтровывается как недоступный или пропускная способность определенных сайтов регулироваться, так что элементы с сайта истечет время ожидания. В этих случаях часто мало что можно сделать, так как китайское правительство контролирует сеть.
Если у вас возникли проблемы в одном или нескольких конкретных местах, вы можете открыть билет поддержки, и наша группа поддержки будет работать с вами, чтобы определить другие возможные проблемы. Иногда могут возникнуть проблемы с неправильной маршрутизацией DNS-сервера, обратным поиском DNS или проблемой, специфичной для местоположения мониторинга.
При запуске сценария UserView может потребоваться добавить в сценарий задержку, чтобы дать сайту больше времени для правильной загрузки всех элементов. Вы также можете повторить шаг, например, нажав на хреф после добавления задержки, так что в случае, если ссылка не была оказана на странице в первый раз, он будет пытаться нажать на него снова.
Существует ряд факторов, определяющих, будет ли отправлено сообщение оповещения и кому оно будет отправлено.
При создании устройства фильтр по умолчанию автоматически применяется ко всем устройствам. Фильтр по умолчанию требует, чтобы более одного местоположения (если только вы не выбрали одно местоположение) получает ошибку до срабатывания оповещения. Это делается для устранения ложноположих оповещений, когда одно местоположение страдает от небольшой сетевой икоты. Вы можете создать фильтр, который не требует более одного места, но имейте в виду, что вы, вероятно, получите много ложных положительных оповещений из-за неконтролируемого характера трафика в Интернете.
Если вы применили график к устройству, устройство не будет контролироваться в течение незапланированных периодов, поэтому данные не будут записаны, чтобы вывести оповещение. Мы рекомендуем вам не применять расписание непосредственно к вашим устройствам, чтобы система контролировалась круглосуточно, даже если вы не хотите получать оповещения круглосуточно. Вы можете применить расписания к различным группам оповещения, чтобы различные группы получали оповещения только во время рабочей смены, например.
При настройке групповых оповещений можно указать, должна ли группа получать уведомление немедленно при обнаружении ошибки, или же должна быть задержка между первым обнаружением ошибки и отправкой ошибки. Например, возможно, у вас есть группа поддержки второго уровня, которая уведомляется только тогда, когда ошибка продолжает возникать через 30 минут после того, как поддержка первого уровня получила оповещение.
По умолчанию включена ложная положительная проверка. Это означает, что если местоположение мониторинга испытывает ошибку, он пытается воссоздать ошибку перед отправкой сообщения об ошибке. Мы не рекомендуем отключать это, поскольку это увеличит риск получения ложноположих оповещений, однако, если ваша задача занимает особенно много времени для завершения одной итерации, вы можете отключить ложноположивную проверку, чтобы вы получили ошибки немедленно, а не через 10 минут после обнаружения первой ошибки (5 минут для выполнения первой задачи , затем, когда ошибка обнаружена, еще 5 минут, чтобы подтвердить ошибку)
Обратите внимание, что группы оповещения могут быть настроены и использованы для нескольких устройств. Если вы заметили, что кто-то не получает оповещение, убедитесь, что их контактная информация существует во всех необходимых группах. Будьте осторожны при редактировании или удалении людей из групп, поскольку эта группа может быть использована для дополнительных устройств.
Есть много различных ошибок, которые могут возникнуть в то время как веб-сайт по-прежнему частично или полностью доступны. Некоторые из наиболее распространенных ошибок, которые могут возникнуть в то время как ваш сайт по-прежнему, как представляется, доступны включают в себя:
Если ошибка указывает на то, что произошел тайм-аут, отредактировать детали задачи мониторинга и искать максимальное значение тайм-аута. Если вы получаете много ошибок тайм-аута вы можете рассмотреть вопрос об увеличении максимального значения тайм-аута или удалить его вообще. Кроме того, вы можете выполнять обновления на своем сайте, чтобы повысить скорость загрузки или разместить отдельные элементы в сети распространения контента (CDN). Если вы не указали максимальное значение тайм-аута, то тайм-аут по умолчанию для задачи составляет 120 секунд.
Если задача включает в себя проверку конкретного ключевого слова или изображения, найденного на странице, остальная часть содержимого может по-прежнему загружаться должным образом, пока ожидаемый элемент отсутствует.
Некоторая проверка может выйти из строя, если задача ищет элемент до полной загрузки элемента. Если задача является скриптом UserView, возможно, потребуется добавить задержку во времени перед проверкой этого конкретного элемента.
Иногда из-за различных сетевых проблем в Интернете или местных поставщиков услуг, один из указанных или верхнего уровня DNS-серверов может быть не в состоянии в полной мере квалифицировать разрешение DNS на ваш сайт. В этом случае большинство браузеров продолжают запрашивать следующий доступный DNS-сервер и завернять разрешение, но в зависимости от того, как настроен ваш мониторинг, вы все равно можете получать оповещения. Для получения дополнительной информации о том, как устранения ошибок DNS, посетите нашу статью базы знаний здесь.
В подробном отчете Online, когда я расширяю индивидуальную сессию мониторинга для просмотра детали этапов, почему мы видим ошибки, но общая задача мониторинга успешно?
Существует ряд случаев, когда отдельный элемент или вызов на контролируемый сервер приводит к помечению или ответу на ошибку. Такие ответы обычно отмечаются красным восклицательным знаком, и текст может быть слегка серым.
