Внимание: у нас появился справочный центр Wialon
С июня 2021 года docs.wialon.com прекращает свое существование. Ответы на вопросы ищите уже в справочном центре Wialon.
С июня при входе на страницы docs.wialon.com система перенаправит вас в справочный центр Wialon. Однако для удобства работы рекомендуем обновить ссылки в ваших закладках или заметках.
Задания
Задание — это определенный набор действий, выполняемых по заданному графику. Заданием может стать выполнение какой-либо команды, отправка важной информации пользователю, манипуляции с правами доступа и др.
Чтобы создавать, редактировать и удалять задания, щелкните по заголовку Задания в верхней панели либо выберите соответствующий пункт в окне настройки меню. Здесь содержится список всех доступных заданий, информация об их состоянии, а также кнопка для создания новых заданий.
Задания в списке располагаются в алфавитном порядке. При поиске и управлении заданиями удобно использовать динамический фильтр. Дополнительные параметры поиска задаются в выпадающем списке, где можно отфильтровать задания по их принадлежности к тому или иному ресурсу (если у текущего пользователя есть доступ к нескольким).
При наведении курсора на название задания во всплывающей подсказке отображается полная информация по нему: тип задания, параметры действия, расписание, время последней попытки выполнения, принадлежность к ресурсу (если у текущего пользователя есть доступ к нескольким), а также некоторые другие (в зависимости от конфигурации задания). В следующих столбцах таблицы указано состояние задания, количество выполненных заданий и максимальное количество выполнений.
Системой предусмотрена возможность тестового выполнения задания. Тестовое выполнение задание — это однократное выполнение созданного задания без привязки ко времени его активации и количеству выполнений. Тестовое выполнение производится в течение 1 минуты по клику соответствующей иконки в рабочем списке. Результат тестового выполнения задания отображается в журнале. Кроме того, информацию по тестовому выполнению задания можно просмотреть в соответствующем отчете по пользователю. Обратите внимание на то, что во время тестового выполнения задания иконка становится неактивной до его окончания.
В панели используются следующие кнопки и обозначения:
Мониторинг в ИТ, как организовать работу
В данной статье хочу поделиться своим опытом организации работы системы мониторинга ИТ. Здесь будет рассмотрен один из возможных вариантов решения именно организационных задач, технические аспекты современных систем мониторинга обсуждаться не будут.Хочу сразу уточнить, что объектами мониторинга в моем случае являются исключительно компоненты ИТ, это: серверы, операционные системы, базы данных, транзакции и т.д. 
Каждый раз в своей профессиональной деятельности, решая задачу построения комплексной системы мониторинга ИТ, я стараюсь придерживаться этого подхода, что позволяет заказчику получать качественно функционирующею систему мониторинга. Подход универсален, убежден, что он может найти свое применение и не на ИТ-шном поприще.
Как бывает
Для чего же нужен мониторинг
Определение правил игры (регламент)
Заявка
Структура заявки
Ответственный – лицо, выступающее со стороны Заказчика, которое курирует создание Заявки. Ответственный обязательный атрибут Заявки, он может меняться, но его не может не быть. Круг лиц, имеющих возможность инициировать процесс создания Заявки, предлагается определить в Регламенте.
Конфигурационные единицы (КЕ) – это список объектов, для которых необходимо реализовать условия данной заявки. Информации о КЕ должно быть в полной мере достаточно для ее однозначной идентификации. На этапе проектирования системы мониторинга предлагается разработать план КЕ, их возможные типы и необходимые атрибуты.
В зависимости от архитектуры системы мониторинга список КЕ в заявке может формироваться вручную или же на основе данных обнаружения объектов инфраструктуры (есть специализированные системы, которые способны инвентаризировать всю ИТ-инфраструктуру). Так же список КЕ в заявке допускается формировать автоматизировано на основе условия (Например: все сервера принадлежащие определенной подсети, это может быть ссылка на запрос в базу данных, где хранится информация об объектах инфраструктуры).
Жизненный цикл заявки
Разработка
Тут все просто! Создание конфигураций в системе мониторинга в соответствии с условиями Заявки и перевод на следующий этап – тестовая эксплуатация.
Не исключаем возможности возврата Заявки на этап оформления для уточнения или переопределения условий мониторинга.
Тестовая эксплуатация
Здесь решаем тонкий политический вопрос: «Кто занимается подготовкой тестовой среды» и проводим все необходимые мероприятия, связанные с тестированием Заявки.
По результатам тестирования возможен возврат Заявки на этапы оформления или разработки в зависимости от выявленных проблем.
При успешном окончании тестовой эксплуатации – следующий этап, промышленная эксплуатация.
И на последок, из промышленной эксплуатации Заявку возможно вывести из эксплуатации или перевести в режим обслуживания. Режим обслуживания – тот случай, когда временно необходимо отключить мониторинг для проведения технических мероприятий.
Схематично жизненные этапы Заявки представлю на следующем рисунке: 
Итого
Подводя итог, хочу сказать, что успешную работу системы мониторинга опираю на три столпа: Регламент, Заявка и технические возможности самой системы.
Хорошей практикой будет — создание некоторого количества Заявок, вмещающих в себя типовые условия мониторинга. Для таких заявок достаточно просто определить объекты мониторинга, определить адресатов уведомлений и вперед – на этап промышленной эксплуатации.
Вот и все что мне хотелось рассказать в этой статье, с удовольствием приглашаю к обсуждению, готов ответить на вопросы.
Организация системы мониторинга
Мониторинг — это главное, что есть у админа. Админы нужны для мониторинга, а мониторинг нужен для админов.
За последние несколько лет поменялась сама парадигма мониторинга. Новая эра уже наступила, и если сейчас вы мониторите инфраструктуру как набор серверов — вы не мониторите почти ничего. Потому что теперь «инфраструктура» — это многоуровневая архитектура, и для мониторинга каждого уровня есть свои инструменты.
Кроме проблем типа «упал сервер», «надо заменить винт в рейде», теперь надо понимать проблемы уровня приложения и уровня бизнеса: «взаимодействие с микросервисом таким-то замедлилось», «в очереди слишком мало сообщений для текущего времени», «время выполнения запросов к бд в приложении растет, запросы — такие-то».
У нас на поддержке около пяти тысяч серверов, в самых разных конфигурациях: от систем из трех серверов с кастомными докеровскими сетками, до больших проектов с сотнями серверов в Kubernetes. И за всем этим надо как-то следить, вовремя понимать, что что-то сломалось и быстро чинить. Для этого надо понять что такое мониторинг, как он строится в современных реалиях, как его проектировать и что он должен делать. Об этом и хотелось бы рассказать.
Как было раньше
Лет десять назад мониторинг был гораздо проще, чем сейчас. Впрочем, и приложения были попроще.
Мониторились, в основном, системные показатели: CPU, память, диски, сеть. Этого вполне хватало, потому что там крутилось одно приложение на php, и ничего больше не использовалось. Проблема в том, что по таким показателям обычно мало что можно сказать. Либо работает, либо нет. Что именно происходит с самим приложением, выше уровня системных показателей понять сложно.
Если проблема была на уровне приложения (не просто “сайт не работает”, а “сайт работает, но что-то не так”), то клиент сам писал или звонил, сообщал, что есть такая-то проблема, мы шли и разбирались, потому что сами мы такие проблемы заметить не могли.
Как сейчас
Сейчас совсем другие системы: с масштабированием, с автоскейлингом, микросервисы, докеры. Системы стали динамичными. Часто никто толком не знает, как именно все работает, на скольких серверах, как именно оно развернуто. Оно живет своей жизнью. Иногда даже неизвестно, что и где запущено (если это Kubernetes, например).
Усложнение самих систем, конечно, повлекло за собой большее количество возможных проблем. Появились метрики приложений, количество запущенных тредов у Java application, частота garbage collector pauses, количество событий в очереди. Очень важно, чтобы мониторинг также следил за масштабированием систем. Допустим, у вас Kubernetes HPA. Надо понимать, сколько запущено подов, и с каждого запущенного пода должны идти метрики в систему мониторинга приложения, в apm.
Все это нужно мониторить, потому что все это отражается на работе системы.
И сами проблемы стали менее очевидными.
Условно, проблемы можно поделить на две большие группы:
Проблемы первого рода – не работает основная, “пользовательская функциональность”.
Проблемы второго рода – что-то работает не так, как должно, и может куда-то не туда привести.
То есть теперь надо мониторить не только дискретное “работает/не работает”, а гораздо больше градаций. Что, в свою очередь, позволяет ловить проблему до того, как все рухнет.
Кроме того, теперь надо следить и за бизнес-показателями. Бизнес захотел иметь графики о деньгах, о том как часто идут заказы, сколько времени прошло с последнего заказа и так далее — это теперь тоже задача мониторинга.
Правильный мониторинг
Проектирование и вообще
Представление о том, что именно надо будет мониторить, должно быть заложено в момент разработки приложения и архитектуры, и речь даже не столько про серверную архитектуру, сколько про архитектуру приложения в целом.
Разработчики/архитекторы должны понимать какие части системы критичны для функционирования проекта и бизнеса, и заранее думать о том, что их работоспобность надо проверять.
Мониторинг должен быть удобным для админа, и давать представление о том, что происходит. Цель мониторинга – вовремя получить оповещение, по графикам быстро понять, что именно происходит и что именно нужно чинить.
Метрики и оповещения (алерты)
Алерты должны быть максимально понятными: админ, получив алерт, даже если он не знаком с системой, должен понять, о чем этот алерт, в какую документацию смотреть, или хотя бы кому позвонить. Должны быть четкие инструкции, что именно нужно делать, и как именно решать проблему.
Когда возникает проблема, очень хочется понять, из-за чего она возникла. Получая алерт о том, что у вас не работает приложение, вам очень хотелось бы знать, какие еще смежные системы ведут себя не так, какие еще есть отклонения от нормы. Должны быть понятные графики, собранные в дашборды, из которых сразу будет видно, где отклонение.
Для этого надо точно понимать, что нормально, а что не нормально. То есть должна быть достаточная историческая справка о состоянии системы. Задача заключается в том, чтобы покрыть алертами все возможные отклонения от нормы.
Когда админ получает алерт, он либо должен знать что с ним делать, либо кого спросить. Должна быть инструкция как именно нужно реагировать, и ее надо регулярно обновлять. Если у вас все работает через систему оркестрирования, то, наверное, у вас все хорошо, если все изменения происходят только через нее, в том числе и мониторинг. Система оркестрирования позволяет адекватно следить за актуальностью мониторинга.
Мониторинг должен расширяться после каждой аварии — если внезапно возникла какая-то проблема, которая проскочила мимо мониторинга, то, очевидно, надо замониторить эту ситуацию, чтобы в следующий раз проблема не была внезапной.
Бизнес-показатели
Полезно мониторить время с последней продажи, количество продаж за период. Если выложили релиз, то что изменилось: есть ли просадки по бизнес-показателям? На это отвечает, конечно, A/B тестирование, но графики тоже хотелось бы иметь. И надо мониторить действия конечного пользователя: писать скрипты на phantomjs, которые повторяют покупку, проходят по всем этапам основного бизнес-процесса.
Также вам, наверное, интересно знать, работает ли сервис логистики, или не свалился ли в очередной раз IpGeoBase. (Комментарий редактора: IpGeoBase — сервис, который использует большое число интернет-магазинов на 1С-Битрикс для определения местоположения пользователя. Чаще всего это делается непосредственно в коде загрузки страницы, и когда падает IpGeoBase — у нас перестают отвечать десятки сайтов. Кто-нибудь пожалуйста, скажите программистам, что это надо обрабатывать и делать таймаут, и кто-нибудь — пожалуйста попросите IpGeoBase не падать).
Нужно понимать, зависит ли просадка по бизнес-показателям от вашей системы, или от внешней.
Мониторинг мониторинга
Сам мониторинг тоже должен хоть как-то мониториться. Должен быть какой-то внешний кастомный скрипт, который будет проверять, что мониторинг работает нормально. Никому не хочется проснуться от звонка, потому что ваша система мониторинга упала вместе со всем дата-центром, и вам об этом никто не сказал.
Основные инструменты
В современных системах, которые масштабируются, у вас наверняка используется Prometheus, потому что аналогов в принципе нет. Для того, чтобы просматривать удобные графики от Prometheus нужна Grafana, потому что в Prometheus графики так себе. Нужен также какой-то APM. Либо это самописная система на Open Trace, jaeger и или что-то подобное. Но это редко кто делает. В основном используется либо New Relic, либо специфичные системы для стеков, типа Dripstat. Если у вас не одна система мониторинга, не один Zabbix, вам еще нужно понимать, как собирать эти метрики, и как раздавать алерты; кого оповещать, кого поднимать, в каком порядке, к кому какой алерт относится, и что с ним вообще делать.
Zabbix — не самая удобная система. Есть проблемы с кастомными метриками, особенно, если система масштабируется, и вам нужно определить роли. И хотя можно строить очень кастомные графики, алерты и дашборды, все это не очень неудобно и нединамично. Это статичная система мониторинга.
Prometheus — отличное решение для сборки огромного количества метрик. У него примерно те же возможности, что у Zabbix по кастомным алертам. Можно выводить графики и строить алерты по любым диким сочетаниям нескольких параметров. И это все очень здорово, но очень неудобно смотреть, поэтому к нему добавляется Grafana. Grafana очень красивая. Но сама по себе не очень помогает для мониторинга систем. Зато по ней удобно все читать. Лучше графиков, наверное, и нет.
ELK и Graylog — для сбора логов по событиям в приложении. Может быть полезно для разработчиков, но для подробной аналитики обычно не достаточно.
New Relic — APM, тоже полезный для разработчиков. Есть возможность понять, когда у вас в приложении прямо сейчас что-то идет не так. Понятно, какие из внешних сервисов не очень хорошо работают, или какая из баз медленно отвечает, либо какое системное взаимодействие просаживается.
Свой APM — если вы написали свою систему на Open Tracing, zipkin или jaeger, то, наверное, вы знаете, как именно это должно работать, и что именно, и в какой части кода идет не так. New Relic тоже позволяет это понять, но это не всегда удобно.
Заключение
О том какие показатели надо мониторить лучше думать в время проектирования системы, заранее подумать о том какие части системы критичны для ее работы и о том, как проверять их работу.
Алертов не должно быть слишком много, алерты должны быть актуальными. Должно быть сразу понятно, что сломалось и как это чинить.
Чтобы правильно замониторить бизнес-показатели, надо понять как устроены бизнес процессы, что нужно вашим аналитикам, хватает ли инструментов чтобы замерить нужные показатели, и как быстро можно узнать, если что-то пойдет не так.
В следующем посте мы расскажем как правильно спланировать мониторинг современной инфраструктуры, на всех уровнях: на уровнях системы, приложений и бизнеса.
Едим слона по частям. Стратегия мониторинга работоспособности приложений на примерах
Наша компания занимается разработкой программного обеспечения и последующей технической поддержкой. В рамках технической поддержки требуется не просто исправлять ошибки, а следить за работоспособностью наших приложений.
Например, если «упал» один из сервисов, то нужно автоматически зафиксировать данную проблему и приступить к её решению, а не ждать обращений в техническую поддержку недовольных пользователей.
У нас небольшая компания, нет ресурсов изучать и содержать какие-то сложные решения для мониторинга приложений, нужно было найти простое и эффективное решение.
Стратегия мониторинга
Выполнить проверку работоспособности приложения не просто, эта задача нетривиальная, можно даже сказать творческая. Особенно сложно выполнить проверку сложной многозвенной системы.
Как можно съесть слона? Только по частям! Используем данный подход для мониторинга приложений.
Суть нашей стратегии мониторинга:
Разбейте приложение на компоненты.
Для каждого компонента придумайте контрольные проверки.
Компонент считается исправным, если все его контрольные проверки выполняются без ошибок. Приложение считается исправным, если исправны все его компоненты.
Таким образом любую систему можно представить в виде дерева компонентов. Сложные компоненты разбиваются на более простые. Простые компоненты имеют проверки.
Контрольные проверки не должны выполнять функциональное тестирование, это не юнит-тесты. Контрольные проверки должны проверять как чувствует себя компонент в текущий момент времени, есть ли все необходимые для его функционирования ресурсы, есть ли какие проблемы.
Чудес не бывает, большинство проверок нужно будет разработать самостоятельно. Но не стоит пугаться, потому что в большинстве случаев одна проверка занимает 5-10 строк кода, но зато вы сможете реализовать любую логику и вам будет четко понятно, как отрабатывает проверка.
Система мониторинга
Допустим мы разбили приложение на компоненты, придумали и реализовали для каждого компонента проверки, но что делать с результатами этих проверок? Как мы узнаем о том, что какая-то проверка выполнилась с ошибкой?
Нам потребуется система мониторинга. Она будет выполнять следующие задачи:
Краткое описание системы АСМО
Лучше всего объяснять на примере. Давайте посмотрим, как организован мониторинг работоспособности системы АСМО.
АСМО – это автоматизированная система метеорологического обеспечения. Система помогает специалистам дорожных служб понять, где и когда необходимо обрабатывать дорогу противогололедными материалами. Система собирает данные с пунктов дорожного контроля. Пункт дорожного контроля – это место на дороге, где установлено оборудование: метеостанция, видеокамера и другое. Для прогнозирования опасных ситуаций система получает прогнозы погоды из внешних источников.
Итак, состав системы достаточно типовой: веб-сайт, агент, оборудование. Приступим к мониторингу.
Разбиваем систему на компоненты
В системе АСМО можно выделить следующие компоненты:
1. Личный кабинет
Это веб-приложение. Как минимум нужно проверять, что приложение доступно в Интернете.
2. База данных
В базе данных хранятся важные для отчетности данные, необходимо проверять, что резервные копи базы данных успешно создаются.
3. Сервер
Под сервером имеется ввиду железо, на котором работают приложения. Необходимо проверять состояние HDD, RAM, CPU.
4. Агент
Это windows-служба, которая выполняет много разных задач по расписанию. Как минимум необходимо проверять, что служба работает.
5. Задача агента
Просто знать, что агент работает — недостаточно. Агент может работать, но не выполнять возложенные на него задачи. Разобьем компонент агента на задачи и будем проверять успешно ли работает каждая задача агента.
6. Пункты дорожного контроля (контейнер всех ПДК)
Пунктов дорожного контроля много, поэтому объединим все ПДК в одном компоненте. Это позволит более удобно читать данные мониторинга. При просмотре состояния компонента «система АСМО» сразу будет понятно где проблемы: в приложениях, железе или в ПДК.
7. Пункт дорожного контроля (один ПДК)
Данный компонент будем считать исправным, если исправны все устройства на данном ПДК.
8. Устройство
Это видеокамера или метеостанция, которые установлены на ПДК. Необходимо проверять, что устройство исправно работает.
В системе мониторинга дерево компонентов будет выглядеть так:
Мониторинг веб-приложения
Итак, мы разбили систему на компоненты, теперь нужно придумать для каждого компонента проверки.
Для мониторинга веб-приложения мы используем следующие проверки:
1. Проверка открытия главной страницы
Эту проверку выполняет система мониторинга. Для её выполнения указываем адрес страницы, ожидаемый фрагмент ответа и максимальное время выполнения запроса.
2. Проверка срока оплаты домена
Очень важная проверка. Когда домен остается без оплаты, пользователи не могут открыть сайт. Решение проблемы может занять несколько дней, т.к. изменения ДНС применяются не сразу.
3. Проверка SSL сертификата
Сейчас почти все сайты используют для доступа протокол https. Для корректной работы протокола нужен валидный SSL сертификат.
Ниже представлен компонент «Личный кабинет» в системе мониторинга:
Все проверки выше подойдут для большинства приложений и не требуют написания кода. Это очень здорово, потому что можно начать мониторинг любого веб-приложения за 5 минут. Ниже приведены дополнительные проверки, которые можно выполнить для веб-приложения, но их реализация более сложная и специфична для разных приложений, поэтому мы не будем разбирать их в этой статье.
Что еще можно проверить?
Для более полного мониторинга веб-приложения можно выполнить следующие проверки:
Мониторинг windows-службы (агента)
В системе АСМО агент выполняет роль планировщика задач, который в фоновом режиме выполняет задачи по расписанию.
Если все задачи агента выполняются успешно, значит агент работает исправно. Получается, чтобы выполнить мониторинг агента, нужно выполнить мониторинг его задач. Поэтому разбиваем компонент «Агент» на задачи. Создадим для каждой задачи отдельный компонент в системе мониторинга, где компонент «Агент» будет «родителем».
Разбиваем компонент «Агент» на дочерние компоненты (задачи):
Итак, мы разбили сложный компонент на несколько простых. Теперь нужно для каждого простого компонента придумать проверки. Обратите внимание, что родительский компонент «Агент» не будет иметь ни одной проверки, потому что его состояние система мониторинга вычислит самостоятельно по статусу его дочерних компонентов. Другими словами, если все задачи выполняются успешно, значит и агент работает успешно.
В системе АСМО более ста задач, неужели для каждой задачи нужно придумывать уникальные проверки? Конечно, контроль будет лучше, если для каждой задачи агента мы придумаем и реализуем свои специальные проверки, но в большинстве случаев достаточно использовать универсальные проверки.
В системе АСМО используются только универсальные проверки для задач и этого достаточно, чтобы следить за работоспособностью системы.
Проверка выполнения
Самая простая и эффективная проверка – это проверка выполнения. Проверка проверяет, что задача выполняется, причем без ошибок. Данная проверка есть у всех задач.
После каждого выполнения задачи нужно отправить в систему мониторинга результат проверки SUCCESS, если выполнение задачи прошло успешно, или ERROR, если выполнение завершилось с ошибкой.
Данная проверка позволяет обнаружить следующие проблемы:
Проблема 1 – Задача выполняется, но завершается ошибкой
Ниже изображен случай, когда задача выполняется, но с 14:00 до 16:00 завершается ошибкой.
По рисунку видно, что когда задача завершается ошибкой, то сразу отправляется сигнал в систему мониторинга и статус соответствующей проверки в системе мониторинга становится alarm.
Обратите внимание, что в системе мониторинга от статуса проверки зависит и статус компонента. Статус alarm проверки переведет в alarm все вышестоящие компоненты, см. рисунок ниже.
Проблема 2 — Задача перестала выполняться (зависла)
Как система мониторинга поймет, что задача зависла?
Результат проверки имеет время актуальности, например, 1 час. Если проходит час, а нового результат проверки нет, то система мониторинга установит проверке статус alarm.
На рисунке выше в 14:00 выключили свет. В 15:00 система мониторинга обнаружит, что результат проверки (от 14:00) протух, т.к. закончилось время актуальности (один час), а нового результата нет, и переведет проверку в статус alarm.
В 16:00 свет опять включили, программа выполнит задачу и отправит результат выполнения в систему мониторинга, статус проверки опять станет success.
Какое время актуальности проверки использовать?
Время актуальности должно быть больше периода выполнения задачи. Рекомендую устанавливать время актуальности в 2-3 раза больше, чем период выполнения задачи. Это нужно, чтобы не получать ложные уведомления, когда, например, задача выполнялась дольше, чем обычно, или кто-то перезагружал программу.
В системе АСМО есть задача «Загрузка прогноза», которая раз в час пытается загрузить новый прогноз из внешнего источника. Точное время, когда во внешней системе появляется новый прогноз не известно, но известно, что это происходит 2 раза в день. Получается, что если нового прогноза нет несколько часов, то это нормально, но если нового прогноза нет уже более суток, то значит где-то что-то сломалось. Например, во внешней системе прогнозов может измениться формат данных, из-за чего АСМО не увидит нового релиза прогноза.
Задача отправляет в систему мониторинга результат проверки SUCCESS, когда удаётся получить прогресс (загрузить новый прогноз погоды). Если прогресса нет или произошла ошибка, то ничего в систему мониторинга не отправляется.
Проверка должна иметь интервал актуальности такой, чтобы за это время гарантированно получить новый прогресс.
Обратите внимание, что о проблеме мы узнаем с задержкой, потому что система мониторинга ждет, когда закончится время актуальности последнего результата проверки. Поэтому время актуальности проверки не нужно делать слишком большим.
Мониторинг базы данных
Для контроля базы данных в системе АСМО мы выполняем следующие проверки:
АСМО раз в неделю создаёт резервную копию и отправляет её в хранилище. Когда данная процедура успешно завершается в систему мониторинга отправляется результат проверки success. Результат проверки имеет время актуальности 9 дней. Т.е. для контроля за созданием резервных копий используется механизм «проверка прогресса», который мы разбирали выше.
Проверка свободного места на диске
Если на диске не будет достаточно свободного места, то база данных не сможет нормально работать, поэтому важно контролировать размер свободного места.
Для проверки числовых параметров удобно использовать метрики.
Метрика – это числовая переменная, значение которой передаётся в систему мониторинга. Система мониторинга проверяет пороговые значения и вычисляет статус метрики.
Ниже представлен рисунок как выглядит компонент «База данных» в системе мониторинга:
Мониторинг сервера
Для мониторинга сервера мы используем следующие проверки и метрики:
1. Свободное место на диске
Если место на диске закончится, то приложение не сможет работать. У нас используется 2 пороговых значения: первое уровня WARNING, второе уровня ALARM.
2. Среднее значение RAM в процентах за час
Мы используем среднее значение за час, т.к. нас не интересуют редкие скачки.
3. Среднее значение CPU в процентах за час
Мы используем среднее значение за час, т.к. нас не интересуют редкие скачки.
4. Проверка ping
Проверяет, что сервер в сети. Данную проверку умеет выполнять система мониторинга, не нужно писать код.
Ниже представлен рисунок как выглядит компонент «Сервер» в системе мониторинга:
Мониторинг оборудования
Расскажу, как происходит получение данных. Для каждого пункта дорожного контроля (ПДК) в планировщике задач есть задача, например, «Опрос ПДК М2 км 200». Задача раз в 30 минут получает данные со всех устройств ПДК.
Проблема канала связи
Большая часть оборудования стоит за городом, для передачи данных используется GSM сеть, которая работает не стабильно (сеть то есть, то её нет).
Из-за частых сбоев сети первое время проверка опроса ПДК в мониторинге выглядела так:
Стало понятно, что это не рабочий вариант, потому что получалось много ложный уведомлений о проблемах. Тогда было принято решение для каждого устройства использовать «проверку прогресса», т.е. в систему мониторинга отправляется только сигнал success, в случае, когда устройство опрашивается без ошибки. Время актуальности поставили 5 часов.
Теперь мониторинг присылает уведомление о проблемах, только когда устройство не удаётся опросить более 5 часов. С высокой долей вероятности это не ложные тревоги, а реальные проблемы.
Ниже представлен рисунок как выглядит оборудование в системе мониторинга:
Важно!
Когда GSM сеть престает работать, то не опрашиваются все устройства ПДК. Чтобы уменьшить количество писем от системы мониторинга, наши инженеры подписываются на уведомления о проблемах компонентов с типом «ПДК», а не «Устройство». Это позволяет получить одно уведомление по каждому ПДК, а не получать отдельное уведомление по каждому устройству.
Итоговая схема мониторинга АСМО
Давайте соберем все вместе и посмотрим какая схема мониторинга у нас получилась.
Заключение
Давайте подведем итоги.
Что нам дал мониторинг работоспособности АСМО?
1. Уменьшилось время устранения дефектов
Раньше мы узнавали о дефектах от пользователей, но не все пользователи сообщают о дефектах. Бывало так, что о неисправности какого-либо компонента системы мы узнавали через неделю после его появления. Теперь система мониторинга уведомляет нас о проблемах сразу, как только проблема обнаружена.
2. Увеличилась стабильность работы системы
Так как дефекты стали устраняться раньше, то и система в целом стала работать гораздо стабильнее.
3. Снижение количества обращений в техническую поддержку
Многие проблемы теперь устраняются до того, как о них узнают пользователи. Пользователи стали меньше обращаться в техническую поддержку. Все это хорошо сказывается на нашу репутацию.
4. Увеличение лояльности заказчика и пользователей
Заказчик заметил положительные изменения в стабильности работы системы. Пользователи меньше сталкиваются с проблемами в работе с системой.
5. Сокращения затрат на техническую поддержку
Мы перестали вручную выполнять какие-либо проверки. Теперь все проверки автоматизированы. Раньше мы узнавали о проблемах от пользователей, часто было сложно понять, о какой проблеме говорит пользователь. Теперь о большинстве проблем сообщает система мониторинга, уведомления содержат технические данные, по которым всегда понятно, что и где сломалось.
Важно!
Нельзя устанавливать систему мониторинга на тот же сервер, где работают ваши приложения. Если сервер выйдет из строя, то приложения перестанут работать, и некому будет отправить об этом уведомление.
Система мониторинга должна работать на отдельном сервере в другом ЦОД.
Если вы не хотите использовать выделенный сервер в новом ЦОД, можно воспользоваться облачной системой мониторинга. В нашей компании используется облачная система мониторинга Zidium, но вы можете использовать любую другую систему мониторинга. Стоимость облачной системы мониторинга ниже аренды нового сервера.
