еще и кролика обидели

Призывыется @ctrlok в защиту сенсу?

Почему кролик не отказоустойчивый? Он не умеет в кластер? (Умеет же)

умеет, но этот так называемый кластер не переживает split brain и потому на более, чем 1 ДЦ не растягивается. плюс, не гарантируется сохранность данных в очередях, но в данном случае это неважно.

Я трогал. Долго отмывал руки потом. Неприменимо. Хуже заббикса (хотя и он не подарок)

Применяю в десятке дц на всех континентах. Есть проблемы, но точно не с кроликами и руби.

в общем, rabbitmq с HA-очередями - это такое оригинальное решение CAP теоремы, где из C, A и P есть либо C, либо A (в зависимости от включенности autosync-а)

умеет, но этот так называемый кластер не переживает split brain и потому на более, чем 1 ДЦ не растягивается. плюс, не гарантируется сохранность данных в очередях, но в данном случае это неважно.

И зачем кластер для мониторинга?

Применяю в десятке дц на всех континентах. Есть проблемы, но точно не с кроликами и руби.

c HA-очередями, растянутыми на несколько ДЦ?

в общем, rabbitmq с HA-очередями - это такое оригинальное решение CAP теоремы, где из C, A и P есть либо C, либо A (в зависимости от включенности autosync-а)

В смысле при Р?

И зачем кластер для мониторинга?

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

c HA-очередями, растянутыми на несколько ДЦ?

Нет. То есть, мастер находится в одном дц, в котором HA.

Нет. То есть, мастер находится в одном дц, в котором HA.

и если ДЦ вырубится, то что?

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

Непонятно в чем проблема держать по сенсу-серверу на ДЦ.

Непонятно в чем проблема держать по сенсу-серверу на ДЦ.

Я так делал. Несколько инсталляций сенсу и не парился

и если ДЦ вырубится, то что?

То все внутри него умрет. Но оно и так умерло. Мониторинг скажет «дц умер».

В смысле при Р?

P в CAP - это partition tolerance. что при этом?

Каких алертов можно ждать от мертвого дц?

Каких алертов можно ждать от мертвого дц?

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

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

Кто-то же мониторит мониторинг

парадокс рассела его мониторит.

:)

Каких алертов можно ждать от мертвого дц?

а если линк между ДЦ порвался или из-за ошибки в сетевой конфигурации ДЦ хитро изолировался от части других ДЦ?

а если линк между ДЦ порвался или из-за ошибки в сетевой конфигурации ДЦ хитро изолировался от части других ДЦ?

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

Да и это редкая ситуация. По сенсу-серверу на дц покрывает большую часть потребностей.

Кто-то же мониторит мониторинг

Один сенсу-сервер может мониторить другой сенсу-сервер:)

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

тут уже дело не в транспорте, а в алгоритме определения кворума. но в случае sensu он сводится к тому, переживет ли отказ рэббит.

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

а у рэббита в этом плане не все радужно.

можно, конечно, отказоустойчивость поверх рэббита на уровне сервиса сделать, но зачем тогда рэббит?

а у рэббита в этом плане не все радужно.

что вместо рэббита ?

что вместо рэббита ?

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

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

А если дальше по списку, тебе не нравится жирноруби. А что у тебя используется сейчас? ЛегкоГо?

хотя бы ЛегкоГо.

вопрос про то, почему fork/exec испольняемого файла (при этом, скорее всего, скрипта) на каждый чек - это не очень, будет? :)

хотя бы ЛегкоГо.

А какая разница по времени выполнения скрипта проверки? Желательно в процентах или в миллисекундах

вопрос про то, почему fork/exec испольняемого файла (при этом, скорее всего, скрипта) на каждый чек - это не очень, будет? :)

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

А какая разница по времени выполнения скрипта проверки? Желательно в процентах или в миллисекундах

ну я просто не считаю нормальным создавать 10-мегабайтный процесс каждый раз, когда надо прочитать строчку из /proc/meminfo

вопрос про то, почему fork/exec испольняемого файла (при этом, скорее всего, скрипта) на каждый чек - это не очень, будет? :)

Вопрос лишь про то, почему это может вызывать проблемы.

ну я просто не считаю нормальным создавать 10-мегабайтный процесс каждый раз, когда надо прочитать строчку из /proc/meminfo

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

Вопрос лишь про то, почему это может вызывать проблемы.

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

Вопрос лишь про то, почему это может вызывать проблемы.

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

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

И все это сьест 1%CPU вместо 0.5%CPU

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

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

Выглядит как преждевременная оптимизация

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

Есть такие решения?

Есть такие решения?

про сбор основных метрик агентом вместо спавна по скрипту на каждый чек отдельной метрики, та же концепция экспортеров у прометеуса неплоха. если и то и другое, то в этом плане неплохо pcp сделан.

