Синтетический мониторинг
 | Эта статья написана как личное размышление, личное эссе или аргументативное эссе , в котором излагаются личные чувства редактора Википедии или излагается оригинальный аргумент по теме. ( Июль 2017 г. ) |
| Эта статья может быть слишком технической для понимания большинства читателей . ( Октябрь 2021 ) |
В разработке программного обеспечения , веб-дизайне и проектировании электронных продуктов синтетический мониторинг (также известный как активный мониторинг или проактивный мониторинг ) — это метод мониторинга, который выполняется с использованием моделирования или скриптовых записей транзакций. Поведенческие сценарии (или пути) создаются для моделирования действия или пути, которые клиент или конечный пользователь предпримет на сайте, в приложении или другом программном обеспечении (или даже оборудовании). Затем эти пути непрерывно контролируются с указанными интервалами для оценки производительности, такой как функциональность, доступность и время отклика .
Синтетический мониторинг позволяет веб-мастеру или специалисту по ИТ/операциям выявлять проблемы и определять, работает ли веб-сайт или приложение медленно или испытывает ли он простой, до того, как эта проблема повлияет на реальных конечных пользователей или клиентов. Этот тип мониторинга не требует фактического трафика , отсюда и название «синтетический», поскольку он позволяет компаниям тестировать приложения 24x7 или тестировать новые приложения перед запуском для клиентов. [1] [2]
Поскольку синтетический мониторинг представляет собой имитацию типичного поведения пользователя или навигации по веб-сайту, его часто лучше всего использовать для мониторинга часто посещаемых путей и критических бизнес-процессов. Синтетические тесты должны быть написаны заранее, поэтому невозможно измерить производительность для каждой перестановки навигационного пути, который может выбрать конечный пользователь. Затем эти скрипты внедряются в код приложения или веб-сайта, который затем тестируется под искусственными нагрузками. Это, конечно, может быть контрастом с фактической нагрузкой/трафиком, когда дизайн запускается в эксплуатацию. В этом случае выполняется реальный мониторинг пользователей , где показатели производительности тестируются относительно реальных нагрузок. Это больше подходит для пассивного мониторинга.
Синтетическое тестирование полезно для измерения времени безотказной работы, доступности и времени отклика критически важных страниц и транзакций (как сайт работает во всех географических точках), но не отслеживает и не фиксирует фактические взаимодействия с конечным пользователем, см. Мониторинг веб-сайта . [3]
Синтетический мониторинг будет сообщать о множестве метрик, и вебмастер или специалист по ИТ/операциям должны определить, какие из них наиболее важны. Общие метрики синтетического мониторинга веб-сайтов включают время до первого байта, индекс скорости, время до интерактивности и завершение страницы. [4]
Спрос на синтетический мониторинг вырос экспоненциально в соответствии с базовым ростом веб-сайтов/приложений. Сотрудникам ИТ/операций нужны механизмы для выявления проблем со здоровьем и производительностью до того, как их клиенты обнаружат их и сообщат о них, чтобы избежать проблем с удовлетворенностью клиентов. Для этого они могут писать пользовательские сценарии моделирования или использовать растущее число коммерческих решений для синтетического мониторинга. Вот некоторые примеры:
- Синтетика New Relic
- Синтетический мониторинг ManageEngine Applications Manager с помощью Real Browser Monitor (RBM)
- Распределенный облачный синтетический мониторинг F5
- Автоматизированный синтетический мониторинг Datadog
- Синтетический мониторинг Powerhouse Nudge от Atakama Technologies
- Визуальный синтетический мониторинг приложений и сервисов Alyvix
Внедряя Synthetic Monitoring, сотрудники ИТ/Операций могут выявлять проблемы приложений до того, как они станут критическими, и предпринимать корректирующие действия. Выявление таких проблем может быть затруднено из-за:
- Число приложений, отслеживаемых организацией среднего размера, может достигать нескольких сотен.
- Проблемы могут различаться в зависимости от географии; например, проблемы с производительностью могут быть очевидны для пользователей в Азии, но могут не проявляться для пользователей в Европе.
- Сотрудникам ИТ/эксплуатации необходимо не только определить факт существования проблемы, но и получить диагностическую информацию о причинах, вызвавших выявленную проблему.
- Сотрудники ИТ/операционного отдела часто не имеют исторической перспективы относительно производительности приложений, которая может быть полезна при диагностике развивающихся проблем.
Смотрите также
Ссылки
- ^ «Приоритет модели APM компании Gartner». APM Digest. 15 марта 2012 г. Архивировано из оригинала 22 марта 2012 г. Получено 28 апреля 2012 г.
- ^ "Вы контролируете свои SaaS-приложения? Если нет, то вам следует это сделать". APMdigest - Управление производительностью приложений . 2017-02-14. Архивировано из оригинала 2017-04-14 . Получено 2017-04-13 .
- ^ "Анатомия APM - 4 основополагающих элемента успешной стратегии". APM Digest. 4 апреля 2012 г. Архивировано из оригинала 8 июня 2012 г. Получено 18 мая 2012 г.
- ^ "Объяснение показателей скорости сайта - TTFB, индекс скорости, интерактивность, загрузка, завершение и многое другое". Блог MachMetrics Speed . 2019-02-22. Архивировано из оригинала 2020-03-18 . Получено 2020-01-17 .
