чисел в ВМ. Похоже, он не проходил теорию информации в универе и не знает, что рандомные числа не сжимаются :)
- потеря точности в младших десятичных цифрах, когда в числе более 12 значащих десятичных цифр. Это ожидаемое поведение из-за конвертации float64 чисел в decimal int + exponent. Мы это уже обсуждали тут. Это компромисс для лучшего сжатия данных. См. https://medium.com/faun/victoriametrics-achieving-better-compression-for-time-series-data-than-gorilla-317bc1f95932
- ВМ не сохраняет значения NaN, из-за этого может пострадать staleness detection. ВМ считает, что ряд оборвался, если у него нет новых значений в течение двойного интервала между предыдущими значениями. Прометей определяет обрыв ряда по NaN'ам, а если их нет, то считает, что ряд оборвался спустя 5 минут после последней точки. Из-за этого он неправильно работает для рядов со scrape_interval'ом больше 5 минут. Как видите, у каждого решения есть плюсы и минусы. ВМ не может использовать staleness detection из прометея еще и потому, что он не работает для данных, полученных по другим поддерживаемым протоколам - Graphite, InfluxDB, OpenTSDB.
Округление меток времени (потеря точности), плюс он упоминал какие-то неработающие запросы.
Обсуждают сегодня