TIG-стек: Telegraf + InfluxDB + Grafana для мониторинга

Retention policy — штука, про которую забывают до первого «диск закончился». Управляйте сроками хранения данных заранее, чтобы не разгребать потом переполненные разделы:

# Создание bucket'а с разным retention
influx bucket create \
  --name monitoring-short \
  --org mycompany \
  --retention 7d

influx bucket create \
  --name monitoring-long \
  --org mycompany \
  --retention 365d

# Downsampling: агрегация старых данных через Task
influx task create --org mycompany --file downsample.flux

# downsample.flux:
option task = {name: "downsample-5m", every: 1h}

from(bucket: "monitoring")
  |> range(start: -2h, stop: -1h)
  |> filter(fn: (r) => r._measurement == "cpu")
  |> aggregateWindow(every: 5m, fn: mean)
  |> to(bucket: "monitoring-long", org: "mycompany")

Основной файл конфигурации — /etc/telegraf/telegraf.conf. Именно здесь описываете, что собирать и куда отправлять:

# /etc/telegraf/telegraf.conf

# Глобальные настройки
[global_tags]
  datacenter = "msk-1"
  role = "webserver"

[agent]
  interval = "10s"
  round_interval = true
  flush_interval = "10s"
  hostname = ""
  omit_hostname = false

# Output: InfluxDB 2.x
[[outputs.influxdb_v2]]
  urls = ["http://monitoring.corp.local:8086"]
  token = "YOUR_API_TOKEN_HERE"
  organization = "mycompany"
  bucket = "monitoring"

# Input: CPU
[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false

# Input: Memory
[[inputs.mem]]

# Input: Disk
[[inputs.disk]]
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]

# Input: Disk I/O
[[inputs.diskio]]

# Input: Network
[[inputs.net]]
  interfaces = ["eth0", "ens*"]

# Input: System (uptime, load)
[[inputs.system]]

# Input: Processes
[[inputs.processes]]

Telegraf умеет мониторить популярные сервисы через специализированные плагины. На практике чаще всего подключаем следующие:

# /etc/telegraf/telegraf.d/services.conf

# Nginx
[[inputs.nginx]]
  urls = ["http://localhost/nginx_status"]

# PostgreSQL
[[inputs.postgresql]]
  address = "host=localhost user=telegraf password=secret dbname=postgres sslmode=disable"
  databases = ["accounting_1c", "hr_1c"]

# Docker
[[inputs.docker]]
  endpoint = "unix:///var/run/docker.sock"
  container_names = []
  timeout = "5s"
  perdevice = true
  total = true

# Redis
[[inputs.redis]]
  servers = ["tcp://localhost:6379"]

# HTTP Response (проверка доступности сайтов)
[[inputs.http_response]]
  urls = ["https://itfresh.ru", "https://corp.local"]
  response_timeout = "5s"
  method = "GET"
  follow_redirects = true
  [inputs.http_response.tags]
    type = "website"

# Exec: произвольные скрипты
[[inputs.exec]]
  commands = ["/opt/scripts/check_1c_sessions.sh"]
  timeout = "10s"
  data_format = "influx"

Запуск и первичная проверка — убеждаемся, что агент стартовал и метрики пошли:

# Тест конфигурации
telegraf --config /etc/telegraf/telegraf.conf --test

# Запуск
sudo systemctl enable telegraf
sudo systemctl start telegraf

# Проверка логов
journalctl -u telegraf -f

Data Source подключается через Grafana UI или provisioning-файл. Покажу оба варианта — выбирайте под свой процесс:

# /etc/grafana/provisioning/datasources/influxdb.yml
apiVersion: 1
datasources:
  - name: InfluxDB
    type: influxdb
    access: proxy
    url: http://localhost:8086
    jsonData:
      version: Flux
      organization: mycompany
      defaultBucket: monitoring
    secureJsonData:
      token: YOUR_API_TOKEN_HERE

Flux-запрос для дашборда по CPU — с него обычно и начинают:

from(bucket: "monitoring")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "cpu")
  |> filter(fn: (r) => r._field == "usage_idle")
  |> filter(fn: (r) => r.cpu == "cpu-total")
  |> map(fn: (r) => ({r with _value: 100.0 - r._value}))
  |> aggregateWindow(every: v.windowPeriod, fn: mean)
  |> yield(name: "CPU Usage %")

Если нужно автоматически разворачивать дашборды — без ручной работы в UI — используйте provisioning. Особенно удобно, когда серверов много:

# /etc/grafana/provisioning/dashboards/default.yml
apiVersion: 1
providers:
  - name: 'default'
    orgId: 1
    folder: 'Infrastructure'
    type: file
    disableDeletion: false
    editable: true
    options:
      path: /var/lib/grafana/dashboards
      foldersFromFilesStructure: true

Не тратьте время на создание дашбордов с нуля. На grafana.com/grafana/dashboards лежат готовые варианты. Для TIG-стека нас устраивают два: ID 928 (Telegraf System) и ID 8159 (Telegraf Host Metrics). Импорт через Grafana UI: Dashboards → Import → вводите ID — и всё готово.

Telegram как канал для алертов — наш выбор для большинства клиентов. Настройка выглядит так:

# /etc/grafana/provisioning/alerting/notifications.yml
apiVersion: 1
contactPoints:
  - orgId: 1
    name: telegram-ops
    receivers:
      - uid: telegram1
        type: telegram
        settings:
          bottoken: "123456:ABC-DEF1234"
          chatid: "-1001234567890"
          parse_mode: HTML

Алерты создаются через Grafana UI или provisioning. Вот набор, который мы считаем минимально достаточным для любой инфраструктуры:

• CPU > 90% более 5 минут — сервер перегружен, пора разбираться что происходит
• RAM > 95% — критическая нехватка памяти, счёт идёт на минуты
• Диск > 85% — место заканчивается, нужно чистить или расширять
• Сервис недоступен — HTTP response timeout, пользователи уже получают ошибки
• Uptime < 10 минут — сервер только что перезагрузился, плановая или нет?

Flux-запрос для алерта на свободное место на диске — один из самых важных в боевой эксплуатации:

from(bucket: "monitoring")
  |> range(start: -5m)
  |> filter(fn: (r) => r._measurement == "disk")
  |> filter(fn: (r) => r._field == "used_percent")
  |> filter(fn: (r) => r.path == "/")
  |> last()
  |> filter(fn: (r) => r._value > 85.0)

Настройте двухуровневую эскалацию: Warning при 85% — в Telegram, Critical при 95% — туда же, плюс дублирование в SMS или звонок. Звонок в три ночи неприятен, но лучше, чем упавший прод.