Что может okerr

Ниже совершенно не полный список возможностей. Это просто некоторые примеры из разных областей, чтобы показать широту возможностей okerr.

Непредвиденная проблема (обнаружение аномалий)

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

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

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

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

Контроль за бэкапами

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

У вас много разных бэкапов и часто добавляются новые? Ну так у нас тоже! И okerr отлично справляется с этой ситуацией.

Есть специальный каталог с бэкапами на сервере бэкапов. Все бэкапы имеют имя по одному шаблону, например, servername-backupname-YYYYMMDD.tar.gz. Бэкапы с разных серверов все собираются в этот каталог.

Знаете, что мы делаем, чтобы окерр начал следить за бэкапами с нового сервера, которые попадают в эту папку, и оповещал нас, если они не созданы или если они "странные"? Ответ: НИЧЕГО. И это лучший ответ, потому что когда вам нужно сделать "ничего", вам довольно сложно сделать это неправильно или забыть это сделать.

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

Но самое важное тут не то, как легко следить за бэкапами, а то, что в okerr нет функции слежения за бэкапами! Это - скрипт, который сделан поверх платформы okerr, чтобы решить задачу таким вот удобным образом. Посмотрите раздел "Sequence > Примеры скриптов"" в документации. И точно так же удобно можно реализовать мониторинг за любыми другими параметрами.

Логика

Что если какое-то событие иногда является проблемой, а иногда нет? На самом деле в реальном мире такое часто. Высокая нагрузка на сервер? Это нормально, если она длится короткое время, и ненормально, если длится очень долго. Сервер выключен? А разве это плохо, повод для паники? Иногда нужно обновлять ПО, например, и сервер должен быть недоступен. Плохо, скорее, наоборот - если сервер никогда не обновляется.

Okerr умеет мыслить логически (если вы ему скажете как). И можно закодировать любое правило. Сервер может лежать в интервале с 5 до 7 утра, если в это время работают два других сервера. Количество новых заказов может быть даже нулевым ночью, но должно быть достаточно высоким днем.

Okerr умеет работать по сценарию. Например, если в каталоге с резервными копиями появятся файлы с сервера X, он догадается, что у вас есть новый сервер, создаст для него индикаторы с правилами (для бэкапов) по-умолчанию и будет отслеживать. И так же вышлет оповещение если новых бэкапов не будет или если они не будут соответствовать нужным условиям.

Наверное любую задачу по проверке, которую вы можете объяснить не слишком талантливому сотруднику, okerr сможет делать для вас регулярно, день и ночь, автоматически.

Да уж не хуже других

Okerr может контролировать внешние параметры системы, такие как пинг, открытый TCP порт, версия SSH, доступность страницы, содержание страницы (статус-код HTTP, оповещать при изменении содержания, оповещать при появлении текста "PHP Error"), валидность SSL сертификата и срок до его истечения, и так далее.

Но как говорила Марла Зингер - это мы делали на уроках труда в начальной школе.

Командная работа

Мы сами используем okerr в довольно крупном проекте (несколько сотен веб-сайтов). Над проектом работает несколько человек. Есть разграничение прав. Алерты отсылаются только тем, кто должен их получать. Качество работы админов (как быстро начинают исправлять проблему, как долго она исправляется) отслеживается. Если задача не исправляется достаточно долго - принимаются дополнительные меры.

Другой подход к работе

Так как серверов много, для выполнения задачи (например, обновление ПО) мы иногда сначала создаем индикаторы в okerr, и затем видим, на каких серверах задача уже выполнена, а на каких еще нет. Или может быть вообще забыли. Десятками серверов можно управлять как одним.

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

Как только запускается новый сервис - начинаем отслеживаеть его в okerr. Если случится проблема или опасная ситуация (мало места на дисках) - узнаём и исправляем быстро. Okerr сообщает об этом быстрее чем клиенты и заказчики. (Они даже и не знают, тссс....)

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

Контакт с пользователями (Страницы статуса)

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

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

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

Гибкость. Прямо по ноге

Для каждой задачи мониторинга можно выбрать наиболее подходящий способ из нескольких. Например, для мониторинга сервера СУБД возможны как минимум 4 способа. Для общения клиентов с сервером мониторинга так же доступно несколько способов (сырой HTTP/S, через okerrclient, через SMTP).

Что okerr не может

Okerr разрабатывался в первую очередь "для себя", для решения тех задач, которые возникали у нас. В нем нет некоторого функционала, который нам не был нужен.
  • Okerr не предназначен для отслеживания трендов в различных числовых индикаторах. То есть, он не очень удобен, чтобы заметить, скажем, что каждую среду, при выходе нового номера, нагрузка на сервер газеты на 80% выше среднего. Хотя эти цифры и видны в okerr, нет удобного способа их анализировать - просто он не для этого создавался. Но зато, он создавался для того, чтобы обнаружить, когда нужно вмешаться, чтобы исправить проблему. Например, вы можете иметь один индикатор для среды, и другой для остальных дней недели.
  • Okerr не предназначен для оценки скорости доступа из разных частей света. Вы не узнаете, что из стран юго-восточной Азии ваш сайт загружается втрое дольше. Вы только можете узнать, что документ с сайта удалось загрузить за допустимое время, либо не удалось.
  • Клиент оkerr не может выполнять внутренние проверки на ОС без достаточно хорошей поддержки языка Python и его модулей. В частности - ОС Windows. Но даже при использовании ОС Windows, сервер можно наблюдать через внешние проверки, и, благодаря открытой архитектуре, любая "самодельная" внутренняя проверка внутри сервера, может сообщать результат на сервер Okerr просто по почте (SMTP). Любая очень старая или очень экзотичная ОС, если она поддерживает отправку электронной почты - может быть интегрирована в okerr.
  • Некоторые типы проверок могут опираться на предыдущее значение индикатора (например, размер лог-файла должен быть не более чем на 10% больше предыдущего), но в целом нет возможности ретроспективного анализа (например, нет возможности сравнивать со средним значением индикатора за последний месяц).

Okerr использует гибридную архитектуру мониторинга. У нее есть свои плюсы.