InfluxDB: знайомство і основні можливості

Автор |  25/10/2025
0 коментарів
 

Є в мене давня ідея self-monitoring, яку, сподіваюсь, я такі почну робити і про яку напишу окремо.

Але суть її така сама, як і в етіх ваших моніторингах – збирати метрики, і відображати графіки.

Почав під цю систему вибирати базу даних, і хоча там частота запису метрик невелика, 1 метрика на день, але хочу її робити у звичному мені time series форматі – як ми це робимо в VictoriaMetrics/Prometheus.

А в рамках написання іншого поста, про структуру TSDB та метрики (все ще в чернетках), я торкнувся InfluxDB, про яку згадав і цього разу.

Саму InfluxDB я трохи використовував ще років п’ять тому, але зовсім трохи – вона просто була одним з бекендів для Grafana, коли ми будували автоматичний load testing з JMeter в Kubernetes (колись до цього знов дійде, і напишу теж, бо там дуже класний сетап).

Але так, щоб самому використовувати InfluxDB – досвіду не було. І коли я зараз глянув на неї – то система прям дуже сподобалась, а тому для свого self-monitoring буду використовувати її.

Ну якщо що – то з InfluxDB завжди можна мігранути дані у VictoriaMetircs, див. Migrate from InfluxDB to VictoriaMetrics.

Тож що сьогодні будемо робити:

  • запустимо InfluxDB локально на Linux-хості
  • розберемо основні концепти і поняття
  • подивимось на інтерфейс, на основні компоненти
  • додамо метрику вручну
  • додамо збір метрик з Telegraf
  • додамо збір логів з Telegraf

VictoriaMetrics vs InfluxDB

Якщо дуже коротко – то для повноцінного моніторингу, для відносно великого проекту я все ж взяв би саме VictoriaMetrics, бо на великих об’ємах вона буде набагато краща в плані CPU/Memory.

Але для якогось pet project – InfluxDB можливо підійде краще за рахунок того, що в ній “з коробки” є можливість будувати дашборди з графіками, є власний alertmanager, є цікаві штуки для різних автоматизацій.

Втім, у InfluxDB є (відносний) недолік – це більш складна мова запитів, яких до того цілих дві – Flux та InfluxQL. Але можливості query builder для простого використання цілком достатньо.

InfluxDB overview

Власне InfluxDB – ще одна Time Series Database, як вже згадувані VictoriaMetrics або Prometheus.

Головна різниця – VictoriaMetrics та Prometheus працюють по pull-моделі (збирають дані з експортерів), а InfluxDB – це push-модель, коли експортери самі, власне, пушать дані в базу.

Різні і мови запитів – в VictoriaMetrics MetricsQL та PromQL в Prometheus маємо звичні нам функції типу rate() і sum by (), тоді як в InfluxDB це мова Flux (“functional data scripting language“), яка по суті являється повноцінною мовою програмування, та InfluxQL – яка більше схожа на SQL, але в InfluxDB v2 вмикається через костиль, і дефолтна мова саме Flux (але в InfluxDB v3 наче знову буде InfluxQL).

VictoriaMetrics/Prometheus – це частина CNCF-екосистеми і LGPT (Loki + Grafana + Prometheus + Tempo) або PLG (Prometheus + Loki + Grafana) стеків, а InfluxDB – це про TICK stack (Telegraf + InfluxDB + Chronograf + Kapacitor).

При цьому в InfluxDB v2 Chronograf та Kapacitor вже вбудовані в саму систему, окремо запускати не треба.

Ну і дані – VictoriaMetrics та Prometheus заточені під зберігання і роботу саме з “класичними” метриками, тоді як в InfluxDB можна збирати логи, дані з IoT девайсів, events, дані від Telegraf-плагінів тощо.

Крім того, InfluxDB наче краще підходить для довготривалого зберігання даних – і за рахунок самої моделі зберігання даних, і за рахунок вбудованих механізмів для data retention.

Ну і можливості візуалізації даних – якщо в VictoriaMetrics та Prometheus у нас “з коробки” є тільки базові графіки, бо це всеж більше бази даних, то в InfluxDB у нас є повноцінний інтерфейс, через який ми можемо робити всі потрібні налаштування і візуалізації

Запуск InfluxDB з Docker

Для “погратись” просто запустимо локально з Docker:

$ docker run -d \
  --name influxdb \
  -p 8086:8086 \
  -v $PWD/influxdb_data:/var/lib/influxdb2 \
  influxdb:2

Використаємо InfluxDB v2.7, хоча вже є версія 3.

Але в v3 багато змін, вона не дуже сумісна з другою версією, а більшість гайдів будуть саме по другій, тому давайте працювати з нею.

Note: по ходу гуглінга знайшов цікавий матеріал – What InfluxDB Got Wrong, де як раз говориться про те, що команда InfluxData робить нові версії несумісні з попередніми, і це, звісно, не дуже гуд

Відкриваємо в браузері http://localhost:8086, налаштовуємо юзера, організацію, і дефолтний бакет (про бакети і інші концепти далі):

Відразу отримуємо пропозицію налаштування – “погратись”, advanced, або просто перейти в базу:

Клікаємо Quick start аби отримати якісь базові дані, де нам відразу автоматично налаштовується збір власних метрик InfluxDB і створюється дашборда:

Key concepts

Коротко пройдемось по основних поняттях.

  • Bucket: на відміну від VictoriaMetrics/Prometheus, в InfluxDB дані організовані в такі собі “корзини” або “бази даних”
  • Measurement: це по факту звичні нам з VictoriaMetrics/Prometheus метрики, і метрики (я їх буду назвати саме так, хоча, мабуть, це не дуже коректно з технічної точки зору) складаються з:
    • Tags: labels для метрик, індексуються для швидкого пошуку
    • Fields: поля зі значеннями, не індексуються
    • Timestamp: час додавання метрики
  • Point: конкретний запис (метрика + теги + значення + час), аналог Sample або data points в термінах VictoriaMetircs/Prometheus
  • Series: група записів (метрика + теги + значення), аналог Time Series в термінах VictoriaMetircs/Prometheus

Формат метрик відрізняється від VictoriaMetrics/Prometheus і записується в форматі line protocol.

Наприклад, у VictoriaMetircs запис може виглядати так:

node_cpu_seconds_total{cpu="0", mode="user"}  120.5

А в InfluxDB він буде таким:

node_cpu_seconds_total,cpu=0,mode=user value=120.5 1735156800000000000

Тут в InfluxDB метриці маємо власне ім’я метрики node_cpu_seconds_total, два теги зі значеннями – cpu=0,mode=user, поле value зі значенням, і timestamp.

Timestamp можна задавати в UNIX epoch, можна в ISO 8601, тобто 2025-10-25T12:00:00Z, але рекомендований і дефолтний формат – саме UNIX.

Доступ до InfluxDB

Тут маємо на вибір сам UI і Data Exporter, CLI-утиліту influx, та InfluxDB HTTP API для всякої автоматизації.

influx CLI

Документація – influx – InfluxDB command line interface.

З influx можемо працювати з контейнера:

$ docker exec -ti influxdb influx --help
NAME:
   influx - Influx Client

USAGE:
   influx [command]

HINT: If you are looking for the InfluxQL shell from 1.x, run "influx v1 shell"

COMMANDS:
   version              Print the influx CLI version
   write                Write points to InfluxDB
   bucket               Bucket management commands
...

Або встановити локально:

$ sudo pacman -S influx-cli

Створюємо токен:

Задаємо його в змінні:

$ export INFLUX_TOKEN="0S_4Co9XTA73SzwUQvbXsEUGKcjhhGWiBLobEOnH-kcmtOwMpbe-kyMrs2vFUcbg27WtneYhmILL7paWAuc8Ow=="

Налаштовуємо підключення:

$ influx config create --config-name test-local --host-url http://localhost:8086 --org setevoy --token $INFLUX_TOKEN  --active
Active  Name            URL                     Org
*       test-local      http://localhost:8086   setevoy

І подивимось які бакети у нас є:

$ influx bucket list
ID                      Name            Retention       Shard group duration    Organization ID         Schema Type
88e39083ae738103        _monitoring     168h0m0s        24h0m0s                 7f284740b8e4ebfa        implicit
f7e383b1a2366840        _tasks          72h0m0s         24h0m0s                 7f284740b8e4ebfa        implicit
0d1b2da0ccaea8cf        testing_bucket  infinite        168h0m0s                7f284740b8e4ebfa        implicit

HTTP API

Документація – InfluxDB HTTP API.

Тут можна просто з curl, передавши токен:

$ curl -s --request GET "http://localhost:8086/api/v2/buckets" --header "Authorization: Token $INFLUX_TOKEN"

Результат:

Інтерфейс

Зліва маємо основне меню:

Load Data

В Load Data: все про дані:

  • Sources: завантажити з файлів або CLI, записати з клієнтів тощо
  • Buckets: менеджмент “баз даних”
  • Telegraf: створення конфігурації для агенту (“експортеру”) для збору метрик  (тільки конфіг, сам Telegraf запускаємо окремо)
  • Scrapers: InfluxDB з другої версії додала можливість самій отримувати дані із зовнішніх ресурсів, фактично як ми це маємо з VictoriaMetircs/Prometheus
  • API Tokens: вже бачили – менеджмент токенів

Data Explorer

Дуже нагадує Kibana – зручний інтерфейс для простої побудови запитів і візуалізації даних:

Notebooks

Документація – Overview of notebooks.

Дуже цікава фішка, аналог Jupyter Notebook – “жива” аналітика, експерименти із запитами, автоматизація запитів:

Дозволяє зберігати послідовності, які потім можна використати в InfluxDB Tasks.

Кожен Notebook розбитий на кілька cell, які можуть бути data source для отримання даних, visualization для графіків, і action – створити алерт або Task.

Dashboards

Дашборди 🙂

Тут вже з коробки маємо одну готову:

Де можемо редагувати візуалізації:

І де я перший раз побачив Flux:

Виглядає… Складно 🙂

Але можемо переключитись на Query builder:

А потім знов повернутись до коду:

Tasks

Документація – Get started with InfluxDB tasks.

Такі собі ETL-джоби по крону.

Приймають дані, виконують модифікацію, зберігають в корзині.

Наприклад, код (ChatGPT непогано генерить):

option task = {name: "copy_http_api_metrics", every: 5s}

data =
    from(bucket: "testing_bucket")
        |> range(start: -1h)
        |> filter(fn: (r) => r._measurement == "http_api_requests_total")
        |> set(key: "example_tag", value: "demo")

data |> to(bucket: "new_bucket", org: "setevoy")

Тут:

  • реєструємо таску з ім’ям copy_http_api_metrics
  • яка зчитує дані з бакету testing_bucket
  • звідки вибирає метрику http_api_requests_total
  • додає до кожного запису новий тег example_tag="demo"
  • і зберігає результат в інший бакет – new_bucket

Зацініть сам редактор! Навіть помилки показує:

Таска пошла виконуватись:

І тепер маємо оновлену метрику в іншому бакеті:

Alerts

Вбудована система алертів:

Цікаво, що відразу є алерти двох типів – Threshold для “стандартних” алертів, і Deadman – якщо сервіс перестає надсилати дані.

В Cheks на першому етапі задаються самі умови перевірки:

А на другому – значення, при яких алерт буде спрацьовувати, при чому відразу різні severity:

В Notification Enpoints можна задати куди відправляти:

А в Notification Rules задаємо куди відправляти, як часто повторювати тощо – але в мене нема ендпоінтів, тому пропустимо.

Виглядає прям дуже круто.

Settings

Тут можемо задати глобальні змінні для використання у своїх запитах чи дашбордах:

Створити шаблони:

При чому шаблони – це не тільки про дашборди і візуалізації, а буквально будь-що, що ми налаштовуємо в InfluxDB.

І Secrets – як змінні, тільки їх значення не буде видно:

Додавання даних

ОК, з інтерфейсом розібрались – давайте запишемо щось в базу.

Додавання і читання метрик з influx CLI

З CLI – influx write:

$ influx write \
  --bucket testing_bucket \
  --org setevoy \
  --precision s \
  "example_requests_total,handler=platform,method=GET value=42 $(date +%s)"

Отримуємо її обратно з influx query:

influx query '
from(bucket: "testing_bucket")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "example_requests_total")
'

Результат:

Додавання метрик через HTTP API

Робимо з curl:

$ curl -X POST "http://localhost:8086/api/v2/write?org=setevoy&bucket=testing_bucket&precision=s" \
  -H "Authorization: Token $INFLUX_TOKEN" \
  --data-raw "api_example_requests_total,handler=platform,method=GET value=42 $(date +%s)"

Отримуємо значення в JSON:

