Бесплатный мониторинг okerr для юниксоидов

Зашел в демо-аккаунт, поменял в ping:BAD ip на 8.8.8.8 - все кружочки с uptime сразу стали зелеными. как так?

https://imgur.com/a/6vvcx

Поменял назад на 8.8.8.9: прошло уже минут 5 - всё как было в «ОК», так и осталось.

Спасибо!

Вот ради таких репортов я и создал тему :-) Не ожидал, что так быстро.

У этого индикатора политика Default (ее видно на вашем скриншоте). Если вы нажмете на гаечный ключ рядом с ней, увидите параметры политики. Самое важное в ней - расписание перепроверок, сейчас оно равно 30сек и 10 мин.

То есть, если индикатор был в состоянии OK, и внезапно проверка дала ошибку - он НЕ переключится в ERR сразу. Будет назначена перепроверка через 30 секунд. (Можно ускорить, если нажать руками кнопку «перепроверить», чтоб не ждать). Если и она не удастся - будет следующая перепроверка через 10 минут. И только если все перепроверки дадут ошибку - только тогда установится статус ERR и будет выслано оповещение. (При этом каждая следующая проверка делается не тем сервером, который дал ошибку на предыдущей).

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

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

Но замечание хорошее, для демо-аккаунта, наверное, перепроверки не нужны, я их уберу, чтобы они не смущали, спасибо!

Регистрация поломана =)

https://i.imgur.com/TBxt1oA.png

Да, еще, кружочки (кстати, нужны ли они? я вот в сомнениях, не слишком часто на них смотрю) - меняются по истории изменений индикатора, которая пишется с момента первой смены статуса.

Так как демо-аккаунт «заколдованный», он каждые несколько часов пересоздается и истории смены статуса там нет (хотя индикатор и создан еще при динозавра). Но сейчас, когда статус изменился - она начинает собираться.

В собственном проекте с этим будет все хорошо, там ваша история изменений будет писаться и храниться с первой смены статуса.

Вопросы?

где можно посмотреть исходники и под какой они лицензией

Ооопс. Я слишком редко регистрируюсь на нем. :-)

Спасибо, вроде исправил.

Сейчас вы можете зарегистрироваться? (повторное письмо может не уйти, тогда в личку напишите емейл или здесь, я сотру запись о неполной регистрации и сможете заново)

Сама серверная часть - наша. Я пока не решил, публиковать ее или нет, пока что идея использовать ее как сервис.

А вот клиентская часть - полностью открыта. Скачать можно с pypi: https://pypi.python.org/pypi/okerrclient/

Она на питоне, так что там все в исходных кодах. Лицензия MIT.

Сам интерфейс между клиентской частью и серверной - по HTTP и описан в документации с примерами, так что, можно хоть curl'ом даже пользоваться, если будет такое желание :-)

roman at serov.co

Удалил. Можете снова зарегистрироваться.

Перепроверки объясняют, почему статус с ОК на BAD не поменялся сразу.

А почему в статистике из «100% BAD» при изменении адреса все перешло сразу в «100% OK»?

А теперь статистика более менее понятная, но сумма OK+BAD=99, а не 100. ;)
Помимо процентов, также было бы интересно видеть время простоя.

Пишется ли куда-нибудь история, кроме как в журнал? Никаких графиков не нашёл.

P.S. зачем нужна анимация у диаграмм? Отвлекает же.

А почему в статистике из «100% BAD» при изменении адреса все перешло сразу в «100% OK»?

Да, еще, кружочки (кстати, нужны ли они? я вот в сомнениях, не слишком часто на них смотрю) - меняются по истории изменений индикатора, которая пишется с момента первой смены статуса.

Ага, вопрос пропал.

Ну там округления всякие 99.1 + 0.9 это ж 99+0. :-)

Есть внутренняя история смены статуса, которая как раз и используется, чтобы рисовать кружочки. Она не отображается.

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

Вообще я сейчас против графиков обычных параметров (ну, например, отслеживать RTT или время загрузки страницы). Это мне кажется другой задачей и с ней другие мониторинги работают («что-то у нас медленно загружается страница из Висконсина»), у окерра функция дискретная - ждать, смотреть и в нужный момент поднять панику. Зато алерт от окерра, если все настроено правильно - должен быть достаточным основанием чтобы бросить все и начать разбираться.

Но вот график аптайма - может иметь смысл, согласен.

Ну там округления всякие 99.1 + 0.9 это ж 99+0. :-)

Это понятно, но может надо округлить одно, а потом второе сделать 100-первое?

А хочется графики аптайма? Я просто не очень представляю как бы их отобразить визуально.

Но вот график аптайма - может иметь смысл, согласен.

Тут под «аптаймом» разные понятия имеются? :) Я имел ввиду числовые параметры. Например, график температуры в серверной. Или график загрузки ЦП.

и с ней другие мониторинги работают

А как вы позиционируете свой мониторинг тогда? Разве ни как мониторинг общего назначения? Я пока не вижу что у вас лучше того же zabbix.

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

Ну так это по сути просто 2 разных мониторинга, которые мониторят один за другим. Нет?

пока что идея использовать ее как сервис.

какой SLA сервиса заложен в развитие ?

что у вас лучше того же zabbix

Ну все, наступили на больную мозоль, налейте чаю - ответ будет долгим.

В презентации я привел несколько примеров, которые нам кажутся интересными, и которые сложно добиться от других мониторингов. Вот те же статусные страницы - лежачий заббикс не покажет пользователям, что «вебсервер1 - работает, сервер заббикс - лежит». Не покажет, потому что лежит. Окерр работает на нескольких серверах и если изредка и падает - то вряд ли он упадет именно в тот момент, когда случится проблема с наблюдаемым клиентским сервером.

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

Код проверок берется с сервера. То есть, если вы придумаете дополнительную проверку, вам не обязательно придется обновлять все наблюдаемые сервера - они автоматом подтянут нужный код проверки, создадут индикаторы.

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

Есть «обратная связь» - когда при любом изменении индикатора тут же вызываем веб-хук и передаем все данные. Например, можно сделать так, чтобы при падении какого-то сервиса клиентский скрипт принимал меры (рестартовал его или изменял имя в DNS чтобы оно вело на рабочий сервис, или создавал тикет в багзилле). Вообще, окерр - больше платформа, а не сервис. Это не «набор проверок», а тулкит, на базе которого можно сделать такой мониторинг, который нужен (просто он сразу уже в собранном виде, но можно пересобрать и иначе).

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

С другой стороны - если человек хорошо владеет инструментом (тем же заббиксом), знает его глубоко, то даже если какая-то функция у нас делается в два клика - такому человеку проще своим удобным инструментом добиться результата. Так что, если Zabbix вас лично на самом деле полностью устраивает - тогда я скорее даже поотговариваю вас от окерра. Стабильность - важнее а любые перемены имеют свою цену и в труде и в даунтайме. Зачем менять то, что полностью хорошо работает? А вот если что-то не очень нравится - тогда можно обсудить, как это можно достичь через окерр.

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

Разве ни как мониторинг общего назначения

Именно так. Основная ориентация - «мы сами» (и люди вроде нас). Небольшие команды технарей. Поэтому и делали в первую очередь под себя. Для нас важно сразу знать о проблеме, иметь возможность избавиться от ложных срабатываний, по возможности обнаруживать аномалии (В интернет-магазине меньше покупок чем обычно. Хотя технически сервер работает, сайт открывается.). Есть желание, чтобы он был удобен и прост для «простого человека» (стоматолог, которая открыла свой сайт). Чтобы это стало стандартом как бесплатный вебмейл. Завел сайт - тут же просто сделал его надежнее. Но это вторичное желание, первичная ориентация - именно на админов/программистов.

Но вот количественные индикаторы нам не слишком важно было смотреть. Числовые индикаторы вообще есть, и есть триггеры в них (например, если бэкап внезапно уменьшился в размерах), но опять же тут суть - в бинарном решении OK/ERR, в алерте, а не в анализе трендов, когда мы вдумчиво смотрим на график и пытается в нем что-то увидеть (например, что по средам сервер на 12% более нагружен).

А что вы хотите наблюдать? Может быть мы переосмыслим этот вопрос. (Опять же, для того и создан этот пост, чтобы взгляд и мнение со стороны получить).

2 разных мониторинга, которые мониторят один за другим. Нет?

Нет. Если уж смотреть на это через призму «обычного мониторинга», то сервер окерр - и есть аналог сервера nagios, zabbix, ... который находится в мире. Не два мониторинга, а один в облаке. Но арендовать сервер, устанавливать, настраивать и поддерживать его не нужно. Вот statuspage - более близкий аналог или NewRelic. Но у них все таки чуть иная ориентация.

Сама серверная часть - наша. Я пока не решил, публиковать ее или нет, пока что идея использовать ее как сервис.

Ну и будут у вас там одни хипстеры да наколенные поделки, потому что никто не будет по нормальному проекту отдавать важные данные каким-то мимопроходилам.

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

ничего такого, что нас бы устроило бы не нашли.

у меня такое ощущение что вы описали circonus ...

какой SLA сервиса заложен в развитие ?

Хочется, конечно же 99 и еще столько девяток после точки, сколько удастся выжать. Отчасти потому для меня лично проект так и интересен, что я маньяк и параноик, и надежность считаю очень важной. Интересно, насколько высокие параметры удастся фактически достичь.

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

В любом случае, падение сервера окерр (ну а оно происходит, хотя бы на пару секунд, когда рестартуется после обновления) опасно только тогда, когда совпадает с моментом проблем на наблюдаемом сервере. То есть, тут будет перемножение (в хорошем смысле) даунтаймов. Если сервер лежит 0,1% времени (0.001) и okerr лежит 0.1%, то шанс сбоя - 0.001 * 0.001 = 0.000001 ( одна тысячная в квадрате = одна миллионная)

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

у меня такое ощущение что вы описали circonus ...

У меня есть списочек «100500 потенциальных аналогов», и самые яркие оттуда я разглядывал, но вот circonus не смотрел. Отпишусь попозже про отличия, когда руками потрогать смогу.

Пока что сходу мне кажется более «тяжелым» ну и цена...

Но спасибо за наводку - погляжу.

Без открытой серверной части получаем очередное хипстерское SaaS ненужно. Спасибо, мы уж как-нибудь zabbix'ом, да nagios'ом обойдемся.

Для чего нужен открытый код серверной части? API и сейчас открыт. (Может быть и код решим открыть - сейчас пока просто смотрим). Вот, например, у меня нет открытого кода серверной части gmail или evernote или freshdesk но это не мешает ими пользоваться и экономить на содержании собственного почтовика.

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

Но если уж обходиться - то выше предложили вариант circonus - он хотя бы внешний. Хотя в нем тоже серверная часть закрыта.

у меня такое ощущение что вы описали circonus ...

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

У вас есть опыт работы с ним? (потому что у меня-то впечатление поверхностное, за час)

Плюсы circonus (по сравнению с окерром)

бОльшая гибкость и универсальность в плане метрик. В HTTP тесте имеем доступ ко всей сопутствующей информации вплоть до набора SSL шифров. Мне кажется - это нафиг не нужно, но зато если нужно - все можно подключить, а это плюс.

Красивые графики.

Больше всяких каналов для алертов (у окерра - почта, телеграм и универсальный веб-хук).

Очень понравился механизм эскалаций, который автоматически требует подтверждения от оператора и эскалирует, если никто не подтвердил. (В окерре для этого отдельный логический индикатор приходится делать). Вот предыдущие пункты мне (на мой личный вкус) кажутся неважными, а этот «зацепил», понравился :-) )

Минусы circonus (по сравнению с окерром)

Пишу на основании своего маленького опыта с ним - может быть ошибаюсь. В общем-то это не минусы, а обратная сторона плюсов. Сложно одновременно иметь и вместительную ГАЗельку и юркую микролитражку.

Не понравился разрыв между самими данными, алертами и дашбордом. Как бы данные отдельно, а потом опционально к ним надо прилеплять отображение и алерты. В окерре в этом плане проще - вся суть в алертах, поэтому индикатор без алертов не имеет особого смысла («чё на него смотреть-то?»). Когда создается индикатор - сразу же определяются и правила алертов (ну и часто они по дефолту разумные - пинг алертит, когда пинга нет, SSL алертит когда сертификат скоро протухнет).

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

Мне кажется, простота использования - довольно важная штука, потому что мониторинг сам по себе «не болит», и если настройка сложная - её будут откладывать на потом. (А все ведь меняется, сервера добавляются, их конфигурации изменяются - в общем, подкручивать мониторинг - задача частая). В итоге, с одной стороны - вроде как мониторинг есть, а с другой - чем больше усилий требуется для того чтобы начать наблюдать новый параметр, тем больше шансов, что это «отложат на потом» (если вы понимаете о чем я).

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

Не очень понравилось то, что нет контроля за тем, как часто исполняется проверки, а правила, перепроверки - каждая настраивается отдельно (у окерра для этого политики есть).

Клиент немного странный, для centos/ubuntu (у окерра - он на питоне и просто ставится везде где есть python одной командой (sudo pip install okerrclient), хотя на винде я пробовал - без портирования не идет.

Не очень понравилось, что в цирконусе их агент - сам по себе сервер (принимает запросы и обслуживает их). В окерре мы принципиально от этого отошли. Окерр никогда не лезет на клиента, только принимает с клиентов. (А клиент может быть хоть с динамическим IP, хоть за NATом, и может вообще не иметь открытых портов, и даже установленного агента. Можно curl'ом обновления отправлять или по SMTP - так что, даже с винды можно, хотя и неудобно).

В окерре гораздо меньше шансов, что из-за ошибки в клиенте будет взломан ваш сервер (вот для примера дырки с zabbix), не потому что у нас код такой безопасный, а потому что архитектурно там взламывать почти нечего, он не сервер, а клиент (как дырку в lynx/curl искать - они могут быть, но ломать систему через них - явно уже совсем другой уровень сложности).

Ну и для частой проверки (раз в минуту, как у них делается) агент, мне кажется, может все таки нагружать машинку, если это слабенькая VPSка.

Субъективный вывод

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

Что-то я не увидел отличий от заббикса, кроме сервера в интернете, который всегда работает (на самом деле так себе фича)

Для чего нужен открытый код серверной части?

Для того, чтобы пользоваться и не бояться, что завтра, когда очередной стартап обанкротиться, серверная часть перестанет существовать. А так же для того, чтобы планировать апдейты и даунтаймы тогда, когда это удобно тебе, а не администраторам сервиса (emfit qs, например, очень любит, например, выкатывать апдейты когда в РФ ночь и их девайс должен работать, а так как он историю накапливать не умеет, то временно превращается в тыкву)

Вот яркий пример того, как это бывает: https://consumerist.com/2016/08/19/tcp-disconnects-smart-lightbulb-servers-le...

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

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

Это верно и резонно.

okerr (по крайней мере сегодня) - не бизнес-проект. Посмотрите историю домена, он с 2014 года существует, так что мы оплачиваем сервера, получаем нулевую прибыль с него и это для нас никак не является поводом даже думать о его закрытии (как я уже говорил, мы плохие менеджеры). Талантливых ребят, как в Гугле, которые скажут «Давайте закроем проект, все равно с него мало прибыли» у нас нет. Одна из функций проекта - чтоб он был и был популярным - хотя бы просто как «рекламный» проект.

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

Что-то я не увидел отличий от заббикса, кроме сервера в интернете, который всегда работает (на самом деле так себе фича)

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

На самом деле, именно внешнее наблюдения и есть ключевое отличие. Если вам она не нужна, а нужны только функции заббикса (смотреть место на диске и так далее) - и заббикс у вас есть и работает - тогда конечно, менять не стоит. Мы не собираемся быть убийцей заббикса, уверены, что у него тоже должна остаться какая-то своя ниша :-)

Ты уже раза 3 написал, что вы не менеджеры, но что-то кроме рекламы и воды ничего не слышно)

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

