Как выбрать инструмент мониторинга веб-сайта в соответствии с вашими потребностями

Вы просыпаетесь от предупреждающего сигнала и не знаете, сколько времени, но снаружи темно, и когда вы начинаете приходить в себя, вы видите поток уведомлений.

Что-то сломало ваше приложение, и пользователи в Европе очень обеспокоены. Прошел час без резервной копии, спасите своего менеджера по работе с клиентами, который спрашивает каждые 15 минут, когда вы ожидаете возвращения к нормальной жизни. Вы двое наблюдаете, как остальная часть вашей команды просыпается, получает новости и начинает показывать пальцами.

Вы думаете, что всей этой ситуации можно избежать, поскольку четвертый час простоя достигает пика. Если бы только что-то предупредило нас о надвигающейся гибели.

Добро пожаловать в мир мониторинга веб -сайтов, где время безотказной работы приложений является главной директивой. Возможно, это было не совсем то, как погас ваш пожар в 3 часа ночи, но если вы так долго выживали в DevOps, он у вас был — и мы готовы поспорить, что это было неприятно.

Если ваша цель состоит в том, чтобы свести к минимуму эту уникальную марку боли, тогда мы здесь, чтобы помочь вам сделать работу по вызову немного менее отстойной с помощью простого руководства, в котором изложено, что вам нужно от поставщика веб-мониторинга .

Универсальное руководство по выбору инструмента для мониторинга веб-сайта

Начнем с основ: мониторинг и отчетность. Подобно всевидящим телекранам 1984 года, мониторинг здесь относится к «внешнему» надзору за вашими действиями. Внешние пробные серверы обычно используются для мониторинга состояния вашего приложения.

Подотчетность начинается с надзора или, скорее, наблюдения. Что вы можете узнать на основе того, что говорит вам ваша инфраструктура?

Отчетность дает количественную оценку вашей ответственности, но хорошая отчетность субъективна. Некоторым могут понравиться необработанные данные, которые они могут упаковать в любой формат. Другие хотят, чтобы отчеты доставлялись автоматически, некоторым нужен более наглядный подход. Отчетность — это обратная сторона мониторинга, и правильное использование этих двух элементов гарантирует, что ваше приложение останется доступным, а ваши соглашения об уровне обслуживания будут выполнены.

Чем лучше вы понимаете свою инфраструктуру, тем большую ценность вы получаете от мониторинга. Провайдеры часто анализируют типы чеков, чтобы снизить затраты. Понимание потребностей веб-мониторинга в вашей инфраструктуре является хорошим источником экономии средств.

Веб-мониторинг и отчетность для подотчетности

Мониторинг — это не просто ловля ваших серверных гномов, спящих на работе, он должен сказать вам больше, чем просто о том, работает ли служба или нет. С помощью показателей производительности вы можете получить четкое представление о том, как работает ваша инфраструктура. Особенно с более продвинутыми проверками, такими как мониторинг реальных пользователей (RUM) — но об этом позже.

Проверьте страницу состояния вашего поставщика и просмотрите данные об отключении за предыдущие шесть-двенадцать месяцев. Продавец часто не работает? Их общее время безотказной работы и управление инцидентами должны дать представление об их надежности.

Какие типы проверки веб-сайтов наиболее полезны?

Прежде чем выбрать поставщика, вы хотите оценить свои потребности. Ответьте на это, что могло разбудить вас посреди ночи? Эта инфраструктура должна быть среди первых компонентов, которые вы настраиваете при тестировании поставщиков.

Разработайте план атаки для мониторинга и составьте список необходимых услуг. Поставщики услуг, предлагающие установленные планы, могут помочь или навредить здесь. Хорошие планы учитывают размер предприятий, которые их используют. Никогда не помешает узнать о вариантах обновлений и надстроек для индивидуальной настройки плана.

