полторы калеки и один дивапс

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

в неделю

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

Хостед инфлакс берут с горем пополам

ну я видел даже живую контору которая продаёт консультации по timescaledb

конкурент для project thanos?

Может быть. С первого взгляда архитектура project thanos выглядит сложнее и менее логичной по сравнению с VictoriaMetrics. Хотя это может быть следствием предвзятого отношения :)

ну мы же не видим вашу архитектуру

Что за навязчивая вообще реклама?

Может быть. С первого взгляда архитектура project thanos выглядит сложнее и менее логичной по сравнению с VictoriaMetrics. Хотя это может быть следствием предвзятого отношения :)

Какая польза для сообщества и конкретно для этого чятика от вашего решения? Никакой.

это всё ещё очень малая часть работы по созданию приличного мониторинга на основе prometheus

так prometheus никуда не исчезает. Вы продолжаете пользоваться prometheus, просто не храните много данных локально, а отправляете их в remote_write.url , где прописан ваш Cloud-адрес для хранения данных в VictoriaMetrics. Решаются только специфичные проблемы вроде маленького retention'а, нехватки места на диске, необходимости делать бэкапы / реплики локальных данных прометеуса, возможности делать произвольные запросы поверх данных, собранных разными прометеусами

только write?

Read у прома не очень полезный, честно говоря

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

Неудачной попытки кого? Вас? Мы используем graphite+clickhouse, у нас есть теги, и мы умеем дружить с данными из промитеуса. Что касается места, то это вопрос легко решаемый шардированием, который в КХ отлично работает, по крайней мере у нас.

да, мы не смогли заточить ClickHouse для управления большим количеством time series с произвольными тэгами, как в прометеусе. Насчет места - вопрос решаемый, но это может оказаться очень дорого. Например, наши ежемесячные расходы на хранение аналитических данных ClickHouse выросли с $0 до нескольких десятков тысяч долларов в течение года, при условии, что мы хранили сырые данные только за последние три месяца. Вы предпочтете тратить $100к в месяц на хранение данных в кликхаус или предпочтете специализированное решение, которое жмет данные в 10 раз лучше, и сэкономить $90к в месяц?

я бы добавил тогда уж "магически жмет данные" так завораживающее

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

Есть планы на создание коробочного решения на основе kubernetes для разворачивания на популярных Cloud-хостерах. Но сначала мы сконцентрируемся на своем Cloud-решении.

да, мы не смогли заточить ClickHouse для управления большим количеством time series с произвольными тэгами, как в прометеусе. Насчет места - вопрос решаемый, но это может оказаться очень дорого. Например, наши ежемесячные расходы на хранение аналитических данных ClickHouse выросли с $0 до нескольких десятков тысяч долларов в течение года, при условии, что мы хранили сырые данные только за последние три месяца. Вы предпочтете тратить $100к в месяц на хранение данных в кликхаус или предпочтете специализированное решение, которое жмет данные в 10 раз лучше, и сэкономить $90к в месяц?

Ну чтож, можно поговорить и в таком ключе: Мы сжимаем данные в 1000 раз лучше чем вообще кто угодно, что вы предпочтёте, тратить на диск 90$ или 10центов? При этом данные читать будет не дёшего но про это потом ;)

да, мы не смогли заточить ClickHouse для управления большим количеством time series с произвольными тэгами, как в прометеусе. Насчет места - вопрос решаемый, но это может оказаться очень дорого. Например, наши ежемесячные расходы на хранение аналитических данных ClickHouse выросли с $0 до нескольких десятков тысяч долларов в течение года, при условии, что мы хранили сырые данные только за последние три месяца. Вы предпочтете тратить $100к в месяц на хранение данных в кликхаус или предпочтете специализированное решение, которое жмет данные в 10 раз лучше, и сэкономить $90к в месяц?

Что значит "сырые данные", вы их не прореживали что ли?

я бы добавил тогда уж "магически жмет данные" так завораживающее

ок, замените 10 раз на 2 раза и получите экономию всего в $50к в месяц :)

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

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

Какая польза для сообщества и конкретно для этого чятика от вашего решения? Никакой.

Я думал, что в этом чятике многие работают с prometheus, а мое решение позволяет решить некоторые проблемы prometheus

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

или скорее "неидеальностью"

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

сейчас есть поддержка remote read, но она, как верно подметил Евгений, не очень полезна, т.к. приходится гонять по сети весь набор сырых данных, необходимых для выполнения запроса. Если вы делаете запрос за год по тысяче time series с миллионами metric values в каждой, то придется гнать по сети миллард metric values :( Поэтому в будущем планируем добавить движок PromQL прямо в VictoriaMetrics, чтобы в графане достаточно было поменять адрес датасорса с прометеуса на VictoriaMetrics.

Ну чтож, можно поговорить и в таком ключе: Мы сжимаем данные в 1000 раз лучше чем вообще кто угодно, что вы предпочтёте, тратить на диск 90$ или 10центов? При этом данные читать будет не дёшего но про это потом ;)