Не, я не хочу презентацию, хочу feature matrix отличий от десятков других мониторингов.

На самом деле, именно внешнее наблюдения и есть ключевое отличие

Да это херня, а не ключевое. Мониторинг вообще считается хорошим тоном держать на внешней системе.

Пишется ли куда-нибудь история, кроме как в журнал? Никаких графиков не нашёл.

Специально для Вас! :-)

1. В демо аккаунте убраны ретраи, они больше запутывают пользователя-новичка, которому они еще не нужны. 2. В блоке аптайма добавлена ссылочка на страницу аптайм лога. Графика нет, но в табличке там видно когда менялись статусы и сколько держался каждый статус. (Статусы пишутся с момента первой смены статуса).

Если предложите красивое и удобное графическое отображение - добавлю его (пока меня сдерживает идея «одномерного» графика, мне кажется он какой-то «график ради графика»). Если потом увидим какой-то хороший вариант - то его сделаем.

хочу feature matrix отличий от десятков других мониторингов

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

Мониторинг вообще считается хорошим тоном держать на внешней системе.

Совершенно согласен! Но не у каждого мелкого проекта есть отдельный внешний сервер для мониторинга (или желание и бюджет, чтобы его арендовать и поддерживать). Если у вас есть дата-центр с «обычными» серверами и хотя бы пара внешних серверов мониторинга в разных точках - отлично!

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

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

вся суть в алертах, поэтому индикатор без алертов не имеет особого смысла («чё на него смотреть-то?»)

иногда есть смымсл делать просто мониторинг - типа сколько запросов в минуту в виде графика общего.. Или тайминг пинг поверх метрики с некой производительностью...

В цирконусе - дашборд можно сделать и даже не один (хотя зачем?)

потому как систему порой надо видеть с разных сторон и разным людям. например для вывода на большой экран в мониторинг комнате надо одно, а для разным уровней суппорта нужна разная «глубина» данных...

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

для этого есть всякие чифы, ансиблы и терраформы

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

okerr (по крайней мере сегодня) - не бизнес-проект. Посмотрите историю домена, он с 2014 года существует, так что мы оплачиваем сервера, получаем нулевую прибыль с него и это для нас никак не является поводом даже думать о его закрытии (как я уже говорил, мы плохие менеджеры). Талантливых ребят, как в Гугле, которые скажут «Давайте закроем проект, все равно с него мало прибыли» у нас нет. Одна из функций проекта - чтоб он был и был популярным - хотя бы просто как «рекламный» проект.

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

Но до этого, я думаю, еще есть пара десятков лет, в течение которых окерр будет обеспечивать надежность вашим проектам :-)

Уверен, что те пацаны, которые разрабатывали и продвигали те IoT лампочки тоже так думали ;)))

Это здорово и красиво, когда большой зал, экран как в ЦУП и все смотрят за графиком и замерли, а потом весь зал аплодирует. У нас все таки применение в масштабах попроще (несколько серверов, много виртуалок и очень много виртхостов). И монитор 27". :-)