Возможно, поиск веб-монитора был вызван ошибкой 404 или ошибкой SSL, но оставьте себе пространство для экспериментов и роста. Во время тестирования вы, несомненно, найдете дополнительные способы мониторинга вашей системы и использования ваших чековых ассигнований.

Базовые проверки и их функции веб-мониторинга

Базовые проверки обычно делают только одну вещь, например, отслеживают один URL-адрес или проверяют записи DNS. Эти типы проверки обычно побуждают кого-то искать мониторинг, как правило, после того, как произошел сбой. Очень важно получить это право.

HTTP(S), SSL, DNS и истечение срока действия домена — это некоторые хорошие базовые проверки, о которых следует помнить, потому что конечный пользователь склонен ощущать такие сбои. Эти проверки также составляют основу мониторинга для большинства корпоративных пользователей. Планы, которые включают только эти типы проверок, являются хорошими «стартовыми» планами для стартапов и малого бизнеса.

Проверки HTTP(S), иногда называемые «веб-мониторингом», отслеживают время безотказной работы. SSL, DNS и срок действия домена, как правило, гарантируют, что критически важная инфраструктура не выйдет из строя по предотвратимым причинам. Если ваш провайдер также включает показатели производительности, это явный бонус.

Убедитесь, что ваш провайдер поддерживает доставку предупреждений там, где вам это нужно. Если у вас приближается истечение срока действия SSL, было бы полезно обойти бюрократию и поставить это уведомление непосредственно перед человеком, который может заплатить за продление, имея достаточно времени для продления. Было бы еще лучше, если бы проблема могла автоматически передаваться кому-то еще, если потребуется больше опыта.

Расширенные проверки, которые должна учитывать каждая команда DevOps

Расширенная проверка — это проверка, которая либо использует реальные пользовательские данные, либо основывает свои действия на действиях пользователя. Эти сложные типы проверки обычно требуют некоторых усилий по настройке. Отдача может быть монументальной для организаций, которые их используют.

Расширенные типы проверки контролируют важные цели или воронки навигации, такие как вход в систему или покупка предмета. Поскольку они действуют как реальные пользователи (или иногда получают данные от них), эти проверки дают четкое представление о производительности вашего сайта в различных условиях.

Зачем вкладывать усилия в настройку этих типов проверок?

• Тестирование: видимость производительности новых функций и обновлений при создании большого количества исторических данных.
• Первый ответ: отключение страницы оформления заказа может означать более чем одну неудачную проверку HTTP(S). Что не удалось и когда — хорошие показатели того, с чего начать диагностику.

Давайте встретимся с Джеймсом и посмотрим, насколько полезными могут оказаться несколько типов проверок:

Джеймс запускает новый продукт для своей компании Edgeco. Для этой новой службы потребуется собственный сертификат безопасности, а также новая инфраструктура. Джеймс развернет эту службу с реальным мониторингом пользователей, чтобы узнать больше о раннем пользовательском опыте. Мониторинг SSL гарантирует, что, когда Джеймс перейдет к другим проектам, его сертификат будет защищен, чтобы гарантировать, что продление не будет забыто.

С проверкой HTTP(S), отслеживающей этот URL-адрес, Джеймс и его команда имеют возможности быстрого реагирования при обнаружении простоя. Используя проверку транзакций, Джеймс может тестировать критически важные пользовательские процессы, такие как вход в новую службу и использование ее основных компонентов.

Поскольку Джеймс развернул систему с Real User Monitoring, его служба собирала статистику использования по всем изменениям, которые он и его команда вносили в течение срока службы службы. В течение шести месяцев у Джеймса будет достаточно данных, чтобы определить проблемы с производительностью, локализованные в конкретных регионах, и направить свою команду на соответствующее улучшение. Многоуровневые проверки помогают защитить и упростить управление сложной инфраструктурой.

Программное обеспечение для веб-мониторинга, которое приятно иметь

