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

Сегодня наткнулся на статью от разработчиков плагина для Postgres TimescaleDB "What InfluxDB Got Wrong", в которой коллеги рассуждают об ошибках, которые допустила команда InfluxDB на своем пути построения базы данных для работы с временными рядами. 

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

• Мониторинг с помощью InfluxData. Часть 1. InfluxDB
• Мониторинг с помощью InfluxData. Часть 2. Telegraf
  
• Мониторинг с помощью InfluxData. Часть 3. Chronograf
  

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

TimescaleDB. Комфортное хранение метрик в PostgreSQL

В статье пойдет речь об opensource базе данных TimescaleDB, которая предназначена для хранения временных рядов. Мы поговорим об особенностях хранения временных рядов, рассмотрим, как устроена внутри TimescaleDB, рассмотрим на примере запись и чтение метрик в TimescaleDB.

В одной из предыдущих статей мы рассматривали одну очень интересную базу данных для хранения временных рядов InfluxDB. Мы говорили о том, что InfluxDB очень гибкая позволяет быстро начать работу и, самое главное, InfluxDB заточена под запись хранение и обработку временных рядов. А что это означает: "заточена под запись хранение и обработку временных рядов"? Давайте разберемся.

Разработчики для хранения данных разрабатываемых приложений (будем называть их бизнес данными) в зачастую используют реляционные SQL базы данных. Такие базы строго структурированы и хорошо обеспечивают целостность данных благодаря механизмам внешних ключей и транзакций, позволяют делать сложные запросы к данным и выполняют эти запросы быстро благодаря индексам на колонки, по которым идет фильтрация и сортировка. Бизнес данные - это в большей своей части описание некоторых сущностей реального мира, которые имеют свои параметры, и эти параметры меняются во времени. Когда происходит изменение параметров сущности - происходит обновление определенной строки в определенной таблице в базе данных, при этом предыдущее значение мы не запоминаем, а перезаписываем на новое. А что если мы хотим сохранить все предыдущие состояния наших сущностей? Если мы будем запоминать все изменения объектов - то наши данные превращаются во временные ряды.

Мониторинг с помощью InfluxData. Часть 3. Chronograf

В предыдущих сериях 

В первой статье мы познакомились с InfluxData - платформой для работы с временными рядами, настроили базу данных временных рядов InfluxDB. Во второй статье настроили сбор метрик и дальнейшую отправку в InfluxDB с помощью Telegraf. В текущей статье научимся рисовать графики значений метрик с помощью Chronograf.

Мониторинг с помощью InfluxData. Часть 2. Telegraf

Добрый день. В предыдущей статье мы познакомились с платформой для работы с временными рядами InfluxData. Разобрались, что она состоит из 4 приложений: Telegraf, InfluxDB, Chronograf и Kapacitor, которые образуют так называемый TICK стек технологий (по первым буквам приложений). Научились устанавливать и работать с базой данных InfluxDB. В текущей статье речь пойдет о приложении Telegraf.

Мониторинг с помощью InfluxData. Часть 1. InfluxDB

Новый год наступил, а значит самое время узнать что-то новое. Текущая статья начинает серию статей про InfluxData - платформу для сбора/хранения/визуализации/управления временными рядами (time-series data).

С помощью данной платформы я буду поэтапно настраивать мониторинг основных параметров компьютера, таких как загрузка процессора, использование оперативной памяти, состояние жестких дисков. Процесс настройки и результаты буду фиксировать в блоге.

В данной статье познакомимся с платформой InfluxData, я опишу основные ее возможности, а также установим, настроим и научимся пользоваться базой данных InfluxDB.

Rootconf: DevOps, мониторинг, метрики, алерты!

В некотором царстве в некотором государстве под названием Москва 21-22 мая 2015 года прошёл фестиваль Российские интернет технологии, на котором мне посчастливилось побывать. Проходил фестиваль в Крокус сити холле. В этом году Олег Бунин и его команда сделали из ежегодной конференции РИТ целый фестиваль. В рамках фестиваля было организовано 5 секций с различной тематикой.

1. RootConf. Конференция по эксплуатации.
2. FronfendConf. Конференция фронтэнд разработчиков.
3. Highload++ Junior. Обучающая конференция разработчиков высоконагруженых систем.
4. WhileRider. Профессиональная конференция по управлению и предпринимательству.
5. Intersystems CacheConf. Конференция по различным типам доступа данных и быстрой разработке.

Подробнее можно ознакомиться с фестивалем на сайте. Я же посещал секцию rootconf, посмотрел на админов и попытался прочувствовать их проблемы посмотреть на эксплуатацию глазами разработчика.

DevOps, мониторинг, метрики, алерты!

Все выступления были пронизаны этими терминами. Основные направления докладов конференции - это хорошие практики использования систем мониторинга, улучшение процесса эксплуатации разработанного ПО. 

Конференция расширила мой кругозор, и я пополнил багаж знаний.

• Открыл для себя пару новых терминов типа devops, гистерезис триггеров. 
• Получил ссылки на незнакомые ранее для меня системы мониторинга: okmeter, graphite.
• Познакомился с интересными людьми.
• Понял, что разработчики и служба эксплуатации должны стать лучшими друзьями для более эффективной работы.
• И многое другое.

Считаю конференцию очень полезной. Если Вы хоть как-то связаны с администрированием и эксплуатацией ПО и есть потребность в мониторинге инфраструктуры, то обязательно посмотрите доклады, видео которых обещают уже выложить в ближайшее время. Доклады будут интересны как инженерам любого уровня, так и руководителям служб эксплуатации.