Окерр не столько для «втыкания» в него (зачем - глаза нужны чтобы что-то другое делать), а чтобы он «разбудил» в нужное время, когда, например, пинг до балансера пропал или стал длинным, или база данных стала «странной» (например, растет быстрее-медленнее обычного). Если есть экран - то подразумевается, что когда-то на нем может быть что-то, что изменит обычный ход работы. А если так - то зачем на него пялиться - можно же просто правило описать, и в нужный момент придет письмо или пропищит телефон, или web-hook сработает - тогда и надо будет смотреть. Бывают ситуации, которые в цирконусе алертами не отлавливаются, а только зорким глазом админа?

В качестве дашбордов есть статуспейджи, их можно много делать (и публичные и приватные) и на них можно смотреть, но они тоже «бинарные» (ok/err, красный/зеленый). Потом можно зайти в индикатор и посмотреть подробнее, что он зеленый, потому что 42, а несколько минут назад было 36.6, но беглый взгляд у нас дает просто эффект «есть красные огоньки/нет красных огоньков», а не «вот там пик на том графике подозрительно совпадает с пиком на другом» - такого нет.

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

Увы, ничто не вечно. И гарантий никаких быть не может в принципе (только их иллюзия). Открытый код - это плюс к надежности, но тоже не гарантия. :-( Не один раз же, когда Open Source проект взлетал, а потом просто медленно умирал. И вроде теоретически - сорцы все есть, а все равно - самому пользователю копаться в них, «тащить», бакфиксить и развивать - не вариант. Если опен-сорсный проект умер - так же переезжать придется.

Конечно, ценности у каждого свои. Но вот я к примеру пользуюсь некоторыми сервисами (freshdesk, gmail), и они мне экономят время-деньги постоянно. Хотелось бы, чтоб так было всегда. Но если так всегда не будет - ну... перееду. Все равно они уже наэкономили ого-го сколько.

В плане переезда - у окерра есть хороший плюс в виде API. Можете хоть каждый день через API все свои проекты сливать к себе. А если потребуется переехать - по этим данным (уже через API другого сервиса) создать аналогичные там:

$ export OKERR_API_USER='okerrdemo@maildrop.cc'
$ export OKERR_API_PASS='okerrdemo'

$ okerrclient -i okerrdemo --api-indicators
antispam:ngs.ru:barracuda
antispam:ngs.ru:sorbs
antispam:yandex.ru:barracuda
antispam:yandex.ru:sorbs
domains:google.com
domains:okerr.com
...

$ okerrclient -i okerrdemo --api-indicator --name domains:google.com > domains:google.com.json

В шелле в цикле по всем индикаторам, и в крон раз в сутки. Переезд (если придется) будет легким и приятным. :-)

Увы, ничто не вечно. И гарантий никаких быть не может в принципе

Разумеется.

Не один раз же, когда Open Source проект взлетал, а потом просто медленно умирал.

Это дает в первую очередь прогнозируемость, и _очень_ большие и гибкие временные рамки для миграции, которые определяешь в первую очередь для себя ты, а не владелец стороннего сервиса, которому нужно срочно выключить до надцатого числа сервера, взять кассу, яшик джемесона и свалить в банановую республику, пока к нему не пришли инвесторы с паяльниками. И дает возможность самому выбирать когда мигрировать (и мигрировать ли вообще?), если на то полшло. И это страхует намного больше от факапа, потому как необходимость миграции может совпасть легко с дедлайном по всем фронтам, когда на нее просто не будет ресурсов. Risk Management, в общем, ничего личного ;)

Конечно, ценности у каждого свои. Но вот я к примеру пользуюсь некоторыми сервисами (freshdesk, gmail), и они мне экономят время-деньги постоянно. Хотелось бы, чтоб так было всегда. Но если так всегда не будет - ну... перееду. Все равно они уже наэкономили ого-го сколько.