согласен, сейчас скорость чтения данных у нас ниже, чем в кликхаусе - всего 30 миллионов metric values в секунду на одно ядро CPU. У кликхауса скорость выше на порядок. Планируем оптимизировать скорость чтения в будущем, если в этом будет затык.

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

хранение - очень-очень небольшая часть того, за что им платят

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

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

значит, вы не наш клиент :)

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

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

у него есть экспертиза по сбору метрик и алертингу

зачем вы ему?

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

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

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

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

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

либо этот сервис должен совсем дешёвым быть

@shefeg будет жить. Поприветствуем!

В графане есть настройка самого графика, параметр null values, значение connected (по умолчанию null). Вроде так навскидку.

@neumeiko будет жить. Поприветствуем!

зачем вы ему?

да ладно, тут как с любым решением - юзеры найдутся

иначе решения бы не существовало

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

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

может, подскажете более подходящий канал с пользователями prometheus ?

я пока не встречал людей которые бы сами ставили прометей но при этом не имели бы в нем экспертизы.

пром довольно замороченный и требует умения читать.

этим даром выши пользователи по идее не должны обладать

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

может, подскажете более подходящий канал с пользователями prometheus ?

я бы мб прошелся бы по devops_ru подобным каналам и в целом каналам для самых маленьких

спасибо, попробую :)

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

этим даром выши пользователи по идее не должны обладать

наоборот, мы ориентируемся на продвинутых пользователей prometheus, которые столкнулись с его ограничениями и желают их обойти. Ограничения вида: - нехватка места на диске для данных прометеуса - маленький retention - невозможность делать произвольные запросы поверх данных из нескольких прометеусов без использования федерации - плохая работа с большим количеством уникальных time series (aka high cardinality problem)

ясно. успехов.

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

про технические решения расскажу после бета-теста :) И опен-сорс решение тоже будет

господа, чот я запамятовал как второй метод построения дашиков называется. один USE а второй ?

Red

ERROR: S client not available

да точно

https://www.weave.works/blog/the-red-method-key-metrics-for-microservices-architecture/

И есть ещё four golden signals от гугла

И это не только про дашики. Это про какие метрики собирать и как дебажить

ага да

мне просто проще запомнить было именно в ключе посторояния графиков

почему то

@morhold будет жить. Поприветствуем!

я пока не встречал людей которые бы сами ставили прометей но при этом не имели бы в нем экспертизы.

Ну в этот чят регулярно приходят

@goffert будет жить. Поприветствуем!

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

В чем суть?

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

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

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

слишком дофига уже, пора агрегировать

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

По какому принципу?

FAN 8 вентиляторов

слишком дофига уже, пора агрегировать

Агрегировать надо в бд

FAN 8 вентиляторов

придумай как ты хочешь это агрегировать и выводи это средняя скорость наверняка не подойдёт

Народ, а никто не знает, существует ли в телеге бот, который умеет извне проверять доступность какого либо сайта, и если тот недоступен/пятисотит - бот начинает орать вЛичку/вПриватныйКанал

Похоже вот что-то подобное: http://telegram.org.ru/184-monitoring-dostupnosti-sayta.html

@Sumgan будет жить. Поприветствуем!

Народ, а никто не знает, существует ли в телеге бот, который умеет извне проверять доступность какого либо сайта, и если тот недоступен/пятисотит - бот начинает орать вЛичку/вПриватныйКанал

uptimerobot ?

uptimerobot ?

нашел 2-их - оба молчат, возможно они в отпуске

Народ, а никто не знает, существует ли в телеге бот, который умеет извне проверять доступность какого либо сайта, и если тот недоступен/пятисотит - бот начинает орать вЛичку/вПриватныйКанал

У ITSumm'ы такое бот за деньги делает :) но вообще несложно самому написать.

У ITSumm'ы такое бот за деньги делает :) но вообще несложно самому написать.

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

Народ, а никто не знает, существует ли в телеге бот, который умеет извне проверять доступность какого либо сайта, и если тот недоступен/пятисотит - бот начинает орать вЛичку/вПриватныйКанал

Uptimerobot.com создашь бота, кинешь его токен в настройки в личном кабинете.

Народ, а никто не знает, существует ли в телеге бот, который умеет извне проверять доступность какого либо сайта, и если тот недоступен/пятисотит - бот начинает орать вЛичку/вПриватныйКанал

https://blog.uptimerobot.com/new-feature-telegram-integration/

У меня через WebHook работает.