Какие ещё алерты? Графановские что ли?

Да и вообще проблемы с самими алертами

тут есть девопсы ?!

эти повелители ci и golang-еры

Тут кругом девопсы

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

заводы стоят в стране одни девопсы

вызов!

Devops, devops everywhere

Ну и вообще, надёжность мониторинга должна быть выше надежности мониторингуемой системы

сегодня вот такое нашёл - http://devopswiki.net/

Девопсы устали. Тасков много, а я одна (ц)

Ну и вообще, надёжность мониторинга должна быть выше надежности мониторингуемой системы

В чём надёжность измеряем?

в штуках

в штуках

Баксов?

В чём надёжность измеряем?

в сантиметрах

в девопсах увезенных в лес

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

одна надежность = 10 девопсов в лесу

Ну и вообще, надёжность мониторинга должна быть выше надежности мониторингуемой системы

обоснуйте тезис

обоснуйте тезис

Ты же не хочешь в лес?

Так чем больше девопсов в лесу тем лучше или хуже? Я не понял

одна надежность = 10 девопсов в лесу

А штат девопс - это запас прочности?

А штат девопс - это запас прочности?

я слышал в епаме на одном проекте надо было 70 штоли девопсов

видимо нужна серьезная надежность.

Пальмиру брали наверное

Фуфу, RethinkDB это документ база, не надо тащить такое в графану

А чем реляционки лучше?)

Фуфу, RethinkDB это документ база, не надо тащить такое в графану

Эластик тоже документный)

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

Ну так любой язык, который поддерживает gPRC и вперед.

Молодой кликхаус как исключение подтверждающее правило?

Правда он впринципе далёк от "нормальных рсубд" ))

и он не рсубд

Про просрать так себе аргумент. Чем неумение в acid хуже drop database?

там уже можно обновлять записи?

В чём надёжность измеряем?

uptime?

А чем реляционки лучше?)

тем что их поддержка уже есть

uptime?

Работать с ошибкой хуже чем не работать вообще

а если аптайм высокий, а данные протерялись? %)

Эластик тоже документный)

В эластике нельзя хранить юзеров, сессии и дашборды. Как и в КХ.

Я думал мы метрики обсуждаем :-/

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

Бакенд-плагины это про хранение настроек графаны?

Работать с ошибкой хуже чем не работать вообще

Спорный тезис, но связи с аптаймом не уловил

тем что их поддержка уже есть

Ну, такое есть(

Спорный тезис, но связи с аптаймом не уловил

Спорный твой изначальный

обоснуйте тезис

Ну какбэ очевидно, даже не знаю что тут обосновывать.

Спорный твой изначальный

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

Ну какбэ очевидно, даже не знаю что тут обосновывать.

аптайм сервиса 99.99%, аптайм мониторинга 99.9%. посчитайте вероятность появления алерта в случае отказа системы.

аптайм сервиса 99.99%, аптайм мониторинга 99.9%. посчитайте вероятность появления алерта в случае отказа системы.

Посчитайте вероятность проеба алерта из за отказа мониторинга и диаметр задницы админа после постмортема.

Посчитайте вероятность проеба алерта из за отказа мониторинга и диаметр задницы админа после постмортема.

и вы посчитайте. а потом посчитайте для других чисел.

Посчитайте вероятность проеба алерта из за отказа мониторинга и диаметр задницы админа после постмортема.

а у вас после постмортема задницы расширяют? ну вы и говноконтора.

Откуда вы такие аптаймы берете?)

У нас нет ?

Нормальный аптайм

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

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

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

если человеку очевидно, а нам нет, значит он умный а мы тупые, очевидно же.

деповсы на охране баблопотока!

деповсы на охране баблопотока!

Только те, которые знают про лес

деповсы на охране баблопотока!

ну так-то рабочий механизм.

Нормальный аптайм

Эм... Нет. У меня вот аптайм системы мониторинга пока 100% за 3-4 месяца и все, что я делаю - это ее не трогаю. Вы не путаете аптайм и sla?

ERROR: S client not available

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

Ты не надёжность оценивал, а 'важность' как я понял. Вообще говоря непонятно ни что ты говорил, ни что говоришь сейчас, кроме мокрой воды

Эм... Нет. У меня вот аптайм системы мониторинга пока 100% за 3-4 месяца и все, что я делаю - это ее не трогаю. Вы не путаете аптайм и sla?

Я - не путаю.

Кто будет мониторить систему мониторинга...?

Система мониторинга мониторинга очевидно же

И должна ли быть система мониторинга мониторинга быть более надежной чем сама система мониторинга ?

консенсус мониторнгов вас спасет

Я так понимаю что под "не менее надежной" ты имел ввиду что-то типа "нельзя мониторить что-либо не имея ha для системы мониторинга"

Я так понимаю что под "не менее надежной" ты имел ввиду что-то типа "нельзя мониторить что-либо не имея ha для системы мониторинга"

Ну HA для бизнеса как правило уже есть.

Поскольку работоспособность мониторинга не влияет на работоспособность системы, которую он мониторит, то сравнивать их аптаймы обсолютно бессмыссленно. Это, как надеяться, что после десяти красных подряд - 100% выпадет черное.

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

С надежностью мониторинга другая ситуация: вот есть 3 датацентра и мониторинг работает только в одном из них. Упал мониторинг вместе с дц — о проблеме оперативно узнать неоткуда, даунтайм вырастает на порядки. И нафига такой мониторинг, который не работает?

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

С надежностью мониторинга другая ситуация: вот есть 3 датацентра и мониторинг работает только в одном из них. Упал мониторинг вместе с дц — о проблеме оперативно узнать неоткуда, даунтайм вырастает на порядки. И нафига такой мониторинг, который не работает?

не надо мониторить ДЦ. Мониторить надо доступность сервиса и его capacity. мониторинг мониторинга должен быть реальзован следуя этому же принципу

не надо мониторить ДЦ. Мониторить надо доступность сервиса и его capacity. мониторинг мониторинга должен быть реальзован следуя этому же принципу

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

а если мониторинг неотказоустойчивый, то не будет ни мониторинга дц, ни мониторинга сервисов.

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

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

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

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

мониторинг тоже надо мониторить, очевидно, что у мониторинга и мониторинга мониторинга есть понятие capacity И service availability

мониторинг это такой же сервис

и относиться к нему надо соответственно

@azhiltsov "мониторинг мониторинга" - звучит, конечно, красиво, но как он реализуется на практике?

отдельная система? мониторинг самого себя?

это каждый сам решает. Можно держать два независимых инстанса и перекрестно мониторитью Можно собирать метрики о сервисах графитом а сам графит мониторить прометеем

а прометея графитом

это каждый сам решает. Можно держать два независимых инстанса и перекрестно мониторитью Можно собирать метрики о сервисах графитом а сам графит мониторить прометеем

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

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

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

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

магической "Пули" нет, каждый решает сам что и как мониторить

Ты не надёжность оценивал, а 'важность' как я понял. Вообще говоря непонятно ни что ты говорил, ни что говоришь сейчас, кроме мокрой воды

Вода бывает сухой когда сильно заморожена