Я тоже пользуюсь SaaS, например emfit qs, у которого альтернатив нет. Но, при наличии альтернатив - стараюсь выбирать полностью opensource решение, с открытой серверной частью, ибо это банально надежнее. Например, связка nextcloud + rainloop (с iRedMail на LDAP в виде бэкенда) заруливает по удобству gmail (ушел на нее как раз, когда задолбался с оным) и все сервисы гугла, и ее имеет смысл дежать даже просто для дома.

В догонку, владелец сервиса всегда оставляет за собой право менять набор фичей, в том чиле выпилив нужные. И опять никакой прогнозируемости, жрите что дают. Пример - welltory, которые когда поняли, что народ просто использует их модное SaaS приложение для телефона как точную беплатную измерялку HRV, быстро закрутили гайки, ограничив детализацию HRV в бесплатной версии 1 запросом в сутки.

И нет, это вопрос не ценностей, как Вы пишите выше, а просто циничный risk management, который нынче почему-то не в тренде.

мне кажется, не очень хорошо, когда такое сравнение делает заинтересованная сторона

почему? «Вот этого нет в заббиксе» - очень легко проверить будет.

Риски безопасности принимают на себя сервера окерр, а не клиенты

Особенно актуально в закрытых от интернета сегментах)) Ну и риски тут принимают клиенты, отправляю свои метрики не пойми куда.

Мы стараемся сделать так, чтобы мониторинг для пользователя был легким и дешевым, а не смыслом жизни

Обычно есть отделы мониторинга, это их работа. Короче я понял, у вас не заббикс, а monitoring as a service.

nextcloud + rainloop (с iRedMail на LDAP в виде бэкенда) заруливает по удобству gmail

Про rainloop не знал - красивый! Но это же на своем железе. То есть надо все таки ставить, связывать, периодически проглядывать логи... Понятно, что любой юниксоид это может, и это дает фулл-контрол но это не то, что мы получаем от gmail (внешний сервис). Все равно, есть расходы своего времени. Железа. Все равно если вдруг упало, а сам - далеко, то сложно пондять. С сервисом проще - он просто работает. (если даже что-то пошло не так - как-то сам чинится)

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

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

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

Зависит от прямоты рук того, кто это настраивал. Хорошо продуманная инфраструктура нуждается в минимуме поддержки и «просто работает» ;)

«Вот этого нет в заббиксе» - очень легко проверить будет.

Ну например статусные страницы (https://status.python.org/ или https://cp.okerr.com/status/okerr) - мне кажется, вряд ли они есть в нем?

Или алерты по сложным условиям (алерт, если у нас в строю меньше 3 веб-серверов больше 2 часов и сейчас будний день).

(Тут нужно мнение человека, который тот же заббикс хорошо знает).

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

риски тут принимают клиенты, отправляю свои метрики не пойми куда

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

Сейчас объясню. Есть данные, которые пользователь боится раскрывать (например, содержание файлов), и есть те, которые он не считает конфиденциальными (% свободного места на диске). Важно, чтобы наружу уходило только не конфиденциальная информация. Представим, что мы параноики, которым очень важно это.

Нет ли в мониторинге какого-то бэкдора? Чтобы узнать это, нам нужно весь его немаленький код проаудитить (ну или скрестить пальцы и надеяться, что другие его читали). Не получится ли так, что бэкдора нету, но его могут взломать и украсть какие-то данные (тут точно ответ для заббикса грустный, так как история дырок у него существует).

Чем окерр в этом лучше? Клиентская часть - относительно маленький скрипт. Если уж аудитить код - то его гораздо проще. Но, допустим, мы вообще не хотим его проверять (тяжело проверить чужой код). Окей. Не ставим. Шлем обновления curl'ом или mail. Все. Нет места для бэкдоров. Нет места для уязвимостей.

Короче я понял, у вас не заббикс, а monitoring as a service.

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

Хорошо продуманная инфраструктура нуждается в минимуме поддержки и «просто работает»

До поры, пока условия стабильны. Рано или поздно просто сгорает сам компьютер и летит винт. Или просто надо апгрейдиться на новую ОС или железо. Или проект Rainloop устаревает, так же как устарел Squirrelmail. Или вообще, сама технология email вдруг устарела, а все модные теперь общаются в вотсаппе или (перекрестился) Одноклассниках. :-).

