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

и тем не менее достаточно сложно учесть все чтобы оно жило вот именно так

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

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

А потом придет понимание, что мониторить мониторинг не достаточно и что надо еще мониторить алертинг этого мониторинга

и тем не менее достаточно сложно учесть все чтобы оно жило вот именно так

ну отказ одного любого ДЦ (если их, конечно, больше одного), имхо, все-таки стоит предусматривать.

угу, например недоступность внешнего сервиса отправки СМСок или тупняк оператора который отправляет СМСки )

ну отказ одного любого ДЦ (если их, конечно, больше одного), имхо, все-таки стоит предусматривать.

но например в чем преимущество отказоустойчивого мониторинга перед мониторингом каждого ДЦ как независимой сущности?

и например мониторинг доступности мониторинга соседних ДЦ

А потом придет понимание, что мониторить мониторинг не достаточно и что надо еще мониторить алертинг этого мониторинга

в нормальном режиме (отказ до 1 ДЦ) мониторинг должен быть отказоустойчивым и мониторить сам себя, а на случай глобальной катастрофы сделать внешний мониторинг, не связанный с основной инфраструктурой.

ну отказ одного любого ДЦ (если их, конечно, больше одного), имхо, все-таки стоит предусматривать.

отказ ДЦ это очень абстрактно. Если вы потеряли 50% емкости сервиса то вот это и надо мониторить. Сетевики будут мониторить полосу до ДЦ, девопсы емкость приложения, бизнес количество транзакций или доступность сервиса в регионе

но например в чем преимущество отказоустойчивого мониторинга перед мониторингом каждого ДЦ как независимой сущности?

тем, что не теряется доступ до сервисных метрик в сбойном дц.

отказ ДЦ это очень абстрактно. Если вы потеряли 50% емкости сервиса то вот это и надо мониторить. Сетевики будут мониторить полосу до ДЦ, девопсы емкость приложения, бизнес количество транзакций или доступность сервиса в регионе

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

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

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

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

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

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

а настройка мониторинга кросс-ДЦ всего существенного уже не выглядит сильно рациональнее отказоустойчивого мониторинга.

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

Механика расчета аптайма проста. Нет данных о мониторинге значит не работает.

тем, что не теряется доступ до сервисных метрик в сбойном дц.

Вопрос в том, стоит ли это существенного усложнения системы мониторинга?

cp -R grafan4 grafana5; sed -e s,4.6.2,5.0.0,g Makefile; make fetch; sha256 $DISTDIR/grafana*5*; vim distinfo; make stage; pkg-plist > pkg-plist; vim pkg-plist; make clean install

хм, пизжу, size лучше так вкорячить (cd $DISTDIR && wc -c grafana* | awk '/grafana/ {print "SIZE (" $2 ") = " $1}') >> distinfo

Это что щас БСД было?

до

А оно ещё живо?

еще не замейнтенили 5-ю графану, решил сам

ну смотри, есть у тебя хранилище с 40тб, и что с ним еще делать? пущай мониторит себе сервера

Ну хз, а если сторадж упадёт, то где графики для него смотреть?

ну как он упадет, по твоему? ?

там 15 дисков и качественное железо

Лол, не разу такого не было и вот опять =)

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

ну как он упадет, по твоему? ?

Опасное заблуждение ))

лишь бы руки прямые были

Нет. Упасть может вообще что угодно и когда угодно.

пусть попробует ?

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

ок, но это тема для другого чата уже.

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

Цепей Маркова на тебя не хватает, да и теорвера немного. Опыта бы тоже было неплохо, но это со временем придёт.

лишь бы не собаки Павлова ?

там 15 дисков и качественное железо

Ты zfs на фряхе юзаешь?

Еще бы

А какой общий объём стора и сколько RAM отдёшь zfs'у?

Позже скажу, я на пляже)

Да там 90+ оперативы.

Как вам такая идея - запускаем на каждом хосте свой инстанс TSDB и все метрики (host level) и контейнеры пишем туда, т.е. эдакий sidecar. Отдельный сервис федерирует все эти данные (индексирует метрики, хранящиеся в каждой локальной TSDB) и пробрасывает запросы к конкретным хостам, при необходимости. Для клиентов это все выглядит как одна большая TSDB.