про сбор основных метрик агентом вместо спавна по скрипту на каждый чек отдельной метрики, та же концепция экспортеров у прометеуса неплоха. если и то и другое, то в этом плане неплохо pcp сделан.

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

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

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

Есть такие решения?

Кхе кхе

а почему нельзя каждый ДЦ мониторить отдельно, а метрики объединять где-нибудь?

с моей колокольни это все выглядит как оверинжиниринг

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

что в общем логично, хотя для архивации и всего такого, потом то неплохо их все где то свести в кучу

а почему нельзя каждый ДЦ мониторить отдельно, а метрики объединять где-нибудь?

где? и насколько это "где" отказоустойчиво?

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

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

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

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

Сорян, уже выяснили почему сенсу норм или ещё нет?

Сорян, уже выяснили почему сенсу норм или ещё нет?

нет, расскажи.

Нью кид он зе блок - https://github.com/mattbostock/timbala

Timbala is a distributed, fault-tolerant time-series database intended to provide durable long-term storage for multi-dimensional metrics. It is designed to integrate easily with Prometheus, supports PromQL and is API-compatible with Prometheus, but can be used standalone. Data stored in Timbala can be visualised using Grafana by configuring a Prometheus data source pointing to Timbala.

Но пока не готово для прода, пилят кластер - https://github.com/mattbostock/timbala/milestone/2

Чот два месяца ни одного коммита

ERROR: S client not available

реально там последний коммит 29 октября

https://github.com/mattbostock/timbala/tree/typo

ну не совсем :D

да вот совсем, дальше просто опечатки правятся

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

А кто-то может напомнить ссылку на табличку с tsdb разными?

@Civiloid

В описании чата: https://goo.gl/BRqzdG

Почему кролик не отказоустойчивый? Он не умеет в кластер? (Умеет же)

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

И все это сьест 1%CPU вместо 0.5%CPU

нет, разница в сотни и тысячи раз. особенно это видно когда у тебя виртуалок много (например тридцатник на машину) - там каждая такая надбавка прям поддает в cpu system time хорошо

нет, разница в сотни и тысячи раз. особенно это видно когда у тебя виртуалок много (например тридцатник на машину) - там каждая такая надбавка прям поддает в cpu system time хорошо

Вот, кстати, имеет ли смысл собирать с каждой виртуалки так много метрик? Может их, как-то покластерно проверять? (Если их много тысяч)

Вот, кстати, имеет ли смысл собирать с каждой виртуалки так много метрик? Может их, как-то покластерно проверять? (Если их много тысяч)

это как?

это как?

У меня ещё не оформилась мысль. Это я пока поток сознания вылил

может достаточно собирать то, что собирает digital ocean по своим дроплетам и все?

Вот, кстати, имеет ли смысл собирать с каждой виртуалки так много метрик? Может их, как-то покластерно проверять? (Если их много тысяч)

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

это как?

В том плане, что если у нас много виртуалок, то они, скорее всего, разбиты по гридам/кластерам. Возможно надо собирать информацию не со всего набора виртуалок, а с 10%, в другую проверку - с других 10% итд

В том плане, что если у нас много виртуалок, то они, скорее всего, разбиты по гридам/кластерам. Возможно надо собирать информацию не со всего набора виртуалок, а с 10%, в другую проверку - с других 10% итд

так не делают

получится средняя температура по больнице

о реальных проблемах с такой системой ты можешь и не узнать

предположим что на виртуалках разные приложения и не сильно взаимосвязаны друг с другом. и надо форком сходить и взять стату с каждого из них. это 30 форков. каждая такая новая стата будет добавлять еще 30

а еще предположим что микросервисная архитектура, где под микросервисы берешь мало ресурсов (у меня есть сервисы которые на 1 cpu могут держать порядка полутора тысяч rps и потребляют не более 50 мегабайт памяти). вот когда агент мониторинга жирнее твоего приложения это становится немного странно.

Когда у тебя микросервисная архитектура, имеет смысл самому сервису отдавать стату о себе

Когда у тебя микросервисная архитектура, имеет смысл самому сервису отдавать стату о себе

Это если разрабы вложили такой функционал :)

Это если разрабы вложили такой функционал :)

Ну... IDE вам в руки)

Нене, допиливать говно за разрабами не моя работа ))

Мы же тут все "девопсы", должны принимать участие в создании сервиса на всех уровнях

Не уверен что это так должно быть всё-таки.

Когда у тебя микросервисная архитектура, имеет смысл самому сервису отдавать стату о себе

когда у тебя микросервисная архитектура не всегда в микросервисе реализован даже роутинг урлов. например разработка может хотеть сделать микросервис наоборот как можно меньшим по обьему. а стату можно пушить в штуковину рядом любую например пушгейтвей или uwsgi stats

syslog-ng кто юзает вместо rsyslog?

Мы же тут все "девопсы", должны принимать участие в создании сервиса на всех уровнях

а может ещё и запросы в базу за них править, а потом и код править, а потом и функционал пилить, и желательно за пол их з\п