После того, как вы установили типы проверок, которые вам нужны, пришло время начать сравнивать полезные функции, которые сделают вашу жизнь немного проще. Здесь существует большая дифференциация, поскольку некоторые провайдеры предоставляют страницу состояния или интеграцию как «премиальные» предложения.

Публичная и частная отчетность

Видимость имеет значение. Кто может это увидеть? Поймут ли это руководители? Есть ли доступ у публики? Во время простоя DevOps, вероятно, подвергается давлению внутри компании и через пользователей, поэтому визуальная отчетность имеет смысл.

Поддержка не работает бесплатно. Каждый запрос в службу поддержки, даже с макросом/быстрым ответом, требует времени. Кто-то должен отправить заявку, прекратить работу над другой задачей и ответить на нее. Увеличьте свою пользовательскую базу на сотни тысяч или миллионы пользователей, и служба поддержки может потерять целые дни продуктивности, отправляя один и тот же шаблонный ответ на вопросы о том, работает она или нет. Наглядные отчеты создают платформу для ответов на вопросы и снижают нагрузку на службу поддержки.

Второстепенным преимуществом является обмен сообщениями, потому что неправильная новость может разрушить вашу репутацию. Когда вы находитесь перед катастрофой, сосредоточившись на прозрачности, вы становитесь источником новостей. Это гораздо лучше, чем быть во власти индустрии, движимой спорами о кликах.

Простота использования и ценность

Все, начиная от мониторинга и отчетности, выглядит великолепно. А стоимость установки ? Как и ваша служба поддержки, ваши инженеры тоже не работают бесплатно. Даже тестирование провайдера требует затрат на настройку, поэтому найдите время, чтобы оценить все ваши требования.

Простота использования относится ко всему, от настройки учетной записи до регистрации новых пользователей. Во время пробного периода вы можете сосредоточиться на основах и как можно скорее приступить к работе; спроектируйте долгосрочную перспективу и подумайте, как пользователи будут взаимодействовать с системой.

Если вы меняете поставщика, также полезно иметь функцию импорта/экспорта, с помощью которой вы можете легко передавать сотни чеков.

Программное обеспечение единого входа (SSO) — хороший пример, предлагающий определенную степень безопасности вашей компании и облегчающий освоение пользователями. Вспомогательная документация и общее использование могут помочь вам разобраться в доступности программного обеспечения. Вы можете пригласить другого пользователя, чтобы попытаться настроить некоторые проверки или получить отчеты, чтобы проверить, как работает система со всех точек зрения.

Настройка и наблюдаемость

Давайте рассмотрим средний вариант корпоративного использования, где 100+ мониторов не исключены. Как выглядит отчетность для такой настройки? Массивность, это одно слово. Запутанный, возможно, другой. Будет сложно отследить более сотни объектов, поэтому при построении наблюдаемости с помощью веб-мониторинга также следует учитывать то, что вам нужно видеть, чтобы выполнять свою работу. То, как ваш провайдер справляется с видимостью, многое говорит вам об их основном бизнесе.

Некоторые полезные функции, на которые следует обратить внимание, включают теги, где вы можете раскрасить код или использовать командное или внутреннее соглашение об именах для организации проверок. Вы также можете предпочесть работать в командной строке, и в этом случае важно обратить внимание на API. Просто не забудьте спросить о любых потенциальных ограничениях, о которых вам нужно знать, когда вы рассматриваете свои варианты.

Информационные панели обеспечивают внутреннюю видимость

Один из способов решить эту проблему объема — предоставить централизованное пространство для управления проверками. Если вы относитесь к тому типу людей, которым нравится обзор и мгновенный доступ к ключевым показателям, информационные панели предоставят вам необходимую наглядность. Бонусы здесь включают возможность совместного использования. Можете ли вы или ваша команда разработать информационные панели, на которые можно переключаться на лету? Можете ли вы контролировать доступ или назначать конкретные панели мониторинга для конкретных пользователей?

Фирменные страницы статуса вызывают доверие