Как вам такая идея - запускаем на каждом хосте свой инстанс TSDB и все метрики (host level) и контейнеры пишем туда, т.е. эдакий sidecar. Отдельный сервис федерирует все эти данные (индексирует метрики, хранящиеся в каждой локальной TSDB) и пробрасывает запросы к конкретным хостам, при необходимости. Для клиентов это все выглядит как одна большая TSDB.

почти кликхаус, только контейнеры ненужны

А почему в графане на дашбордах конпка "-" есть, а "+" нет?

Как вам такая идея - запускаем на каждом хосте свой инстанс TSDB и все метрики (host level) и контейнеры пишем туда, т.е. эдакий sidecar. Отдельный сервис федерирует все эти данные (индексирует метрики, хранящиеся в каждой локальной TSDB) и пробрасывает запросы к конкретным хостам, при необходимости. Для клиентов это все выглядит как одна большая TSDB.

метрики на хосте все же слишком печально

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

DC-wide еще спорно

а host-wide полезно

особенно для прогнозирования а не для мониторинга

но ты описал netdata :)

Как вам такая идея - запускаем на каждом хосте свой инстанс TSDB и все метрики (host level) и контейнеры пишем туда, т.е. эдакий sidecar. Отдельный сервис федерирует все эти данные (индексирует метрики, хранящиеся в каждой локальной TSDB) и пробрасывает запросы к конкретным хостам, при необходимости. Для клиентов это все выглядит как одна большая TSDB.

польза от tsdb на каждом хосте разве что в том, что в случае пропажи сети можно будет в будущем дососать недостающие точки и посмотреть, что на машине творилось в оффлайне, но это мало кому нужно

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

каждому хосту - по прометеусу!

каждому прометеусу - по федерейшну!

фабрики рабочим

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

why not?

скорее наоборот, в проме можно это себе позволить

ERROR: S client not available

а на хосте сложнее

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

можно же рестартануть, данные останутся, но неудобно конечно

может на хосте каждый процент диска и памяти на счету

можно же рестартануть, данные останутся, но неудобно конечно

а если это эфимерный контейнер без ФС?

рестартанул - вся история тю-тю

так что ее надо куда-то увозить еще

но юзкейс под локальный сторадж есть

покуда из него можно забрать данные дальше

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

примерно похожий подход у intel snap и у netdata

Как вам такая идея - запускаем на каждом хосте свой инстанс TSDB и все метрики (host level) и контейнеры пишем туда, т.е. эдакий sidecar. Отдельный сервис федерирует все эти данные (индексирует метрики, хранящиеся в каждой локальной TSDB) и пробрасывает запросы к конкретным хостам, при необходимости. Для клиентов это все выглядит как одна большая TSDB.

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

@SaveTheRbtz можно взять и броадкастить запросы :D

держи две прокси на vrrp

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

@SaveTheRbtz да я представляю )

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

Обычно в системе уже есть знания о хостах. Ну там hosts файл в ansible например. Но вот нормальную распределенную TSDB я пока не видел, либо piggyback на чем-нибудь вроде HBase, либо полу-ручные операции по масштабированию/шардингу, либо вообще нет.

тут как раз пофиг, запустили новый, переиндексировали и все (при условии что хосты известны)

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

тут как раз пофиг, запустили новый, переиндексировали и все (при условии что хосты известны)

Если хосты неизвестны то тебе в любом случае жопа

На прошлой работе наелись бардака

нормальный дискавери не проблема написать, взять Memberlist от Hashicorp, например

или просто взять puppet, который уже был

c puppetdb

А какой общий объём стора и сколько RAM отдёшь zfs'у?

NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank 43.2T 22.9T 20.3T - 19% 52% 1.00x ONLINE - Mem: 342M Active, 3258M Inact, 876K Laundry, 79G Wired, 107M Buf, 12G Free

Неплохой сторадж для домашнего офиса =)

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

Ну в современные серваки можно воткнуть в районе сотни дисков, PMR — в районе 10ТБ будет. SMR можно и 16+, соответственно на сервак 1-1.5ПБ, делать реально

Хм... А если я в prometheus в node_exporter делаю ключи —collector.xxxx, он всё остальное выбрасывает что ли?

Дальше вопрос, сколько нужно IOPS на сервак и сколько сети можно воткнуть

я там бекапы складирую, мне пох)