стандартное однотипное оборудование

вообще идеально для обнов

то же с мониторингом

Стандартное, это огонь

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

многие кластеры с сети бутятся

ноды

вообще идеально для обнов

Казалось бы. Но по факту - это боль :) все друг от друга по кругу зависит, часто - глючит и медленнее чем было до обновления

хз. кароче что-то не то у вас

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

тестировать. задуматься о необходимости обнов в принципе

Ага. Или all_reduce в imb начале падать с 64 годами. И ебемся пару месяцев

Тестировать. Угу. На одной-двух нодах может работать а на 100 - уже нет

@BaikodromKosmodur я немного растерян. вы говорите что если бы кластер был один он был бы весь заскриптован и замониторен. но в чем рахзница между серийными кластерами и одним ?

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

Разные вендора железа, разный софт, не говоря уж про версии этого софта

тоесть кластер не серийный.

вы штампуете не свое по а апк

и это представляет некоторую сложность. так ?

btw https://github.com/HewlettPackard/lustre_exporter

Да, железо может быть какое угодно. Наша маржа на валидации, установке и конфигурировании

но от системы мониторинга вы хотите мониторинга любого железа на которое ваш софт встанет.

не логично ли разделить процессы мониторинга на софт/железо. ?

Именно. Желательно автоматизировано, что бы не забыть от мониторить какую-нибудь редкую железку

но заказчику вы на тему мониторинга железа не доверяете конечно

поэтому хотите чт бы мониторинг умел в оба

не логично ли разделить процессы мониторинга на софт/железо. ?

Я об этом думал выше. Смущает несколько агентов на нодах

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

я не решаю задачу мониторинга железа никак.

и не считаю железо частью системы.

но увас я там слышал слова типа rdma и такое. у вас очевидно так низя ага.

но заказчику вы на тему мониторинга железа не доверяете конечно

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

заказчик имеет рута на серверах ?

Да

вы говорите какие параметры железа для вас критичны ?

Фактически мы узкоспециализированный интегратор

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

вы говорите какие параметры железа для вас критичны ?

Нет. Определяем сами "на глаз". Но хотим от этого отойти - установить что-то что задисклверит что есть и настроит базу

2 мониторинга - инфра и аппоикейшен

а у вас есть параметры железа которые влияют на систему ?

Нет. Определяем сами "на глаз". Но хотим от этого отойти - установить что-то что задисклверит что есть и настроит базу

вам бы стандартизироваться

и абстрагироваться от железа

чот я тоже думаю что надо два или полтора мониторинга.

вам бы стандартизироваться

Я ж только "за". Но это несбыточная мечта :(

стандартизироваться это долго и сложно

софт только требования выставляет и все

стандартизироваться это долго и сложно

нет. если говно не брать

глубина хранения мониторинговых данных большая ?

нет. если говно не брать

А у нас говна много. Асус, делл, гигабайт, супермикро. Чем дешевле - тем лучше :)

эта понятно всё.

А у нас говна много. Асус, делл, гигабайт, супермикро. Чем дешевле - тем лучше :)

я понимаю. по сути в аналогичной ситуации

глубина хранения мониторинговых данных большая ?

Обсуждаемо. Но сейчас тренды храним год

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

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

мы да. просто опыт

я дмитрия спрашиваю

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

Нету такого - ставим все что подходит по цене.

хм. или железо не играет большой роли или ... ?

или вы недомониторили

Или говно и палки :)

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

Поэтому имеем что имеем

Я прошу прощения, я сливаюсь до вечера. На меня семья косо смотрит уже

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

То есть оно в дистрибутиве не собрано с этим плагином, как так?)

Эх... Года 3 как железо не трогаю. Облака, мать их. А тут такая романтика.

Эх... Года 3 как железо не трогаю. Облака, мать их. А тут такая романтика.

Выделенный сервер который никогда не видел можно считать "железо не трогаю"?

Ладно))) У меня был DC. Хорошо все работало, налаженые процессы замены итд) Все бутстрапилось само удаленно... Неплохая экономия если просто смотреть на железо-облако

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

ERROR: S client not available

То есть оно в дистрибутиве не собрано с этим плагином, как так?)

ни в одном из дистров не собрано

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

Меня вдохновляет надпись в клауде "вы можете сэкономить xxx*k$ если нажмёте кнопку " auto adjust nodes"

Которую никто не думает нажать

Ну да.

Все жестко зависит от размера конторы) Я считал как-то. там 4 фазы получились. Условно: 1. Стартап-инкубатор ("хз че делаем") 2. стартап-понятный "стока мощи надо, такая волатильность ресурсов", 3. стартап растущий (завтра может сильно шибануть , нужно будет 10x ресурсов) 4. энтерпрайз безконтрольный (нам надо любыми силами снизить непрофильные операционные расходы)

