Все время было интересно почему чаты держать пользователя за дебила, и дают копировать только сообщение целиком? Просто дайте ему возможность выделить текст самому, как в браузере, и не надо никакого хипста ML и прочих перделок
Поэтому Thanos рекомендует уменьшать время хранения данныех (data retention) в локальном storage до 6-8 часов, чтобы снизить этот overhead большого количества мелких блоков.
Thanos Sidecar в этот момент заметит это, сообщит об ошибке, может свалиться и после этого перестать работать.
Store Gateway может отдавать неконсистентные данные из-за race'ов между Compactor'ом и Sidecar'ами.
Все компоненты Thanos сложно поместить в один Kubernetes кластер, в отличие от кластерных компонент VictoriaMetrics.
В отличие от Thanos, VictoriaMetrics редко теряет данные.
Очень жалко выглядит когда в рекламной статье пишут голословно про проблемы конкурента. Приводите ссылки на issue или не упоминайте вообще.
Часто кластер Thanos неправильно работал, неправильно подключались к нему ноды из-за gossip протокола. Поэтому решили его оттуда убрать. Я считаю, что это правильное решение.
Это было минорное изменение версии 0.5, которое было запланировано за несколько версий до. Т.к к тому времени большинство уже пользовалось sd_file и sd_dns.
VictoriaMetrics в отличие от Thanos, масштабируется как вертикально так и горизонтально.
Лишь показывает что вы не представляете как масштабировать Thanos. Зачем тогда упоминать его? Там кстати и шардировать можно.
Это Thanos Compact, который занимается слиянием мелких файлов
Эти файлы, если их не сливать в более крупные файлы, то их количество может вырастить очень существенно.
Вы видимо не понимаете что именно делает thanos-compact. Компакшн файлов — это лишь малая часть, основная часть — это downsampling. Создаются усреднения для ренджей 5m и 1h, где каждая точка по сути содержит 5 значений (min, max, sum, count, avg) чтобы все функции продолжали работать на усредненных данных корректно. Далее когда вы делаете query за большой диапазон времени (например за месяц, год) thanos-store использует эти посчитанные данные. Т.е. raw данные не используются, даже если они у вас есть за годы назад. И основная отличительная черта Thanos — что можно настроить retention и хранить raw только за последние 2 недели, а 1h — бесконечно, что очень дешево на S3-IA.
Перед тем, как начать работать с Thanos, нужно создать storage bucket в Object Storage, такой как S3 или GCS, чтобы Thanos sidecar мог туда записывать данные.
Если мы говорим про легкость сетапа — S3 вовсе не обязателен для начала работы с Thanos и получения global-view из нескольких прометеев.
Нам не нужно держать подключение от VictoriaMetrics ко всем Prometheus'ам, потому что Prometheus'ы сами подключаются к VictoriaMetrics и передают данные.
Большинство минусов которые вы описываете не относятся к сравнению Thanos или VictoriaMetrics, a являются сравнением схем remote-write и thanos-sidecar. При этом Thanos так же поддерживает remote-write Т.е. он может так же стоять в центре и получать данные, как и VictoriaMetrics и m3db.
Но его отличительная черта, что он так же позволяет локализовать данные и не посылать их в единое место. И все равно иметь global-view и long term storage при этом. Представьте ситуцию когда у вас несколько регионов в AWS. Вы можете в каждом регионе иметь свой prometheus который пишет данные в локальный S3. Вы приходите из центральной графаны за мизерным обьемом тех точек графиков на которые вы смотрите (ответы на PromQL запросы), а основные гигабайты остаются лежать локально. А в случае remote-write вы бы все время передавали эти гигабайты со всех регионов, без разницы смотрит на них кто-либо или нет, и платили за траффик.
Если записывать реальные данные, то пользователи говорят о 2-5 кратном уменьшение размера данных на диске по сравнению с Prometheus и Thanos.
Очевидно вы пытаетесь сказать про "уменьшение размера данных" не принимая в расчет downsampling с retention, который ваш продукт не умеет в отличии от Thanos и m3db.
В отличие от Thanos, исходный код VictoriaMetrics написан с нуля и оптимизирован по скорости и потребляемым ресурсам.
https://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."
"This shows that Prometheus is faster in all cases, by ~2.0-4.4x."
Adidas внедряет VictoriaMetrics и даже сделал доклад на последнем PromCon 2019
Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal). Для сравнения в Thanos всегда можно перегенировать 5m,1h опять по raw данным. m3db поддерживает rebalance.
К сожалению доклад выполнен в худших маркетинговых традициях, которые в технической среде сразу приводят к нелюбви к продукту. Даже удивительно, что он сделан СТО.
Я предложил бы вам больше рассказывать про детали своего продукта, а не хаять конкурента опыта с которым вы не имеете.
Спасибо за ваш коментарий — это в каком-то виде поддержка.
Не собирался делать статью пессимистичной, это наверно отпечаток настоящей нашей проблемы — масштабируемость бд.
И здесь прометеусы и графиты предлагают архитектурно лучшее решение. (Которое так же сводит на нет и проблему даунскейлинга — он происходит при записи, как в rrd).
Для заббикса известно было только об одной попытке перехода на MongoDB в Ring Central и это не было реализовано. Теперь они используют грфит рядом с заббиксом, что говорит о многом.
Возможно заббикс — действительно просто не наш инструмент.
По поводу КДПВ — действительно я искал, но не смог найти, скриншот просмотра графиков для версии 1.4 (с которой я начинал). С тех пор этот экран не изменился.
Вы уж определитесь, вы хотите sysv инит-скрипт или systemd юнит ;)
В том виде, в котором вы написали, запускаться будет php-7.0.4-fpm.service и в /etc/init.d/php-7.0.4-fpm нет смысла.
А так же неоднократно говорилось что не надо трогать грязными руками файлы в /lib/systemd/ — это место хранения вендор конфигов.
Свои надо создавать в /etc/systemd/system где они будут иметь больший приоритет и оверрайдить вендор-дефоулт
Нашел эту отличную статью поиском. Для таких же как я, хотел оставить коммент:
В c# System.Data.Sqlite уже включена поддержка unicode.
При складывании русского текста в utf8 в FTS — регистронезависимый поиск работает.
Не надо городить костыли с записью lower(text) в FTS.
>Sony PRS-T3 будет оснащена HD дисплеем и защитной обложкой.
>Разрешение увеличилось: 1024x768. Подобное разрешение улучшает чёткость не только текста, но и картинок.
Так HD или XGA?) Kobo aura HD: 1440 x 1080 c подсветкой за €139,67 (без НДС для России)
Mele A2000G на стареньком А10 имеет SATA и выдает через USB-сетевуху 80мегабит по самбе. (Встроенная сетевуха к сожалению работает, но при дуплексной нагрузке аплоад падает до 800кбс.)
Вот тот вариант WinRM, который надо было делать изначально www.powershellinside.com/powershell/ssh/
То что сейчас выпущено Microsoft — это издевательство. Как можно называть «это» удаленной ком-строкой, если там даже пайп не работает?
Альтернативное бесплатное решение проблемы автора, даже influx и grafana хостить не надо
https://grafana.com/blog/2021/01/26/how-to-connect-and-monitor-your-raspberry-pi-with-grafana-cloud/
Теперь есть официальный контейнер который делает это: https://blog.jetbrains.com/idea/2021/02/early-access-program-for-qodana-a-new-product-that-brings-the-smarts-of-jetbrains-ides-into-your-ci-pipeline/
Можно больше не комитить "кучу IDE-specific файлов", зависимости из gradle/maven будут установлены автоматически.
Все время было интересно почему чаты держать пользователя за дебила, и дают копировать только сообщение целиком? Просто дайте ему возможность выделить текст самому, как в браузере, и не надо никакого хипста ML и прочих перделок
Очень жалко выглядит когда в рекламной статье пишут голословно про проблемы конкурента. Приводите ссылки на issue или не упоминайте вообще.
Это было минорное изменение версии 0.5, которое было запланировано за несколько версий до. Т.к к тому времени большинство уже пользовалось sd_file и sd_dns.
Лишь показывает что вы не представляете как масштабировать Thanos. Зачем тогда упоминать его? Там кстати и шардировать можно.
Вы видимо не понимаете что именно делает thanos-compact. Компакшн файлов — это лишь малая часть, основная часть — это downsampling. Создаются усреднения для ренджей 5m и 1h, где каждая точка по сути содержит 5 значений (min, max, sum, count, avg) чтобы все функции продолжали работать на усредненных данных корректно. Далее когда вы делаете query за большой диапазон времени (например за месяц, год) thanos-store использует эти посчитанные данные. Т.е. raw данные не используются, даже если они у вас есть за годы назад. И основная отличительная черта Thanos — что можно настроить retention и хранить raw только за последние 2 недели, а 1h — бесконечно, что очень дешево на S3-IA.
Если мы говорим про легкость сетапа — S3 вовсе не обязателен для начала работы с Thanos и получения global-view из нескольких прометеев.
Большинство минусов которые вы описываете не относятся к сравнению 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.
https://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."
"This shows that Prometheus is faster in all cases, by ~2.0-4.4x."
Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal). Для сравнения в Thanos всегда можно перегенировать 5m,1h опять по raw данным. m3db поддерживает rebalance.
К сожалению доклад выполнен в худших маркетинговых традициях, которые в технической среде сразу приводят к нелюбви к продукту. Даже удивительно, что он сделан СТО.
Я предложил бы вам больше рассказывать про детали своего продукта, а не хаять конкурента опыта с которым вы не имеете.
Не у всех с ним отрицательный опыт, задачи бывают разные.
https://en.m.wikipedia.org/wiki/Artemis_(novel)
Такой кабель до добра не доводит)
Не собирался делать статью пессимистичной, это наверно отпечаток настоящей нашей проблемы — масштабируемость бд.
И здесь прометеусы и графиты предлагают архитектурно лучшее решение. (Которое так же сводит на нет и проблему даунскейлинга — он происходит при записи, как в rrd).
Для заббикса известно было только об одной попытке перехода на MongoDB в Ring Central и это не было реализовано. Теперь они используют грфит рядом с заббиксом, что говорит о многом.
Возможно заббикс — действительно просто не наш инструмент.
По поводу КДПВ — действительно я искал, но не смог найти, скриншот просмотра графиков для версии 1.4 (с которой я начинал). С тех пор этот экран не изменился.
Вы уж определитесь, вы хотите sysv инит-скрипт или systemd юнит ;)
В том виде, в котором вы написали, запускаться будет php-7.0.4-fpm.service и в /etc/init.d/php-7.0.4-fpm нет смысла.
А так же неоднократно говорилось что не надо трогать грязными руками файлы в /lib/systemd/ — это место хранения вендор конфигов.
Свои надо создавать в /etc/systemd/system где они будут иметь больший приоритет и оверрайдить вендор-дефоулт
В c# System.Data.Sqlite уже включена поддержка unicode.
При складывании русского текста в utf8 в FTS — регистронезависимый поиск работает.
Не надо городить костыли с записью lower(text) в FTS.
>Разрешение увеличилось: 1024x768. Подобное разрешение улучшает чёткость не только текста, но и картинок.
Так HD или XGA?)
Kobo aura HD: 1440 x 1080 c подсветкой за €139,67 (без НДС для России)
Starting today, you'll get to experience the next big step for Gmail, Introducing Gmail Blue
www.powershellinside.com/powershell/ssh/
То что сейчас выпущено Microsoft — это издевательство. Как можно называть «это» удаленной ком-строкой, если там даже пайп не работает?
www.gbridge.com/
судя по wiki их конкурентов: