Comments 26
Вот уже несколько месяцев используется для рисования графиков вместо pnp4nagios — пара скриптов + curl, несколько дашбордов в Grafana. Также в InfluxDB скидывается статистика из collectd, в планах скидывать счетчики производительности из Windows (используя github.com/Iristyle/PerfTap + github.com/armon/statsite) и из Java-приложений (jmxtrans).
Непонято, как всё это бекапить и, пока этот вопрос не решится, ставить в продакшен даже не-кластер побоюсь.
Попытки поднять кластер в текущих релизах работают не всегда — несколько попыток закончились потерей данных на первом узле и неподнявшимся кластером. Если собирать из Git, то ситуация несколько лучше.
Ещё есть интересный вопрос, как всё это будет работать с большим количеством данных — приложение написано на Go, а значит что временами будет отрабатывать Garbage Collector.
Решение об использовании SQL-подобного языка запросов тоже кажется несколько спорным.
Из дополнительных источников информации я бы отметил dieter.plaetinck.be/, в частности для желающих смигрировать с graphite или желающих поставит influxdb параллельно graphite.
Непонято, как всё это бекапить и, пока этот вопрос не решится, ставить в продакшен даже не-кластер побоюсь.
Попытки поднять кластер в текущих релизах работают не всегда — несколько попыток закончились потерей данных на первом узле и неподнявшимся кластером. Если собирать из Git, то ситуация несколько лучше.
Ещё есть интересный вопрос, как всё это будет работать с большим количеством данных — приложение написано на Go, а значит что временами будет отрабатывать Garbage Collector.
Решение об использовании SQL-подобного языка запросов тоже кажется несколько спорным.
Из дополнительных источников информации я бы отметил dieter.plaetinck.be/, в частности для желающих смигрировать с graphite или желающих поставит influxdb параллельно graphite.
Использую influxdb в одном проекте, с удовольствием поделимся опытом и обсудим впечатления. Пока что influx радует почти всем, но есть пара моментов:
1. Все-таки весьма куцые возможности по обработке данных, выборкам, агрегатным функциям и т.п. Хотелось бы where в continuous queries, функций типа moving average, и/или какого-нибудь вообще встроенного скриптинга.
2. Он у нас уже несколько раз падал или зависал — при условии постоянной нагрузки на запись (средней интенсивности — порядка 200 записей в секунду, пачками) и пары тяжелых запросов на чтение поверх нее. Причем, без всякий слов в логах. У вас не случалось подобного?
1. Все-таки весьма куцые возможности по обработке данных, выборкам, агрегатным функциям и т.п. Хотелось бы where в continuous queries, функций типа moving average, и/или какого-нибудь вообще встроенного скриптинга.
2. Он у нас уже несколько раз падал или зависал — при условии постоянной нагрузки на запись (средней интенсивности — порядка 200 записей в секунду, пачками) и пары тяжелых запросов на чтение поверх нее. Причем, без всякий слов в логах. У вас не случалось подобного?
Графики машины во время падения были ок? Память в частности.
Да, память и подозреваю. Сейчас уже нет графиков (у меня эта машина мониторится только за сутки, надо бы свой мониторинг настроить), но память там точно кушалась (как и проц).
Я так понимаю, influx не очень умеет справляться с ситуацией, когда ему кидают одновременно десяток-два запросов, которые заставляют его бежать по данным на сутки назад. К сожалению, та же grafana устроена так, что она закидывает его отдельными запросами для каждого графика, хотя могло бы быть намного оптимальнее.
Я так понимаю, influx не очень умеет справляться с ситуацией, когда ему кидают одновременно десяток-два запросов, которые заставляют его бежать по данным на сутки назад. К сожалению, та же grafana устроена так, что она закидывает его отдельными запросами для каждого графика, хотя могло бы быть намного оптимальнее.
Для истории оставлю это здесь: отказались от influxdb после еще пары эпизодов полной потери данных в бою.
Influxdb в непредсказуемые моменты необъяснимо портил свои файлы данных, после чего полностью переставал запускаться. Я пообщался про это с его разработчиками, но разобраться не смогли. В итоге переехали на старый добрый mysql, разработав под него немного другую структуру данных. Все написанное относится к influxdb версии 0.8.x, на текущий момент готовится 0.9.0 (есть release candidate), но его мы не пробовали.
Influxdb в непредсказуемые моменты необъяснимо портил свои файлы данных, после чего полностью переставал запускаться. Я пообщался про это с его разработчиками, но разобраться не смогли. В итоге переехали на старый добрый mysql, разработав под него немного другую структуру данных. Все написанное относится к influxdb версии 0.8.x, на текущий момент готовится 0.9.0 (есть release candidate), но его мы не пробовали.
странно, наш сторадж: github.com/pulsedb/pulsedb справляется с куда более существенными нагрузками, хотя не имеет конечно такого клевого интерфейса
Очень внимательно слежу за этим крайне интересным проектом, но пока использовать мешают три немаленькие проблемы:
1. сих пор нет отмены исполнения запроса при разрыве конекта,
2. нет возможности перегенирить данные для continuous query,
3. не решена проблема OOM для continuous query на большом объеме.
1. сих пор нет отмены исполнения запроса при разрыве конекта,
2. нет возможности перегенирить данные для continuous query,
3. не решена проблема OOM для continuous query на большом объеме.
Было бы интересно увидеть сравнение производительности с Graphite.
Видел в сети сравнение со стабильной версией graphite — на больших объемах influxdb быстрее.
В целом графит это отдельная песня. Тоже слежу очень вниамтельно: он где-то год лежал мертвецом, летом вроде бы разработка активизировалась. Нас ждет много интересных плюшек.
Не исключаю что новая версия будет на уровне. Не исключено, что скажутся особенности стека технологий. Go разрабатывался как язык для параллельных вычислений. Python же со своим GIL порой вгоняет в беспросветную тоску.
В целом графит это отдельная песня. Тоже слежу очень вниамтельно: он где-то год лежал мертвецом, летом вроде бы разработка активизировалась. Нас ждет много интересных плюшек.
Не исключаю что новая версия будет на уровне. Не исключено, что скажутся особенности стека технологий. Go разрабатывался как язык для параллельных вычислений. Python же со своим GIL порой вгоняет в беспросветную тоску.
Пара комментариев.
1. Текущая версия 0.8.7 (и все ниже) написаны не на чистом Go. Чистый Go будет начиная с версии 0.9.0 (http://influxdb.com/blog/2014/12/08/clustering_tags_and_enhancements_in_0_9_0.html)
2. Также начиная с версии 0.9.0 произойдет переход на BoltDB как единственный вариант стораджа. LevelDB, RocksDB, HyperLevelDB и LMDB больше поддерживаться не будут (обещают предоставить средства миграции)
Мы использует Инфлюкс в сетевом устройстве на процессоре ARM для хранения кучи разных метрик (параметры самого устройства и внешнего окружения). Выбор пал на него, так как ничего другого вразумительного, компактного и для ARM не нашлось. Поначалу процесс компиляции под ARM это был тот еще ад, благо сейчас все делается автоматом через скрипт.
Поддержку пользователя smart — был период когда Инфлюкс сходил с ума, кушал весь CPU, по логам разобраться в чем причина не удалось. Переписали некоторые запросы, и еще местами пошаманили и с тех пор полет нормальный.
Нас немного расстроил отказ от LevelDB, так как он позволяет очень компактно хранить данные, в нашем случае ограниченного места это очень важно.
1. Текущая версия 0.8.7 (и все ниже) написаны не на чистом Go. Чистый Go будет начиная с версии 0.9.0 (http://influxdb.com/blog/2014/12/08/clustering_tags_and_enhancements_in_0_9_0.html)
2. Также начиная с версии 0.9.0 произойдет переход на BoltDB как единственный вариант стораджа. LevelDB, RocksDB, HyperLevelDB и LMDB больше поддерживаться не будут (обещают предоставить средства миграции)
Мы использует Инфлюкс в сетевом устройстве на процессоре ARM для хранения кучи разных метрик (параметры самого устройства и внешнего окружения). Выбор пал на него, так как ничего другого вразумительного, компактного и для ARM не нашлось. Поначалу процесс компиляции под ARM это был тот еще ад, благо сейчас все делается автоматом через скрипт.
Поддержку пользователя smart — был период когда Инфлюкс сходил с ума, кушал весь CPU, по логам разобраться в чем причина не удалось. Переписали некоторые запросы, и еще местами пошаманили и с тех пор полет нормальный.
Нас немного расстроил отказ от LevelDB, так как он позволяет очень компактно хранить данные, в нашем случае ограниченного места это очень важно.
github.com/pulsedb/pulsedb? 2 байта на замер.
Используем для того же OrientDB (http://www.orientechnologies.com/orientdb/) и Orienteer (http://orienteer.org/). Не без собственных костылей, но зато можно использовать преимущества OrientDB: key-value/document/graph DB/RDBM в одном флаконе + масштабируемость.
За наводку спасибо! Весьма интересно особенно «синтаксический сахар» в InfluxDB SQL для временных данных…
За наводку спасибо! Весьма интересно особенно «синтаксический сахар» в InfluxDB SQL для временных данных…
Из переписки с одной австралийской компанией:
Собственно парни работают в аналогичной сфере что и вы.
Тут можно прочитать про их TSDB,
Исходники на github, язык реализации haskell.
Does that interest you?
We are currently working on an open source TSDB:
github.com/anchor/vaultaire/tree/v2
> Yes, it is interesting,
> I review code, you are use cerph as distributed store,
> but why not using InfuxDB? ( influxdb.com )
We chose to build our own TSDB after evaluating a few, such as influxdb and
finding them immature/unstable/etc. We could not get influxdb to build at the
time, and fixed a few bugs before giving up. We already have Ceph rolled out
internally as a data store and trust it to replicate data without losing it. I
will be releasing a blog post shortly on the subject, I'll send you a copy.
Собственно парни работают в аналогичной сфере что и вы.
Тут можно прочитать про их TSDB,
Исходники на github, язык реализации haskell.
We could not get influxdb to build at the time, and fixed a few bugs before giving up.Я тут несколько месяцев назад собирал InfluxDB под ARM, и вы даже не представляете, что я испытал. Эти ребята вообще не знают, что существуют системы сборки. Я буквально переписывал makefile.
Ну с другой стороны концепт обещает быть весьма интересным.
В мой проект, в качестве хранилища для метрик, он у меня вписался как влитой.
В процессе разработки пока удобно, буду ближе к релизу, буду думать, оставлять его или менять на что-нибудь другое (архитектура позволяет, код привязки строк 150).
А так да, сыроват, эпизодически странно себя ведет.
В мой проект, в качестве хранилища для метрик, он у меня вписался как влитой.
В процессе разработки пока удобно, буду ближе к релизу, буду думать, оставлять его или менять на что-нибудь другое (архитектура позволяет, код привязки строк 150).
А так да, сыроват, эпизодически странно себя ведет.
А под windows не пробовал собирать? Я собрать то собрал, да только даже консоли 8083 нет. Хотя «exe» запускаются.
Почему бы не попробовать для ARM использовать SQLite?
UFO just landed and posted this here
Вот небольшая и легковесная Time Series DB: github.com/Akumuli/libakumuli via Lazin
Sign up to leave a comment.
Time Series, метрики и статистика: знакомство с InfluxDB