Как в Бойцовском клубе:

when you buy furniture, you tell yourself: that's it, that's the last sofa I'm gonna need. No matter what else happens, I've got that sofa problem handled.

Беда в том, что когда мы что-то делаем - мы опираемся на наши предсказания и представления. А жизнь все время непредвиденные сюрпризы приносит.

Бывают ситуации, которые в цирконусе алертами не отлавливаются, а только зорким глазом админа?

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

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

Какой дебил будет ынтерпрайзный заббикс выставлять в интернеты?
Какой дебил будет гонять данные от агентов в заббикс не через впн?
Серьезно?

Какой дебил будет ынтерпрайзный заббикс выставлять в интернеты?
Какой дебил будет гонять данные от агентов в заббикс не через впн?

Значит, если заббикс и не дебил - то покупает циску и нанимает цискоадмина.

Мы уже уходим в область прекрасных правильных женщин и не менее прекрасных мужчин с сертификатами и трехзначными почасовыми рейтами. Ах, если б каждый бизнес мог себе позволить для алертов «у вас тут сервер не пингается» легко понести такие расходы. Дорого выходит, с заббиксом, то.

Как видите, мы плохие менеджеры и продажники,

Нууу, скромняжки))

Дорого выходит, с заббиксом, то

Тот бизнес, где новые киски и спецы по ним не по карману, идут и спокойно поднимают все на OpenVPN или, прости господи, на микротыках. А то и вообще покупают списанные киски. Не дорого, обычный уровень пивного ларька.

Значит, если заббикс и не дебил - то покупает циску и нанимает цискоадмина.

какие то крайности... по вашей логике получается что или продакшн смотрит во внешний мир всеми своими портами, или нужна дорогущая циска - среднего не дано?

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

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

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

Идея системы - именно в автоматическом отслеживании проблем и посылке алертов - эта часть и отработает как надо. Умерла = алерт. А о том, как она там жила, в загробном мире - это уже не очень интересно в мире живых. Ну, по крайней мере нам не требовалось. Если, скажем, следим за местом на диске, и его стало мало - алерт. Нет сигнала - алерт. В любом случае для админа схема простая - получил алерт - надо разбираться.

Кстати, в цирконусе он шлет алерты если не может до клиента (брокера) достучаться?

Вот попробовал поиспользовать как пинговалку с уведомлениями.

Мне кажется что у вас такие условия, что пользоваться особо нельзя - максимум 5 индикаторов и минимальное время проверки 1 час.

Узнал о проблеме через полтора часа. Через час после решения проблемы увидел что она решилась.

Мне пользователи позвонили бы быстрее, если бы я сейчас не болел.

А с ограничением в 5 индикаторов даже ssl checker не сделаешь - поддоменов слишком много.

Прошу прощения, я тут редковато бываю :-)

При часовом периоде, алерт должен быть в интервале от 0 до 1 часа после проблемы. Или у вас перепроверки были? Мне алерты очень быстро приходят.

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

Напомните свой адрес (можно через тикет в support - его я же увижу, или тут, можно со звездочками - я найду), я на него дам другие лимиты, там и период будет короче. Никаких гарантий, но скорее всего лет на 10 вперед - должно быть достаточно :-)

Кстати, если пройти тренинг (со странички профиля), то всем дается уровень с 20 индикаторами по часу + 1 быстрый 10-минутный. (Но предложение по более высокому уровню все еще в силе).