вот такая хрень выходит

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

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

Мне так помнится, что идеологически там counter

И совет авторов делать всегда counter

Даже для response time

И на этапе построения графиков уже делать rate

типа того? c.inc(1.6) , c.inc(0.111)

Если что я Прометей не юзал, но общался с одним из разработчиков

Как раз по этому поводу

хотя rate не даст точных значений же ( будет пересчитано все к интервалу [1m]

который ты укажешь

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

хотя rate не даст точных значений же ( будет пересчитано все к интервалу [1m]

Ну как бы да. Но если ты данные собираешь раз в минуту то что еще ты ждешь?

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

Ну как бы да. Но если ты данные собираешь раз в минуту то что еще ты ждешь?

не, раз в секунду в прометее настроено

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

похоже на то

не, раз в секунду в прометее настроено

Ну значит и рейт будет не по минутам

А по секундам. Не?

не, там рейту секунду не поставить

похоже на то

либо в лог писать и ЕЛК юзать

не, там рейту секунду не поставить

Попробуй с авторами связаться. Они отзывчивые

Попробуй с авторами связаться. Они отзывчивые

ок, попробую, только надо правильно суть изложить на англ(

Я уверен что то что ты хочешь - делается

либо в лог писать и ЕЛК юзать

Елк довольно медленный

Я уверен что то что ты хочешь - делается

вполне может быть, да

Уважаемые доны

подскажите куда копать в сторону аналитики мониторинга?

поиск флуктуаций, корреляций и т.д.

может есть что-то что можно подключить к ELK или что-то независимое

кто-то занимался таким?

Уважаемые доны

боюсь я сейчас этим частично занят, точнее схему этого делаю

подскажите куда копать в сторону аналитики мониторинга?

Мониторинг это про статусы. Метрики про числа. Вам что?

А вообще, мат статистика и вперед

Можно рассмотреть язык R, как инструмент. Хотя, Python и numpy, scipy тоже ок

icinga+ elasticsearch+ Kibana+graphite+grafana+ Fluentd+system nspawn+PostgreSQL как такая связка под мониторинг?

что она упустит

В такой формулировке, упустит всё

Инструмент неважен, пока не сформулирована задача

Что мы имеем, 4 дата центра, предположим 2 дц имеет 400 железных серверов и 60 свитчей по 36 портов для линейной схемы подключения 350 серверов там сделаны под приложения, ещё 50 под хранения информации, управление vm, сетью и частично сторенджами, в нашем случае с glusterfs происходит через openstack, ещё 2 дц 40 серверов и 6 свитчей, 35 под приложения и 5 под данные. Между дц сделано 3 канала связи, с разными провайдерами.

основной софт

Что мы имеем, 4 дата центра, предположим 2 дц имеет 400 железных серверов и 60 свитчей по 36 портов для линейной схемы подключения 350 серверов там сделаны под приложения, ещё 50 под хранения информации, управление vm, сетью и частично сторенджами, в нашем случае с glusterfs происходит через openstack, ещё 2 дц 40 серверов и 6 свитчей, 35 под приложения и 5 под данные. Между дц сделано 3 канала связи, с разными провайдерами.

Я не хочу решать за кого-то его задачи, честно говоря

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

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

Метрики, метрики, не статистику

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

И я не вижу Prometheus в связке

Я не хочу решать за кого-то его задачи, честно говоря

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

ну статику тоже, например у новы кол-во инсталяйций

ну статику тоже, например у новы кол-во инсталяйций

И это может быстро вырасти, я количестве

ну статику тоже, например у новы кол-во инсталяйций

Количество - не статистическая величина

Количество - не статистическая величина

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

Начни с малого, научись собирать метрики в одно место, например, в Prometheus. Потом, начни отображать, например, в Grafana

я недавно делал связку icinga(nagios)+graphite+grafana

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

Среднее может уже и статистика

я недавно делал связку icinga(nagios)+graphite+grafana

Icinga пуш же

Смотри в Prometheus:) Icinga выше транспортного уровня большого смысла не имеет

Да и то node exporter решает почти всё, что она может

а прометеус же не умеет хранить данные в дб другой, чтобы потом графики делать за месяц, 3, 6 12 24

а прометеус же не умеет хранить данные в дб другой, чтобы потом графики делать за месяц, 3, 6 12 24

Grafana

У неё из коробки поддержка прома, как источника данных

Прома пусть собирает, от него не надо больше ничего почти. Ну, алертинг можно ещё его использовать, но можно и другой намутить

Мониторинг это про статусы. Метрики про числа. Вам что?

Анализ и первого и второго, поиск корреляций между этим

Анализ не ручками

ERROR: S client not available

В ручном режиме не продуктивно

☹️ блин не врубаюсь, как из 5 прометев получиться статистика для 1 веб интерфейса графана

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

☹️ блин не врубаюсь, как из 5 прометев получиться статистика для 1 веб интерфейса графана

Балансер поверх

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

Время гуляет?

по-хорошему счетчики нужно нормировать на разброс времени

Балансер поверх

Какой балансер? Разберись сначала

☹️ блин не врубаюсь, как из 5 прометев получиться статистика для 1 веб интерфейса графана

Они все разное собирают?

Они все разное собирают?

они должны будут мониторить 4 дата центра, собирают одно и тоже, но сделано так, для надёжности

чтобы если по каким либо причинам 1-2 умерли. другие продолжали давать данные

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

они должны будут мониторить 4 дата центра, собирают одно и тоже, но сделано так, для надёжности

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

А вот оттуда уже да, haproxy на них и всё

Какой балансер? Разберись сначала

ты сам хапрокси ему предложил, такой и балансер

? 20 тб логов, в больших 2 дц и 2 тб логов в мелких, и ещё по реплике

ты сам хапрокси ему предложил, такой и балансер

Ну разобрались потому что

Ну разобрались потому что

ну ок, просто не надо высказывать претензии прежде чем в вопрос вникнешь, ок?

ну ок, просто не надо высказывать претензии прежде чем в вопрос вникнешь, ок?

Себе скажи про ответы на вопросы тоже самое

160 тб логов при репликах, это ебануться

Себе скажи про ответы на вопросы тоже самое

Угу, мистер "Какой нафиг балансер, разберись сначала, а ваще возьми хапрокси"

Угу, мистер "Какой нафиг балансер, разберись сначала, а ваще возьми хапрокси"

Разобрались и взяли

вы мне лучше скажите, 160 тб логов, это это 27 дисков по 6 тб, и это только минимальное кол-во их

особенно всопминая сколько срёт nginx php

вы мне лучше скажите, 160 тб логов, это это 27 дисков по 6 тб, и это только минимальное кол-во их

Ты метрики или логи собираешь?

Ты метрики или логи собираешь?

у меня связка prometheus+ elasticsearch+ Kibana+ graphite+grafana+ Fluentd+Docker +PostgreSQL+centos/rhel

у меня связка prometheus+ elasticsearch+ Kibana+ graphite+grafana+ Fluentd+Docker +PostgreSQL+centos/rhel

Не ответ

и то и то

Ок

Не собирай логи

логи нужны для разбора ошибок