вот для 1,3,4 облако оказалось лучше. А для 2 дц

4 спорный момент, но все же облако.

это обсуждение все же больше в @ru_devops :)

@kireevco для 4 - очевидно, что айти - не профильные расходы :) Потому что если бизнес - it-based то свое железо в какой-то момент становится выгоднее. Ну либо ты становишься netflix'ом и фактически сжираешь половину ресурсов какого-нибудь крупного облака и поэтому можешь получить специальные условия.

Тока нетфликсов обычно один на облако)

Тока нетфликсов обычно один на облако)

И не на все регионы и со своим сдн который и молотит основной трафик

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

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

Это для алерт менеджера или копия prometheus.you-domain.com//alerts?

Это для алерт менеджера или копия prometheus.you-domain.com//alerts?

без разницы на самом деле, главное чтобы выглядело понятно в графане

Мне казалось, в графане можно просто отобразить веб страницу ...

Что-то типо такого: https://github.com/jether-energy/grafana-html-panel

Не очень удобно, конечно

А если именно что-то вроде панельки с зелеными/красными квадратиками, то вроде пока только свой экспортер писать.... Но может я и не прав.

Гдето было в инете такач пикча и подпись "понюхай руку"

Я прошу прощения, я сливаюсь до вечера. На меня семья косо смотрит уже

Интересная задача кстати. Я бы разделил ее на две: коллектор и бэкэнд. Если попытаться прикинуть на пальцах по бэкенду, то при постановке «мониторим все до чего дотянемся в операционке» с сервера можно снимать до 100k метрик (кейс нетдаты: https://github.com/firehol/netdata/issues/1323#issuecomment-265501668 там сервер конечно, о 144 ядрах поэтому случай немного предельный) если твои ноды будут давать раз в 10 меньше метрик и собирать их раз в 10 сек, то кластер из 500 таких нод даст поток в 500 километрик в секунду. Тут если оставаться в рамках одного сервера мониторинга наверное зайдет либо прометей либо кликхаус. Коллектор скорее всего придется обвешивать своими плагинами тк 100% подходящего под задачу думаю не существует, перспективно выглядит та же нетдата или телеграф, нужно выбирать кто удобнее. Еще пара моментов: 1. пуш или пулл и соответственно 2. как коллектор найдет бэкенд (или наоборот). Если нужно будет собирать метрики изнутри расчетных задач пуш выглядит правильнее (задачи живут не долго и каждый раз разные) но тут каждый «студент» должен будет кодить отправку метрик

С Новым годом от команды Айхор Хостинга!!!!

Сахалин услышал вас )

Спасибо за совет сделать все на основе typescript-template-datasource. На этот раз все получилось.

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

Интересная задача кстати. Я бы разделил ее на две: коллектор и бэкэнд. Если попытаться прикинуть на пальцах по бэкенду, то при постановке «мониторим все до чего дотянемся в операционке» с сервера можно снимать до 100k метрик (кейс нетдаты: https://github.com/firehol/netdata/issues/1323#issuecomment-265501668 там сервер конечно, о 144 ядрах поэтому случай немного предельный) если твои ноды будут давать раз в 10 меньше метрик и собирать их раз в 10 сек, то кластер из 500 таких нод даст поток в 500 километрик в секунду. Тут если оставаться в рамках одного сервера мониторинга наверное зайдет либо прометей либо кликхаус. Коллектор скорее всего придется обвешивать своими плагинами тк 100% подходящего под задачу думаю не существует, перспективно выглядит та же нетдата или телеграф, нужно выбирать кто удобнее. Еще пара моментов: 1. пуш или пулл и соответственно 2. как коллектор найдет бэкенд (или наоборот). Если нужно будет собирать метрики изнутри расчетных задач пуш выглядит правильнее (задачи живут не долго и каждый раз разные) но тут каждый «студент» должен будет кодить отправку метрик

Спасибо. Заставлять каждого студента кодить метрики - не вариант. Обсуждалось брать все что нужно с системы и "как-то обрабатывать". Для начала - память + проц + IB, Потом будем думать что делать с IO. Пран минимум - кому-нибудь внедрить и посмотреть что получилось.

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

templateSrv позволяет получить список переменных. Во встроенных data sources можно пример посмотреть.

templateSrv позволяет получить список переменных. Во встроенных data sources можно пример посмотреть.

Круто, спасибо!

templateSrv позволяет получить список переменных. Во встроенных data sources можно пример посмотреть.

А это как-то связано с функцией targetContainsTemplate(target) { return this.templateSrv.variableExists(target.expr); } которую реализуют многие плагины? Я так и не смог найти откуда она вызывается.