Большинство компаний ценят прозрачность, поэтому страницы статуса — еще одно приятное дополнение. Доверие никак не проявляется. Объединение страницы мониторинга и состояния упрощает задачу. Если вы используете поставщика для каждой из этих служб, вам необходимо иметь некоторый промежуточный слой, который помогает улучшить связь между ними. Обычно это означает, что кто-то должен либо тщательно создавать компоненты, либо писать сценарий. Даже в этом случае вы, вероятно, загружаете данные в автономную службу, которая может подвергаться тем же рискам сбоя, что и ваш веб-сайт.

Бесшовное взаимодействие между вашей страницей статуса и вашим веб-сайтом выглядит профессионально. Тем не менее, вам необходимо внедрить управление инцидентами в свою процедуру реагирования, включая регулярные обновления вашей страницы состояния в течение периода простоя или обслуживания.

Существуют также внутренние страницы состояния, предназначенные для хранения информации по мере необходимости. Люди, не входящие в вашу ИТ-команду, могут видеть критические простои. Когда происходит сбой, внутренние страницы состояния становятся центром обновления всей компании.

Оповещения и наблюдаемость

Соглашения об уровне обслуживания, как правило, имеют встроенные пороговые значения, сигнализирующие о том, что пора реагировать на проблему. Эти «бюджеты ошибок» позволяют вашей команде спать по ночам. Предупреждения и то, что они содержат, определяют время ответа от пяти до 60 минут.

Хорошее оповещение поучительно. Предупреждения могут содержать коды состояния, предлагаемые исправления или направлять вас к полезным ресурсам, таким как анализ предупреждений. Лучшие оповещения означают, что возникла реальная проблема, и сообщают вам, в чем она может заключаться. «Он не работает» и «Он сообщает об ошибке 500» указывают на очень разные проблемы.

Оповещения и подробности

Слишком расплывчато и devops, скорее всего, потеряют волосы в поисках проблемы, но редко возникает проблема из-за слишком конкретики. Тщательно тестируйте системы оповещения. Если вы планируете сменить провайдера, запустите упражнение игрового дня с помощью системы оповещения. Какая информация предоставляется вашей команде? Помогло ли оповещение в постановке диагноза?

Если вы планируете несколько отключений, будь то игровые упражнения или расширенные тесты, вы можете многое узнать о том, как работает ваша система мониторинга. Распространяются ли оповещения? Как насчет периодов обслуживания вместо перерывов в работе? Может ли ваша система различать?

Доставка оповещений

Вернемся к нашему варианту использования Edgecom. Джеймс следит за своей службой, когда он получает пинг в своем канале Slack. Сбой HTTP(S) сигнализирует о том, что его блог не работает. Джеймс может пометить человека, ответственного за блог, который быстро расследует инцидент. Оказывается, причиной является необычное количество загрузок страниц.

Команда интересуется, стал ли недавний пост вирусным. Джеймс чувствует надвигающуюся атаку и масштабирует серверы, чтобы повысить их пропускную способность. Конечно же, его действия являются частью цепочки событий, которые помогают отразить DDoS-атаку, направленную на вывод из строя его основного сайта.

Мораль здесь заключается в том, что оповещения, доставленные вашей команде, могут привести к диагностике и неожиданной интуиции. Отсутствие предупреждений означает боль. Ужасная боль.

Веб-мониторинг — это действительно анализ

Не забывайте о ценности истории предупреждений. Опытные пользователи devops, вероятно, имеют сверхъестественное чутье на катастрофу. Как они оттачивают это чувство? Наблюдая за причинами бедствия и тщательно документируя их.

Эскалация и гибкость

Допустим, Джеймс больше не DevOps-Человек-паук, и его сверхъестественные чувства не совсем в порядке. DDoS-атака выводит из строя некоторые сервисы. Чем может помочь провайдер мониторинга?

