• Выбираем хранилище данных для Prometheus: Thanos vs VictoriaMetrics
    +3
    Очень жалко выглядит когда в рекламной статье пишут голословно про проблемы конкурента. Приводите ссылки на issue или не упоминайте вообще.

    Не скажу, что это выглядит «жалко», скорее «агрессивно». Все-таки это статья о сравнении двух подходов. Но считаю правильным приводит такие ссылки на issue и надеюсь автор это сделает. Во всяком случае, другие его статьи всегда аргументированны и подкреплены фактами — medium.com/@valyala

    Лишь показывает что вы не представляете как масштабировать Thanos. Зачем тогда упоминать его? Там кстати и шардировать можно.

    Ну насколько я знаю, у thanos все-таки есть проблемы с шардированием, как ни странно, индекса. Посмотрите, например, на статы gitlab — gitlab.com/gitlab-com/gl-infra/infrastructure/issues/8685#note_261760187. Здесь индекс для «db» занимает 2TB и, как я понимаю, thanos-store потребует именно такой обьем ОЗУ на машине чтобы запуститься. Поправьте, если я ошибаюсь.

    Вы видимо не понимаете что именно делает thanos-compact. Компакшн файлов — это лишь малая часть, основная часть — это downsampling. Создаются усреднения для ренджей 5m и 1h, где каждая точка по сути содержит 5 значений (min, max, sum, count, avg) чтобы все функции продолжали работать на усредненных данных корректно. Далее когда вы делаете query за большой диапазон времени (например за месяц, год) thanos-store использует эти посчитанные данные. Т.е. raw данные не используются, даже если они у вас есть за годы назад. И основная отличительная черта Thanos — что можно настроить retention и хранить raw только за последние 2 недели, а 1h — бесконечно, что очень дешево на S3-IA.

    Даунсемлпинг не такая простая вещь, чтобы ее просто «включить». Для читателей предлагаю ознакомиться с github.com/thanos-io/thanos/issues/813.
    Если мы говорим о даунсемплинге счетчиков (метрик, которые только увеличиваются), то сокращения разрешения до 1ч еще может быть валидным. Но представьте что произойдет с информативностью метрики использованию CPU, если сохраниться только одна точка в 1ч — она просто станет бессмысленной. К примеру, у gitlab только 6% метрик даунсемплированы. Я признаю, что даунсемплинг это хорошая вещь, но только нужно четко понимать как ее использовать.

    Если мы говорим про легкость сетапа — S3 вовсе не обязателен для начала работы с Thanos и получения global-view из нескольких прометеев.

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

    Большинство минусов которые вы описываете не относятся к сравнению Thanos или VictoriaMetrics, a являются сравнением схем remote-write и thanos-sidecar. При этом Thanos так же поддерживает remote-write Т.е. он может так же стоять в центре и получать данные, как и VictoriaMetrics и m3db.
    Но его отличительная черта, что он так же позволяет локализовать данные и не посылать их в единое место. И все равно иметь global-view и long term storage при этом. Представьте ситуцию когда у вас несколько регионов в AWS. Вы можете в каждом регионе иметь свой prometheus который пишет данные в локальный S3. Вы приходите из центральной графаны за мизерным обьемом тех точек графиков на которые вы смотрите (ответы на PromQL запросы), а основные гигабайты остаются лежать локально. А в случае remote-write вы бы все время передавали эти гигабайты со всех регионов, без разницы смотрит на них кто-либо или нет, и платили за траффик.

    Валидное замечание, на мой взгляд. Это определнно нужно учитывать!

    Очевидно вы пытаетесь сказать про «уменьшение размера данных» не принимая в расчет downsampling с retention, который ваш продукт не умеет в отличии от Thanos и m3db.

    Я бы тоже не принимал в расчет downsampling, т.к. он не помогает уменьшить размер данных на диске — thanos.io/components/compact.md/#downsampling-resolution-and-retention. Хорошее сжатие же помогает не только сэкономить место, но и позволяет многократно увеличить производительность системы, т.к. чем меньше данные занимают места, тем меньше времени система проведет считывая их с диска.

    www.robustperception.io/evaluating-performance-and-correctness
    «Prometheus server's compression (which both Cortex and Thanos use) is slightly better by about 10% than VictoriaMetrics and that in addition VictoriaMetrics was not storing all the information that Prometheus does.»

    Я в курсе данной статьи. Для интересующихся темой очень рекомендую прочесть и ответ на нее — medium.com/@valyala/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87. Здесь очень важно услышать обе стороны, а еще лучше — проверить и посмотреть все самому.

    «This shows that Prometheus is faster in all cases, by ~2.0-4.4x.»

    К сожалению, автор приведенной вами статьи не приводит исходный код бенчмарка, на основе которого он получил результаты. Бенчмарк же взятый из исходников прометеуса показывает, что VM быстрее — github.com/VictoriaMetrics/VictoriaMetrics/commit/b6f22a62cb385db5eb149789c42aaddd246a6750

    Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal). 

    Хм, я не услышал ничего про «потерей данных при rolling-reboot» в том докладе. Пожалуйста уточните, что именно имеется в виду или сбросьте линк на ту часть доклада, где об этом говориться.
    Решардинга действительно нет, но я и не считаю, что он настолько важен для VM. Пример КХ показывает, что система может быть крайне жизнеспособной и производительной и без этой фичи.

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

    Тут согласен! Считаю, что подобные статьи должны быть больше сконцентрированы на технических аспектах, это не соревнование.

  • Собираем логи из Nginx с помощью nginx-clickhouse, отправляем в Clickhouse и отображаем в Grafana
    0
    Насколько я помню, плагин table в Grafana загружает все строки и только потом делает по ним пагинацию. Т.е. это пагинация на стороне фронт-энда. Если у вас будет значимое кол-во логов в базе — таблица может «подвесить» бразуер.
  • Долгосрочное хранение метрик Prometheus (Алексей Палажченко, Percona)
    0
    На каком этапе сейчас находится PromHouse? На гитхабе не заметно активности последние 3 месяца.
  • Представляем loghouse — Open Source-систему для работы с логами в Kubernetes
    0
    Визуализировать в Grafana можно.
    На графиках удобно отслеживать интенсивность получения логов от приложений.
    А вот табличная форма отображения требует доработок, т.к. встроеный плагин `table` расчитан на небольшие обьемы данных. Поэтому мы используем свой плагин таблиц, который умеет в пагинацию(отправку запросов в КХ с LIMIT N, M), кеширование ответов, визуализацию JSON в виде раскрывающегося дерева.
  • Как запустить ClickHouse своими силами и выиграть джекпот
    0
    Вы можете найти что-нибудь подходящее здесь:
    clickhouse-datasource
    dashboards
  • Небольшое сравнение производительности СУБД «MongoDB vs ClickHouse»
    +4
    Не указано как именно осуществлялась вставка. В документации CH указано, что оптимальным считается вставка батчами по 100к записей.
  • Автоматизация нагрузочного тестирования: связка Jmeter + TeamCity + Grafana
    0
    Prometheus представляет собой time-series database. Нет никакой надобности писать в influxdb — Grafana прекрасно работает с Prometheus.

    Но Вы правы, для Prometheus понадобится и сервер и агент (экспортер). Хотя и в Вашем случае понадобиться telegraf и influxdb
  • Monitoring driven эксплуатация
    0
    Думаю, стоит упомянуть так же anomaly detection. Штука весьма полезная и часто может подсказать вам о проблеме. В качестве примера можно привести алерт, который будет сравнивать частоту чтений из postgres. Если частота чтений в течении 5 минут меньше на 60% чем усредненное за последний час — это явный признак того, что с базой что-то случилось и ей пора уделить внимание.
  • Prometheus — практическое использование
    0
    Статью о Prometheus без упоминания об интеграции с Grafana и правда тяжело найти, но эта статья как раз из таких. Я много читал о Grafana, но до сих пор не возникало надобности в её использовании — все задачи отлично решались с помощью консолей.