$ curl -X POST "http://localhost:8086/api/v2/query?org=setevoy" \
  -H "Authorization: Token $INFLUX_TOKEN" \
  -H "Content-Type: application/vnd.flux" \
  -H "Accept: application/json" \
  --data-binary 'from(bucket: "testing_bucket")
    |> range(start: -1h)
    |> filter(fn: (r) => r._measurement == "api_example_requests_total")'

Результат:

Використання Telegraf

Metrics

Насправді доволі потужний інструмент з купою плагінів, але для прикладу зберемо метрики CPU з хоста:

Зберігаємо:

І навіть отримуємо інструкції як запустити:

Прямо при запуску ми в Telegraf передаємо URL з конфігом – і він отримає саме ті налаштування, які ми робили на попередньому екрані, тобто нам взагалі не треба писати локальний telegraf.conf.

Це прям якась кілер-фіча.

Встановлюємо клієнт:

$ yay -S telegraf

Запускаємо:

$ export INFLUX_TOKEN=CMmL9cSOiukwFpWF0hNuVoCOML9XC80mQxUukMhOO8XIM8vOGxCneUYpM-2wuOXonSx9gbZKc73pq-SqRn59_w==
$ telegraf --config http://localhost:8086/api/v2/telegrafs/0fb2cd69daf77000
2025-10-25T12:00:12Z I! Loading config: http://localhost:8086/api/v2/telegrafs/0fb2cd69daf77000
2025-10-25T12:00:12Z I! Starting Telegraf unknown brought to you by InfluxData the makers of InfluxDB
2025-10-25T12:00:12Z I! Available plugins: 239 inputs, 9 aggregators, 35 processors, 26 parsers, 65 outputs, 6 secret-stores
2025-10-25T12:00:12Z I! Loaded inputs: linux_cpu
2025-10-25T12:00:12Z I! Loaded aggregators:
2025-10-25T12:00:12Z I! Loaded processors:
2025-10-25T12:00:12Z I! Loaded secretstores:
2025-10-25T12:00:12Z I! Loaded outputs: influxdb_v2
2025-10-25T12:00:12Z I! Tags enabled: host=setevoy-work
2025-10-25T12:00:12Z I! [agent] Config: Interval:10s, Quiet:false, Hostname:"setevoy-work", Flush Interval:10s
...

І перевіряємо метрики:

Можемо звідси відразу зберегти в нову дашборду:

Logs

Аналогічно можемо збирати логи з Telegraf inputs.tail:

Задаємо файл, формат і власні теги:

...
# Parse the new lines appended to a file
[[inputs.tail]]
  files = ["/var/log/firewalld"]
  from_beginning = true

  data_format = "grok"
  grok_patterns = ["%{GREEDYDATA:message}"]

  [inputs.tail.tags]
    source = "firewalld"
    env = "testing"
    example_tag = "demo"

Запускаємо від рута, бо /var/log/firewalld недоступний від звичайного юзера:

[root@setevoy-work Influx]# export INFLUX_TOKEN=-uYQA4L2F7EnT5dcaYKkN7o5aF-mnjTBfTf7gHV-LgDuRguOkO8yL_w6liJY8y5HG8eATCg7MxZrrRGS2035fA==
[root@setevoy-work Influx]# telegraf --config http://localhost:8086/api/v2/telegrafs/0fb2d88892777000 --debug
2025-10-25T12:43:09Z I! Loading config: http://localhost:8086/api/v2/telegrafs/0fb2d88892777000
2025-10-25T12:43:09Z I! Starting Telegraf unknown brought to you by InfluxData the makers of InfluxDB
2025-10-25T12:43:09Z I! Available plugins: 239 inputs, 9 aggregators, 35 processors, 26 parsers, 65 outputs, 6 secret-stores
2025-10-25T12:43:09Z I! Loaded inputs: tail
...
2025-10-25T12:43:19Z D! [outputs.influxdb_v2] Wrote batch of 146 metrics in 20.649008ms
...

І перевіряємо – включаємо Agregate function == sort, і View raw data:

Власне, на цьому поки все.

Щось якось дійсно в захваті 🙂

Для когось self-monitoring – класна система, де не треба нічого зайвого.

Але треба все ж дивитись на ресурси, бо навіть оцей мінімальний сетап вже єсть 250 метрів пам’яті:

Ну і 100% є якісь підводні камені, які можна побачити вже в продакшені.

Корисні посилення