Эскалация и техническое обслуживание — хорошее начало. Если ваш провайдер разрешает это, периоды обслуживания могут обеспечить гибкость реагирования на сбои и оповещения пользователей. Вне зависимости от того, учитывается ли техническое обслуживание в вашем SLA, полезно, когда вы можете планировать периоды регулярного обслуживания и отправлять обновления своим опытным пользователям.

Вы также тратите меньше времени на перетасовку ответственности и повышение внутренней ответственности, если заранее определите свои пределы. Сколько времени слишком долго для простоя? Эскалация после пяти- или десятиминутной отметки — хорошее место для начала, так как более длительные сбои означают, что что-то действительно не так. Системы оповещения, которые автоматизируют эскалацию, устраняют эти догадки, позволяя вашей команде работать, не беспокоясь о том, когда уведомлять более высокие уровни.

Синтетический и реальный пользовательский веб-мониторинг для захвата пользовательского опыта

Перестаньте полагаться на пользовательские отчеты платных бета-тестеров (ваших клиентов) и оцените пользовательский опыт из первых рук. Реальный мониторинг пользователей обычно требует некоторого кода, такого как пиксель отслеживания, но отдача — это фактические пользовательские данные из реальных сеансов. Если вы когда-нибудь задумывались о том, что видит ваш пользователь, RUM-мониторинг станет полезным дополнением к вашему инструментарию.

Синтетический мониторинг

Синтетический мониторинг обычно бывает двух видов: API и транзакционный. Проверка транзакций — это именно то, на что они похожи. Они тестируют воронки достижения целей и предоставляют возможности быстрого реагирования для критических транзакций. Узнавайте первыми о проблемах с вашей корзиной, регистрационными формами, входами в систему и многим другим.

Проверки API полезны для изучения конечных точек, которые управляют автоматизацией вашего сервиса. Вы можете GET, PUSH, PULL, PATCH или DELETE с большинством провайдеров, предоставляя множество возможностей для мониторинга конечных точек. Бонусные баллы, если вы можете устанавливать и извлекать переменные.

Поддержка является невидимым фактором в веб-мониторинге

Сейчас 2 часа ночи, и ваш веб-мониторинг выдает предупреждения то направо, то налево. Тебе нужна помощь! Вам нужен анализ и объяснения. Оперативная поддержка от вашего провайдера доказывает свою ценность, когда вы сталкиваетесь с ошибкой, которую вы либо не видите, либо не можете воспроизвести.

Когда вам нужна помощь, важно, чтобы рядом была команда, готовая работать с вами. Раннее обращение в службу поддержки является хорошим показателем качества обслуживания. Сколько времени требуется агентам, чтобы ответить на заявку? Каково качество их ответа и какую документацию они могут предоставить? Какие типы поддержки доступны, например, поддержка по телефону или в чате? Когда провайдер скрывает кнопку контакта, это может быть красным флажком.

Документация

Документация должна быть тщательной, содержать примеры и пошаговые инструкции. Если ваш провайдер использует код в своей документации, это хороший признак того, что он знает, о чем говорит, и относится к этому серьезно. Бонусные баллы для провайдеров, которые разрабатывают сторонние наборы инструментов, расширения для браузера и многое другое, чтобы помочь в создании вашей системы мониторинга.

Обращение к провайдеру веб-мониторинга

Мониторинг и отчетность являются наиболее важными компонентами при выборе поставщика услуг, но удобный список функций может упростить вашу работу и улучшить контроль. Помните, что суть предупреждения — первая реакция. Если ваше оповещение потерялось в эфире и никто не может его забрать, действительно ли произошел пожар?

Программное обеспечение для веб-мониторинга является частью важного обязательства, которое вы берете на себя перед своей клиентской базой. Это говорит о том, что вы заботитесь о предоставлении услуги и что ваши пользователи могут доверять вам в том, что вы будете рядом с ними. Серьезное отношение к этому обязательству означает размышление о том, какие из этих требований наиболее актуальны для вашей организации.