1. Сколько соединений может обработать один воркер

В NGINX каждый воркер‑процесс способен обслуживать определённое число одновременных соединений. Это задаётся директивой:

worker_connections 1024;

• Здесь учитываются все дескрипторы, включая клиентские соединения и прокси‑сессии к бэкендам.

• По умолчанию NGINX использует 768 соединений, но для серьёзных нагрузок лучше поднять до 1024+, не забывая про лимит открытых файлов в ОС (ulimit -n).

Расчёт максимального числа клиентов:

max_clients=worker_processes×worker_connections\text{max\_clients} = \text{worker\_processes} \times \text{worker\_connections}max_clients=worker_processes×worker_connections

Пример:

worker_processes = 4
worker_connections = 1024
max_clients = 4 × 1024 = 4096

То есть сервер может обслуживать до 4096 соединений одновременно (минус коннекты к upstream).

Пример конфигурации events.conf:

events {
    worker_connections 1024;  # максимум соединений на воркер
    # accept_mutex on;        # равномерное принятие коннектов (опционально)
}

2. Ограничение одновременных соединений: limit_conn

Чтобы защитить сервер от «дружелюбной» перегрузки, например, когда бот‑краулер открывает сотни соединений, используется ngx_http_limit_conn_module:

• limit_conn_zone — создаёт область памяти для хранения текущих соединений (обычно по IP).

• limit_conn — задаёт лимит одновременных соединений.

Пример настройки:

http {
    limit_conn_zone $binary_remote_addr zone=perip:10m;

    server {
        location / {
            limit_conn perip 10;         # не больше 10 соединений на IP
            limit_conn_status 429;       # выдаём 429 вместо дефолтного 503
            limit_conn_log_level info;   # уровень логирования при отказе
        }
    }
}

• 10m зоны на 64-битной платформе хранят примерно 16 000 уникальных IP.

• При переполнении NGINX сразу отдаёт ошибку (503/429).

Dry-run и логирование:

limit_conn_dry_run on;       # не блокирует, а только логирует
limit_conn_log_level notice;

Так можно тестировать лимиты, не блокируя клиентов.

3. Ограничение скорости запросов: limit_req

Если нужно контролировать частоту запросов, применяется ngx_http_limit_req_module.

Механизм основан на «leaky bucket» — запросы попадают в бакет и «вытекают» с заданной скоростью.

http {
    limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;

    server {
        location /login {
            limit_req zone=login burst=10 nodelay;
            limit_req_status 429;
            limit_req_log_level warn;
        }
    }
}

• burst — пиковое количество запросов, которое сервер пропускает сверх лимита.

• nodelay — отказ сразу при превышении лимита, без задержки.

• Без nodelay лишние запросы будут ожидать своей очереди.

4. Где хранится состояние

В NGINX есть shared memory zones — специальная общая память для лимитов:

• Slab-пул разбивает память на одинаковые блоки для быстрого выделения и освобождения.

• Для limit_conn используется хеш-таблица или сбалансированное дерево по IP.

• Для limit_req — красно‑чёрное дерево + очередь «протекающего ведра».

• Доступ защищён встроенным мьютексом — нет гонок даже при сотнях воркеров.

Механизм работы:

1. При новом запросе NGINX берёт ключ (IP), ищет запись в зоне.

2. Если записи нет — создаёт новую.

3. Проверяет счётчики и решает, пропускать запрос или отказать.

5. Реакция сервера при превышении лимита

• По умолчанию:

  • limit_conn → 503 Service Unavailable

  • limit_req → 503 Service Unavailable

• Лучше отдавать 429 Too Many Requests, чтобы клиенты понимали причину.

Пример логов

2025/04/04 13:45:12 [warn] 12345#0: *67890 limiting requests, excess: 5 by zone "login"
2025/04/04 13:45:12 [info] 12345#0: *67890 a client request is temporarily blocked by zone "perip"

6. Практические нюансы

• Размер зоны: 1 MB ≈ 16 000 записей; для 100 000 IP/сутки потребуется 10–12 MB.

• burst vs delay: для login/API можно применять разные подходы:

  • login: burst=1; nodelay

  • API: burst=10; delay 10

• Разные зоны для разных endpoint: чтобы лимиты не конфликтовали.

• Исключения: через map или geo можно исключить внутренние IP:

map $remote_addr $limit {
    10.0.0.0/8         "";
    default            $binary_remote_addr;
}

limit_req_zone $limit zone=api:20m rate=20r/s;

7. Сторонние модули и NGINX Plus

7.1 ngx_brotli — снижение трафика

• Brotli‑сжатие уменьшает объём передаваемых данных, разгружая лимиты по трафику:

http {
    brotli on;
    brotli_comp_level 6;
    brotli_types text/html text/css application/javascript;
}

7.2 ngx_http_limit_traffic_ratefilter_module — лимит по байтам

• Позволяет ограничить скорость передачи, например 100 KB/s на IP:

http {
    limit_traffic_rate_zone $binary_remote_addr zone=bytetraf:10m;

    server {
        location /downloads/ {
            limit_traffic_rate zone=bytetraf rate=100k;
        }
    }
}

7.3 NGINX Plus — расширенные возможности

• Синхронизация зон между нодами — zone_sync.

• Адаптивное ограничение: скорость передачи зависит от метрик, например:

map $upstream_response_time $dyn_rate {
    "~^[0-9]\.[0-1]" 200k;   # быстрые ответы — больше скорости
    default           50k;    # медленные — ограничение
}

server {
    location /stream/ {
        limit_rate $dyn_rate;
    }
}

Ошибки в сетевой инфраструктуре: от планирования до эксплуатации

Ошибки, которые могут допустить IT-специалисты, практически неисчерпаемы. Некоторые из них незаметны обычным пользователям — например, отсутствие настроенного журналирования событий. Даже взлом, произошедший из-за этого, может остаться незамеченным, пока об этом не напишут в новостях.

Другие ошибки становятся очевидными сразу: проблемы в работе сети замечает каждый сотрудник. В этой статье разберём наиболее частые ошибки при проектировании и эксплуатации сетей и дадим практические рекомендации, как их избежать.

1. Планирование сети: превыше всего

Часто сети строятся без должного планирования. Причины бывают разные: экономия средств, отсутствие компетенций у проектировщиков, поспешные решения руководства.

Пример: интегратор готовит детальную спецификацию сети, а заказчик «подрезает» её, чтобы сэкономить — в итоге сеть строится с недочётами, которые потом приходится исправлять дорого и долго.

Правильное планирование включает:

• оценку количества рабочих мест и будущего расширения;

• разработку документации и схем сети;

• расчёт емкости портов на коммутаторах и маршрутизаторах;

• планирование отказоустойчивости и резервирования.

2. Кабельная инфраструктура: детали имеют значение

Даже при массовом использовании Wi‑Fi проводные соединения остаются критически важными.

Ошибки:

• Недостаток розеток и кабелей.

• Плохая организация кабельных каналов.

• Попытка «все на Wi‑Fi», что может привести к перегрузке сети.

Решение:

• Планируйте количество розеток с запасом (+4–6 на кабинет).

• Разделяйте кабели по цветам:

  • Жёлтые — кроссы,

  • Красные — серверы и NAS,

  • Синие — настенные разъёмы и коммутаторы,

  • Чёрные — инфраструктурные соединения,

  • Зелёные — временные подключения.

• Маркируйте оба конца кабеля, чтобы быстро находить подключение к устройству.

3. Коммутаторы: порты не должны заканчиваться

Ошибка многих сетевых администраторов — неправильный расчёт портовой емкости. Если все порты заняты «впритык», в критический момент новые устройства подключить будет невозможно.

Совет:

• Для этажных коммутаторов рассчитывайте запас портов.

• Для коммутаторов ядра — учитывайте отказоустойчивость и настройку Spanning Tree.

4. Маршрутизаторы: не пытайтесь сделать всё

Современные маршрутизаторы умеют почти всё: VPN, DHCP, файрволл, межсетевой экран.
Но перегружать маршрутизатор всеми функциями не стоит:

• Он станет точкой отказа.

• Пропускная способность упадёт.

• Риски безопасности увеличатся.

Рекомендация: оставьте маршрутизатор только для маршрутизации, VPN и файрволл — на отдельные устройства.

5. Серверная: порядок и скорость

Ошибки:

• Перепутанные кабели, отсутствие маркировки.

• Серверы, размещённые далеко от магистралей сети, что замедляет работу.

Пример:
Представьте автостраду и деревенскую дорогу. Магистраль позволяет двигаться быстро без остановок, а локальные дороги замедляют движение. Так же работает и сеть: чем больше устройств между пользователем и сервером, тем медленнее передача данных.

Решение:

• Сразу организуйте кабели аккуратно и с маркировкой.

• Размещайте серверы так, чтобы минимизировать количество промежуточных устройств.

6. Документирование: бумажки — это важно

Без документации можно потерять контроль над сетью: свободные порты окажутся заняты, кабели не будут подписаны, схемы станут нечитаемыми.

Советы:

• Ведите журнал портов на коммутаторах.

• Создавайте схемы сети на уровнях L1/L2/L3, не перегружая одну схему всеми деталями.

• Обновляйте документацию регулярно.

Заключение

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

Даже если что-то осталось за кадром — избегая этих типичных ошибок, вы уже делаете сеть более надёжной.

Введение

Событийно-ориентированные архитектуры (EDA) на бумаге выглядят идеальными: продюсеры и консюмеры отделены друг от друга, потоки асинхронны, а система легко масштабируется. Но реальность часто оказывается сложнее.

Представьте распродажу на «Чёрную пятницу»: ваша система обработки платежей получает в 5 раз больше трафика. В этот момент серверлесс-функции запускаются «холодно», очереди SQS переполняются, а DynamoDB начинает троттлить. Результат: сбои заказов клиентов. И это не гипотетический сценарий — с этим сталкиваются многие команды eCommerce, SaaS и FinTech.

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

Задержка — не единственная проблема

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

• Пропускная способность

• Эффективное использование ресурсов

• Надёжная передача данных между компонентами

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

Вывод: задержка — это сигнал о «давлении» в системе. Её нужно воспринимать как индикатор накопления нагрузки, а не только минимизировать.

Паттерны проектирования для масштабируемости и отказоустойчивости

1. Шардирование и перемешивающее шардирование

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

Пример:
В очереди SQS несколько клиентов могут быть хэшированы на одну очередь. Если один клиент начинает генерировать пик событий, он влияет на всех остальных. Перемешивающее шардирование уменьшает вероятность этого, распределяя клиентов случайным образом по разным очередям.

2. Предварительное выделение ресурсов для критических задач

Для задач с высокой чувствительностью к задержке (например, обнаружение мошенничества в FinTech) заранее выделяйте ресурсы.

Пример:
Для AWS Lambda используйте provisioned concurrency или авто-масштабирование с выделенной параллельностью. Это гарантирует быструю обработку критических событий, сохраняя экономичность при изменении нагрузки.

Паттерны инфраструктуры

1. Очереди и буферы

Очереди SQS, Kafka, Kinesis и EventBridge действуют как буферы между продюсерами и консюмерами, поглощая резкие всплески нагрузки.

Пример:

• Реальное время кликов на рекламной платформе → Kinesis (шардирование по региону)

• Выставление счетов → FIFO SQS для гарантии порядка и предотвращения дублирования

2. Быстрый сбой и предсказуемый отказ

Если консюмер не может обработать событие (например, база данных недоступна), лучше завершить операцию с ошибкой сразу, чем блокировать очередь на длительное время.

Пример:
Контейнер Lambda зависал на аутентификации 30 секунд → добавили тайм-аут 5 секунд и явное завершение с ошибкой → очередь перестала накапливать сообщения.

Распространённые ошибки и как их избежать

1. Переоценка средней нагрузки:
   Систему нужно тестировать под резкие пики (p95, p99), а не под средние значения.

2. Повторные попытки как панацея:
   Бесконтрольные повторные попытки могут создать петли трафика и троттлинг. Используйте экспоненциальное затухание с джиттером и разделяйте ошибки на повторяемые и нет.

3. Недостаточная наблюдаемость:
   Метрики должны показывать не только ошибки и время отклика, но и глубину очередей, повторные попытки и масштабируемость компонентов.

4. Одинаковое обращение со всеми событиями:
   Событие оплаты ≠ событие логирования. Разделяйте критические и низкоприоритетные события с помощью отдельных очередей или маршрутизации в разные Lambdas.

Заключение

Отказоустойчивость — это не попытка создать «идеальную систему», а способность выдерживать удары и продолжать работу. Основные принципы:

• Эластичность и буферы, поглощающие пики нагрузки

• Умные повторные попытки

• Предсказуемые режимы отказа

• Наблюдаемость, позволяющая подтверждать работоспособность системы

С чего начать:
Создайте простое событийно-ориентированное приложение на SQS и Lambda. Попробуйте DLQ, обработку сбоев и маршрутизацию событий через EventBridge. Постепенно добавляйте шардирование, авто-масштабирование и сложные паттерны.

Отказоустойчивость — это подход, который строится шаг за шагом. Начните с малого, изучайте поведение системы и постепенно добавляйте сложность.

Введение

Перенос базы данных PostgreSQL — задача непростая, особенно для больших проектов. Часто это один из самых крупных и ответственных процессов для разработчиков и администраторов. Основные сценарии переноса включают:

• обновление до новой версии PostgreSQL;

• перенос базы на другой сервер или хостинг;

• миграция с минимальным временем простоя.

В зависимости от размера базы и ограничений инфраструктуры есть три основных подхода.

1. Перенос с помощью pg_dump и pg_restore

pg_dump позволяет создать дамп всей базы, включая схемы, таблицы и специальные объекты. Для небольших баз (50–150 ГБ) это часто самый простой вариант.

Пример использования:

pg_dump -Fc $SOURCE_DB_URI > dump_file.dump
pg_restore --no-acl --no-owner -d $TARGET_DB_URI dump_file.dump

Плюсы:

• Надёжно и просто;

• Полный дамп базы, включая схему и данные.

Минусы:

• При больших базах (сотни ГБ и выше) процесс может занять часы;

• Требуется время на восстановление и минимизация простоя.

2. Использование WAL (Write-Ahead Logging)

Если у вас настроено резервное копирование на основе WAL, например через pgBackRest, WAL-G или WAL-E, можно выполнить масштабную миграцию:

1. Создаётся полная резервная копия базы;

2. Настраивается потоковая передача WAL на новый сервер;

3. После завершения первичной синхронизации можно переключить приложение на новую базу с минимальным простоем.

Плюсы:

• Подходит для терабайтных баз;

• Минимизирует простой.

Минусы:

• Требует доступа к WAL (не поддерживается, например, в Amazon RDS).

3. Логическая миграция PostgreSQL

Логическая репликация позволяет переносить данные на новый сервер без доступа к WAL.

• Принцип работы: текущая база (publisher) передаёт изменения новой базе (subscriber);

• Репликация распространяется на данные таблиц, но не переносит схему, индексы и последовательности;

• С помощью дополнительных шагов можно выполнить полную миграцию.

Основные шаги логической миграции

Шаг 1: Перенос схемы

Сначала необходимо создать на новом сервере структуру базы:

pg_dump -Fc -s $SOURCE_DB_URI | pg_restore --no-acl --no-owner -d $TARGET_DB_URI

• При активной разработке изменений схемы: синхронизируйте изменения и на подписчике.

Шаг 2: Настройка издателя (старый сервер)

1. Включите логическую репликацию:

ALTER SYSTEM SET wal_level = logical;

2. Настройте параметры слотов репликации:

max_replication_slots
max_wal_senders
max_logical_replication_workers
max_worker_processes
max_sync_workers_per_subscription

3. Убедитесь, что сеть разрешает подключения с нового сервера.

4. Создайте пользователя для репликации:

CREATE ROLE elizabeth WITH REPLICATION LOGIN PASSWORD 'my_password';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO elizabeth;

5. Определите таблицы без первичных ключей:

select tab.table_schema, tab.table_name
from information_schema.tables tab
left join information_schema.table_constraints tco
  on tab.table_schema = tco.table_schema
  and tab.table_name = tco.table_name
  and tco.constraint_type = 'PRIMARY KEY'
where tab.table_type = 'BASE TABLE'
  and tab.table_schema not in ('pg_catalog', 'information_schema')
  and tco.constraint_name is null
order by table_schema, table_name;

• Для таких таблиц используйте уникальный индекс или REPLICA IDENTITY FULL:

ALTER TABLE tablename REPLICA IDENTITY USING INDEX idx_unique_index;
-- или
ALTER TABLE tablename REPLICA IDENTITY FULL;

6. Создайте публикацию всех таблиц:

CREATE PUBLICATION bridge_migration FOR ALL TABLES;
SELECT * FROM pg_publication_tables;

Шаг 3: Настройка подписчика (новый сервер)

Создаём подписку на публикацию:

CREATE SUBSCRIPTION bridge_migration
CONNECTION 'host={host} port=5432 dbname={database} user={login} password={password}'
PUBLICATION bridge_migration;

• Для больших баз можно ограничить число одновременно синхронизируемых таблиц через max_sync_workers_per_subscription.

Шаг 4: Мониторинг первичной загрузки

Проверяем прогресс через:

SELECT * FROM pg_stat_subscription;
SELECT * FROM pg_subscription_rel;

• Состояния таблиц:

  • i — инициализация

  • d — копирование данных

  • f — копирование завершено

  • s — синхронизация выполнена

  • r — обычная репликация

Шаг 5: Тестирование и переключение

1. Остановите запись на исходной базе;

2. Проверьте данные на новом сервере;

3. Переключите приложение на новую базу.

Шаг 6: Синхронизация последовательностей

Логическая репликация не переносит последовательности. Используйте команды setval:

SELECT
  'SELECT setval(' || quote_literal(quote_ident(n.nspname) || '.' || quote_ident(c.relname)) || ', ' || s.last_value || ');'
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_sequences s ON s.schemaname = n.nspname AND s.sequencename = c.relname
WHERE c.relkind = 'S';

• Выполните результат на новом сервере, чтобы синхронизировать все последовательности.

Заключение

Логическая репликация — безопасный и эффективный способ миграции PostgreSQL, особенно при крупных базах и ограничениях по доступу к WAL.

• Данные остаются согласованными, если схема подписчика идентична схеме издателя;

• Репликация однонаправленная, без конфликтующих записей на подписчике;

• Можно минимизировать простой при переходе на новый сервер.

«Как вы узнали о проблеме?» — «Пожаловались пользователи» — так работать нельзя. Правильный мониторинг означает, что вы знаете о проблеме раньше, чем её заметят пользователи. Эта статья о построении полноценного стека мониторинга для Linux-инфраструктуры: от сбора метрик до умных алертов.

Архитектура: что и зачем

Серверы                   Мониторинг             Визуализация
[node_exporter] ──────► [Prometheus] ──────► [Grafana]
[php-fpm_exporter]          │                    │
[mysql_exporter]            │ алерты         дашборды
[nginx_exporter]            ▼
[redis_exporter]       [Alertmanager]
                            │
                    [Email/Slack/PagerDuty]

Prometheus — это time-series база данных с pull-моделью сбора данных. Exporters на серверах открывают HTTP endpoint с метриками в формате Prometheus, и сервер Prometheus их периодически «скрейпит».

Node Exporter: метрики операционной системы

Установка

# Через пакет
apt install prometheus-node-exporter  # Ubuntu
# или скачиваем бинарник

# Проверяем endpoint
curl http://localhost:9100/metrics | head -50

Что собирает node_exporter

# CPU
node_cpu_seconds_total{cpu="0",mode="idle"}
node_cpu_seconds_total{cpu="0",mode="user"}
node_cpu_seconds_total{cpu="0",mode="system"}
node_cpu_seconds_total{cpu="0",mode="iowait"}

# Память
node_memory_MemTotal_bytes
node_memory_MemAvailable_bytes
node_memory_SwapUsed_bytes

# Диски
node_disk_read_bytes_total{device="sda"}
node_disk_written_bytes_total{device="sda"}
node_disk_io_time_seconds_total{device="sda"}

# Сеть
node_network_receive_bytes_total{device="eth0"}
node_network_transmit_bytes_total{device="eth0"}
node_network_receive_errs_total{device="eth0"}

# Файловая система
node_filesystem_avail_bytes{mountpoint="/"}
node_filesystem_size_bytes{mountpoint="/"}

# Нагрузка
node_load1   # средняя нагрузка за 1 минуту
node_load5
node_load15

Кастомные метрики через textfile collector

# Создаём директорию для textfile
mkdir -p /var/lib/node_exporter/textfile_collector

# Запускаем node_exporter с collector
/usr/bin/prometheus-node-exporter \
    --collector.textfile.directory=/var/lib/node_exporter/textfile_collector

# Скрипт для метрик приложения (запускаем по cron)
cat > /usr/local/bin/app-metrics.sh << 'EOF'
#!/bin/bash

METRICS_FILE="/var/lib/node_exporter/textfile_collector/app.prom"

# Количество PHP-FPM процессов
fpm_workers=$(ps aux | grep php-fpm | grep -v grep | wc -l)

# Количество MySQL соединений
mysql_connections=$(mysql -u monitoring -ppassword -e "SHOW STATUS LIKE 'Threads_connected';" | awk 'NR==2{print $2}')

# Место в очереди Redis
redis_queue_size=$(redis-cli llen myapp:jobs)

cat > "$METRICS_FILE" << METRICS
# HELP myapp_fpm_workers Number of PHP-FPM worker processes
# TYPE myapp_fpm_workers gauge
myapp_fpm_workers $fpm_workers

# HELP myapp_mysql_connections Active MySQL connections
# TYPE myapp_mysql_connections gauge
myapp_mysql_connections $mysql_connections

# HELP myapp_queue_size Redis job queue size
# TYPE myapp_queue_size gauge
myapp_queue_size $redis_queue_size
METRICS
EOF
chmod +x /usr/local/bin/app-metrics.sh

# Добавляем в cron (каждую минуту)
echo "* * * * * root /usr/local/bin/app-metrics.sh" > /etc/cron.d/app-metrics

Установка Prometheus

# Создаём пользователя
useradd --no-create-home --shell /bin/false prometheus

# Создаём директории
mkdir -p /etc/prometheus /var/lib/prometheus
chown prometheus:prometheus /var/lib/prometheus

# Скачиваем (проверьте актуальную версию)
cd /tmp
wget https://github.com/prometheus/prometheus/releases/download/v2.50.1/prometheus-2.50.1.linux-amd64.tar.gz
tar xvf prometheus-*.tar.gz
cp prometheus-*/prometheus /usr/local/bin/
cp prometheus-*/promtool /usr/local/bin/
cp -r prometheus-*/consoles /etc/prometheus/
cp -r prometheus-*/console_libraries /etc/prometheus/
chown prometheus:prometheus /usr/local/bin/prometheus /usr/local/bin/promtool

Конфигурация Prometheus

/etc/prometheus/prometheus.yml:

global:
  scrape_interval: 15s      # как часто собираем метрики
  evaluation_interval: 15s  # как часто оцениваем правила алертов
  scrape_timeout: 10s

# Правила алертов
rule_files:
  - /etc/prometheus/rules/*.yml

# Куда отправлять алерты
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - localhost:9093

# Источники метрик
scrape_configs:
  # Сам Prometheus
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Node exporters — наши серверы
  - job_name: 'node'
    static_configs:
      - targets:
          - 'web01:9100'
          - 'web02:9100'
          - 'db01:9100'
    # Добавляем метки для группировки
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance
    # Статические метки
    static_configs:
      - targets: ['web01:9100']
        labels:
          env: production
          role: web
      - targets: ['db01:9100']
        labels:
          env: production
          role: database

  # MySQL exporter
  - job_name: 'mysql'
    static_configs:
      - targets: ['localhost:9104']

  # Nginx exporter
  - job_name: 'nginx'
    static_configs:
      - targets: ['localhost:9113']

  # Redis exporter
  - job_name: 'redis'
    static_configs:
      - targets: ['localhost:9121']

  # PHP-FPM — через статус страницу
  - job_name: 'php-fpm'
    static_configs:
      - targets: ['localhost:9253']

  # Service discovery через файлы (удобно для динамической инфраструктуры)
  - job_name: 'dynamic-servers'
    file_sd_configs:
      - files:
          - /etc/prometheus/targets/*.yml
        refresh_interval: 30s

Systemd unit для Prometheus

[Unit]
Description=Prometheus Monitoring
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
    --config.file=/etc/prometheus/prometheus.yml \
    --storage.tsdb.path=/var/lib/prometheus \
    --storage.tsdb.retention.time=30d \
    --storage.tsdb.retention.size=10GB \
    --web.enable-lifecycle \
    --web.enable-admin-api

Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

PromQL: язык запросов

PromQL — мощный язык для работы с time-series. Основные паттерны:

# Мгновенные значения
node_memory_MemAvailable_bytes

# Использование памяти в %
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# CPU usage (rate нужен для счётчиков)
100 - (avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle"}[5m])
) * 100)

# Disk I/O latency
rate(node_disk_io_time_seconds_total[5m])

# Свободное место на диске в %
(node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100

# Количество TCP соединений по состоянию
node_netstat_Tcp_CurrEstab

# Nginx requests per second
rate(nginx_http_requests_total[5m])

# 95-й перцентиль времени ответа
histogram_quantile(0.95, 
    rate(http_request_duration_seconds_bucket[5m])
)

# Агрегация по серверам
sum by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))

# Топ 5 серверов по CPU
topk(5, 
    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100
)

Правила алертов

/etc/prometheus/rules/linux.yml:

groups:
  - name: linux_nodes
    rules:
      # CPU
      - alert: HighCPUUsage
        expr: |
          100 - (avg by (instance) (
            rate(node_cpu_seconds_total{mode="idle"}[5m])
          ) * 100) > 85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU on {{ $labels.instance }}"
          description: "CPU usage is {{ printf \"%.1f\" $value }}% on {{ $labels.instance }}"

      - alert: CriticalCPUUsage
        expr: |
          100 - (avg by (instance) (
            rate(node_cpu_seconds_total{mode="idle"}[5m])
          ) * 100) > 95
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "CRITICAL CPU on {{ $labels.instance }}"

      # Память
      - alert: HighMemoryUsage
        expr: |
          (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 90
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High memory on {{ $labels.instance }}"
          description: "Memory usage is {{ printf \"%.1f\" $value }}%"

      # Диск
      - alert: DiskSpaceLow
        expr: |
          (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 15
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Low disk space on {{ $labels.instance }}"
          description: "Only {{ printf \"%.1f\" $value }}% disk space remaining"

      - alert: DiskSpaceCritical
        expr: |
          (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 5
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "CRITICAL: Disk almost full on {{ $labels.instance }}"

      # Инод
      - alert: DiskInodesLow
        expr: |
          (node_filesystem_files_free / node_filesystem_files) * 100 < 10
        for: 2m
        labels:
          severity: warning

      # Сервер недоступен
      - alert: InstanceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Instance {{ $labels.instance }} is DOWN"

      # Load average
      - alert: HighLoadAverage
        expr: node_load1 > (count by (instance)(node_cpu_seconds_total{mode="idle"}) * 2)
        for: 5m
        labels:
          severity: warning

      # OOM Killer
      - alert: OOMKillerActive
        expr: increase(node_vmstat_oom_kill[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: "OOM Killer active on {{ $labels.instance }}"

      # Много TIME_WAIT соединений
      - alert: HighTimeWaitConnections
        expr: node_sockstat_TCP_tw > 10000
        for: 5m
        labels:
          severity: warning

Alertmanager: умная маршрутизация уведомлений

/etc/alertmanager/alertmanager.yml:

global:
  smtp_smarthost: 'smtp.gmail.com:587'
  smtp_from: 'alerts@example.com'
  smtp_auth_username: 'alerts@example.com'
  smtp_auth_password: 'password'
  
  slack_api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'

# Шаблоны уведомлений
templates:
  - /etc/alertmanager/templates/*.tmpl

# Маршрутизация
route:
  group_by: ['alertname', 'instance']
  group_wait: 30s       # ждём перед первым уведомлением
  group_interval: 5m    # интервал между повторными уведомлениями группы
  repeat_interval: 4h   # когда повторить если не решено
  
  receiver: 'slack-warnings'
  
  routes:
    # Критические — немедленно в PagerDuty
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
      group_wait: 0s
      repeat_interval: 1h
    
    # Ночью тишина для warnings
    - match:
        severity: warning
      receiver: 'slack-warnings'
      mute_time_intervals:
        - nights-and-weekends
    
    # Отдельный канал для базы данных
    - match:
        job: mysql
      receiver: 'slack-dba-channel'

# Время тишины
time_intervals:
  - name: nights-and-weekends
    time_intervals:
      - weekdays: [saturday, sunday]
      - times:
          - start_time: '22:00'
            end_time: '08:00'

# Получатели
receivers:
  - name: 'slack-warnings'
    slack_configs:
      - channel: '#alerts'
        icon_emoji: ':warning:'
        title: '{{ .GroupLabels.alertname }}'
        text: |
          {{ range .Alerts }}
          *Instance:* {{ .Labels.instance }}
          *Description:* {{ .Annotations.description }}
          {{ end }}
        send_resolved: true

  - name: 'pagerduty-critical'
    pagerduty_configs:
      - service_key: 'YOUR_PAGERDUTY_KEY'

  - name: 'slack-dba-channel'
    slack_configs:
      - channel: '#dba-alerts'

Grafana: визуализация

# Установка
apt-get install -y apt-transport-https software-properties-common
wget -q -O - https://packages.grafana.com/gpg.key | gpg --dearmor | \
    tee /usr/share/keyrings/grafana.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/grafana.gpg] \
    https://packages.grafana.com/oss/deb stable main" | \
    tee /etc/apt/sources.list.d/grafana.list
apt-get update && apt-get install grafana -y
systemctl enable --now grafana-server

Provisioning дашбордов через код

/etc/grafana/provisioning/datasources/prometheus.yaml:

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://localhost:9090
    isDefault: true
    jsonData:
      timeInterval: "15s"

/etc/grafana/provisioning/dashboards/default.yaml:

apiVersion: 1
providers:
  - name: default
    orgId: 1
    folder: ''
    type: file
    disableDeletion: false
    updateIntervalSeconds: 30
    options:
      path: /var/lib/grafana/dashboards

Готовые дашборды

На grafana.com/dashboards есть тысячи готовых дашбордов. Популярные ID для импорта:

• 1860 — Node Exporter Full

• 7362 — MySQL Overview

• 763 — Redis Dashboard

• 12708 — PHP-FPM Dashboard

• 11074 — Node Exporter for Prometheus

blackbox_exporter: мониторинг снаружи

Для мониторинга HTTP, TCP, DNS, ICMP с внешней точки зрения:

# /etc/blackbox_exporter/config.yml
modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
      valid_status_codes: []  # 2xx
      follow_redirects: true
      tls_config:
        insecure_skip_verify: false

  http_post_2xx:
    prober: http
    http:
      method: POST
      headers:
        Content-Type: application/json
      body: '{"probe": "check"}'

  tcp_connect:
    prober: tcp
    timeout: 5s

  ssl_expiry:
    prober: http
    timeout: 5s
    http:
      fail_if_ssl: false
      fail_if_not_ssl: true
      tls_config:
        insecure_skip_verify: false

В prometheus.yml добавляем:

- job_name: 'blackbox'
  metrics_path: /probe
  params:
    module: [http_2xx]
  static_configs:
    - targets:
        - https://myapp.example.com/health
        - https://api.example.com/status
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: localhost:9115

# Алерт на SSL
- alert: SSLCertExpiringSoon
  expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 30
  labels:
    severity: warning
  annotations:
    summary: "SSL cert expires in {{ $value | humanizeDuration }}"

Правильный мониторинг — это инвестиция, которая окупается при первом же инциденте, когда вы знаете о проблеме за 10 минут до того, как позвонят пользователи. Начните с node_exporter и базовых алертов, постепенно добавляйте экспортеры для ваших сервисов.

Резервное копирование в Linux: стратегии и инструменты

Правило 3-2-1

Любая стратегия резервного копирования должна начинаться с правила 3-2-1:

• 3 копии данных

• 2 разных типа носителей

• 1 копия вне офиса

Rsync: умное инкрементальное копирование

#!/usr/bin/env bash
# Скрипт резервного копирования с ротацией

BACKUP_SOURCE="/var/www"
BACKUP_DEST="/mnt/backup"
RETAIN_DAYS=30
DATE=$(date +%Y%m%d_%H%M%S)

# Создаём снэпшот через hard links (не дублируем неизменённые файлы)
rsync -avz --delete \
    --link-dest="$BACKUP_DEST/latest" \
    --exclude="*.log" \
    --exclude="cache/" \
    --exclude="tmp/" \
    "$BACKUP_SOURCE/" \
    "$BACKUP_DEST/$DATE/"

# Обновляем симлинк на последний бэкап
ln -sfn "$BACKUP_DEST/$DATE" "$BACKUP_DEST/latest"

# Удаляем старые бэкапы
find "$BACKUP_DEST" -maxdepth 1 -type d -mtime +$RETAIN_DAYS -exec rm -rf {} +

echo "Backup completed: $BACKUP_DEST/$DATE"
du -sh "$BACKUP_DEST/$DATE"

Borg: дедупликация и шифрование

Borg — продвинутый инструмент с дедупликацией (одинаковые блоки хранятся один раз):

# Установка
apt install borgbackup

# Инициализация репозитория с шифрованием
borg init --encryption=repokey-blake2 user@backup-server:/backups/myserver

# Создание бэкапа
borg create \
    --verbose \
    --filter AME \
    --list \
    --stats \
    --show-rc \
    --compression lz4 \
    --exclude-caches \
    --exclude '/home/*/.cache/*' \
    --exclude '/var/cache/*' \
    --exclude '/var/tmp/*' \
    user@backup-server:/backups/myserver::myserver-$(date +%Y%m%d_%H%M) \
    /etc \
    /var/www \
    /home \
    /var/lib/mysql  # осторожно с активной БД!

# Список архивов
borg list user@backup-server:/backups/myserver

# Проверка целостности
borg check user@backup-server:/backups/myserver

# Восстановление
cd /tmp/restore
borg extract user@backup-server:/backups/myserver::myserver-20240115_0300 \
    var/www/myapp/public  # только конкретная директория

# Ротация (хранить: 7 ежедневных, 4 недельных, 12 ежемесячных)
borg prune \
    --keep-daily=7 \
    --keep-weekly=4 \
    --keep-monthly=12 \
    user@backup-server:/backups/myserver

Бэкап MySQL без блокировок

#!/usr/bin/env bash
# Бэкап MySQL с минимальным влиянием на продакшн

DB_USER="backup"
DB_PASS="backup_password"
BACKUP_DIR="/var/backups/mysql"
DATE=$(date +%Y%m%d_%H%M)

mkdir -p "$BACKUP_DIR"

# Создаём пользователя для бэкапа (только необходимые права)
# GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER, PROCESS ON *.* TO 'backup'@'localhost';

# Бэкап всех баз
mysqldump \
    --user="$DB_USER" \
    --password="$DB_PASS" \
    --single-transaction \
    --routines \
    --triggers \
    --events \
    --all-databases \
    --master-data=2 \
    | gzip > "$BACKUP_DIR/full-$DATE.sql.gz"

# Проверяем что файл не пустой
size=$(stat -c%s "$BACKUP_DIR/full-$DATE.sql.gz")
if [[ $size -lt 1000 ]]; then
    echo "ERROR: Backup file too small ($size bytes)" >&2
    rm "$BACKUP_DIR/full-$DATE.sql.gz"
    exit 1
fi

echo "Backup created: $BACKUP_DIR/full-$DATE.sql.gz ($size bytes)"

# Ротация — удаляем старше 7 дней
find "$BACKUP_DIR" -name "full-*.sql.gz" -mtime +7 -delete

# XtraBackup для горячего бэкапа InnoDB (без --single-transaction ограничений)
# apt install percona-xtrabackup-80
# xtrabackup --backup --user="$DB_USER" --password="$DB_PASS" \
#     --target-dir="$BACKUP_DIR/xtrabackup-$DATE"

Проверка восстановления — самое важное

Бэкап без проверки восстановления — не бэкап. Автоматизируйте:

#!/usr/bin/env bash
# Тест восстановления MySQL (запускать еженедельно)

BACKUP_FILE=$(ls -t /var/backups/mysql/full-*.sql.gz | head -1)
TEST_DB="restore_test_$(date +%s)"

echo "Testing restore of $BACKUP_FILE"

# Создаём тестовую базу
mysql -e "CREATE DATABASE $TEST_DB"

# Восстанавливаем
zcat "$BACKUP_FILE" | mysql "$TEST_DB"

# Проверяем количество таблиц
table_count=$(mysql -sN -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='$TEST_DB'")
echo "Tables restored: $table_count"

# Удаляем тестовую базу
mysql -e "DROP DATABASE $TEST_DB"

if [[ $table_count -gt 0 ]]; then
    echo "Restore test PASSED"
else
    echo "Restore test FAILED!" >&2
    exit 1
fi

Nginx: тюнинг и продвинутая конфигурация

Производительность nginx

# /etc/nginx/nginx.conf

user www-data;
# Одни worker per CPU core
worker_processes auto;
# Привязываем к ядрам (снижаем context switch)
worker_cpu_affinity auto;

# Максимум соединений = worker_processes * worker_connections
events {
    worker_connections 4096;
    use epoll;           # лучший I/O multiplexer для Linux
    multi_accept on;     # принимаем все соединения за один раз
}

http {
    # Базовые оптимизации
    sendfile on;
    tcp_nopush on;       # отправлять заголовки и начало файла вместе
    tcp_nodelay on;      # отключить Nagle для активных соединений

    # Таймауты
    keepalive_timeout 65;
    keepalive_requests 1000;
    client_header_timeout 15;
    client_body_timeout 15;
    send_timeout 15;

    # Буферы
    client_body_buffer_size 128k;
    client_max_body_size 50M;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 16k;

    # Сжатие
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_comp_level 5;
    gzip_types
        text/plain
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        image/svg+xml;

    # Кэширование статики
    open_file_cache max=10000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    # Безопасность
    server_tokens off;
    more_clear_headers Server;  # если установлен nginx-extras

    # Rate limiting
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
    limit_conn_zone $binary_remote_addr zone=perip:10m;
}

Virtual host для PHP-приложения

# /etc/nginx/sites-available/myapp.conf

# Upstream pool с health checks
upstream php_fpm {
    least_conn;  # балансировка по наименее загруженному
    server 127.0.0.1:9000 weight=5 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:9001 weight=5 max_fails=3 fail_timeout=30s;
    keepalive 32;  # постоянные соединения к FPM
}

# Кэш для FastCGI ответов
fastcgi_cache_path /var/cache/nginx/fastcgi
    levels=1:2
    keys_zone=php_cache:100m
    max_size=2g
    inactive=60m
    use_temp_path=off;

server {
    listen 80;
    server_name myapp.example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name myapp.example.com;
    root /var/www/myapp/public;
    index index.php;

    # SSL
    ssl_certificate /etc/letsencrypt/live/myapp.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.example.com/privkey.pem;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_stapling on;
    ssl_stapling_verify on;

    # Безопасность
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Логи
    access_log /var/log/nginx/myapp-access.log combined buffer=512k flush=1m;
    error_log /var/log/nginx/myapp-error.log warn;

    # Ограничения
    limit_conn perip 20;

    # Статика с долгим кешированием
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        log_not_found off;
        access_log off;
    }

    # API с rate limiting
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        try_files $uri $uri/ /index.php?$query_string;
    }

    location /api/auth {
        limit_req zone=login burst=5 nodelay;
        try_files $uri $uri/ /index.php?$query_string;
    }

    # PHP-FPM
    location ~ \.php$ {
        fastcgi_pass php_fpm;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;

        # Кеширование (осторожно — только для некэшируемого поставьте X-Cache-Bypass)
        fastcgi_cache php_cache;
        fastcgi_cache_key "$scheme$request_method$host$request_uri";
        fastcgi_cache_valid 200 302 60m;
        fastcgi_cache_valid 404 1m;
        fastcgi_cache_bypass $http_pragma $http_authorization $cookie_PHPSESSID;
        fastcgi_no_cache $http_pragma $http_authorization;
        add_header X-Cache-Status $upstream_cache_status;

        # Буферизация
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;

        # Таймаут для долгих запросов
        fastcgi_read_timeout 300;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Запрещаем служебные файлы
    location ~ /\.(ht|git|env) {
        deny all;
        return 404;
    }
}

Централизованное логирование: rsyslog, loki, ELK

rsyslog: маршрутизация логов

# /etc/rsyslog.conf — продвинутая конфигурация

# Шаблоны
template(name="FileFormat" type="string"
    string="%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n"
)

# JSON формат для Logstash/Loki
template(name="JSONFormat" type="list") {
    constant(value="{")
    constant(value="\"timestamp\":\"")
    property(name="timereported" dateFormat="rfc3339")
    constant(value="\",\"host\":\"")
    property(name="hostname")
    constant(value="\",\"severity\":\"")
    property(name="syslogseverity-text")
    constant(value="\",\"facility\":\"")
    property(name="syslogfacility-text")
    constant(value="\",\"program\":\"")
    property(name="programname")
    constant(value="\",\"pid\":\"")
    property(name="procid")
    constant(value="\",\"message\":\"")
    property(name="msg" format="json")
    constant(value="\"}\n")
}

# Маршрутизация по приоритету
*.emerg  :omusrmsg:*                    # все терминалы при критической ошибке
auth,authpriv.*  /var/log/auth.log
mail.*   -/var/log/mail.log             # дефис = буферизованная запись
cron.*   /var/log/cron.log
*.warn   /var/log/warnings.log

# Отдельный файл для nginx
if $programname == 'nginx' then {
    action(type="omfile" file="/var/log/nginx/error.log" template="FileFormat")
    stop
}

# Пересылка на центральный сервер
*.* action(type="omfwd"
    target="log-server.internal"
    port="514"
    protocol="tcp"
    template="JSONFormat"
    action.resumeRetryCount="-1"
    queue.type="linkedList"
    queue.size="50000"
    queue.filename="rsyslog_queue"
    queue.saveonshutdown="on"
)

Loki + Promtail: современный стек

Loki — это "Prometheus для логов", хранит логи как метрики с метками:

# /etc/promtail/promtail-config.yaml
server:
  http_listen_port: 9080

positions:
  filename: /var/log/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: nginx
    static_configs:
      - targets: [localhost]
        labels:
          job: nginx
          env: production
          __path__: /var/log/nginx/access.log
    
    pipeline_stages:
      - regex:
          expression: '^(?P<remote_addr>\S+) - (?P<remote_user>\S+) \[(?P<time>[^\]]+)\] "(?P<method>\S+) (?P<path>[^\s"]+)[^"]*" (?P<status>\d+) (?P<body_bytes>\d+)'
      
      - labels:
          method:
          status:
      
      - metrics:
          http_requests_total:
            type: Counter
            description: "Total HTTP requests"
            source: status
            config:
              action: inc

  - job_name: php-app
    static_configs:
      - targets: [localhost]
        labels:
          job: php-app
          __path__: /var/www/myapp/storage/logs/*.log
    
    pipeline_stages:
      - multiline:
          firstline: '^\[\d{4}-\d{2}-\d{2}'
          max_wait_time: 3s
      
      - regex:
          expression: '^\[(?P<time>[^\]]+)\] (?P<env>\w+)\.(?P<level>[A-Z]+): (?P<message>.+)'
      
      - labels:
          level:
          env:

Запросы LogQL (язык Loki)

# Все ошибки nginx
{job="nginx"} |= "error"

# HTTP 500 ошибки за последний час
{job="nginx"} | regex `status=(?P<status>\d+)` | status="500"

# Медленные запросы (>1 секунды)
{job="nginx"} | regex `request_time=(?P<rt>[0-9.]+)` | rt > 1.0

# Топ URL по количеству запросов
topk(10, sum by (path) (rate({job="nginx"} | json [5m])))

# Уровень ошибок в приложении
sum(rate({job="php-app", level="ERROR"}[5m])) by (level)

Ansible: управление конфигурациями Linux-серверов

Структура Ansible-проекта

ansible/
├── ansible.cfg
├── inventory/
│   ├── production/
│   │   ├── hosts.yml
│   │   └── group_vars/
│   │       ├── all.yml
│   │       ├── web.yml
│   │       └── db.yml
│   └── staging/
│       └── hosts.yml
├── roles/
│   ├── common/
│   ├── nginx/
│   ├── php/
│   └── mysql/
└── playbooks/
    ├── site.yml
    ├── deploy.yml
    └── update.yml

ansible.cfg

[defaults]
inventory = inventory/production
remote_user = deploy
private_key_file = ~/.ssh/id_ed25519
host_key_checking = False
retry_files_enabled = False
stdout_callback = yaml
callback_whitelist = timer, profile_tasks
forks = 20

[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=60s

Роль для hardening

# roles/common/tasks/main.yml
---
- name: Update and upgrade apt packages
  apt:
    upgrade: dist
    update_cache: yes
    cache_valid_time: 3600

- name: Install required packages
  apt:
    name:
      - ufw
      - fail2ban
      - unattended-upgrades
      - logrotate
      - htop
      - curl
      - git
    state: present

- name: Configure sysctl security settings
  sysctl:
    name: "{{ item.key }}"
    value: "{{ item.value }}"
    state: present
    reload: yes
  loop: "{{ sysctl_settings }}"

- name: Configure UFW
  ufw:
    state: enabled
    policy: deny
    direction: incoming

- name: Allow SSH
  ufw:
    rule: allow
    port: "{{ ssh_port }}"
    proto: tcp

- name: Configure fail2ban
  template:
    src: jail.local.j2
    dest: /etc/fail2ban/jail.local
    owner: root
    group: root
    mode: '0644'
  notify: restart fail2ban

- name: Configure SSH
  template:
    src: sshd_config.j2
    dest: /etc/ssh/sshd_config
    validate: 'sshd -t -f %s'
    owner: root
    group: root
    mode: '0600'
  notify: restart sshd

Идемпотентность: делаем правильно

# Создание пользователя (идемпотентно)
- name: Create deploy user
  user:
    name: deploy
    groups: www-data
    shell: /bin/bash
    create_home: yes
    state: present

# Копируем SSH ключ
- name: Set authorized keys
  authorized_key:
    user: deploy
    state: present
    key: "{{ lookup('file', 'files/deploy_key.pub') }}"
    exclusive: yes  # удалить другие ключи

# Изменение конфига только если нужно
- name: Configure PHP-FPM
  template:
    src: php-fpm-pool.conf.j2
    dest: /etc/php/8.2/fpm/pool.d/www.conf
    owner: root
    group: root
    mode: '0644'
  notify: reload php-fpm

# Handlers (выполняются только если что-то изменилось)
# roles/php/handlers/main.yml
- name: reload php-fpm
  service:
    name: php8.2-fpm
    state: reloaded

- name: restart php-fpm
  service:
    name: php8.2-fpm
    state: restarted

Деплой приложения через Ansible

# playbooks/deploy.yml
---
- name: Deploy MyApp
  hosts: web
  serial: "30%"  # Rolling update: 30% серверов одновременно
  vars:
    app_dir: /var/www/myapp
    git_repo: git@github.com:company/myapp.git
    git_branch: "{{ branch | default('main') }}"

  tasks:
    - name: Pull latest code
      git:
        repo: "{{ git_repo }}"
        dest: "{{ app_dir }}"
        version: "{{ git_branch }}"
        force: yes

    - name: Install Composer dependencies
      composer:
        command: install
        working_dir: "{{ app_dir }}"
        no_dev: yes
        optimize_autoloader: yes

    - name: Run migrations
      command: php spark migrate --all
      args:
        chdir: "{{ app_dir }}"
      run_once: true  # только на одном сервере

    - name: Clear application cache
      command: php spark cache:clear
      args:
        chdir: "{{ app_dir }}"

    - name: Reload PHP-FPM (graceful)
      service:
        name: php8.2-fpm
        state: reloaded

    - name: Warm up cache
      uri:
        url: "https://{{ inventory_hostname }}/health"
        status_code: 200
      retries: 5
      delay: 2

Диагностика Linux: алгоритм поиска проблем

Методология USE

USE Method (Brendan Gregg): для каждого ресурса проверяем:

• Utilization — использование (в %)

• Saturation — насыщение (очереди, ожидание)

• Errors — ошибки

# CPU Utilization
mpstat -P ALL 1 3

# CPU Saturation (очередь на выполнение)
vmstat 1 | awk '{print $1}'  # r - run queue

# Memory Utilization
free -h

# Memory Saturation (swapping)
vmstat 1 | awk '{print $7, $8}'  # si/so - swap in/out

# Disk Utilization
iostat -xz 1 | grep -E "Device|sd|nvme"

# Disk Saturation (await > service time)
iostat -xz 1 | awk 'NR>3 {print $1, $16}'  # %util

# Network Utilization
sar -n DEV 1 5

60-секундный анализ сервера

# Быстрый обзор за 60 секунд (по Brendan Gregg)

uptime                    # load average
dmesg -T | tail -5        # ошибки ядра
vmstat -SM 1 3            # VM, CPU, I/O обзор
mpstat -P ALL 1 3         # CPU по ядрам
pidstat 1 3               # процессы
iostat -xz 1 3            # I/O дисков
free -m                   # память
sar -n DEV 1 3            # сеть
sar -n TCP,ETCP 1 3       # TCP метрики
top                       # интерактивно

Диагностика "сервер завис"

# 1. Можем ли мы что-то делать?
# Если не отвечает по SSH - физический доступ или IPMI/iLO

# 2. Что не отвечает?
ping server-ip             # сеть живая?
nc -zv server-ip 22        # SSH порт открыт?
nc -zv server-ip 80        # HTTP открыт?

# 3. Загрузка
uptime
# load: 0.5 — норма
# load: = CPU cores — занят
# load: > CPU cores * 2 — перегружен

# 4. Кто виноват?
top -bn1 | head -20
ps auxwf | head -30

# 5. Есть ли OOM?
dmesg | grep -i "oom\|killed process"
journalctl -k --since "1 hour ago" | grep -i oom

# 6. Диск переполнен?
df -h
du -sh /var /tmp /home    # кто занял место

# 7. Иноды кончились?
df -i

# 8. Что происходит с сетью?
ss -s                      # статистика сокетов
ss -tnp state time-wait | wc -l  # TIME_WAIT
netstat -i                 # ошибки на интерфейсах

# 9. Дисковые проблемы
dmesg | grep -i "error\|fail\|i/o"
smartctl -H /dev/sda       # здоровье диска

# 10. Полная картина за последний час
sar -A 1 10               # всё что собрал sar

strace и ltrace: что делает процесс

# Что делает процесс прямо сейчас
strace -p $(pgrep nginx | head -1)

# Только конкретные системные вызовы
strace -e trace=open,read,write,network -p PID

# Статистика системных вызовов за 5 секунд
strace -c -p PID -e trace=all &
sleep 5
kill %1

# ltrace — вызовы библиотечных функций
ltrace -p PID

# Запустить и трейсить
strace -e trace=network curl google.com 2>&1 | grep connect

# Дочерние процессы тоже
strace -f -p PID -o /tmp/strace.log

Анализ производительности с perf

# Профиль за 10 секунд (нужен linux-tools-generic)
perf record -F 99 -g -p $(pgrep php-fpm | head -1) -- sleep 10
perf report --stdio | head -50

# Hotspot функции
perf top -K -p $(pgrep nginx | head -1)

# Счётчики производительности
perf stat -p PID -- sleep 5
# cache-misses, branch-misses, context-switches

# Flame graph (установить FlameGraph от Brendan Gregg)
perf record -F 99 -ag -- sleep 10
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg

Диагностика сетевых задержек

# Измеряем задержки на разных уровнях
# 1. ICMP (сеть)
ping -c 100 server-ip | tail -3

# 2. TCP handshake (OS + сеть)
hping3 -S -c 100 -p 80 server-ip | tail -5

# 3. HTTP time_to_first_byte (приложение)
curl -o /dev/null -s -w "
dns:      %{time_namelookup}s
connect:  %{time_connect}s
tls:      %{time_appconnect}s
ttfb:     %{time_starttransfer}s
total:    %{time_total}s
" https://myapp.example.com

# 4. Детальная трассировка HTTP
curl -v --trace-time https://myapp.example.com 2>&1 | head -50

# 5. Tcpdump для анализа конкретного запроса
tcpdump -i eth0 -w request.pcap host client-ip and port 443
# Открываем в Wireshark для детального анализа

# 6. Статистика задержки на уровне сокета
ss -ti  # socket timing info

Инструменты для экстренной диагностики: шпаргалка

# Процессы
ps auxwf               # дерево процессов
pstree -pu             # красивое дерево
pgrep -a nginx         # найти процессы
lsof -p PID            # файлы процесса
lsof -i :80            # кто слушает порт 80
fuser -n tcp 80        # pid процесса на порту

# Файловая система
lsof +D /var/log       # кто держит файлы в директории
inotifywait -m /etc/passwd  # слежка за изменениями
find / -newer /tmp/stamp -type f 2>/dev/null  # что изменилось с timestamp

# Сеть
tcpdump -i any port 80 -nn -q
conntrack -L | wc -l   # количество трекируемых соединений
nmap -sV localhost     # сканируем себя

# История команд в случае инцидента
history | grep -i "rm\|mv\|chmod\|dd" | tail -20
last | head -20        # последние логины
lastb | head -10       # неудачные логины
who                    # кто сейчас залогинен
w                      # что они делают

Диагностика — это смесь знаний, методологии и опыта. Самые ценные навыки: не паниковать, следовать методологии USE, измерять прежде чем делать выводы, и помнить что 90% проблем с производительностью — это диск, память или сеть, а не код.

Почему Ceph, а не просто NAS или SAN?

Представьте ситуацию: у вас 50 серверов, каждый с несколькими терабайтами данных, виртуальные машины, S3-хранилище для бэкапов, общий файловый ресурс для кластера Kubernetes — и всё это нужно хранить надёжно, быстро и так, чтобы смерть одного (или нескольких) серверов не привела к потере данных и даунтайму.

Традиционные решения здесь ломаются. NAS — единая точка отказа. SAN — дорого, сложно, проприетарно. RAID — не масштабируется за пределы одной машины. Ceph решает эту задачу радикально иначе: он распределяет данные по всем дискам всех серверов одновременно, и любой узел может умереть прямо сейчас, пока вы это читаете, — вы ничего не потеряете.

Ceph используют CERN (те самые, что ищут бозон Хиггса), крупнейшие облачные провайдеры, Proxmox, OpenStack — в общем, люди, которым нельзя терять данные. Давайте разберёмся, как это устроено.

Три уровня хранения в одном кластере

Ceph — это не одна технология, это три совершенно разных интерфейса хранения, построенных поверх одного движка:

┌─────────────────────────────────────────────────┐
│              Приложения и клиенты               │
├──────────────┬──────────────┬───────────────────┤
│   RBD        │   CephFS     │   RGW (S3/Swift)  │
│  Блочное     │  Файловая    │  Объектное         │
│  хранилище   │  система     │  хранилище         │
├──────────────┴──────────────┴───────────────────┤
│                    RADOS                        │
│        (Reliable Autonomic Distributed          │
│              Object Store)                      │
├─────────────────────────────────────────────────┤
│         OSD OSD OSD OSD OSD OSD OSD             │
│         (физические диски/SSD/NVMe)             │
└─────────────────────────────────────────────────┘

RBD (RADOS Block Device) — виртуальный блочный диск. С точки зрения виртуальной машины или Kubernetes pod — это просто диск. Внутри он разбит на объекты по 4 МБ (по умолчанию) и размазан по всему кластеру. Размер — до 16 эксабайт.

CephFS — POSIX-совместимая распределённая файловая система. Монтируется как обычная папка, понимает права доступа, символические ссылки, всё как у людей. Метаданные хранит отдельно от данных через специальный демон MDS.

RGW (RADOS Gateway) — HTTP-интерфейс объектного хранилища, совместимый с Amazon S3 и OpenStack Swift. Загружаете файлы через API, получаете бакеты, версионирование, lifecycle-политики — всё как в S3.

Самое красивое: всё три интерфейса используют один и тот же кластер RADOS. Вы можете одновременно монтировать CephFS на NFS-сервере, раздавать RBD-диски виртуалкам Proxmox и гонять бэкапы в RGW — и все они делят одни и те же физические диски.

Архитектура: четыре типа демонов

Ceph-кластер — это набор демонов, каждый со своей ролью. Никаких монолитов, никакого единого «сервера хранилища».

MON — Monitor (мозг кластера)

MON1  MON2  MON3
  \     |     /
   \    |    /
    кластерная карта
    (cluster map)

Мониторы хранят карту кластера — полное описание топологии: какие OSD существуют, где они физически расположены, здоровы ли они. Это не данные, это метаданные. Мониторы работают по протоколу Paxos и требуют кворума: нужно нечётное число, минимум 3 в продакшне.

Без кворума мониторов — нет записи (но чтение может работать). Мониторы не хранят пользовательские данные вообще — они лёгкие, их можно держать даже на небольших VM.

OSD — Object Storage Daemon (мышцы кластера)

Один OSD = один физический диск (или раздел). OSD хранит данные, обслуживает запросы чтения/записи, участвует в репликации, сам находит соседей для репликации по карте кластера.

Типичный сервер в кластере: 12 дисков = 12 OSD-процессов + небольшой SSD для BlueStore WAL/DB.

OSD общаются напрямую — без центрального сервера хранения. Если клиент пишет данные в pool с репликацией 3x, primary OSD сам синхронно реплицирует на двух соседей и только потом отвечает клиенту «записано».

MDS — Metadata Server

Нужен только для CephFS. Хранит иерархию директорий и метаданные файлов (права, размеры, время). Данные файлов хранятся в обычных RADOS-объектах — MDS только помогает по пути /my/dir/file.txt найти нужные объекты.

Можно запустить несколько MDS для параллелизма — активный-активный режим (multi-MDS).

MGR — Manager

Менеджер собирает статистику, запускает модули (dashboard, prometheus-экспортер, балансировщик), обрабатывает оркестровку через cephadm. Нужно минимум 2 для отказоустойчивости (один active, один standby).

CRUSH: как Ceph решает, куда положить данные

Вот где начинается самое интересное. В обычном RAID контроллер знает: «диск 1, 2, 3». В Ceph нет центрального индекса «где лежит файл» — это было бы узким местом в огромном кластере.

Вместо этого используется алгоритм CRUSH (Controlled Replication Under Scalable Hashing). Зная только имя объекта и карту кластера, CRUSH детерминированно вычисляет, на каких OSD хранить данные — без запросов к какому-либо серверу метаданных.

object "my_file_chunk_0042" 
    │
    ▼
pg_id = hash(object_name) % pg_count
    │
    ▼
CRUSH(pg_id, crush_map) → [OSD.7, OSD.23, OSD.41]

Когда приходит запрос «где лежит объект X» — любой клиент, зная карту кластера, сам вычисляет ответ и идёт напрямую к нужному OSD. Без промежуточных серверов. Это и есть причина масштабируемости.

Placement Groups (PG): промежуточный уровень

Объектов в кластере могут быть миллиарды. Если бы каждый объект CRUSH маппил напрямую на OSD — карта кластера была бы гигантской. Поэтому объекты сначала группируются в Placement Groups (PG), а уже PG маппятся на OSD.

Объект → PG (группа объектов) → OSD

Число PG на pool — важный параметр настройки. Слишком мало — неравномерное распределение, узкое место. Слишком много — накладные расходы. Золотое правило: ~100 PG на OSD в pool.

CRUSH Map: физическая топология

CRUSH знает физику вашего датацентра:

datacenter DC1
├── rack Rack-A
│   ├── host server-01
│   │   ├── osd.0 (weight 1.0)
│   │   ├── osd.1 (weight 1.0)
│   │   └── osd.2 (weight 1.0)
│   └── host server-02
│       ├── osd.3
│       └── osd.4
└── rack Rack-B
    └── host server-03
        ├── osd.5
        └── osd.6

Правило репликации может звучать так: «три копии, каждая на отдельном rack'е». Тогда при смерти целого стойки ни одна PG не потеряет больше одной копии данных.

BlueStore: почему Ceph не использует ext4 или XFS

До Ceph 12 OSD хранил данные на обычной файловой системе (FileStore). Это работало, но было медленно: каждая запись проходила через XFS/ext4 со всеми их накладными расходами, двойным кешированием, лишними syscall'ами.

С Ceph 12 появился BlueStore — кастомный бэкенд хранения, который работает напрямую с блочным устройством, минуя файловую систему. FileStore официально удалён начиная с Reef (18.x).

Архитектура BlueStore

OSD Process
├── BlueStore
│   ├── RocksDB (метаданные объектов, omap)
│   │   └── хранится на быстром SSD/NVMe (BlueFS)
│   ├── WAL (write-ahead log)
│   │   └── тоже лучше на SSD
│   └── данные объектов
│       └── на основном диске (HDD или SSD)
└── BlueFS (микрофайловая система для RocksDB)

В Tentacle (20.x) BlueStore получил улучшенное сжатие и новый, более быстрый WAL — это не маркетинг, а реальные измеримые улучшения для workload'ов с частой записью.

Ключевые преимущества BlueStore:

• Полный контроль над I/O без лишних слоёв

• Атомарные транзакции без двойного буферирования

• Встроенное сжатие (zlib, snappy, zstd, lz4)

• Checksums для данных и метаданных (обнаружение битрот)

• Эффективный omap для небольших значений ключ-значение

Репликация vs. Erasure Coding: выбираем стратегию

Репликация (Replication)

Простейший вариант: каждый объект хранится в N копиях на N разных OSD.

Запись "hello.txt":
    [OSD.5 — первичная копия]
        ├── реплицирует → [OSD.12 — копия 2]
        └── реплицирует → [OSD.31 — копия 3]

Плюсы: простота, низкая latency, любой OSD может обслужить чтение. Минусы: 3x overhead по дисковому пространству.

Для продакшна стандарт — size=3, min_size=2. Это значит: нормальный режим — 3 копии, деградированный (когда один OSD умер) — 2 копии, меньше 2 — запись заблокирована.

Erasure Coding (EC)

EC — это как RAID 5/6, но распределённый. Данные разбиваются на K кусков, добавляются M паритетных кусков. Всего K+M кусков на K+M OSD. Для восстановления нужно любые K из K+M кусков.

Пример EC 4+2:
  chunk0 chunk1 chunk2 chunk3 | parity0 parity1
   OSD.1  OSD.2  OSD.3  OSD.4    OSD.5   OSD.6

При смерти OSD.2 и OSD.5 — данные восстанавливаются из оставшихся 4 из 6.

Плюсы: экономия места. EC 4+2 даёт overhead 1.5x против 3x для репликации. Минусы: сложнее, выше latency, CPU overhead на кодирование/декодирование.

EC оптимально для холодного хранилища, S3-бэкапов, больших объектов. Для горячих IOPS-нагруженных данных (БД, VM) — репликация.

FastEC в Tentacle: революция для Erasure Coding

В Ceph Tentacle (20.2.0) появилась долгожданная функция FastEC — принципиально новая реализация I/O для EC пулов с поддержкой partial reads и partial writes.

До FastEC: запись небольшого объекта в EC-пул требовала читать все K кусков, обновлять данные, пересчитывать все паритеты и писать всё обратно. Это называется Read-Modify-Write (RMW) — катастрофа для производительности при мелких записях.

FastEC оптимизирует именно этот случай. По словам разработчиков и независимым тестам, на определённых workload'ах FastEC обгоняет даже репликацию 3x по производительности — при вдвое меньшем расходе места.

Важно: FastEC включается явно на уровне пула командой allow_ec_optimizations:

ceph osd pool set mypool allow_ec_optimizations true

Существующие пулы можно мигрировать без пересоздания данных — достаточно обновить OSD и MON до Tentacle.

Что нового в Ceph Tentacle (20.2.0)

Tentacle вышел 18 ноября 2025 года и является 20-м стабильным релизом Ceph. Это значительный релиз, не косметический. Вот главное:

FastEC — новый движок Erasure Coding

Уже разобрали выше. Переключение плагина по умолчанию с устаревшего Jerasure на ISA-L (Intel ISA-L library) — более быстрый, активно поддерживаемый. Jerasure больше не обслуживается авторами.

SMB-поддержка через Ceph

Ceph теперь умеет создавать SMB-шары прямо из кластера через новый модуль mgr. Технически это Samba поверх CephFS с автоматическим управлением через cephadm. Поддерживает Active Directory и standalone. Работает в кластерном режиме через CTDB.

ceph smb cluster create mysmb active-directory DC=corp,DC=example,DC=com \
  --domain-realm corp.example.com

mgmt-gateway: единая точка входа для управления

Новый сервис mgmt-gateway — nginx reverse proxy с TLS, который объединяет Dashboard, Prometheus, Grafana, Alertmanager под одним адресом. Никаких «зайди на порт 8443 для дашборда, 9090 для Prometheus, 3000 для Grafana».

Плюс интеграция с OAuth 2.0/OIDC для SSO. Настраивается через cephadm в пару команд.

certmgr: автоматические TLS-сертификаты

Подсистема управления сертификатами. Ceph теперь сам выступает корневым CA, выпускает сертификаты для своих сервисов, обновляет их автоматически, предупреждает об истечении. Никаких самоподписанных сертификатов вручную.

Data Availability Score

Новая команда для мониторинга доступности данных:

ceph osd pool availability-status

Показывает «score» для каждого пула — сколько данных доступно прямо сейчас. Пул считается недоступным если любая PG не в состоянии active или есть unfound объекты.

Crimson OSD + SeaStore (Tech Preview)

Crimson — полностью переписанный OSD на основе Seastar (асинхронный, без блокирующих операций). В Tentacle к нему добавили развёртывание SeaStore — нового бэкенда хранения рядом с Crimson. Это всё ещё tech preview, в продакшне не используем — но прогресс виден.

Удаление устаревших модулей

Модули mgr/restful и mgr/zabbix официально удалены. Они были deprecated с 2020 года и имели уязвимости в зависимостях (CVE-2023-46136). Переходите на Dashboard API и Prometheus.

Когда Ceph — правильный выбор

Ceph имеет смысл когда у вас:

• Минимум 3 физических сервера (иначе нет смысла в распределённости)

• Объём данных от нескольких терабайт

• Потребность в нескольких типах хранилища одновременно (block + object + file)

• Нужна горизонтальная масштабируемость: добавил серверы → ёмкость и производительность выросли

• Нужна отказоустойчивость без дорогого проприетарного железа

Когда Ceph — не правильный выбор:

• Один сервер или только два — берите ZFS/BTRFS

• Небольшой проект: overhead на управление не окупится

• Нужна очень низкая latency (< 1ms) для транзакционной БД — NVMe All-Flash Array или local SSD в приоритете

Итог: ключевые концепции для запоминания

В следующей статье мы разворачиваем реальный кластер с нуля через cephadm, настраиваем пулы и подключаем RBD к Proxmox.

Далее читай - Часть #2

В прошлой статье мы разобрались с теорией — теперь руки в землю. Будем разворачивать минимальный продакшн-кластер Ceph Tentacle (20.2.x) через cephadm — официальный инструмент оркестровки, который умеет всё: установку, конфигурирование, обновление, добавление узлов.

Что мы будем строить

Минимальная продакшн-конфигурация:

┌─────────────────────────────────────────────────────┐
│  ceph-node1  │  ceph-node2  │  ceph-node3           │
│              │              │                       │
│  MON + MGR   │  MON + MGR   │  MON                 │
│  OSD.0       │  OSD.3       │  OSD.6               │
│  OSD.1       │  OSD.4       │  OSD.7               │
│  OSD.2       │  OSD.5       │  OSD.8               │
│              │              │                       │
│  /dev/sdb    │  /dev/sdb    │  /dev/sdb            │
│  /dev/sdc    │  /dev/sdc    │  /dev/sdc            │
│  /dev/sdd    │  /dev/sdd    │  /dev/sdd            │
└─────────────────────────────────────────────────────┘

Требования к каждому узлу:

• OS: Ubuntu 22.04 LTS или Debian 12 (рекомендуется), RHEL 9 тоже ок

• RAM: минимум 16 GB (рекомендуется 32+ GB для продакшна)

• CPU: 4+ ядра

• Сеть: минимум 1 GbE, лучше 10 GbE; отдельная сеть для репликации — хорошая идея

• Диски: минимум 1 диск для OSD (не системный!), лучше SSD или NVMe

Важно: диски для OSD должны быть пустыми — без разделов, без файловых систем. BlueStore сам их форматирует.

Шаг 1: Подготовка всех узлов

Выполняем на каждом из трёх узлов.

Обновление системы и базовые пакеты

apt update && apt upgrade -y
apt install -y \
    chrony \
    curl \
    python3 \
    python3-pip \
    lvm2 \
    podman \   # или docker
    ntp

Почему chrony важен: Ceph очень чувствителен к рассинхронизации времени. Разница > 5 секунд между узлами вызывает предупреждения и может дестабилизировать кластер. Убедитесь что NTP работает:

timedatectl status
chronyc tracking

Настройка hostname и /etc/hosts

# На ceph-node1:
hostnamectl set-hostname ceph-node1

# На всех трёх узлах добавляем в /etc/hosts:
cat >> /etc/hosts << 'EOF'
192.168.10.11  ceph-node1
192.168.10.12  ceph-node2
192.168.10.13  ceph-node3
EOF

SSH ключи: cephadm общается через SSH

Генерируем ключ на первом узле (bootstrap узел) и распространяем:

# На ceph-node1:
ssh-keygen -t ed25519 -N "" -f /root/.ssh/id_ed25519

# Копируем на все узлы (включая node1 самого себя):
for node in ceph-node1 ceph-node2 ceph-node3; do
    ssh-copy-id -i /root/.ssh/id_ed25519.pub root@$node
done

# Проверяем:
for node in ceph-node1 ceph-node2 ceph-node3; do
    echo "=== $node ==="
    ssh root@$node "hostname && uname -r"
done

Подготовка дисков: убеждаемся что они чистые

# Проверяем состояние дисков
lsblk
fdisk -l /dev/sdb
wipefs -a /dev/sdb  # если нужно очистить

# cephadm сам зачистит диски при добавлении — если они "чистые"
# (без LVM, без партиций, без файловой системы)
# Принудительно зачистить:
ceph-volume lvm zap /dev/sdb --destroy  # после установки ceph

Шаг 2: Bootstrap первого узла

Устанавливаем cephadm

# На ceph-node1:
curl --silent --remote-name --location \
    https://github.com/ceph/ceph/raw/reef/src/cephadm/cephadm

chmod +x cephadm

# Устанавливаем в систему
./cephadm install

# Добавляем репозиторий Tentacle
cephadm add-repo --release tentacle

# Устанавливаем ceph-common (для команды ceph)
cephadm install ceph-common

Bootstrap кластера

cephadm bootstrap \
    --mon-ip 192.168.10.11 \
    --cluster-network 192.168.20.0/24 \
    --initial-dashboard-user admin \
    --initial-dashboard-password 'YourStrongPassword!123' \
    --allow-fqdn-hostname \
    --skip-monitoring-stack  # добавим мониторинг позже отдельно

Что делает эта команда за кулисами:

1. Создаёт директории конфигурации /etc/ceph/

2. Генерирует ключи аутентификации

3. Поднимает первый MON в контейнере

4. Поднимает MGR

5. Активирует модуль Dashboard

6. Пишет /etc/ceph/ceph.conf и /etc/ceph/ceph.client.admin.keyring

После успешного выполнения вы увидите URL дашборда:

Ceph Dashboard is now available at:
             URL: https://ceph-node1:8443/
            User: admin
        Password: YourStrongPassword!123

Параметр --cluster-network: Это сеть для трафика репликации между OSD. Если у вас только одна сеть — уберите этот параметр. Но если есть выделенная сеть — обязательно используйте её, это критично для производительности публичной сети.

Шаг 3: Добавляем узлы в кластер

Проверяем первый узел

ceph status
# Должны увидеть: mon: 1 mons at quorum...
# health: HEALTH_WARN (это нормально на старте)

ceph orch status
# Оркестратор должен быть активен

Добавляем ceph-node2 и ceph-node3

# На ceph-node1 — добавляем public SSH ключ cephadm в авторизованные на узлах
ceph cephadm get-pub-key > /tmp/ceph.pub

ssh root@ceph-node2 "mkdir -p /root/.ssh && \
    cat >> /root/.ssh/authorized_keys" < /tmp/ceph.pub

ssh root@ceph-node3 "mkdir -p /root/.ssh && \
    cat >> /root/.ssh/authorized_keys" < /tmp/ceph.pub

# Добавляем хосты в кластер
ceph orch host add ceph-node2 192.168.10.12
ceph orch host add ceph-node3 192.168.10.13

# Проверяем
ceph orch host ls

Шаг 4: Добавляем MON и MGR

# По умолчанию cephadm хочет 5 MON — для нас 3 достаточно
ceph orch apply mon 3

# Проверяем что MON есть на всех трёх узлах
ceph orch ps --daemon-type mon

# Добавляем второй MGR (для failover)
ceph orch apply mgr 2

Ждём пока cephadm автоматически запустит MON на node2 и node3. Следим:

watch ceph status
# Ждём: mon: 3 mons at quorum ceph-node1,ceph-node2,ceph-node3

Шаг 5: Добавляем OSD — сердце кластера

Инвентаризация доступных дисков

# Смотрим что cephadm видит на всех узлах
ceph orch device ls

# Вывод покажет диски и их статус:
# HOST        PATH      TYPE  SIZE  AVAILABLE  REFRESHED
# ceph-node1  /dev/sdb  hdd   2TiB  Yes        12s ago
# ceph-node1  /dev/sdc  hdd   2TiB  Yes        12s ago
# ...

Диск помечен как AVAILABLE если он полностью пустой. Если нет — смотрим причину в колонке REJECT REASONS.

Автоматическое добавление всех доступных дисков

# Самый простой способ — использовать все доступные диски
ceph orch apply osd --all-available-devices

# Следим за прогрессом
watch ceph osd tree

Ручное добавление конкретных дисков (рекомендуется для продакшна)

# Добавляем по одному — больше контроля
ceph orch daemon add osd ceph-node1:/dev/sdb
ceph orch daemon add osd ceph-node1:/dev/sdc
ceph orch daemon add osd ceph-node1:/dev/sdd

ceph orch daemon add osd ceph-node2:/dev/sdb
ceph orch daemon add osd ceph-node2:/dev/sdc
ceph orch daemon add osd ceph-node2:/dev/sdd

ceph orch daemon add osd ceph-node3:/dev/sdb
ceph orch daemon add osd ceph-node3:/dev/sdc
ceph orch daemon add osd ceph-node3:/dev/sdd

OSD Service Spec для воспроизводимой конфигурации

Для инфраструктуры-как-код создаём spec-файл:

# osd-spec.yaml
service_type: osd
service_id: default
placement:
  host_pattern: 'ceph-node*'
data_devices:
  paths:
    - /dev/sdb
    - /dev/sdc
    - /dev/sdd
# Если есть отдельные SSD для WAL/DB:
# db_devices:
#   paths:
#     - /dev/nvme0n1
# wal_devices:
#   paths:
#     - /dev/nvme1n1

ceph orch apply -i osd-spec.yaml

Шаг 6: Проверяем здоровье кластера

После добавления OSD кластер начнёт балансировку данных (backfill). Это нормально и займёт время. Следим:

# Общий статус
ceph status

# Подробный статус OSD
ceph osd stat
ceph osd df  # использование дискового пространства

# Статус PG
ceph pg stat

# Потребление ресурсов
ceph df detail

# Дерево OSD с весами
ceph osd tree

Хорошее состояние:

cluster:
  id:     a7f64266-0894-4f1e-a635-d0aeaca0e993
  health: HEALTH_OK

services:
  mon: 3 daemons, quorum ceph-node1,ceph-node2,ceph-node3
  mgr: ceph-node1.xxx(active), ceph-node2.xxx(standby)
  osd: 9 osds: 9 up (since 5m), 9 in (since 5m)

data:
  pools: 1 pools, 1 pgs
  objects: 0 objects, 0 B
  usage:   450 MiB used, 54 TiB / 54 TiB avail
  pgs:     1 active+clean

Шаг 7: Создаём пулы хранения

Пул — логический контейнер для данных. Каждый пул имеет свою политику репликации/EC, количество PG и другие параметры.

Пул с репликацией 3x (для VM, баз данных)

# Создаём пул
ceph osd pool create vmpool 32 32  # 32 PG

# Настраиваем репликацию
ceph osd pool set vmpool size 3      # 3 копии
ceph osd pool set vmpool min_size 2  # минимум 2 для записи

# Тип пула - для RBD
ceph osd pool application enable vmpool rbd

# Инициализируем для RBD
rbd pool init vmpool

# Проверяем
ceph osd pool ls detail

Сколько PG нужно?

Формула: PG = (OSDs * 100) / pool_size

Для нашего кластера (9 OSD, репликация 3):

• PG = (9 * 100) / 3 = 300 — но возьмём ближайшую степень 2 = 256

# Изменить количество PG (только увеличение)
ceph osd pool set vmpool pg_num 64
ceph osd pool set vmpool pgp_num 64

С Ceph Luminous появился PG autoscaler — он сам подбирает оптимальное число PG:

# Включаем автоскалер для пула
ceph osd pool set vmpool pg_autoscale_mode on

# Глобально включить автоскалер
ceph mgr module enable pg_autoscaler
ceph config set global osd_pool_default_pg_autoscale_mode on

Пул с Erasure Coding (для S3/бэкапов)

# Создаём EC-профиль
# k=4 data chunks, m=2 parity chunks = 6 OSD минимум
# overhead = 1.5x против 3x у репликации
ceph osd erasure-code-profile set myec \
    k=4 m=2 \
    plugin=isa \
    crush-failure-domain=host

# Просматриваем профиль
ceph osd erasure-code-profile get myec

# Создаём пул с EC
ceph osd pool create ecpool 32 32 erasure myec

# Включаем FastEC оптимизации (Tentacle 20.x+)
ceph osd pool set ecpool allow_ec_optimizations true

# Для работы RGW с EC нужен overlay pool
ceph osd pool create ecpool-index 16  # репликация для индексов
ceph osd pool application enable ecpool rgw
ceph osd pool application enable ecpool-index rgw

Шаг 8: Подключаем RBD — блочное хранилище

Создаём RBD-образ

# Создаём образ диска 100 GB
rbd create --size 102400 vmpool/myvm-disk01

# Смотрим информацию
rbd info vmpool/myvm-disk01

# Листинг образов в пуле
rbd ls vmpool

# Размер всех образов
rbd du vmpool

Монтируем на Linux через kernel driver

# Маппируем образ как блочное устройство
rbd device map vmpool/myvm-disk01 --id admin \
    --keyring /etc/ceph/ceph.client.admin.keyring

# Видим устройство
rbd device list
# /dev/rbd0 → vmpool/myvm-disk01

# Форматируем и монтируем
mkfs.xfs /dev/rbd0
mkdir /mnt/rbd-data
mount /dev/rbd0 /mnt/rbd-data

# Авто-монтирование через /etc/fstab через rbdmap
# /etc/ceph/rbdmap:
# vmpool/myvm-disk01 id=admin,keyring=/etc/ceph/ceph.client.admin.keyring
systemctl enable rbdmap

RBD для Proxmox VE

Proxmox имеет встроенную поддержку Ceph. Добавляем через GUI или:

# На Proxmox хосте устанавливаем ceph-клиент
apt install ceph-common

# Копируем конфиг и ключ с Ceph кластера
scp root@ceph-node1:/etc/ceph/ceph.conf /etc/pve/ceph.conf
scp root@ceph-node1:/etc/ceph/ceph.client.admin.keyring \
    /etc/pve/priv/ceph/

# Или создаём отдельного пользователя с ограниченными правами
ceph auth get-or-create client.proxmox \
    mon 'profile rbd' \
    osd 'profile rbd pool=vmpool' \
    mgr 'profile rbd pool=vmpool' \
    > /tmp/ceph.client.proxmox.keyring

# Добавляем Ceph storage в Proxmox
pveceph pool create vmpool --pg_num 64 --pg_autoscale_mode on

Шаг 9: CephFS — распределённая файловая система

# Создаём CephFS (автоматически создаёт metadata и data пулы)
ceph fs volume create myfs --placement="3"

# Проверяем статус MDS
ceph mds stat
ceph fs status myfs

# Монтируем через FUSE (для тестов)
apt install ceph-fuse
mkdir /mnt/cephfs
ceph-fuse /mnt/cephfs -m ceph-node1:6789

# Или через kernel driver (лучше производительность)
# Получаем ключ
ceph auth get-key client.admin | base64
# Монтируем:
mount -t ceph ceph-node1:6789:/ /mnt/cephfs \
    -o name=admin,secret=<base64-key>

# В /etc/fstab:
# ceph-node1:6789,ceph-node2:6789:/ /mnt/cephfs ceph \
#   name=admin,secretfile=/etc/ceph/admin.secret,noatime 0 0

Subvolumes для Kubernetes

# Создаём subvolume group
ceph fs subvolumegroup create myfs k8s

# Создаём subvolume (persistent volume)
ceph fs subvolume create myfs pvc-001 --group-name k8s --size 10G

# Получаем путь
ceph fs subvolume getpath myfs pvc-001 --group-name k8s
# /volumes/k8s/pvc-001/...

Шаг 10: RGW — S3-совместимое объектное хранилище

# Разворачиваем RGW через cephadm
ceph orch apply rgw myrgw --placement="2 ceph-node1 ceph-node2" \
    --port=8080

# Проверяем статус
ceph orch ps --daemon-type rgw

# Создаём пользователя
radosgw-admin user create \
    --uid=s3user \
    --display-name="S3 User" \
    --email=s3user@example.com

# Получаем ключи
radosgw-admin user info --uid=s3user
# access_key и secret_key для S3 клиентов

# Тестируем через s3cmd или mc (MinIO client)
apt install s3cmd
s3cmd --configure  # вводим access_key, secret_key, endpoint

# Или через AWS CLI
aws configure  # вводим ключи
aws --endpoint-url http://ceph-node1:8080 s3 mb s3://mybucket
aws --endpoint-url http://ceph-node1:8080 s3 ls
aws --endpoint-url http://ceph-node1:8080 s3 cp /tmp/test.txt s3://mybucket/

Шаг 11: Стек мониторинга

Ceph Tentacle поставляет готовый стек мониторинга через cephadm. В Tentacle появился новый mgmt-gateway — единая точка входа:

# Разворачиваем полный стек мониторинга
ceph orch apply prometheus
ceph orch apply grafana
ceph orch apply alertmanager
ceph orch apply node-exporter

# Новый в Tentacle: mgmt-gateway (nginx reverse proxy + TLS)
cat > mgmt-gateway.yaml << 'EOF'
service_type: mgmt-gateway
placement:
  count: 2  # HA — два инстанса
spec:
  port: 443
  enable_auth: true  # требовать аутентификацию
EOF

ceph orch apply -i mgmt-gateway.yaml

# Проверяем
ceph orch ps --daemon-type mgmt-gateway

Теперь Dashboard, Grafana, Prometheus — всё доступно через один HTTPS endpoint на порту 443.

Встроенные Grafana-дашборды Ceph показывают:

• OSD latency и throughput

• Pool utilization

• MON quorum status

• PG состояния

• Алерты

Полезные команды для ежедневной работы

# === КЛАСТЕР ===
ceph status              # общий статус
ceph health detail       # детали о проблемах
ceph df                  # использование пространства
ceph versions            # версии всех демонов

# === OSD ===
ceph osd tree            # топология
ceph osd df              # место по OSD
ceph osd perf            # latency метрики
ceph osd dump            # полный дамп карты OSD

# Вывести из эксплуатации OSD (graceful)
ceph osd out osd.5
ceph osd drain osd.5     # ждём пока PG переедут

# === PG ===
ceph pg stat             # статус всех PG
ceph pg dump | grep -v active+clean  # проблемные PG
ceph pg repair 1.a3      # принудительный repair конкретной PG

# === Логи ===
ceph log last 20         # последние записи кластерного лога
journalctl -u ceph-osd@0 -f  # лог конкретного OSD

# === Оркестратор ===
ceph orch ls             # список сервисов
ceph orch ps             # список демонов с состоянием
ceph orch events         # события оркестратора

Типичные проблемы при развёртывании

HEALTH_WARN: too few PGs

ceph health detail
# HEALTH_WARN too few PGs per OSD

# Увеличиваем PG для затронутых пулов
ceph osd pool set vmpool pg_num 64
ceph osd pool set vmpool pgp_num 64

OSD не добавляется: диск не определяется как доступный

# Смотрим причины отказа
ceph orch device ls --wide

# Часто причина: старые сигнатуры на диске
# Зачищаем через ceph-volume
cephadm shell -- ceph-volume lvm zap /dev/sdb --destroy

# Или более агрессивно
wipefs -a /dev/sdb
dd if=/dev/zero of=/dev/sdb bs=4M count=10

clock skew detected

# Проверяем время на всех узлах
for node in ceph-node1 ceph-node2 ceph-node3; do
    echo "$node: $(ssh root@$node date)"
done

# На проблемном узле — синхронизируем немедленно
chronyc makestep
timedatectl set-ntp true

Кластер застрял в rebalancing надолго

# Смотрим прогресс
ceph progress

# Ускоряем (только во время обслуживания, не в бою)
ceph tell osd.* injectargs --osd-max-backfills 8
ceph tell osd.* injectargs --osd-recovery-max-active 8

# После — возвращаем в норму
ceph tell osd.* injectargs --osd-max-backfills 3

В следующей, финальной статье: производительность и тюнинг кластера, стратегии апгрейда с предыдущих версий, disaster recovery и продвинутые сценарии использования.

Далее читай - Часть #3

Кластер работает. Теперь начинается настоящая работа: выжать из него максимум производительности, не потерять данные при апгрейде и знать, что делать когда (не «если») что-то сломается.

Часть 1: Планирование железа — правильный старт

Перед тем как тюнить — убедитесь что железо подобрано правильно. Никакой тюнинг не исправит плохую архитектуру.

Сети: разделяйте публичную и кластерную

Худшее что можно сделать — смешать пользовательский трафик и репликацию в одну сеть.

Публичная сеть (client network): клиенты → MON/OSD
Кластерная сеть (cluster network): OSD → OSD (репликация)

Рекомендация:
- Публичная: 10 GbE minimum
- Кластерная: 25 GbE или bond из двух 10 GbE

Конфигурируем при bootstrap:

cephadm bootstrap \
    --mon-ip 192.168.10.11 \
    --cluster-network 192.168.20.0/24
# или после:
ceph config set global cluster_network 192.168.20.0/24

Размещение BlueStore компонентов

BlueStore — три уровня данных с разными требованиями:

Если все компоненты на одном диске — они конкурируют за I/O. Выносим DB и WAL на NVMe:

# osd-spec-nvme.yaml
service_type: osd
service_id: nvme-optimized
placement:
  host_pattern: 'ceph-node*'
data_devices:
  paths:
    - /dev/sdb  # HDD для данных
    - /dev/sdc
db_devices:
  paths:
    - /dev/nvme0n1  # NVMe для DB (разделяется между несколькими OSD)
wal_devices:
  paths:
    - /dev/nvme1n1  # отдельный NVMe для WAL

Золотое правило: один NVMe может обслуживать WAL/DB для 4-6 HDD OSD.

Расчёт оптимального числа OSD на сервер

Больше OSD — больше параллелизма, но больше RAM. Один OSD потребляет:

• ~1 GB RAM (HDD OSD, небольшие данные)

• ~2-4 GB RAM (SSD/NVMe OSD под нагрузкой)

• BlueStore cache: по умолчанию 1/4 RAM на все OSD

# Проверяем потребление памяти OSD
ceph daemon osd.0 dump_mempools
ceph daemon osd.0 perf dump | grep -i mem

Часть 2: Тюнинг производительности

BlueStore: кэш и компрессия

# Размер BlueStore кэша — главный параметр
# По умолчанию: 1/4 от общей RAM (авто)
# Можно задать явно для SSD/NVMe (они меньше нуждаются в кэше)
ceph config set osd bluestore_cache_size_ssd 1073741824  # 1 GB для SSD OSD

# HDD нуждаются в бОльшем кэше
ceph config set osd bluestore_cache_size_hdd 536870912   # 512 MB для HDD OSD

# Компрессия — включаем для cold data
ceph osd pool set mypool compression_mode aggressive  # сжимать всегда
# или
ceph osd pool set mypool compression_mode passive     # сжимать если выгодно

ceph osd pool set mypool compression_algorithm zstd   # лучший ratio
# или snappy — быстрее, но меньше сжимает
# или lz4   — самый быстрый, минимальное сжатие

ceph osd pool set mypool compression_min_blob_size 8192  # мин. размер для сжатия

Настройка очереди I/O — mclock

С Ceph Pacific появился планировщик mclock, дающий QoS на уровне OSD:

# Проверяем текущий планировщик
ceph config get osd osd_op_queue
# должен быть: mclock_scheduler

# Приоритеты для workload'ов:
# client — пользовательские операции
# recovery — восстановление данных
# scrub — фоновая проверка

# Для HDD-кластера снижаем агрессивность recovery
ceph config set osd osd_mclock_scheduler_client_res 1
ceph config set osd osd_mclock_scheduler_recovery_res 1
ceph config set osd osd_mclock_scheduler_scrub_res 1

В Tentacle добавили защиту от нереалистичных значений IOPS capacity для mclock — теперь если измеренное значение IOPS слишком низкое (< 50 для HDD, < 1000 для SSD), планировщик использует последнее валидное значение.

Оптимизация для конкретных workload'ов

Для виртуальных машин (много случайных мелких I/O):

# Увеличиваем число OSD threads
ceph config set osd osd_op_num_shards 8
ceph config set osd osd_op_num_threads_per_shard 2

# Write pipeline
ceph config set osd bluestore_throttle_bytes 67108864  # 64 MB
ceph config set osd bluestore_throttle_deferred_bytes 134217728  # 128 MB

# Для NVMe — отключаем оверхед на большие буферы
ceph config set osd bluestore_max_blob_size_ssd 65536

Для больших последовательных записей (S3, медиа):

# Увеличиваем объект для EC
ceph config set osd osd_max_write_size 512  # MB

# RGW chunk size
ceph config set client rgw_obj_stripe_size 8388608  # 8 MB

Для read-heavy workload'ов:

# Увеличиваем BlueStore cache для чтения
ceph config set osd bluestore_cache_meta_ratio 0.4   # 40% для метаданных
ceph config set osd bluestore_cache_kv_ratio 0.4     # 40% для RocksDB

# Readahead на уровне BlueStore
ceph config set osd bluestore_default_buffered_read true

Настройка RBD для Kubernetes / Proxmox

# Включаем RBD кеширование на стороне клиента
cat >> /etc/ceph/ceph.conf << 'EOF'
[client]
rbd cache = true
rbd cache size = 134217728      # 128 MB
rbd cache max dirty = 100663296 # 96 MB
rbd cache target dirty = 67108864  # 64 MB
rbd cache max dirty age = 5.0
rbd cache writethrough until flush = true
EOF

# Для diskless систем — через librbd
rbd config image set vmpool/myvm-disk01 rbd_cache true
rbd config image set vmpool/myvm-disk01 rbd_cache_size 134217728

Часть 3: FastEC — как правильно использовать

FastEC — главная фича Tentacle для EC пулов. Разберём как мигрировать и что получаем.

Создаём новый EC пул с FastEC

# Профиль с ISA-L (новый дефолт в Tentacle)
ceph osd erasure-code-profile set fastec-profile \
    k=4 m=2 \
    plugin=isa \
    technique=reed_sol_van \
    crush-failure-domain=host

# Создаём пул
ceph osd pool create fastec-pool 64 64 erasure fastec-profile

# Включаем FastEC оптимизации
ceph osd pool set fastec-pool allow_ec_optimizations true

# Проверяем что включилось
ceph osd pool get fastec-pool allow_ec_optimizations

Миграция существующего EC пула

Если у вас был EC пул с Jerasure — миграция возможна без пересоздания данных:

# Обновляем OSD и MON до Tentacle (см. раздел Upgrade)

# После апгрейда — включаем оптимизации
ceph osd pool set oldpool allow_ec_optimizations true

# Следим за состоянием пула во время активации
watch ceph pg stat

Бенчмарк: насколько быстрее FastEC?

Сравниваем производительность:

# Устанавливаем инструменты
apt install ceph-common

# Тест записи в EC пул с FastEC
rados bench -p fastec-pool 60 write --no-cleanup

# Тест чтения
rados bench -p fastec-pool 60 seq

# Сравниваем с репликацией
rados bench -p vmpool 60 write --no-cleanup
rados bench -p vmpool 60 seq

# Очищаем после теста
rados bench -p fastec-pool 60 cleanup
rados bench -p vmpool 60 cleanup

По данным разработчиков и независимым тестам (blog nuvotex.de, 42on.com): FastEC при workload'е с преобладанием чтения и объектами среднего размера (1-4 MB) может превысить производительность репликации 3x при вдвое меньшем расходе места.

Часть 4: Апгрейд с Squid (19.x) до Tentacle (20.x)

Подготовка к апгрейду

Это самый важный раздел. Апгрейд Ceph — процедура, требующая внимания.

# 1. Проверяем здоровье — ОБЯЗАТЕЛЬНО перед началом
ceph status
ceph health detail

# Кластер ДОЛЖЕН быть в HEALTH_OK или HEALTH_WARN (без critical)
# НЕ начинайте при: OSD down, degraded PGs, incomplete PGs

# 2. Проверяем версии клиентов
ceph features  # показывает connected clients и их версии

# 3. Делаем снэпшот всех RBD образов (опционально, но разумно)
for pool in $(ceph osd pool ls); do
    for image in $(rbd ls $pool 2>/dev/null); do
        rbd snap create $pool/$image@pre-upgrade-$(date +%Y%m%d)
    done
done

# 4. Отключаем PG autoscaler на время апгрейда
ceph osd pool set noautoscale

# 5. Устанавливаем noout флаг (предотвращает rebalancing при рестарте OSD)
ceph osd set noout

Апгрейд через cephadm (рекомендуется)

# Запускаем апгрейд — cephadm делает всё сам, rolling update
ceph orch upgrade start --image quay.io/ceph/ceph:v20.2.0

# Мониторим прогресс
ceph orch upgrade status

# Детальный лог
ceph -W cephadm

# В реальном времени
watch ceph versions

Cephadm обновляет в правильном порядке:

1. MGR (сначала standby, потом active)

2. MON (по одному, ждёт quorum)

3. OSD (по одному, ждёт чистых PG после каждого)

4. MDS, RGW, другие сервисы

Вы можете поставить на паузу и возобновить:

ceph orch upgrade pause
ceph orch upgrade resume

Апгрейд вручную (для не-cephadm кластеров)

# Порядок строго важен!
# 1. MON
for mon_host in ceph-node1 ceph-node2 ceph-node3; do
    echo "Upgrading MON on $mon_host"
    ssh root@$mon_host "apt update && apt install -y ceph-mon"
    ssh root@$mon_host "systemctl restart ceph-mon.target"
    
    # Ждём возврата quorum
    sleep 30
    ceph mon stat
done

# Проверяем что все MON обновились
ceph mon dump | grep min_mon_release
# Должно показать: min_mon_release 20 (tentacle)

# 2. MGR
for mgr_host in ceph-node1 ceph-node2; do
    ssh root@$mgr_host "apt install -y ceph-mgr"
    ssh root@$mgr_host "systemctl restart ceph-mgr.target"
    sleep 10
done

# 3. OSD (по одному за раз!)
for osd_id in $(ceph osd ls); do
    osd_host=$(ceph osd find $osd_id | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['crush_location']['host'])")
    
    echo "Upgrading OSD.$osd_id on $osd_host"
    
    # Устанавливаем новый пакет
    ssh root@$osd_host "apt install -y ceph-osd"
    
    # Рестартуем OSD
    ssh root@$osd_host "systemctl restart ceph-osd@$osd_id"
    
    # Ждём пока OSD поднимется
    sleep 30
    
    # Проверяем что OSD up и PGs чистые
    while ceph pg stat | grep -q "degraded\|recovering"; do
        echo "Waiting for PGs to recover..."
        sleep 30
    done
    
    echo "OSD.$osd_id upgraded successfully"
done

# 4. После всех OSD — финализация
ceph osd require-osd-release tentacle

Финализация апгрейда

# Снимаем noout
ceph osd unset noout

# Включаем PG autoscaler обратно
ceph osd pool unset noautoscale

# Проверяем что все демоны на новой версии
ceph versions

# Убеждаемся что все фичи Tentacle включены
ceph osd dump | grep require_osd_release

# Включаем новые возможности Tentacle
ceph osd pool set mypool allow_ec_optimizations true  # если EC пул

Часть 5: Disaster Recovery — что делать когда всё плохо

Сценарий 1: OSD упал

# Смотрим что произошло
ceph health detail
ceph osd tree | grep -i down

# Оценка: сколько времени OSD уже down?
ceph osd info osd.5 | grep "last_clean_epoch"

# Быстрый рестарт (если проблема временная)
systemctl restart ceph-osd@5
# или через cephadm:
ceph orch daemon restart osd.5

# Если OSD не стартует — смотрим логи
journalctl -u ceph-osd@5 -n 100 --no-pager

# OSD сломан физически — нужно заменить
# Помечаем как out (начнётся rebalancing)
ceph osd out osd.5

# Ждём завершения rebalancing
watch ceph pg stat  # ждём active+clean

# Удаляем из кластера
ceph osd purge osd.5 --yes-i-really-mean-it

# Меняем диск, зачищаем и добавляем обратно
ceph orch daemon add osd ceph-node2:/dev/sdc

Сценарий 2: Целый хост упал

# Если хост не вернётся — убираем его OSD
# Для примера: умер ceph-node2 с OSD 3,4,5

# Помечаем все OSD хоста как out
ceph osd host-down-out ceph-node2  # если есть команда
# или вручную:
for osd in 3 4 5; do ceph osd out osd.$osd; done

# После rebalancing — удаляем
for osd in 3 4 5; do
    ceph osd purge osd.$osd --yes-i-really-mean-it
done

# Удаляем MON если он был на этом хосте
ceph mon remove ceph-node2

# Удаляем хост из оркестратора
ceph orch host drain ceph-node2
ceph orch host rm ceph-node2 --force

# Проверяем здоровье после
ceph status

Сценарий 3: PG застряла в inconsistent/corrupt

# Находим проблемные PG
ceph pg dump | grep -v "active+clean"

# Запускаем repair
ceph pg repair 3.1a

# Если repair не помогает — более агрессивно
ceph osd set nodeep-scrub  # временно отключаем deep-scrub

# Смотрим детали PG
ceph pg 3.1a query

# OSD с повреждёнными данными
ceph osd tree
ceph pg 3.1a get  # какие OSD участвуют

# Принудительное восстановление из другой реплики
# (осторожно! только если уверены что данные на primary повреждены)
ceph pg force-recovery 3.1a

Сценарий 4: MON потерял quorum

# Проверяем статус MON
ceph mon stat
ceph mon dump

# Если 1 из 3 MON не отвечает — quorum ещё есть (2 из 3)
# Рестартуем проблемный
systemctl restart ceph-mon@ceph-node2

# Если quorum потерян (0 из 3 доступны) — режим аварийного восстановления
# Это серьёзная ситуация

# На одном живом MON:
ceph-mon -i ceph-node1 --extract-monmap /tmp/monmap
monmaptool --print /tmp/monmap

# Удаляем недостижимые MON из карты
monmaptool --rm ceph-node2 /tmp/monmap
monmaptool --rm ceph-node3 /tmp/monmap

# Инжектируем исправленную monmap
ceph-mon -i ceph-node1 --inject-monmap /tmp/monmap

# Запускаем с одним MON
ceph-mon -i ceph-node1

# Добавляем новые MON после стабилизации
ceph orch apply mon ceph-node1,ceph-node2,ceph-node3

Сценарий 5: Восстановление удалённого RBD образа

# Если образ удалён — проверяем trash
rbd trash ls vmpool

# Восстанавливаем из trash (образы там держатся delay_seconds)
rbd trash restore vmpool/trash-id

# Если включён rbd-mirror с журналированием — восстановление из журнала
# В крайнем случае — восстановление из снэпшота
rbd snap ls vmpool/myvm-disk01
rbd snap rollback vmpool/myvm-disk01@pre-upgrade-20241201

# Восстановление из бэкапа через export
rbd export vmpool/myvm-disk01 /mnt/backup/myvm-disk01.raw
# Восстановление:
rbd import /mnt/backup/myvm-disk01.raw vmpool/myvm-disk01-restored

Часть 6: Продвинутые возможности Tentacle

SMB shares из CephFS

# Создаём SMB кластер (Active Directory интеграция)
ceph smb cluster create mysmb \
    active-directory \
    --domain DC=corp,DC=example,DC=com \
    --realm CORP.EXAMPLE.COM \
    --dns-server 192.168.1.10

# Добавляем CephFS share
ceph smb share create mysmb myshare \
    --cephfs-volume myfs \
    --cephfs-path /shares/myshare

# Проверяем
ceph smb cluster ls
ceph smb share ls

# Через Dashboard — аналогично с GUI

RBD Live Migration — новинка Tentacle

Мгновенный импорт образов из других кластеров без копирования данных:

# Импорт из другого Ceph кластера (native format)
rbd migration prepare \
    --source-spec '{"type":"native","cluster_name":"src-cluster","pool_name":"vmpool","image_name":"myvm"}' \
    dstpool/myvm-imported

# Импорт через NBD (из любого источника)
rbd migration prepare \
    --source-spec '{"type":"nbd","uri":"nbd://192.168.1.100:10809/disk"}' \
    dstpool/imported-disk

# Запускаем миграцию (фоновая копия данных)
rbd migration execute dstpool/myvm-imported

# Когда завершится — фиксируем
rbd migration commit dstpool/myvm-imported

Магия в том, что образ доступен для чтения и записи немедленно — пока данные копируются в фоне, читаются напрямую с источника.

Data Availability Score — новый инструмент мониторинга

# Включаем tracking
ceph config set global enable_availability_tracking true

# Проверяем score для каждого пула
ceph osd pool availability-status

# Вывод:
# POOL    AVAILABLE  SCORE
# vmpool  yes        1.00
# ecpool  yes        0.99   ← одна PG в не-clean состоянии

# Очищаем статус для пула после устранения проблемы
ceph osd pool clear-availability-status vmpool

Scrub: планирование глубоких проверок

# Принудительный scrub для конкретной PG
ceph pg scrub 1.a3
ceph pg deep-scrub 1.a3

# Scrub всего пула
ceph osd pool scrub vmpool

# Планирование — ограничиваем scrub нерабочим временем
ceph config set osd osd_scrub_begin_hour 1    # с 1:00
ceph config set osd osd_scrub_end_hour 6      # до 6:00
ceph config set osd osd_scrub_min_interval 86400   # не чаще раза в день
ceph config set osd osd_deep_scrub_interval 604800  # deep-scrub раз в неделю

# Статус scrub
ceph pg dump | awk '{print $1, $16, $17}' | head -30
# PG_ID | LAST_SCRUB | LAST_DEEP_SCRUB

Часть 7: Capacity planning и масштабирование

Добавление нового хоста и OSD

# Добавляем хост
ceph orch host add ceph-node4 192.168.10.14

# Добавляем OSD
ceph orch daemon add osd ceph-node4:/dev/sdb
ceph orch daemon add osd ceph-node4:/dev/sdc

# Автоматическая ребалансировка начнётся сразу
# Следим за прогрессом
ceph progress
watch ceph df

Расчёт сырого хранилища

Полезное место = (Общий объём) / overhead_factor

Репликация 3x: overhead = 3.0
EC 4+2:         overhead = 1.5
EC 6+3:         overhead = 1.5
EC 8+3:         overhead = 1.375

Для кластера с 9 × 4TB HDD и репликацией 3x:
- Сырое: 36 TB
- Полезное: 36 / 3 = 12 TB (минус ~10% overhead Ceph = ~10.8 TB)

Правило большого пальца: не заполняйте более 80% полезного места!
При 80%+ производительность падает из-за фрагментации и задержек recovery.

Мониторинг через Prometheus

# ceph exporter уже встроен, prometheus конечные точки:
# http://ceph-node1:9283/metrics  - MGR prometheus module

# Ключевые метрики для алертов:
# ceph_health_status != 0          — нездоровый кластер
# ceph_osd_in == 0                 — OSD out
# ceph_pg_degraded > 0             — деградированные PG
# ceph_osd_available_bytes < 20%   — заканчивается место
# ceph_osd_apply_latency_ms > 50   — высокая задержка записи

# Пример alertmanager rule:
cat >> /etc/prometheus/rules/ceph.yml << 'EOF'
groups:
- name: ceph
  rules:
  - alert: CephHealthError
    expr: ceph_health_status == 2
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Ceph cluster is in ERROR state"

  - alert: CephOSDDown  
    expr: ceph_osd_up == 0
    for: 2m
    labels:
      severity: warning

  - alert: CephDiskAlmostFull
    expr: (ceph_osd_stat_bytes_used / ceph_osd_stat_bytes) > 0.80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Ceph OSD {{ $labels.ceph_daemon }} is {{ $value | humanizePercentage }} full"
EOF

Чеклист: Ceph в продакшне

До разворачивания:

• [ ] Минимум 3 физических хоста (лучше 5+ для отказоустойчивости)

• [ ] Отдельные сети для публичного и кластерного трафика (10 GbE+)

• [ ] NTP синхронизирован на всех узлах

• [ ] SSD/NVMe для BlueStore DB и WAL

• [ ] Резервные диски наготове для горячей замены

• [ ] CRUSH map настроен с учётом физической топологии (стойки, ЦОД)

Оперативный мониторинг:

• [ ] Prometheus + Grafana с Ceph дашбордами

• [ ] Алерты на HEALTH_ERR, OSD down, PG degraded, диск >80%

• [ ] mgmt-gateway настроен (Tentacle 20.x)

• [ ] certmgr управляет TLS сертификатами

Регулярные процедуры:

• [ ] Ежедневная проверка ceph status

• [ ] Еженедельный deep-scrub (автоматически через cron)

• [ ] Тестирование восстановления из снэпшотов раз в квартал

• [ ] Обновления безопасности: следим за ceph-announce

Перед апгрейдом:

• [ ] Кластер в HEALTH_OK

• [ ] Снэпшоты критичных RBD образов

• [ ] ceph osd set noout

• [ ] Тест в staging среде

• [ ] Откат-план: как вернуться на предыдущую версию (downgrade невозможен, нужен rollback через снэпшоты)

Где учиться дальше

Официальная документация:

• docs.ceph.com — эталонная документация, всегда актуальная

• ceph.io/en/news/blog — официальный блог с release notes и углублёнными техническими статьями

Сообщество:

• ceph-users@ceph.io — рассылка для пользователей

• irc.oftc.net #ceph — IRC канал

• Cephalocon — ежегодная конференция сообщества

Практика:

• Vagrant + VirtualBox: поднимите тестовый кластер на ноутбуке (cephadm работает в VM)

• Rook — Ceph оператор для Kubernetes, хороший способ изучить интеграцию

• Proxmox VE имеет встроенный Ceph — отличная песочница

Ceph — это не инструмент «поставил и забыл». Это живая система, требующая понимания и регулярного внимания. Но когда вы научитесь с ней работать — получаете petabyte-scale хранилище корпоративного уровня на обычном commodity железе. Это стоит вложенных усилий.

Введение

Корректный запуск процессов внутри контейнера — одна из ключевых тем при разработке Docker-образов. Формально всё описано в документации Docker, однако на практике регулярно возникают неоднозначные ситуации:

• контейнер не останавливается корректно;

• сигналы не доходят до приложения;

• появляются zombie-процессы;

• PID 1 ведёт себя неожиданно.

В этой статье разберём:

1. Разницу между ENTRYPOINT и CMD.

2. Отличие exec и shell форм.

3. Почему критически важно, какой процесс имеет PID 1.

4. Как правильно писать docker-entrypoint.sh.

5. Когда и зачем использовать tini.

Материал ориентирован на практическое применение и реальные сценарии.

1. ENTRYPOINT и CMD: фундаментальная разница

В Dockerfile существуют две директивы для запуска процессов:

• ENTRYPOINT

• CMD

Обе участвуют в формировании итоговой команды запуска контейнера, но выполняют разные роли.

Логическая модель

Можно представить их так:

ENTRYPOINT + CMD = финальная команда контейнера

Рекомендуемая практика

• ENTRYPOINT — фиксированная команда (исполняемый файл или скрипт).

• CMD — аргументы по умолчанию, которые можно переопределить.

Exec-форма и Shell-форма

Docker поддерживает два синтаксиса.

1️⃣ Exec-форма (рекомендуется)

ENTRYPOINT ["/bin/ping"]
CMD ["it-lux.ru"]

Особенности:

• Не используется shell.

• Нет подстановки переменных.

• Процесс запускается напрямую.

• Корректная обработка сигналов.

После сборки:

docker run ping

Внутри контейнера выполнится:

/bin/ping it-lux.ru

Переопределение аргументов:

docker run ping google.com

Теперь выполнится:

/bin/ping google.com

Это правильная архитектура: один образ — разные параметры запуска.

2️⃣ Shell-форма (менее предпочтительна)

ENTRYPOINT ping it-lux.ru

Фактически Docker запустит:

/bin/sh -c "ping it-lux.ru"

Минусы:

• Появляется промежуточный shell.

• Сигналы могут не дойти до целевого процесса.

• PID 1 становится shell.

Shell-форма допустима, но требует понимания последствий.

2. Проблема PID 1

В Linux процесс с PID 1 — особый.

Особенности:

• Он не имеет обработчиков сигналов по умолчанию.

• Он ответственен за "усыновление" осиротевших процессов.

• Он должен корректно обрабатывать SIGTERM.

Docker при остановке контейнера выполняет:

docker stop → отправляет SIGTERM → PID 1

Если PID 1:

• не обрабатывает сигнал,

• не передаёт его дочерним процессам,

то контейнер завершится некорректно (force kill через SIGKILL спустя timeout).

3. Ошибка с docker-entrypoint.sh

Типичный пример:

FROM centos:7

COPY docker-entrypoint.sh /usr/bin
ENTRYPOINT ["/usr/bin/docker-entrypoint.sh"]

Содержимое:

#!/bin/bash
ping ya.ru

Что происходит?

PID 1 — это:

/bin/bash /usr/bin/docker-entrypoint.sh

А ping — дочерний процесс.

При docker stop:

• SIGTERM получает bash

• bash может не передать сигнал дальше

• ping зависает

• появляются zombie-процессы

Это некорректная архитектура контейнера.

4. Правильное решение — exec

В bash существует встроенная команда exec.

Она:

• заменяет текущий процесс

• передаёт ему PID

• не создаёт дополнительный уровень

Правильный вариант:

#!/bin/bash
exec ping ya.ru

Теперь:

PID 1 → ping

Контейнер завершится корректно.

5. Использование CMD внутри entrypoint

Более гибкий вариант:

ENTRYPOINT ["/usr/bin/docker-entrypoint.sh"]
CMD ["ya.ru"]

Скрипт:

#!/bin/bash

# подготовительные действия

set -- ping "$@"
exec "$@"

Разбор:

• $@ — все аргументы контейнера.

• set -- — формирует новую команду.

• exec "$@" — запускает её как PID 1.

Запуск:

docker run ping google.com

Результат:

PID 1 → ping google.com

Это production-подход.

6. Когда одного exec недостаточно

Теперь усложним сценарий.

Допустим, запускается:

• Jenkins

• Apache

• Zabbix server

Такие системы активно создают дочерние процессы.

Примеры:

• Jenkins

• Zabbix

• Apache HTTP Server

Если дочерние процессы:

• завершаются некорректно,

• остаются "осиротевшими",

то PID 1 должен их "подчищать".

Но большинство приложений:

• не реализуют init-поведение,

• не умеют корректно reaping zombie-процессов.

7. Решение — tini

Здесь используется tini.

• Минималистичный init для контейнеров.

• Корректно проксирует сигналы.

• Убирает zombie-процессы.

• Работает как PID 1.

Название — это "init" наоборот.

Как подключить tini

Пример Dockerfile:

FROM debian:stable

RUN apt-get update && apt-get install -y tini

ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["your-app"]

Теперь:

PID 1 → tini
PID 7 → your-app

Что делает tini:

1. Получает SIGTERM.

2. Передаёт сигнал дочернему процессу.

3. Reap'ит zombie-процессы.

4. Корректно завершает контейнер.

Это production best practice.

8. Почему bash ≠ tini

Это принципиально разные роли.

9. Итоговые рекомендации (Best Practices)

1. Используйте exec-форму всегда, когда возможно.

2. В docker-entrypoint.sh обязательно применяйте exec.

3. Разделяйте:

   • ENTRYPOINT — исполняемый файл

   • CMD — аргументы по умолчанию

4. Если приложение создаёт дочерние процессы — используйте tini.

5. Проверяйте, кто имеет PID 1:

docker exec -it container ps aux

Заключение

На простых примерах всё работает и без этих нюансов. Однако при усложнении логики контейнера:

• появляются проблемы с остановкой,

• теряются сигналы,

• возникают zombie-процессы,

• контейнер завершает работу некорректно.

Docker упрощает деплой, но не отменяет фундаментальные принципы работы процессов в Linux.

Понимание:

• роли PID 1,

• различий exec и shell,

• корректного построения entrypoint,

• необходимости tini

позволяет создавать production-ready Docker-образы, которые ведут себя предсказуемо и корректно в любой среде.

Введение: Почему SysVinit умер, и при чём тут Systemd

Представьте себе повара, который готовит ужин на 10 человек, но строго по одному блюду за раз — сначала суп, потом только начинает нарезать салат. Именно так работала старая система инициализации SysVinit: запускала службы строго по одной, в заранее заданном порядке. Независимо от того, зависят ли они друг от друга.

С усложнением Linux-систем это стало болью:

• Медленная загрузка. Служба A ждёт завершения службы B, даже если между ними нет никакой реальной зависимости.

• Нет контроля за процессами. Запустил — и забыл. Упал дочерний процесс? SysVinit об этом не знает.

• Хаос в логах. Каждый сервис пишет куда хочет: один в /var/log/nginx/, другой в syslog, третий в /tmp/. Никакой единой точки входа.

• Хрупкие скрипты. Shell-скрипты в /etc/init.d/ — это огромное поле для ошибок и несовместимостей между дистрибутивами.

В 2010 году Леннарт Поттеринг (Lennart Poettering) представил systemd — систему, которая решала все эти проблемы разом. Параллельный запуск, граф зависимостей, контрольные группы, централизованные логи. Сообщество поначалу встретило его в штыки (споры были жаркими), но сегодня systemd — стандарт де-факто в Fedora, Debian, Ubuntu, Arch, RHEL, CentOS и большинстве других дистрибутивов.

Давайте разберём его по косточкам.

Часть 1. Архитектура systemd — что происходит под капотом

1.1 PID 1 — главный процесс системы

Когда ядро Linux загружается, оно запускает самый первый пользовательский процесс с PID 1. В системах с systemd это и есть демон systemd. Он — прямой родитель всех остальных процессов в системе.

Это важно по двум причинам:

1. Если PID 1 упадёт — система паникует. Поэтому systemd написан максимально надёжно.

2. Все процессы, которые становятся «сиротами» (их родитель умер), автоматически переходят под крыло PID 1.

Ядро Linux
    └── systemd (PID 1)
            ├── journald (логирование)
            ├── udevd (устройства)
            ├── networkd (сеть)
            ├── nginx.service (ваш веб-сервер)
            ├── postgresql.service (БД)
            └── ... все остальные сервисы

1.2 Ключевые компоненты системы

systemd (PID 1) Главный дирижёр. Читает юнит-файлы, строит граф зависимостей, запускает процессы в нужном порядке, следит за их состоянием через cgroups.

systemctl Ваш пульт управления. Когда вы пишете systemctl start nginx, эта утилита НЕ запускает nginx напрямую. Она отправляет сообщение по D-Bus демону systemd, который и выполняет работу. Это ключевое отличие от простого вызова скрипта.

journald Централизованная система логирования. Перехватывает stdout и stderr всех сервисов, обогащает каждую запись метаданными (PID, UID, имя юнита, хостнейм) и сохраняет в структурированном бинарном формате. Это позволяет делать сложные запросы к логам — как SQL к базе данных.

udevd Менеджер устройств. Когда вы подключаете USB-флешку, именно udevd создаёт /dev/sdb, загружает нужные модули ядра и может запустить определённый сервис.

networkd, timedated, logind Специализированные демоны для управления сетью, системным временем и пользовательскими сессиями. Они общаются с PID 1 через D-Bus.

1.3 D-Bus — как компоненты разговаривают друг с другом

D-Bus — это системная шина сообщений, аналог внутренней корпоративной почты между процессами. Вместо того чтобы процессы вызывали функции друг друга напрямую (что небезопасно), они отправляют структурированные сообщения через шину.

Практический пример: systemctl start nginx

1. systemctl формирует D-Bus-сообщение: «Вызови метод StartUnit с аргументом nginx.service»

2. Сообщение уходит в системную шину

3. Демон systemd получает его и выполняет

4. Возвращает ответ через ту же шину

Это даёт безопасность (права проверяются на уровне D-Bus), гибкость (любая программа может управлять сервисами) и расширяемость.

Часть 2. Юниты — строительные блоки systemd

Юнит (unit) — это описание любого системного ресурса в виде декларативного конфигурационного файла. Думайте о нём как о «паспорте» для сервиса, сокета, таймера или точки монтирования.

2.1 Где хранятся юниты

Важно: Никогда не редактируйте файлы в /usr/lib/systemd/system/ напрямую — они перезапишутся при обновлении пакетов. Для изменения стандартного юнита используйте systemctl edit <имя>, который создаст drop-in файл в /etc/systemd/system/<имя>.d/override.conf.

2.2 Типы юнитов

.service — сервисы (самый частый тип)

Описывает демон или процесс. Именно с ним вы работаете в 90% случаев.

ini

# /etc/systemd/system/myapp.service
[Unit]
Description=My Awesome Application
After=network.target postgresql.service
Requires=postgresql.service

[Service]
Type=simple
ExecStart=/usr/bin/myapp --config /etc/myapp/config.yml
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
User=myapp
Group=myapp

[Install]
WantedBy=multi-user.target

Параметр Type= — это важно понимать правильно:

Жизненный цикл и перезапуск:

ini

[Service]
# Варианты для Restart=:
# no          — не перезапускать никогда
# on-success  — только при коде выхода 0
# on-failure  — при любом ненулевом коде, сигнале или таймауте (самый частый выбор)
# on-abnormal — при сигнале или таймауте (не при коде выхода)
# always      — перезапускать всегда (даже при systemctl stop!)
Restart=on-failure
RestartSec=5s

# Ограничение на количество перезапусков:
# Максимум 5 попыток за 30 секунд, потом сдаться
StartLimitIntervalSec=30s
StartLimitBurst=5

.socket — socket-based activation (ленивый запуск)

Это одна из самых мощных и недооценённых фич systemd. Идея простая: зачем держать 20 сервисов запущенными, если большинство из них обращаются раз в час?

Socket-based activation работает так:

1. systemd открывает и слушает сокет (порт, Unix socket, FIFO)

2. Сам сервис не запущен

3. Приходит первое подключение

4. systemd запускает сервис и передаёт ему уже установленное соединение

5. Клиент не замечает разницы — соединение не потеряно!

ini

# /etc/systemd/system/echo.socket
[Unit]
Description=Echo Server Socket

[Socket]
ListenStream=12345
Accept=no

[Install]
WantedBy=sockets.target

ini

# /etc/systemd/system/echo.service
[Unit]
Description=Echo Server Service

[Service]
Type=simple
ExecStart=/usr/local/bin/echo-server
# Сервис получит сокет через файловый дескриптор 3
StandardInput=socket

Активация: sudo systemctl enable --now echo.socket — и сервис будет запускаться автоматически при первом подключении.

.timer — замена cron с суперспособностями

Таймеры systemd мощнее cron по нескольким причинам:

• Поддерживают зависимости (запустить только если работает такой-то сервис)

• Логируются в journald как обычные юниты

• Могут «догнать» пропущенные запуски после перезагрузки (Persistent=true)

• Точность до секунды и поддержка случайных задержек для распределения нагрузки

ini

# /etc/systemd/system/backup.timer
[Unit]
Description=Daily Backup Timer

[Timer]
# Запускать каждый день в 02:30
OnCalendar=*-*-* 02:30:00
# Случайная задержка до 10 минут (не всё одновременно в 02:30!)
RandomizedDelaySec=10m
# Запустить задачу, если она была пропущена (например, система была выключена)
Persistent=true

[Install]
WantedBy=timers.target

ini

# /etc/systemd/system/backup.service
[Unit]
Description=Daily Backup Job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
User=backup

Активация: sudo systemctl enable --now backup.timer

Проверить все активные таймеры: systemctl list-timers --all

Синтаксис OnCalendar:

Проверить выражение: systemd-analyze calendar "Mon-Fri *-*-* 08:30:00"

.target — группы юнитов (замена runlevel)

Target — это не сервис, а точка синхронизации. Думайте об этом как о «состоянии системы», которого нужно достичь.

bash

# Узнать текущий target (аналог текущего runlevel)
systemctl get-default

# Сменить target (аналог init 3)
sudo systemctl isolate multi-user.target

# Установить target по умолчанию
sudo systemctl set-default multi-user.target

.path — реакция на события файловой системы

Аналог incron. Запускает сервис при изменениях в файловой системе.

ini

# /etc/systemd/system/watch-uploads.path
[Unit]
Description=Watch for new uploads

[Path]
# Запустить связанный .service когда появится этот файл
PathExists=/var/spool/uploads/trigger.flag
# Или мониторить директорию на изменения
DirectoryNotEmpty=/var/spool/uploads/

[Install]
WantedBy=multi-user.target

2.3 Зависимости между юнитами — граф, а не очередь

Это одно из ключевых отличий systemd от SysVinit. Вместо фиксированного порядка — направленный граф зависимостей.

Директивы зависимостей:

Директивы порядка:

Важный нюанс: After= и Before= задают только порядок, но не зависимость! Если вы напишете только After=postgresql.service, но не Requires=postgresql.service, то ваш сервис стартует после PostgreSQL, но запустится даже если PostgreSQL упал. Обычно нужно использовать оба.

ini

[Unit]
# Правильная комбинация: сначала БД, потом мы, и мы не работаем без БД
After=postgresql.service
Requires=postgresql.service

Часть 3. cgroups — почему systemd знает всё о ваших процессах

3.1 Проблема, которую решают cgroups

Представьте: nginx запущен. Он форкает 4 воркера. Один воркер форкает ещё процесс для CGI. Тот форкает что-то ещё. Итого 10 процессов, и все они «принадлежат» nginx, но в SysVinit это было невозможно отследить.

Control Groups (cgroups) — механизм ядра Linux, который позволяет объединять процессы в иерархические группы и управлять ими совместно.

Systemd автоматически создаёт cgroup для каждого сервиса. Все дочерние процессы — внутри этой группы. Всегда.

/sys/fs/cgroup/
├── system.slice/
│   ├── nginx.service/        ← все процессы nginx здесь
│   │   ├── pid: 1234 (master)
│   │   ├── pid: 1235 (worker 1)
│   │   ├── pid: 1236 (worker 2)
│   │   └── pid: 1237 (cache loader)
│   ├── postgresql.service/   ← и postgres здесь
│   └── redis.service/
└── user.slice/
    └── user-1000.slice/      ← процессы пользователя

3.2 Что даёт cgroup на практике

Точный kill без зомби-процессов: При systemctl stop nginx systemd отправляет сигнал всей cgroup — умирают все 10 процессов, включая те, о которых вы не знали. Больше никаких «phantom workers».

Мониторинг:

bash

# Показать дерево процессов cgroup сервиса
systemd-cgls /system.slice/nginx.service
# Вывод:
# /system.slice/nginx.service
# └─ 1234 /usr/sbin/nginx -g daemon off;
#    ├─ 1235 nginx: worker process
#    ├─ 1236 nginx: worker process
#    └─ 1237 nginx: cache loader process

# Мониторинг ресурсов в реальном времени (как top, но для cgroups)
systemd-cgtop

3.3 Ограничение ресурсов через юнит-файлы

Это магия. Вместо сложных настроек cgroups вручную — просто добавляете строки в секцию [Service]:

ini

[Service]
# === ПАМЯТЬ ===
# Мягкий лимит: systemd начнёт агрессивно освобождать память
MemoryHigh=400M
# Жёсткий лимит: OOM Killer убьёт процесс если превысит
MemoryMax=512M
# Гарантированная память (не будет отдана другим)
MemoryMin=100M

# === CPU ===
# 50% от одного ядра
CPUQuota=50%
# Или: вес CPU (1-10000, default=100)
CPUWeight=200

# === ДИСК (I/O) ===
# Ограничение чтения/записи для конкретного устройства
IOReadBandwidthMax=/dev/sda 50M
IOWriteBandwidthMax=/dev/sda 20M

# === СЕТЬ (через IP accounting) ===
IPAccounting=yes
IPAddressAllow=192.168.0.0/24
IPAddressDeny=any

Проверка текущих лимитов:

bash

# Посмотреть параметры cgroup напрямую в файловой системе
cat /sys/fs/cgroup/system.slice/nginx.service/memory.max
# 536870912 (512 МБ в байтах)

# Или через systemctl
systemctl show nginx.service | grep -E 'Memory|CPU|IO'

Часть 4. journald — логи как база данных

4.1 Почему journald лучше текстовых логов

Обычный syslog — это текстовый файл. Хочешь найти все ошибки nginx за последний час? Пишешь grep "error" /var/log/nginx/error.log | grep "$(date +%b\ %d)" и молишься.

journald — структурированное хранилище с индексами. Каждая запись — не строчка текста, а объект с полями:

_SYSTEMD_UNIT=nginx.service    ← какой сервис
_PID=1234                       ← какой процесс
_UID=www-data                   ← от какого пользователя
_HOSTNAME=web-01                ← на каком хосте
PRIORITY=3                      ← уровень важности (err)
MESSAGE=connection refused...   ← само сообщение
_SOURCE_REALTIME_TIMESTAMP=...  ← точное время

4.2 Полное руководство по journalctl

bash

# === БАЗОВЫЕ ЗАПРОСЫ ===

# Все логи конкретного сервиса
sudo journalctl -u nginx.service

# Последние 50 строк
sudo journalctl -u nginx.service -n 50

# Следить в реальном времени (как tail -f)
sudo journalctl -u nginx.service -f

# С определённого момента
sudo journalctl -u nginx.service --since "2024-01-15 10:00:00"
sudo journalctl -u nginx.service --since "1 hour ago"
sudo journalctl -u nginx.service --since today
sudo journalctl -u nginx.service --since yesterday --until "2024-01-14 23:59:59"

# === ФИЛЬТРАЦИЯ ПО УРОВНЮ ВАЖНОСТИ ===
# 0=emerg, 1=alert, 2=crit, 3=err, 4=warning, 5=notice, 6=info, 7=debug
sudo journalctl -p err                      # только err
sudo journalctl -p err..warning             # от err до warning
sudo journalctl -u nginx -p warning         # предупреждения nginx

# === ФИЛЬТРАЦИЯ ПО ЗАГРУЗКЕ ===
sudo journalctl -b                          # текущая загрузка
sudo journalctl -b -1                       # предыдущая загрузка
sudo journalctl -b -2                       # позапрошлая загрузка
sudo journalctl --list-boots                # список всех загрузок

# === ФОРМАТЫ ВЫВОДА ===
sudo journalctl -u nginx -o json            # JSON (для парсинга)
sudo journalctl -u nginx -o json-pretty     # JSON с форматированием
sudo journalctl -u nginx -o verbose         # Все поля записи
sudo journalctl -u nginx -o cat             # Только текст сообщений

# === ПРОДВИНУТЫЕ ЗАПРОСЫ ===

# Логи конкретного процесса
sudo journalctl _PID=1234

# Логи от конкретного пользователя
sudo journalctl _UID=1000

# Комбинирование условий (OR)
sudo journalctl _SYSTEMD_UNIT=nginx.service + _SYSTEMD_UNIT=php-fpm.service

# Экспорт в файл
sudo journalctl -u nginx --since today -o json > nginx-today.json

# === УПРАВЛЕНИЕ ЖУРНАЛОМ ===

# Размер журнала на диске
sudo journalctl --disk-usage

# Очистка старых логов (оставить только за последние 2 недели)
sudo journalctl --vacuum-time=2weeks

# Очистка до определённого размера
sudo journalctl --vacuum-size=500M

4.3 Настройка journald

ini

# /etc/systemd/journald.conf
[Journal]
# Максимальный размер журнала на диске
SystemMaxUse=1G

# Максимальный размер одного файла журнала
SystemMaxFileSize=100M

# Хранить журналы не дольше
MaxRetentionSec=1month

# Сжатие (по умолчанию включено)
Compress=yes

# Перенаправить в syslog (для совместимости)
ForwardToSyslog=no

# Уровень логирования по умолчанию
MaxLevelStore=debug
MaxLevelSyslog=warning

После изменения: sudo systemctl restart systemd-journald

Часть 5. Практика — реальные сценарии

5.1 Создание production-ready сервиса с нуля

Задача: создать сервис для Go-приложения с полной изоляцией и автоматическим перезапуском.

ini

# /etc/systemd/system/api-server.service
[Unit]
Description=API Server
Documentation=https://github.com/company/api-server
After=network.target
Wants=network-online.target
After=network-online.target

# Если зависит от БД:
Requires=postgresql.service
After=postgresql.service

[Service]
Type=notify
# Путь к бинарнику
ExecStart=/usr/local/bin/api-server
# Путь к конфигу через переменную окружения
EnvironmentFile=/etc/api-server/env
# Или напрямую:
Environment="PORT=8080"
Environment="LOG_LEVEL=info"

# Перезапуск
Restart=on-failure
RestartSec=5s
StartLimitIntervalSec=60s
StartLimitBurst=3

# Пользователь и группа
User=api
Group=api

# Рабочая директория
WorkingDirectory=/opt/api-server

# === БЕЗОПАСНОСТЬ ===
# Запрет повышения привилегий
NoNewPrivileges=yes
# Изолированный /tmp
PrivateTmp=yes
# Только чтение для /usr, /boot, /etc
ProtectSystem=strict
# Запрет доступа к домашним директориям
ProtectHome=yes
# Изолированная сеть для системных вызовов
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
# Список разрешённых системных вызовов
SystemCallFilter=@system-service
# Разрешить запись только в эти директории
ReadWritePaths=/var/lib/api-server /var/log/api-server

# === РЕСУРСЫ ===
MemoryMax=512M
CPUQuota=200%
# Ограничение открытых файлов
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Применение:

bash

sudo systemctl daemon-reload
sudo systemctl enable --now api-server.service
sudo systemctl status api-server.service

5.2 Drop-in файлы — переопределение без изменения оригинала

Золотое правило: никогда не редактируйте файлы в /usr/lib/systemd/system/. Используйте drop-in файлы.

bash

# Удобный способ — systemctl edit сам создаст файл
sudo systemctl edit nginx.service

Создастся файл /etc/systemd/system/nginx.service.d/override.conf:

ini

[Service]
# Добавим лимит памяти к стандартному nginx
MemoryMax=256M
# Переопределим тип перезапуска
Restart=always
# Добавим переменную окружения
Environment="NGINX_ENVSUBST_OUTPUT_DIR=/etc/nginx"

bash

# После сохранения:
sudo systemctl daemon-reload
sudo systemctl restart nginx.service

# Посмотреть итоговую конфигурацию (оригинал + drop-ins)
sudo systemctl cat nginx.service

5.3 Анализ и оптимизация времени загрузки

bash

# Общее время загрузки
systemd-analyze
# Startup finished in 2.134s (kernel) + 8.643s (userspace) = 10.777s

# Топ «тормозов» при загрузке
systemd-analyze blame
# 4.123s NetworkManager-wait-online.service
# 2.456s plymouth-quit-wait.service
# 1.234s dev-sda1.device
# 0.987s apparmor.service

# Критический путь загрузки — что тормозит конкретный target
systemd-analyze critical-chain graphical.target

# Визуальная диаграмма в SVG (откройте в браузере!)
systemd-analyze plot > boot-plot.svg

# Проверить юнит-файл на ошибки
systemd-analyze verify /etc/systemd/system/myapp.service

Частые причины медленной загрузки и как их лечить:

5.4 Диагностика падающего сервиса — пошаговый алгоритм

bash

# Шаг 1: Статус сервиса
sudo systemctl status myapp.service
# Ищем: статус (failed/active), последние строки лога, код выхода

# Шаг 2: Последние логи с подробными метаданными
sudo journalctl -u myapp.service -n 100 --no-pager

# Шаг 3: Логи с момента последней загрузки (для проблем при старте)
sudo journalctl -u myapp.service -b

# Шаг 4: Все ошибки в системе в момент падения
sudo journalctl -p err --since "10 min ago" --no-pager

# Шаг 5: Проверить зависимости
systemctl list-dependencies myapp.service
# Все зависимости должны быть зелёными

# Шаг 6: Запустить вручную под тем же пользователем (для воспроизведения)
sudo -u myapp /usr/local/bin/myapp --config /etc/myapp/config.yml

# Шаг 7: Посмотреть все переменные окружения сервиса
sudo systemctl show myapp.service -p Environment

# Шаг 8: Проверить права доступа к файлам
sudo systemctl cat myapp.service | grep -E 'ExecStart|WorkingDirectory|User'
sudo ls -la /usr/local/bin/myapp

Часть 6. Продвинутые техники

6.1 Шаблонные юниты — один файл для многих экземпляров

Если нужно запустить один и тот же сервис с разными параметрами (например, несколько воркеров), используйте шаблоны.

ini

# /etc/systemd/system/worker@.service
# Обратите внимание на @ в имени файла!
[Unit]
Description=Worker Instance %i
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/worker --id=%i --config=/etc/worker/config.yml
User=worker
Restart=on-failure

[Install]
WantedBy=multi-user.target

Запуск нескольких экземпляров:

bash

# %i заменится на значение после @
sudo systemctl start worker@1.service
sudo systemctl start worker@2.service
sudo systemctl start worker@3.service

# Или всех сразу:
sudo systemctl enable worker@{1..5}.service
sudo systemctl start worker@{1..5}.service

# Посмотреть все запущенные экземпляры
systemctl list-units 'worker@*'

6.2 Временные сервисы через systemd-run

bash

# Запустить команду как временный сервис (исчезнет после завершения)
sudo systemd-run --unit=my-task /usr/bin/python3 /opt/scripts/heavy_task.py

# С ограничением ресурсов
sudo systemd-run --unit=cpu-heavy --property=CPUQuota=50% --property=MemoryMax=256M \
    /usr/bin/python3 /opt/scripts/heavy_task.py

# Следить за прогрессом
journalctl -u my-task -f

6.3 Полезные команды, о которых мало кто знает

bash

# Проверить юнит-файл на синтаксические ошибки ДО применения
systemd-analyze verify /etc/systemd/system/myapp.service

# Показать все переопределения (drop-in файлы) для сервиса
systemctl cat nginx.service

# Показать все свойства юнита
systemctl show nginx.service

# Показать конкретное свойство
systemctl show nginx.service -p MainPID
systemctl show nginx.service -p MemoryCurrent

# Перезагрузить конфиги без daemon-reload (для drop-in файлов)
sudo systemctl daemon-reload

# Перечитать конфиги всех сервисов (более мягкий вариант)
sudo systemctl reload-or-restart nginx.service

# Узнать, какой пакет установил юнит
systemctl cat nginx.service | head -1
# # /lib/systemd/system/nginx.service
dpkg -S /lib/systemd/system/nginx.service   # Debian/Ubuntu
rpm -qf /lib/systemd/system/nginx.service  # RHEL/Fedora

# Блокировка: сервис не запустится даже вручную
sudo systemctl mask dangerous-service.service
# Разблокировка
sudo systemctl unmask dangerous-service.service

Шпаргалка — все команды в одном месте

Управление сервисами

Просмотр состояния

Логи (journalctl)

Диагностика производительности

Заключение

Systemd — это не монстр, которого стоит бояться. Это мощный инструмент, понимание которого делает вас значительно эффективнее как системного администратора или разработчика. Несколько ключевых идей, которые стоит унести из этой статьи:

1. Юниты — декларативные описания ресурсов. Пишите их правильно, используя все доступные настройки безопасности.

2. cgroups — системd всегда знает, где ваши процессы. Используйте это для мониторинга и ограничения ресурсов.

3. journald — это база данных, а не текстовый файл. Учитесь делать правильные запросы.

4. Drop-in файлы — никогда не редактируйте оригинальные юнит-файлы из пакетов.

5. systemd-analyze — ваш первый инструмент при проблемах с загрузкой.

Introduction: Why SysVinit Died and What Systemd Fixed

Imagine a chef cooking dinner for 10 guests but making each dish completely from scratch, one at a time — starting the salad only after the soup is fully served. That's essentially how SysVinit worked: it started services one by one, in a fixed order, regardless of whether they were actually dependent on each other.

As Linux systems grew more complex, this became a serious bottleneck:

• Slow boot times. Service A waits for Service B to finish, even if there's zero dependency between them.

• No process tracking. Init launched a script and moved on. A child process crashed? SysVinit had no idea.

• Log chaos. Every service wrote logs wherever it wanted — /var/log/nginx/, syslog, /tmp/ — no unified interface.

• Brittle shell scripts. The /etc/init.d/ scripts were fragile, hard to maintain, and inconsistent across distros.

In 2010, Lennart Poettering introduced systemd to solve all of these problems simultaneously: parallel startup, dependency graphs, control groups, and centralized logging. The community response was controversial (to put it mildly), but today systemd is the de-facto standard on Fedora, Debian, Ubuntu, Arch, RHEL, and most other major distributions.

Let's break it down piece by piece.

Part 1. Systemd Architecture — What's Under the Hood

1.1 PID 1 — The Ruler of All Processes

When the Linux kernel boots, it launches the very first user-space process with PID 1. On systemd systems, that process IS the systemd daemon. It's the direct parent of everything else in the system.

This matters for two reasons:

1. If PID 1 crashes, the system panics. Hence systemd is written to be extremely robust.

2. All orphaned processes (whose parent died) are automatically reparented to PID 1.

Linux Kernel
    └── systemd (PID 1)
            ├── journald (logging)
            ├── udevd (device management)
            ├── networkd (networking)
            ├── nginx.service (your web server)
            ├── postgresql.service (database)
            └── ... all other services

1.2 Key Components

systemd (PID 1) The conductor of the whole orchestra. It reads unit files, builds a dependency graph, launches processes in the right order, and tracks them via cgroups.

systemctl Your control panel. When you type systemctl start nginx, this tool does NOT start nginx directly. It sends a D-Bus message to the systemd daemon, which does the actual work. This is a fundamental difference from running a script.

journald Centralized logging daemon. It captures stdout and stderr from all services, enriches each entry with structured metadata (PID, UID, unit name, hostname), and stores everything in a binary format that supports complex queries — think SQL for logs.

udevd Device manager. When you plug in a USB drive, udevd creates /dev/sdb, loads the appropriate kernel modules, and can trigger specific services.

networkd, timedated, logind Specialized daemons for network management, system time, and user sessions. They all communicate with PID 1 via D-Bus.

1.3 D-Bus — The Communication Backbone

D-Bus is an inter-process communication (IPC) system bus — think of it as an internal messaging platform between processes. Instead of processes calling each other's functions directly (which is unsafe), they send structured messages through the bus.

Example flow for systemctl start nginx:

1. systemctl forms a D-Bus message: "Call the StartUnit method with argument nginx.service"

2. The message goes onto the system bus

3. The systemd daemon receives and processes it

4. Returns the result through the same bus

This provides security (permissions checked at the D-Bus level), flexibility (any program can manage services), and extensibility.

Part 2. Units — The Building Blocks of Systemd

A unit is a description of any system resource as a declarative configuration file. Think of it as the "passport" for a service, socket, timer, or mount point.

2.1 Where Units Live

Important: Never edit files in /usr/lib/systemd/system/ directly — they'll be overwritten on package updates. To modify a stock unit, use systemctl edit <name>, which creates a drop-in override at /etc/systemd/system/<name>.d/override.conf.

2.2 Unit Types

.service — Service Units (Most Common)

Describes a daemon or process. This is what you'll use in 90% of cases.

ini

# /etc/systemd/system/myapp.service
[Unit]
Description=My Awesome Application
After=network.target postgresql.service
Requires=postgresql.service

[Service]
Type=simple
ExecStart=/usr/bin/myapp --config /etc/myapp/config.yml
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
User=myapp
Group=myapp

[Install]
WantedBy=multi-user.target

The Type= parameter — get this right:

Restart policy:

ini

[Service]
# Restart= options:
# no          — never restart
# on-success  — only on exit code 0
# on-failure  — on non-zero exit, signal, or timeout (most common choice)
# on-abnormal — on signal or timeout (not normal exit)
# always      — always restart (even after systemctl stop!)
Restart=on-failure
RestartSec=5s

# Limit restart attempts:
# Max 5 attempts within 30 seconds, then give up
StartLimitIntervalSec=30s
StartLimitBurst=5

.socket — Socket-Based Activation (Lazy Launch)

This is one of the most powerful and underappreciated features of systemd. The idea: why keep 20 services running when most of them get called once an hour?

Socket-based activation works like this:

1. systemd opens and listens on a socket (port, Unix socket, or FIFO)

2. The actual service is not running

3. The first connection arrives

4. systemd launches the service and passes the established connection to it

5. The client never notices — the connection isn't lost!

ini

# /etc/systemd/system/echo.socket
[Unit]
Description=Echo Server Socket

[Socket]
ListenStream=12345
Accept=no

[Install]
WantedBy=sockets.target

ini

# /etc/systemd/system/echo.service
[Unit]
Description=Echo Server

[Service]
Type=simple
ExecStart=/usr/local/bin/echo-server
# Service receives the socket via file descriptor 3
StandardInput=socket

Enable: sudo systemctl enable --now echo.socket — and the service starts on the first connection.

.timer — Cron Replacement with Superpowers

Systemd timers beat cron on several fronts:

• Support dependencies (run only if some service is running)

• Logged in journald like any other unit

• Can "catch up" on missed runs after reboot (Persistent=true)

• Support random delays to spread load across the hour

ini

# /etc/systemd/system/backup.timer
[Unit]
Description=Daily Backup Timer

[Timer]
# Run every day at 02:30
OnCalendar=*-*-* 02:30:00
# Random delay up to 10 minutes (don't hammer the server at exactly 02:30!)
RandomizedDelaySec=10m
# Run the task if it was missed (e.g. system was off)
Persistent=true

[Install]
WantedBy=timers.target

ini

# /etc/systemd/system/backup.service
[Unit]
Description=Daily Backup Job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
User=backup

Enable: sudo systemctl enable --now backup.timer

Check all active timers: systemctl list-timers --all

OnCalendar syntax cheatsheet:

Validate an expression: systemd-analyze calendar "Mon-Fri *-*-* 08:30:00"

.target — Unit Groups (Replacing Runlevels)

A target is not a service — it's a synchronization point. Think of it as a "system state" to be reached.

bash

# Check current default target (like current runlevel)
systemctl get-default

# Switch target (like init 3)
sudo systemctl isolate multi-user.target

# Set default target
sudo systemctl set-default multi-user.target

2.3 Unit Dependencies — A Graph, Not a Queue

This is one of the key differentiators from SysVinit. Instead of a fixed sequence, systemd builds a directed dependency graph.

Dependency directives:

Ordering directives:

Critical nuance: After= and Before= only define ordering, NOT dependency! If you write only After=postgresql.service without Requires=postgresql.service, your service will start after PostgreSQL but will also start even if PostgreSQL failed. You almost always need both.

Part 3. cgroups — Why Systemd Always Knows Your Processes

3.1 The Problem cgroups Solve

Consider: nginx is running. It forks 4 workers. One worker forks a CGI process. That forks something else. Now there are 10 processes, all "belonging" to nginx, but in SysVinit there was no way to track this.

Control Groups (cgroups) are a Linux kernel mechanism that lets you group processes hierarchically and manage them collectively.

Systemd automatically creates a cgroup for every service. All child processes live inside that group. Always.

/sys/fs/cgroup/
├── system.slice/
│   ├── nginx.service/        ← all nginx processes here
│   │   ├── pid: 1234 (master)
│   │   ├── pid: 1235 (worker 1)
│   │   ├── pid: 1236 (worker 2)
│   │   └── pid: 1237 (cache loader)
│   ├── postgresql.service/
│   └── redis.service/
└── user.slice/
    └── user-1000.slice/      ← user processes

3.2 What cgroups Give You in Practice

Clean process termination — no zombie processes: When you run systemctl stop nginx, systemd sends the signal to the entire cgroup — all 10 processes die, including ones you didn't know existed. No more phantom workers.

Monitoring:

bash

# Show process tree for a service's cgroup
systemd-cgls /system.slice/nginx.service

# Real-time resource monitoring (like top, but for cgroups)
systemd-cgtop

3.3 Resource Limits via Unit Files

Instead of manually configuring cgroups, just add lines to your [Service] section:

ini

[Service]
# === MEMORY ===
# Soft limit: systemd will aggressively reclaim memory
MemoryHigh=400M
# Hard limit: OOM Killer will kill the process if exceeded
MemoryMax=512M
# Guaranteed memory (won't be given to others)
MemoryMin=100M

# === CPU ===
# 50% of a single core
CPUQuota=50%
# Or: CPU weight (1-10000, default=100)
CPUWeight=200

# === DISK I/O ===
IOReadBandwidthMax=/dev/sda 50M
IOWriteBandwidthMax=/dev/sda 20M

# === NETWORK ===
IPAccounting=yes
IPAddressAllow=192.168.0.0/24
IPAddressDeny=any

Verify current limits:

bash

# Check cgroup filesystem directly
cat /sys/fs/cgroup/system.slice/nginx.service/memory.max
# 536870912 (512 MB in bytes)

# Or via systemctl
systemctl show nginx.service | grep -E 'Memory|CPU|IO'

Part 4. journald — Logs as a Database

4.1 Why journald Beats Plain Text Logs

A plain syslog is a text file. Want to find all nginx errors from the last hour? You write grep "error" /var/log/nginx/error.log | grep "$(date +%b\ %d)" and hope for the best.

journald is a structured store with indexes. Every entry is not a text string but an object with fields:

_SYSTEMD_UNIT=nginx.service    ← which service
_PID=1234                       ← which process
_UID=www-data                   ← which user
_HOSTNAME=web-01                ← which host
PRIORITY=3                      ← severity level (err)
MESSAGE=connection refused...   ← the message itself
_SOURCE_REALTIME_TIMESTAMP=...  ← precise timestamp

4.2 Complete journalctl Reference

bash

# === BASIC QUERIES ===

# All logs for a service
sudo journalctl -u nginx.service

# Last 50 lines
sudo journalctl -u nginx.service -n 50

# Follow in real time (like tail -f)
sudo journalctl -u nginx.service -f

# From a specific time
sudo journalctl -u nginx.service --since "2024-01-15 10:00:00"
sudo journalctl -u nginx.service --since "1 hour ago"
sudo journalctl -u nginx.service --since today
sudo journalctl -u nginx.service --since yesterday --until "2024-01-14 23:59:59"

# === FILTERING BY SEVERITY ===
# 0=emerg, 1=alert, 2=crit, 3=err, 4=warning, 5=notice, 6=info, 7=debug
sudo journalctl -p err                      # only errors
sudo journalctl -p err..warning             # err through warning
sudo journalctl -u nginx -p warning         # nginx warnings only

# === FILTERING BY BOOT ===
sudo journalctl -b                          # current boot
sudo journalctl -b -1                       # previous boot
sudo journalctl -b -2                       # two boots ago
sudo journalctl --list-boots                # list all boots

# === OUTPUT FORMATS ===
sudo journalctl -u nginx -o json            # JSON (for parsing)
sudo journalctl -u nginx -o json-pretty     # Formatted JSON
sudo journalctl -u nginx -o verbose         # All metadata fields
sudo journalctl -u nginx -o cat             # Message text only

# === ADVANCED QUERIES ===

# Logs for a specific process
sudo journalctl _PID=1234

# Logs from a specific user
sudo journalctl _UID=1000

# Combine conditions (OR)
sudo journalctl _SYSTEMD_UNIT=nginx.service + _SYSTEMD_UNIT=php-fpm.service

# Export to file
sudo journalctl -u nginx --since today -o json > nginx-today.json

# === JOURNAL MANAGEMENT ===

# Disk usage of the journal
sudo journalctl --disk-usage

# Clean up logs older than 2 weeks
sudo journalctl --vacuum-time=2weeks

# Clean up to a specific size
sudo journalctl --vacuum-size=500M

Part 5. Real-World Scenarios

5.1 Creating a Production-Ready Service from Scratch

ini

# /etc/systemd/system/api-server.service
[Unit]
Description=API Server
Documentation=https://github.com/company/api-server
After=network-online.target
Wants=network-online.target
Requires=postgresql.service
After=postgresql.service

[Service]
Type=notify
ExecStart=/usr/local/bin/api-server
EnvironmentFile=/etc/api-server/env
Environment="PORT=8080"
Environment="LOG_LEVEL=info"

Restart=on-failure
RestartSec=5s
StartLimitIntervalSec=60s
StartLimitBurst=3

User=api
Group=api
WorkingDirectory=/opt/api-server

# === SECURITY HARDENING ===
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
SystemCallFilter=@system-service
ReadWritePaths=/var/lib/api-server /var/log/api-server

# === RESOURCE LIMITS ===
MemoryMax=512M
CPUQuota=200%
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

5.2 Drop-in Files — Override Without Touching Originals

bash

# systemctl edit creates the override file automatically
sudo systemctl edit nginx.service
# Creates: /etc/systemd/system/nginx.service.d/override.conf

ini

[Service]
MemoryMax=256M
Restart=always
Environment="NGINX_ENVSUBST_OUTPUT_DIR=/etc/nginx"

bash

sudo systemctl daemon-reload
sudo systemctl restart nginx.service

# View the full effective config (original + drop-ins)
sudo systemctl cat nginx.service

5.3 Boot Time Analysis and Optimization

bash

# Total boot time
systemd-analyze
# Startup finished in 2.134s (kernel) + 8.643s (userspace) = 10.777s

# Top boot-time offenders
systemd-analyze blame

# Critical path to a specific target
systemd-analyze critical-chain graphical.target

# Generate visual timeline (open in browser!)
systemd-analyze plot > boot-plot.svg

# Validate a unit file for errors
systemd-analyze verify /etc/systemd/system/myapp.service

5.4 Diagnosing a Failing Service — Step by Step

bash

# Step 1: Service status
sudo systemctl status myapp.service

# Step 2: Recent logs with full detail
sudo journalctl -u myapp.service -n 100 --no-pager

# Step 3: Logs since last boot (for startup issues)
sudo journalctl -u myapp.service -b

# Step 4: All errors in the system at the time of failure
sudo journalctl -p err --since "10 min ago" --no-pager

# Step 5: Check dependencies
systemctl list-dependencies myapp.service

# Step 6: Run manually as the service user (to reproduce)
sudo -u myapp /usr/local/bin/myapp --config /etc/myapp/config.yml

# Step 7: Check environment variables
sudo systemctl show myapp.service -p Environment

# Step 8: Check file permissions
sudo systemctl cat myapp.service | grep -E 'ExecStart|WorkingDirectory|User'
sudo ls -la /usr/local/bin/myapp

Quick Reference Cheatsheet

Service Control

Viewing State

Logs (journalctl)

Performance Diagnostics

Conclusion

Systemd is not a monster to be feared — it's a powerful tool that makes you dramatically more effective as a sysadmin or developer. Key takeaways from this guide:

1. Units are declarative resource descriptions. Write them properly and use available security directives.

2. cgroups mean systemd always knows where your processes are. Use this for monitoring and resource constraints.

3. journald is a database, not a text file. Learn to query it properly.

4. Drop-in files — never edit original package-installed unit files.

5. systemd-analyze — your first tool when diagnosing boot problems.

Зачем специализированная БД для временных рядов

Технологические данные — это всегда временной ряд: температура каждую секунду, давление каждые 100 мс, состояние оборудования каждые 10 мс. PostgreSQL или MySQL могут хранить такие данные. Но при миллионах записей в день начинаются проблемы.

Почему реляционные БД плохо справляются:

• Индексы B-Tree неэффективны для временных запросов ("за последний час")

• Запись строк в таблицу с индексами — медленно при высоком темпе

• GROUP BY time_interval требует дорогих вычислений

• Партиционирование по времени нужно настраивать вручную

• Хранение тысяч тегов → тысячи колонок или плохая схема

Что умеют Time-Series TSDB:

• Оптимизированная запись: 100 000+ точек/сек на скромном железе

• Встроенное сжатие (delta-delta, XOR float compression)

• Автоматические retention policies (TTL данных)

• Downsampling: автоматически агрегируем "горячие" данные в "холодные"

• Встроенные временны́е функции: moving average, rate, derivative

InfluxDB 2.x: промышленный стандарт IoT

Основные концепции

Measurement — аналог таблицы:

measurement: "telemetry"

Tags — индексированные метаданные (строки):

tags: device="conveyor1", location="line1", area="factory"

Fields — неиндексированные данные (числа, строки, bool):

fields: temperature=87.3, current=15.5, running=true

Timestamp — время с нано-точностью.

Точка данных (Point):

measurement,tags fields timestamp
telemetry,device=conveyor1,location=line1 temperature=87.3,current=15.5 1710000000000000000

Почему Tags vs Fields важно

Tags:    ИНДЕКСИРОВАНЫ → используйте для группировки/фильтрации
         device, location, sensor_type, unit_id

Fields:  НЕ индексированы → используйте для числовых данных
         temperature, pressure, current, voltage
         
ОШИБКА: положить temperature в Tag — поиск по значению работает,
        но карданальность огромная → индекс разрастётся → InfluxDB замедлится.
ОШИБКА: положить device_id в Field — нельзя эффективно фильтровать по устройству.

Python клиент InfluxDB 2.x:

from influxdb_client import InfluxDBClient, Point, WritePrecision
from influxdb_client.client.write_api import SYNCHRONOUS, WriteOptions
from datetime import datetime, timezone
import time

INFLUX_URL    = "http://localhost:8086"
INFLUX_TOKEN  = "your-api-token-here"
INFLUX_ORG    = "factory"
INFLUX_BUCKET = "process_data"

# Клиент с батчевой записью
client = InfluxDBClient(url=INFLUX_URL, token=INFLUX_TOKEN, org=INFLUX_ORG)

write_api = client.write_api(write_options=WriteOptions(
    batch_size        = 1000,    # Накапливаем до 1000 точек
    flush_interval    = 5_000,   # Или сбрасываем каждые 5 секунд
    jitter_interval   = 500,     # ±500мс для сглаживания нагрузки
    retry_interval    = 5_000,   # Retry при ошибке через 5с
    max_retry_time    = 180_000, # Максимум 3 минуты retry
))

query_api = client.query_api()

# ===== ЗАПИСЬ =====

def write_single_point(device: str, location: str,
                        temperature: float, current: float, running: bool):
    """Запись одной точки"""
    point = (
        Point("telemetry")
        .tag("device",   device)
        .tag("location", location)
        .field("temperature", temperature)
        .field("current",     current)
        .field("running",     int(running))  # bool → int (InfluxDB лучше хранит)
        .time(datetime.now(timezone.utc))
    )
    write_api.write(bucket=INFLUX_BUCKET, record=point)


def write_batch(measurements: list[dict]):
    """
    Эффективная пакетная запись.
    measurements: [{'device': 'pump1', 'temp': 25.3, 'current': 12.1}, ...]
    """
    points = []
    for m in measurements:
        p = (
            Point("telemetry")
            .tag("device",   m['device'])
            .tag("location", m.get('location', 'unknown'))
            .field("temperature", float(m.get('temp',    0)))
            .field("current",     float(m.get('current', 0)))
            .field("pressure",    float(m.get('pressure', 0)))
        )
        points.append(p)
    
    write_api.write(bucket=INFLUX_BUCKET, record=points)


# Запись в нативном line protocol (максимальная производительность):
def write_line_protocol(lines: list[str]):
    """
    Прямая запись в line protocol — самый быстрый способ.
    Формат: measurement[,tag=value...] field=value[,field=value...] [timestamp]
    """
    write_api.write(bucket=INFLUX_BUCKET, record='\n'.join(lines),
                    write_precision=WritePrecision.NANOSECONDS)

# Пример:
lines = [
    "telemetry,device=pump1,location=line1 temperature=87.3,current=15.5 1710000000000000000",
    "telemetry,device=pump2,location=line1 temperature=72.1,current=8.2  1710000000000000000",
    "telemetry,device=valve1,location=line2 position=75.0               1710000000000000000",
]
write_line_protocol(lines)


# ===== ЗАПРОСЫ (Flux) =====

def query_last_hour(device: str) -> list[dict]:
    """Последний час данных устройства"""
    flux = f'''
    from(bucket: "{INFLUX_BUCKET}")
        |> range(start: -1h)
        |> filter(fn: (r) => r._measurement == "telemetry")
        |> filter(fn: (r) => r.device == "{device}")
        |> filter(fn: (r) => r._field == "temperature" or r._field == "current")
        |> pivot(rowKey: ["_time"], columnKey: ["_field"], valueColumn: "_value")
        |> sort(columns: ["_time"])
    '''
    
    tables = query_api.query(flux)
    results = []
    for table in tables:
        for record in table.records:
            results.append({
                'time':        record.get_time().isoformat(),
                'temperature': record.values.get('temperature'),
                'current':     record.values.get('current'),
            })
    return results


def query_aggregated_stats(device: str, window: str = "5m",
                            range_start: str = "-24h") -> list[dict]:
    """
    Агрегированная статистика по временным окнам.
    window: "1m", "5m", "1h", "1d"
    """
    flux = f'''
    from(bucket: "{INFLUX_BUCKET}")
        |> range(start: {range_start})
        |> filter(fn: (r) => r._measurement == "telemetry" and r.device == "{device}")
        |> filter(fn: (r) => r._field == "temperature")
        |> aggregateWindow(
            every: {window},
            fn: (tables=<-, column) => tables |> reduce(
                identity: {{mean: 0.0, min: 99999.0, max: -99999.0, count: 0}},
                fn: (r, accumulator) => ({{
                    mean:  accumulator.mean + r._value,
                    min:   if r._value < accumulator.min  then r._value else accumulator.min,
                    max:   if r._value > accumulator.max  then r._value else accumulator.max,
                    count: accumulator.count + 1,
                }})
            ),
            createEmpty: false
        )
    '''
    # Для простого avg/min/max лучше использовать встроенные функции:
    flux_simple = f'''
    from(bucket: "{INFLUX_BUCKET}")
        |> range(start: {range_start})
        |> filter(fn: (r) => r._measurement == "telemetry" 
                          and r.device == "{device}"
                          and r._field == "temperature")
        |> aggregateWindow(every: {window}, fn: mean, createEmpty: false)
        |> yield(name: "mean")
    '''
    
    tables = query_api.query(flux_simple)
    return [{'time': r.get_time().isoformat(), 'mean_temp': r.get_value()}
            for table in tables for r in table.records]


def query_anomalies(threshold_high: float = 85.0,
                     range_start: str = "-7d") -> list[dict]:
    """Поиск аномалий — превышений порога"""
    flux = f'''
    from(bucket: "{INFLUX_BUCKET}")
        |> range(start: {range_start})
        |> filter(fn: (r) => r._measurement == "telemetry" and r._field == "temperature")
        |> filter(fn: (r) => r._value > {threshold_high})
        |> group(columns: ["device"])
        |> sort(columns: ["_time"], desc: true)
    '''
    
    tables = query_api.query(flux)
    return [{
        'device': r.values.get('device'),
        'time':   r.get_time().isoformat(),
        'value':  r.get_value(),
        'excess': round(r.get_value() - threshold_high, 2),
    } for table in tables for r in table.records]


def query_device_availability(range_start: str = "-30d") -> list[dict]:
    """Доступность (availability) по устройствам за период"""
    flux = f'''
    import "math"
    
    total = from(bucket: "{INFLUX_BUCKET}")
        |> range(start: {range_start})
        |> filter(fn: (r) => r._measurement == "telemetry" and r._field == "running")
        |> group(columns: ["device"])
        |> count()
        |> rename(columns: {{_value: "total_count"}})
    
    running = from(bucket: "{INFLUX_BUCKET}")
        |> range(start: {range_start})
        |> filter(fn: (r) => r._measurement == "telemetry" and r._field == "running")
        |> filter(fn: (r) => r._value == 1)
        |> group(columns: ["device"])
        |> count()
        |> rename(columns: {{_value: "running_count"}})
    
    join(tables: {{total, running}}, on: ["device"])
        |> map(fn: (r) => ({{ r with availability_pct: 
            math.round(x: r.running_count / r.total_count * 1000.0) / 10.0
        }}))
    '''
    
    tables = query_api.query(flux)
    return [{'device': r.values.get('device'),
             'availability': r.values.get('availability_pct')}
            for table in tables for r in table.records]

Retention Policies и Downsampling

Хранить сырые данные с секундным разрешением 10 лет — безумно дорого. Правильная стратегия:

"Горячие" данные:  1 секунда, 30 дней    → быстрый SSD
"Тёплые" данные:   1 минута,  1 год      → обычный SSD
"Холодные" данные: 1 час,     10 лет     → HDD/объектное хранилище

Конфигурация в InfluxDB 2.x:

# Создание bucket с retention 30 дней (сырые данные)
influx bucket create \
    --name process_data_raw \
    --retention 30d \
    --org factory

# Bucket для агрегированных данных (бессрочно)
influx bucket create \
    --name process_data_aggregated \
    --retention 0 \
    --org factory

Задача downsampling (Flux):

def setup_downsampling_task():
    """
    Создаём задачу InfluxDB для автоматического downsampling.
    Каждые 5 минут агрегируем сырые данные в минутные.
    """
    
    flux_task = '''
    option task = {
        name: "Downsampling: raw→1min",
        every: 5m,          // Запускать каждые 5 минут
        offset: 1m,         // Смещение (ждём пока данные придут)
    }
    
    // Читаем сырые данные за последние 5 минут
    data = from(bucket: "process_data_raw")
        |> range(start: -task.every)
        |> filter(fn: (r) => r._measurement == "telemetry")
    
    // Агрегируем каждую числовую метрику
    data
        |> filter(fn: (r) => r._field == "temperature" or 
                              r._field == "current"     or
                              r._field == "pressure")
        |> aggregateWindow(every: 1m, fn: mean, createEmpty: false)
        |> set(key: "_measurement", value: "telemetry_1m")
        |> to(bucket: "process_data_aggregated")
    
    // Для бинарных данных (running) — используем last
    data
        |> filter(fn: (r) => r._field == "running")
        |> aggregateWindow(every: 1m, fn: last, createEmpty: false)
        |> set(key: "_measurement", value: "telemetry_1m")
        |> to(bucket: "process_data_aggregated")
    '''
    
    # Создание задачи через API
    tasks_api = client.tasks_api()
    task = tasks_api.create_task_every(
        name="Downsampling: raw→1min",
        flux=flux_task,
        every="5m",
        organization=INFLUX_ORG
    )
    print(f"Задача создана: {task.id}")

TimescaleDB: PostgreSQL для временных рядов

TimescaleDB — расширение PostgreSQL. Если вы уже используете PostgreSQL и знаете SQL — это лучший выбор. Вы получаете TSDB-оптимизации при сохранении полного SQL.

-- Установка расширения
CREATE EXTENSION IF NOT EXISTS timescaledb;

-- Обычная таблица PostgreSQL
CREATE TABLE telemetry (
    time        TIMESTAMPTZ NOT NULL,
    device      TEXT        NOT NULL,
    location    TEXT        NOT NULL,
    temperature FLOAT,
    current     FLOAT,
    pressure    FLOAT,
    running     BOOLEAN,
    quality     TEXT DEFAULT 'GOOD'
);

-- Превращаем в hypertable (TimescaleDB магия!)
SELECT create_hypertable('telemetry', 'time',
    chunk_time_interval => INTERVAL '1 day'  -- Партиция = 1 день
);

-- Индекс на часто используемые теги
CREATE INDEX ON telemetry (device, time DESC);
CREATE INDEX ON telemetry (location, time DESC);

-- Compression (сжатие старых данных)
ALTER TABLE telemetry SET (
    timescaledb.compress,
    timescaledb.compress_segmentby = 'device',
    timescaledb.compress_orderby = 'time DESC'
);

-- Автоматическое сжатие данных старше 7 дней
SELECT add_compression_policy('telemetry', INTERVAL '7 days');

-- Автоматическое удаление старых данных (30 дней)
SELECT add_retention_policy('telemetry', INTERVAL '30 days');

Запросы (обычный SQL!):

-- Последний час данных с устройства
SELECT time, temperature, current, running
FROM telemetry
WHERE device = 'pump1'
  AND time > NOW() - INTERVAL '1 hour'
ORDER BY time DESC;

-- Среднее по 5-минутным окнам
SELECT 
    time_bucket('5 minutes', time) AS bucket,
    device,
    ROUND(AVG(temperature)::numeric, 2) AS avg_temp,
    ROUND(MIN(temperature)::numeric, 2) AS min_temp,
    ROUND(MAX(temperature)::numeric, 2) AS max_temp,
    COUNT(*) AS samples
FROM telemetry
WHERE device = 'pump1'
  AND time > NOW() - INTERVAL '24 hours'
GROUP BY bucket, device
ORDER BY bucket DESC;

-- Обнаружение аномалий (значение > avg + 2*stddev)
WITH stats AS (
    SELECT 
        device,
        AVG(temperature) AS avg_temp,
        STDDEV(temperature) AS std_temp
    FROM telemetry
    WHERE time > NOW() - INTERVAL '7 days'
    GROUP BY device
)
SELECT 
    t.time, t.device, t.temperature,
    s.avg_temp, s.std_temp,
    (t.temperature - s.avg_temp) / NULLIF(s.std_temp, 0) AS z_score
FROM telemetry t
JOIN stats s ON t.device = s.device
WHERE t.time > NOW() - INTERVAL '24 hours'
  AND ABS((t.temperature - s.avg_temp) / NULLIF(s.std_temp, 0)) > 2.0
ORDER BY ABS((t.temperature - s.avg_temp) / NULLIF(s.std_temp, 0)) DESC
LIMIT 50;

-- Доступность оборудования за месяц
SELECT 
    device,
    COUNT(*) FILTER (WHERE running = true)  AS running_count,
    COUNT(*) AS total_count,
    ROUND(
        COUNT(*) FILTER (WHERE running = true)::numeric / COUNT(*) * 100, 1
    ) AS availability_pct,
    SUM(CASE WHEN running THEN 1 ELSE 0 END) * 
        EXTRACT(EPOCH FROM INTERVAL '1 second') / 3600.0 AS running_hours
FROM telemetry
WHERE time > NOW() - INTERVAL '30 days'
GROUP BY device
ORDER BY availability_pct DESC;

Непрерывные агрегации (Continuous Aggregates):

-- Создаём материализованное представление с автообновлением
CREATE MATERIALIZED VIEW telemetry_5min
WITH (timescaledb.continuous) AS
SELECT 
    time_bucket('5 minutes', time) AS bucket,
    device,
    location,
    AVG(temperature)  AS avg_temp,
    MIN(temperature)  AS min_temp,
    MAX(temperature)  AS max_temp,
    AVG(current)      AS avg_current,
    MAX(current)      AS max_current,
    BOOL_OR(running)  AS any_running,
    COUNT(*)          AS sample_count
FROM telemetry
GROUP BY bucket, device, location
WITH NO DATA;

-- Автоматическое обновление каждые 5 минут
SELECT add_continuous_aggregate_policy('telemetry_5min',
    start_offset => INTERVAL '15 minutes',
    end_offset   => INTERVAL '5 minutes',
    schedule_interval => INTERVAL '5 minutes'
);

-- Запрос к агрегированным данным (мгновенно!)
SELECT * FROM telemetry_5min
WHERE device = 'pump1'
  AND bucket > NOW() - INTERVAL '24 hours'
ORDER BY bucket DESC;

Python + SQLAlchemy + TimescaleDB:

from sqlalchemy import create_engine, text
from sqlalchemy.orm import Session
import pandas as pd
from datetime import datetime, timedelta, timezone

DATABASE_URL = "postgresql://user:password@localhost:5432/factory_db"
engine = create_engine(DATABASE_URL, pool_size=10, max_overflow=20)

class TelemetryRepository:
    
    def write_batch(self, records: list[dict]) -> int:
        """Пакетная запись телеметрии"""
        if not records:
            return 0
        
        with engine.begin() as conn:
            result = conn.execute(
                text("""
                    INSERT INTO telemetry (time, device, location,
                                          temperature, current, pressure, running)
                    VALUES (:time, :device, :location,
                            :temperature, :current, :pressure, :running)
                    ON CONFLICT DO NOTHING
                """),
                records
            )
            return result.rowcount
    
    def get_latest(self, device: str, fields: list[str] = None) -> dict | None:
        """Последнее значение устройства"""
        field_list = ', '.join(fields or ['temperature', 'current', 'pressure', 'running'])
        
        with engine.connect() as conn:
            row = conn.execute(
                text(f"""
                    SELECT time, {field_list}
                    FROM telemetry
                    WHERE device = :device
                    ORDER BY time DESC
                    LIMIT 1
                """),
                {'device': device}
            ).fetchone()
            
            return dict(row._mapping) if row else None
    
    def get_as_dataframe(self, device: str, hours: int = 24) -> pd.DataFrame:
        """Загрузка данных в Pandas DataFrame для анализа"""
        query = text("""
            SELECT time, temperature, current, pressure, running
            FROM telemetry
            WHERE device = :device
              AND time > :since
            ORDER BY time
        """)
        
        with engine.connect() as conn:
            df = pd.read_sql(
                query,
                conn,
                params={'device': device,
                        'since': datetime.now(timezone.utc) - timedelta(hours=hours)},
                parse_dates=['time'],
                index_col='time'
            )
        
        return df
    
    def detect_anomalies_zscore(self, device: str, 
                                  field: str = 'temperature',
                                  threshold: float = 2.5) -> pd.DataFrame:
        """Обнаружение аномалий методом z-score"""
        df = self.get_as_dataframe(device, hours=24)
        
        if df.empty or field not in df.columns:
            return pd.DataFrame()
        
        mean = df[field].mean()
        std  = df[field].std()
        
        if std == 0:
            return pd.DataFrame()
        
        df['z_score'] = (df[field] - mean) / std
        anomalies = df[df['z_score'].abs() > threshold].copy()
        anomalies['is_high'] = anomalies['z_score'] > 0
        
        return anomalies[['z_score', field, 'is_high']]
    
    def get_equipment_report(self, days: int = 30) -> pd.DataFrame:
        """Отчёт по оборудованию за период"""
        query = text("""
            SELECT 
                device,
                COUNT(*) as total_records,
                COUNT(*) FILTER (WHERE running) as running_records,
                ROUND((COUNT(*) FILTER (WHERE running)::numeric / COUNT(*) * 100)::numeric, 1) as availability_pct,
                ROUND(AVG(temperature)::numeric, 1) as avg_temp,
                ROUND(MAX(temperature)::numeric, 1) as max_temp,
                ROUND(AVG(current)::numeric, 2) as avg_current
            FROM telemetry
            WHERE time > NOW() - MAKE_INTERVAL(days => :days)
            GROUP BY device
            ORDER BY device
        """)
        
        with engine.connect() as conn:
            return pd.read_sql(query, conn, params={'days': days})

Выбор TSDB: сравнительная таблица

Заключение

Выбор TSDB зависит от контекста. InfluxDB — лучший выбор для чистых IoT/телеметрия проектов: максимальная производительность, мощный Flux для временны́х вычислений, отличная экосистема. TimescaleDB — если уже есть PostgreSQL инфраструктура, нужны JOINs с другими данными или разработчики лучше знают SQL.

Ключевые принципы для production: всегда настраивайте retention policies (данные должны автоматически удаляться), используйте downsampling для долгосрочного хранения агрегатов, настройте сжатие (экономия 90%+ дискового пространства), мониторьте производительность самой TSDB.

Deadband-фильтрация на уровне edge-узла (не писать если значение не изменилось существенно) снижает нагрузку на БД в 5–50 раз для медленно меняющихся процессов. Это первое что нужно сделать перед любой оптимизацией TSDB.

Введение: PostgreSQL в продакшене — другой зверь

Поднять PostgreSQL локально — просто. Запустить его в продакшене под реальной нагрузкой так, чтобы он не падал, не тормозил и не раздувался до потери диска — это уже инженерия.

PostgreSQL 16, 17 и 18 принесли серьёзные улучшения производительности: логическая репликация стала намного мощнее, параллельные запросы умнее, планировщик научился большему. Но дефолтная конфигурация по-прежнему рассчитана на «запустить на ноутбуке с 256 МБ RAM», а не на production-сервер с 128 ГБ памяти.

Эта статья — системный разбор всего, что нужно сделать, чтобы PostgreSQL работал быстро, надёжно и предсказуемо. Никакой воды: только параметры, SQL, реальные кейсы.

Глава 1. Конфигурация: postgresql.conf с нуля

Память: самые важные параметры

# postgresql.conf

# shared_buffers — основной кэш PostgreSQL в памяти.
# Правило: 25-40% от RAM сервера.
# На 64 ГБ RAM: 16 ГБ
shared_buffers = 16GB

# effective_cache_size — подсказка планировщику, сколько памяти
# доступно для кэширования (shared_buffers + OS page cache).
# Правило: 50-75% от RAM.
# На 64 ГБ RAM: 48 ГБ
effective_cache_size = 48GB

# work_mem — память для одной операции сортировки/хэширования
# ВНИМАНИЕ: умножается на число параллельных запросов × число операций в плане!
# На сервере с 500 соединениями и work_mem=256MB → потенциально 128 ГБ!
# Разумно: 4-64 МБ для OLTP, 256 МБ-1 ГБ для аналитики
work_mem = 32MB

# maintenance_work_mem — для VACUUM, CREATE INDEX, ALTER TABLE
# Больше = быстрее индексы и вакуум. Безопасно давать больше, чем work_mem.
maintenance_work_mem = 2GB

# huge_pages — используем hugepages Linux для shared_buffers
# Обязательно для shared_buffers > 8 ГБ
huge_pages = on

WAL и checkpoint: баланс между скоростью и надёжностью

# wal_level — минимальный уровень для репликации
# replica — для физической репликации
# logical — для логической репликации (больше overhead)
wal_level = replica

# Размер WAL буфера (с PostgreSQL 16 wal_buffers=auto работает хорошо)
wal_buffers = 64MB

# checkpoint_completion_target — размазываем запись checkpoint во времени
# 0.9 означает: записать грязные страницы за 90% интервала между checkpoint
checkpoint_completion_target = 0.9

# max_wal_size — максимальный объём WAL между checkpoint
# При большой нагрузке на запись увеличьте до 4-16 ГБ
# Это НЕ размер хранилища WAL, а порог для инициации checkpoint
max_wal_size = 4GB

# min_wal_size — минимальный резерв WAL файлов
min_wal_size = 1GB

# wal_compression — сжатие WAL (PostgreSQL 15+: поддержка lz4, zstd)
# Снижает I/O, небольшой CPU overhead
wal_compression = lz4

Параллелизм (PostgreSQL 16+)

# max_worker_processes — общий пул фоновых процессов
max_worker_processes = 16

# max_parallel_workers_per_gather — параллельные воркеры на один запрос
# Правило: не более числа физических ядер / 2
max_parallel_workers_per_gather = 4

# max_parallel_workers — суммарно параллельных воркеров
max_parallel_workers = 8

# max_parallel_maintenance_workers — для CREATE INDEX CONCURRENTLY, VACUUM
max_parallel_maintenance_workers = 4

# parallel_tuple_cost, parallel_setup_cost — влияют на решение планировщика
# использовать параллельность. Снизить если параллельные планы не строятся.
parallel_tuple_cost = 0.1
parallel_setup_cost = 100

Соединения

# max_connections — ОСТОРОЖНО! Каждое соединение ≈ 5-10 МБ памяти.
# При PgBouncer: достаточно 100-200 серверных соединений.
# Без пула: реальное число ≤ 200-300
max_connections = 200

# superuser_reserved_connections — резерв для DBA
superuser_reserved_connections = 5

Планировщик: тонкая настройка

# random_page_cost — стоимость случайного чтения страницы.
# Для SSD: 1.1-1.5 (против дефолта 4.0 для HDD).
# Занижение → планировщик чаще выбирает Index Scan.
random_page_cost = 1.1

# seq_page_cost — стоимость последовательного чтения (база = 1.0)
seq_page_cost = 1.0

# effective_io_concurrency — параллельных I/O для Bitmap Heap Scan
# SSD: 200-300, HDD: 2-4, NVMe: 500+
effective_io_concurrency = 200

# default_statistics_target — точность статистики для планировщика
# Дефолт 100. Для колонок с высокой кардинальностью — до 500.
default_statistics_target = 200

# enable_partitionwise_join — важно для партиционированных таблиц
enable_partitionwise_join = on
enable_partitionwise_aggregate = on

Глава 2. Индексная стратегия

Правильные индексы — половина успеха. Неправильные — гарантированный bloat и тормоза на INSERT/UPDATE.

Типы индексов: когда что использовать

B-Tree — дефолт, для равенства и диапазонов:

-- Стандартный случай
CREATE INDEX idx_orders_user_id ON orders(user_id);

-- Частичный индекс — только активные записи
-- Занимает меньше места, быстрее обновляется
CREATE INDEX idx_orders_active ON orders(created_at)
WHERE status = 'active';

-- Покрывающий индекс (INCLUDE) — избегаем обращения к таблице
-- PostgreSQL 11+, активно улучшен в 16/17
CREATE INDEX idx_orders_cover ON orders(user_id)
INCLUDE (total_amount, status, created_at);

-- Составной: порядок имеет значение!
-- Ставьте впереди колонки с высокой кардинальностью
-- и те, по которым фильтрация точнее
CREATE INDEX idx_orders_composite ON orders(user_id, status, created_at);

GIN — для массивов, JSONB, полнотекстового поиска:

-- JSONB поиск
CREATE INDEX idx_products_attrs ON products USING GIN(attributes);

-- Полнотекстовый поиск
CREATE INDEX idx_articles_fts ON articles
USING GIN(to_tsvector('russian', title || ' ' || body));

-- Поиск в массивах
CREATE INDEX idx_tags ON posts USING GIN(tags);

BRIN — для очень больших таблиц с естественной сортировкой:

-- Для таблиц логов, временных рядов — экономия места 99%+
-- BRIN не хранит каждое значение, только мин/макс по блокам
CREATE INDEX idx_events_time_brin ON events
USING BRIN(created_at) WITH (pages_per_range = 128);

-- PostgreSQL 14+: bloom filter в BRIN
CREATE INDEX idx_events_bloom ON events
USING BRIN(device_id, created_at)
WITH (pages_per_range = 64);

Hash — только для точного равенства, быстрее B-Tree:

CREATE INDEX idx_sessions_token ON sessions
USING HASH(session_token);

Найти неиспользуемые и дублирующие индексы

-- Неиспользуемые индексы (кандидаты на удаление)
SELECT
    schemaname,
    tablename,
    indexname,
    pg_size_pretty(pg_relation_size(indexrelid)) AS index_size,
    idx_scan,
    idx_tup_read,
    idx_tup_fetch
FROM pg_stat_user_indexes
WHERE idx_scan = 0
  AND indexrelname NOT LIKE 'pg_%'
ORDER BY pg_relation_size(indexrelid) DESC;

-- Дублирующие индексы
SELECT
    indrelid::regclass AS table_name,
    array_agg(indexrelid::regclass) AS indexes,
    array_agg(indkey) AS index_keys
FROM pg_index
GROUP BY indrelid, indkey
HAVING count(*) > 1;

-- Индексы vs размер таблицы: раздутые индексы
SELECT
    t.tablename,
    pg_size_pretty(pg_total_relation_size(t.tablename::regclass)) AS total,
    pg_size_pretty(pg_relation_size(t.tablename::regclass)) AS table_size,
    pg_size_pretty(
        pg_total_relation_size(t.tablename::regclass) -
        pg_relation_size(t.tablename::regclass)
    ) AS indexes_size,
    round(
        (pg_total_relation_size(t.tablename::regclass) -
         pg_relation_size(t.tablename::regclass))::numeric /
        nullif(pg_total_relation_size(t.tablename::regclass), 0) * 100, 1
    ) AS index_ratio_pct
FROM pg_tables t
WHERE t.schemaname = 'public'
ORDER BY pg_total_relation_size(t.tablename::regclass) DESC
LIMIT 30;

Глава 3. EXPLAIN ANALYZE: читаем план запроса как профессионал

EXPLAIN ANALYZE — главный инструмент оптимизации. Без него — гадание на кофейной гуще.

-- Всегда используйте все опции
EXPLAIN (
    ANALYZE,           -- Реально выполнить и показать время
    BUFFERS,           -- Показать попадания/промахи кэша
    FORMAT TEXT,       -- или JSON для авто-анализа
    TIMING ON,         -- Время каждого узла
    SETTINGS ON,       -- Показать изменённые параметры
    WAL ON             -- PostgreSQL 13+: WAL активность
)
SELECT ...;

Анатомия плана: на что смотреть

EXPLAIN (ANALYZE, BUFFERS)
SELECT o.id, o.total, u.email
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.created_at > NOW() - INTERVAL '7 days'
  AND o.status = 'completed';

-- Типичный вывод:
--                                               QUERY PLAN
-- Hash Join  (cost=1250.00..8934.21 rows=1523 width=48) (actual time=45.231..189.443 rows=1287 loops=1)
--   Buffers: shared hit=4521 read=2341   ← read > 0 = данных нет в кэше
--   Hash Cond: (o.user_id = u.id)
--   ->  Bitmap Heap Scan on orders o  (cost=87.3..7512.4 rows=1523 width=32)
--         (actual time=2.341..145.231 rows=1287 loops=1)
--         Recheck Cond: (created_at > (now() - '7 days'::interval))
--         Filter: (status = 'completed')
--         Rows Removed by Filter: 4521   ← КРАСНЫЙ ФЛАГ: фильтруем 4521 строк!
--         Heap Blocks: exact=1823
--         Buffers: shared hit=123 read=1823
--         ->  Bitmap Index Scan on idx_orders_created_at
--               Index Cond: (created_at > (now() - '7 days'::interval))
--   ->  Hash  (cost=890.00..890.00 rows=21000 width=24) (actual time=42.3..42.3 rows=21000 loops=1)
--         Buckets: 32768  Batches: 1  Memory Usage: 1856kB
--         Buffers: shared hit=4398 read=518
--         ->  Seq Scan on users u  (cost=0.00..890.00 rows=21000 width=24)
-- Planning Time: 1.234 ms
-- Execution Time: 190.123 ms   ← Реальное время!

Красные флаги в плане:

Автоматический поиск медленных запросов

-- pg_stat_statements: топ-20 самых дорогих запросов
-- Требует: shared_preload_libraries = 'pg_stat_statements'
-- postgresql.conf: pg_stat_statements.track = all

SELECT
    round(total_exec_time::numeric, 2) AS total_ms,
    calls,
    round(mean_exec_time::numeric, 2) AS mean_ms,
    round(stddev_exec_time::numeric, 2) AS stddev_ms,
    round((total_exec_time / sum(total_exec_time) OVER () * 100)::numeric, 2) AS pct_total,
    round(rows::numeric / calls, 1) AS avg_rows,
    -- Соотношение кэш-попаданий
    round(
        100.0 * shared_blks_hit /
        nullif(shared_blks_hit + shared_blks_read, 0), 2
    ) AS cache_hit_pct,
    -- Нормализованный текст запроса (без значений параметров)
    left(query, 100) AS query_snippet
FROM pg_stat_statements
WHERE calls > 10
ORDER BY total_exec_time DESC
LIMIT 20;

-- Запросы с самым высоким среднем временем (не суммарным!)
SELECT
    calls,
    round(mean_exec_time::numeric, 2) AS mean_ms,
    round(max_exec_time::numeric, 2) AS max_ms,
    round(stddev_exec_time::numeric, 2) AS stddev_ms,
    left(query, 120) AS query
FROM pg_stat_statements
WHERE calls > 5
  AND mean_exec_time > 100  -- Больше 100 мс в среднем
ORDER BY mean_exec_time DESC
LIMIT 20;

-- Запросы с плохим cache hit ratio (много disk reads)
SELECT
    calls,
    round(mean_exec_time::numeric, 2) AS mean_ms,
    shared_blks_read,
    shared_blks_hit,
    round(100.0 * shared_blks_hit /
          nullif(shared_blks_hit + shared_blks_read, 0), 2) AS cache_hit_pct,
    left(query, 120) AS query
FROM pg_stat_statements
WHERE calls > 10
  AND (shared_blks_hit + shared_blks_read) > 0
  AND shared_blks_read > shared_blks_hit  -- Больше промахов чем попаданий
ORDER BY shared_blks_read DESC
LIMIT 20;

Глава 4. Autovacuum: настройка, а не молитва

Autovacuum — не враг, а друг. Но дефолтные настройки рассчитаны на небольшие таблицы. На больших таблицах он либо не успевает, либо тормозит рабочую нагрузку.

Понять текущее состояние vacuum

-- Таблицы с наибольшим dead tuple bloat
SELECT
    schemaname,
    relname AS tablename,
    n_live_tup,
    n_dead_tup,
    round(n_dead_tup::numeric / nullif(n_live_tup + n_dead_tup, 0) * 100, 2) AS dead_pct,
    last_vacuum,
    last_autovacuum,
    last_analyze,
    last_autoanalyze,
    autovacuum_count,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||relname)) AS total_size
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC
LIMIT 20;

-- Таблицы, которым скоро нужен vacuum (по счётчику транзакций)
-- age() показывает сколько транзакций прошло с последнего freeze
SELECT
    schemaname,
    relname,
    pg_size_pretty(pg_total_relation_size(oid)) AS size,
    age(relfrozenxid) AS xid_age,
    round(age(relfrozenxid)::numeric / 2000000000 * 100, 2) AS freeze_pct,
    -- Когда автовакуум сделает freeze (по умолчанию при 150M транзакций)
    (200000000 - age(relfrozenxid)) AS txids_until_freeze
FROM pg_class
JOIN pg_namespace ON pg_namespace.oid = pg_class.relnamespace
WHERE relkind = 'r'
  AND nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY age(relfrozenxid) DESC
LIMIT 20;

-- Текущие процессы autovacuum
SELECT
    pid,
    now() - xact_start AS duration,
    query,
    state,
    wait_event_type,
    wait_event
FROM pg_stat_activity
WHERE query LIKE 'autovacuum:%'
ORDER BY duration DESC;

Оптимальная настройка autovacuum

# postgresql.conf — глобальные настройки autovacuum

# Число процессов autovacuum
autovacuum_max_workers = 6   # Дефолт 3; на активном сервере — 4-8

# Стоимостной лимит для autovacuum (throttling)
# Дефолт 200 — очень агрессивное ограничение скорости.
# На SSD можно поднять до 800-2000.
autovacuum_vacuum_cost_limit = 800

# Задержка между "порциями" vacuum (cooldown)
# При cost_limit=800 и delay=2ms → ~400 МБ/с максимальная скорость vacuum
autovacuum_vacuum_cost_delay = 2ms

# Порог запуска VACUUM: n_dead_tup > autovacuum_vacuum_threshold + n_live_tup * scale_factor
autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.02   # 2% от таблицы (дефолт 20%)

# Порог запуска ANALYZE
autovacuum_analyze_threshold = 50
autovacuum_analyze_scale_factor = 0.01  # 1% (дефолт 20%)

# Для больших таблиц scale_factor делает vacuum очень редким:
# Таблица 100M строк × 0.02 = 2M dead tuples до запуска vacuum — МНОГО

Настройка per-table (лучше глобальных для горячих таблиц):

-- Для высокоактивных таблиц: vacuum чаще, агрессивнее
ALTER TABLE orders SET (
    autovacuum_vacuum_scale_factor = 0.005,   -- Запуск при 0.5% dead tuples
    autovacuum_analyze_scale_factor = 0.002,  -- Analyze при 0.2%
    autovacuum_vacuum_cost_limit = 1600,      -- Более высокий лимит I/O
    autovacuum_vacuum_cost_delay = 1          -- Меньше пауз
);

-- Для append-only таблиц (логи, временные ряды):
-- Vacuum не нужен часто, но freeze — важен
ALTER TABLE event_log SET (
    autovacuum_vacuum_scale_factor = 0.2,        -- Редкий vacuum (мало UPDATE/DELETE)
    autovacuum_freeze_max_age = 500000000,        -- Freeze через 500M транзакций
    autovacuum_vacuum_cost_limit = 2000           -- Быстрый когда запустился
);

-- Проверить что настройки применились:
SELECT relname, reloptions
FROM pg_class
WHERE relname IN ('orders', 'event_log');

Обнаружение table bloat (раздутых таблиц)

-- Скрипт оценки bloat (не требует сторонних расширений)
WITH constants AS (
    SELECT current_setting('block_size')::numeric AS bs,
           23 AS hdr, 8 AS ma
),
columns_per_table AS (
    SELECT att.attrelid,
           count(*) AS cols,
           -- Байт nullmap на строку
           (count(*) + 7) / 8 AS nullhdr
    FROM pg_attribute att
    WHERE att.attnum > 0 AND NOT att.attisdropped
    GROUP BY 1
),
rows_estimate AS (
    SELECT c.oid,
           CASE WHEN c.reltuples < 0 THEN 0 ELSE c.reltuples END AS est_rows,
           c.relpages,
           c.relname,
           n.nspname
    FROM pg_class c
    JOIN pg_namespace n ON n.oid = c.relnamespace
    WHERE c.relkind = 'r'
      AND n.nspname NOT IN ('pg_catalog', 'information_schema')
)
SELECT
    re.nspname || '.' || re.relname AS table_name,
    re.est_rows,
    re.relpages AS current_pages,
    pg_size_pretty(re.relpages * 8192) AS current_size,
    -- Оценочный реальный размер
    pg_size_pretty(
        ceil(re.est_rows * 30 / 8192.0)::bigint * 8192
    ) AS estimated_real_size,
    round(
        100.0 * (re.relpages - ceil(re.est_rows * 30 / 8192.0)) /
        nullif(re.relpages, 0), 1
    ) AS bloat_pct
FROM rows_estimate re
WHERE re.relpages > 100
ORDER BY (re.relpages - ceil(re.est_rows * 30 / 8192.0)) DESC
LIMIT 20;

-- Для точного bloat используйте расширение pgstattuple:
-- CREATE EXTENSION pgstattuple;
SELECT * FROM pgstattuple('orders');
-- Поля: table_len, live_tuple_count, dead_tuple_count, dead_tuple_percent, free_space

Глава 5. Connection Pooling с PgBouncer

Каждое соединение с PostgreSQL — это отдельный процесс (~5 МБ памяти + overhead планировщика). 1000 соединений = 5 ГБ памяти только на процессы. PgBouncer решает эту проблему.

Режимы PgBouncer

Конфигурация PgBouncer

# /etc/pgbouncer/pgbouncer.ini

[databases]
# Синтаксис: alias = host=... dbname=... port=... user=...
myapp = host=127.0.0.1 port=5432 dbname=myapp_db

# Для чтения — отдельный пул на реплику
myapp_ro = host=replica.internal port=5432 dbname=myapp_db

[pgbouncer]
# Режим пула
pool_mode = transaction

# Адрес и порт PgBouncer
listen_addr = 0.0.0.0
listen_port = 5432

# Максимум клиентских соединений (к PgBouncer)
max_client_conn = 2000

# Размер серверного пула на базу (к PostgreSQL)
# PostgreSQL: max_connections = 200
# PgBouncer: default_pool_size = 80 (на каждую базу)
default_pool_size = 80

# Минимальный пул (держим готовые соединения)
min_pool_size = 10

# Резерв для суперпользователя (аналог reserved_connections)
reserve_pool_size = 5
reserve_pool_timeout = 3

# Таймауты
server_idle_timeout = 600      # Закрыть серверное соединение через 10 мин idle
client_idle_timeout = 0        # Не закрывать клиентские (0 = infinite)
server_connect_timeout = 5     # Таймаут подключения к PostgreSQL
query_timeout = 0              # 0 = нет лимита на запрос (лучше ставить в app)
query_wait_timeout = 120       # Ждать свободного соединения до 120 с

# Проверка соединений
server_check_query = select 1
server_check_delay = 30

# Аутентификация (scram-sha-256 — стандарт PG 14+)
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt

# Логирование (не слишком подробное — влияет на производительность)
log_connections = 0
log_disconnections = 0
log_pooler_errors = 1

# Admin интерфейс
admin_users = pgbouncer_admin
stats_users = monitoring_user

# Производительность
tcp_keepalive = 1
tcp_keepidle = 60
tcp_keepintvl = 10
tcp_keepcnt = 5

Мониторинг PgBouncer

-- Подключиться к admin БД PgBouncer:
-- psql -h localhost -p 5432 -U pgbouncer_admin pgbouncer

-- Состояние пулов
SHOW POOLS;
-- cl_active  — клиентов с активным серверным соединением
-- cl_waiting — клиентов в очереди (ждут свободного соединения!)
-- sv_active  — серверных соединений в работе
-- sv_idle    — серверных соединений в ожидании (пул)
-- sv_used    — только что освобождённые (не проверены ещё)
-- maxwait    — максимальное время ожидания клиента (критический параметр!)

-- Статистика
SHOW STATS;
-- total_query_time — суммарное время выполнения запросов
-- avg_query_time   — среднее время запроса
-- total_wait_time  — суммарное время ожидания в очереди

-- Список клиентов
SHOW CLIENTS;

-- Перезагрузить конфиг без перезапуска
RELOAD;

-- Сбросить статистику
RESET STATS;

Интеграция с PostgreSQL 17: встроенный connection shard

PostgreSQL 17 улучшил max_connections по производительности и добавил механизм connection_obeys_lc_messages — мелочь, но полезная. Работа над встроенным пулингом (connection pooling) ведётся активно, следите за PostgreSQL 18.

Глава 6. Партиционирование: когда таблица растёт до сотен ГБ

Партиционирование делит одну логическую таблицу на несколько физических. PostgreSQL 16/17 значительно улучшили работу с партициями: умный pruning, параллельные операции, partition-wise joins.

RANGE партиционирование (самое частое — по дате)

-- Создание партиционированной таблицы
CREATE TABLE events (
    id          BIGSERIAL,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    device_id   INT NOT NULL,
    event_type  TEXT NOT NULL,
    payload     JSONB,
    PRIMARY KEY (id, created_at)  -- created_at обязательна в PK для партиций!
) PARTITION BY RANGE (created_at);

-- Создание партиций (вручную или автоматически)
CREATE TABLE events_2024_01 PARTITION OF events
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

CREATE TABLE events_2024_02 PARTITION OF events
    FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

-- DEFAULT партиция для данных вне диапазона
CREATE TABLE events_default PARTITION OF events DEFAULT;

-- Индексы создаются на каждой партиции отдельно
-- (или глобально через CREATE INDEX на родительской — PG 11+)
CREATE INDEX idx_events_device ON events(device_id, created_at);
-- Автоматически создаст индекс на каждой партиции!

Автоматическое создание партиций (pg_partman)

Ручное создание партиций — путь к ошибкам. Используйте pg_partman:

-- Установка pg_partman
-- Добавить в postgresql.conf: shared_preload_libraries = 'pg_partman_bgw'

-- Настройка автоматического управления партициями
SELECT partman.create_parent(
    p_parent_table   => 'public.events',
    p_control        => 'created_at',
    p_interval       => 'monthly',       -- или 'weekly', 'daily', 'yearly'
    p_premake        => 3,               -- Создавать 3 будущих партиции заранее
    p_start_partition => '2024-01-01'
);

-- Настройка retention (удаление старых партиций)
UPDATE partman.part_config
SET retention = '12 months',           -- Хранить 12 месяцев
    retention_keep_table = false,       -- Удалять партицию физически
    retention_keep_index = false        -- Удалять и индексы
WHERE parent_table = 'public.events';

-- Запуск обслуживания вручную (обычно pg_partman_bgw делает это сам)
CALL partman.run_maintenance_proc();

Partition Pruning: проверяем что планировщик умный

-- Планировщик должен сканировать только нужные партиции
EXPLAIN
SELECT count(*)
FROM events
WHERE created_at BETWEEN '2024-03-01' AND '2024-03-31';

-- Ищем в плане: "Partitions: events_2024_03"
-- НЕ должно быть: "Append (всех партиций)"
-- Если pruning не работает — проверьте что условие на колонку партиционирования
-- и её тип совпадают (нет неявных каст)

-- Partition pruning во время выполнения (runtime pruning, PG 11+)
-- Работает даже для параметров ($1, $2) если enable_partition_pruning = on
SET enable_partition_pruning = on;  -- Дефолт on в PG 16+

LIST партиционирование (по типу/региону)

CREATE TABLE orders (
    id         BIGSERIAL,
    region     TEXT NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    total      DECIMAL(10,2)
) PARTITION BY LIST (region);

CREATE TABLE orders_eu   PARTITION OF orders FOR VALUES IN ('DE', 'FR', 'NL', 'PL');
CREATE TABLE orders_us   PARTITION OF orders FOR VALUES IN ('US', 'CA', 'MX');
CREATE TABLE orders_asia PARTITION OF orders FOR VALUES IN ('CN', 'JP', 'KR', 'IN');
CREATE TABLE orders_rest PARTITION OF orders DEFAULT;

HASH партиционирование (равномерное распределение)

-- Для таблиц без естественного ключа партиционирования
-- Гарантирует примерно равный размер партиций
CREATE TABLE sessions (
    id         UUID DEFAULT gen_random_uuid(),
    user_id    INT NOT NULL,
    data       JSONB
) PARTITION BY HASH (user_id);

-- Создаём N партиций (степень двойки — хорошая практика)
CREATE TABLE sessions_0 PARTITION OF sessions FOR VALUES WITH (MODULUS 8, REMAINDER 0);
CREATE TABLE sessions_1 PARTITION OF sessions FOR VALUES WITH (MODULUS 8, REMAINDER 1);
-- ... и т.д. до sessions_7

Глава 7. Репликация: PostgreSQL 16/17/18

Физическая репликация (Streaming Replication)

# На Primary: postgresql.conf
wal_level = replica
max_wal_senders = 10          # Максимум одновременных реплик
wal_keep_size = 1GB           # Буфер WAL для реплик (PG 13+, заменил wal_keep_segments)
hot_standby = on              # Разрешить запросы на реплике
hot_standby_feedback = on     # Реплика сообщает Primary о своих транзакциях

# pg_hba.conf на Primary — разрешаем репликацию с адреса реплики:
# host replication replicator 10.0.0.2/32 scram-sha-256

# На Standby: создание базовой копии
pg_basebackup \
    -h primary.host \
    -U replicator \
    -D /var/lib/postgresql/17/main \
    -P \
    --wal-method=stream \
    --checkpoint=fast \
    --write-recovery-conf    # Создаёт standby.signal и postgresql.auto.conf

# postgresql.auto.conf на Standby (создаётся pg_basebackup):
# primary_conninfo = 'host=primary.host port=5432 user=replicator password=...'

-- Мониторинг репликации на Primary:
SELECT
    client_addr,
    usename,
    application_name,
    state,
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    -- Лаг в байтах
    pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replay_lag_bytes,
    -- Лаг во времени (PG 10+)
    write_lag,
    flush_lag,
    replay_lag,
    sync_state
FROM pg_stat_replication
ORDER BY replay_lag DESC;

-- На Standby — проверка своего лага:
SELECT
    now() - pg_last_xact_replay_timestamp() AS replication_lag,
    pg_is_in_recovery() AS is_replica,
    pg_last_wal_receive_lsn() AS received_lsn,
    pg_last_wal_replay_lsn() AS replayed_lsn;

Логическая репликация (PostgreSQL 16/17: серьёзно улучшена)

Логическая репликация в PostgreSQL 16 получила:

• Двунаправленная (bidirectional) репликация — обе стороны могут принимать запись

• Streaming больших транзакций в реальном времени (без ожидания COMMIT)

• Параллельное применение изменений на подписчике

-- На Publisher (источник):
-- postgresql.conf: wal_level = logical

-- Создание публикации
CREATE PUBLICATION my_pub
    FOR TABLE orders, users, products
    WITH (publish = 'insert, update, delete', publish_via_partition_root = true);

-- Для всех таблиц:
CREATE PUBLICATION all_tables FOR ALL TABLES;

-- На Subscriber (назначение):
-- Создание подписки
CREATE SUBSCRIPTION my_sub
    CONNECTION 'host=primary.host port=5432 dbname=mydb user=replicator password=secret'
    PUBLICATION my_pub
    WITH (
        connect = true,
        slot_name = 'my_sub_slot',
        synchronous_commit = 'off',  -- Более быстрая репликация
        streaming = on               -- PG 14+: stream больших транзакций
    );

-- Мониторинг логической репликации на Publisher:
SELECT
    slot_name,
    plugin,
    slot_type,
    database,
    active,
    active_pid,
    -- КРИТИЧНО: wal_status = 'lost' означает что слот отстал и WAL удалён
    wal_status,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn))
        AS subscriber_lag
FROM pg_replication_slots;

-- ОПАСНОСТЬ: неактивный logical slot держит WAL! Диск кончится.
-- Если слот не используется > 24ч — проверить и при необходимости удалить:
-- SELECT pg_drop_replication_slot('my_sub_slot');

Глава 8. Мониторинг: что смотреть в продакшене

Системные вьюшки — источник правды

-- ===== АКТИВНЫЕ ЗАПРОСЫ И БЛОКИРОВКИ =====

-- Запросы дольше 30 секунд — потенциальные проблемы
SELECT
    pid,
    now() - pg_stat_activity.query_start AS duration,
    query,
    state,
    wait_event_type,
    wait_event,
    client_addr,
    usename,
    application_name
FROM pg_stat_activity
WHERE (now() - pg_stat_activity.query_start) > INTERVAL '30 seconds'
  AND state != 'idle'
ORDER BY duration DESC;

-- Граф блокировок: кто кого блокирует
WITH RECURSIVE lock_graph AS (
    -- Базовый случай: запросы, ожидающие блокировку
    SELECT
        blocked.pid AS blocked_pid,
        blocked.query AS blocked_query,
        blocked.query_start AS blocked_start,
        blocker.pid AS blocker_pid,
        blocker.query AS blocker_query,
        0 AS depth
    FROM pg_stat_activity blocked
    JOIN pg_stat_activity blocker
        ON blocker.pid = ANY(pg_blocking_pids(blocked.pid))
    WHERE blocked.wait_event_type = 'Lock'
    
    UNION ALL
    
    -- Рекурсивный случай: цепочки блокировок
    SELECT
        lg.blocked_pid,
        lg.blocked_query,
        lg.blocked_start,
        blocker.pid,
        blocker.query,
        lg.depth + 1
    FROM lock_graph lg
    JOIN pg_stat_activity blocker
        ON blocker.pid = ANY(pg_blocking_pids(lg.blocker_pid))
    WHERE lg.depth < 10
)
SELECT
    blocked_pid,
    left(blocked_query, 80) AS blocked_query,
    now() - blocked_start AS wait_duration,
    blocker_pid,
    left(blocker_query, 80) AS blocker_query,
    depth
FROM lock_graph
ORDER BY wait_duration DESC;

-- Если нужно убить зависший запрос (мягко):
-- SELECT pg_cancel_backend(pid);  -- Отмена запроса, транзакция откатывается

-- Если не реагирует (жёстко):
-- SELECT pg_terminate_backend(pid);  -- Завершение процесса


-- ===== КЭШ И I/O =====

-- Cache hit ratio (цель: > 99%)
SELECT
    sum(heap_blks_hit) AS heap_hit,
    sum(heap_blks_read) AS heap_read,
    round(
        sum(heap_blks_hit)::numeric /
        nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0) * 100, 3
    ) AS cache_hit_ratio
FROM pg_statio_user_tables;

-- По каждой таблице:
SELECT
    relname AS table_name,
    heap_blks_hit,
    heap_blks_read,
    round(heap_blks_hit::numeric / nullif(heap_blks_hit + heap_blks_read, 0) * 100, 2)
        AS cache_hit_pct,
    idx_blks_hit,
    idx_blks_read,
    round(idx_blks_hit::numeric / nullif(idx_blks_hit + idx_blks_read, 0) * 100, 2)
        AS idx_cache_hit_pct
FROM pg_statio_user_tables
WHERE heap_blks_read + heap_blks_hit > 0
ORDER BY heap_blks_read DESC
LIMIT 20;


-- ===== CHECKPOINT СТАТИСТИКА =====
SELECT
    checkpoints_timed,
    checkpoints_req,            -- Если часто req >> timed: увеличить max_wal_size
    checkpoint_write_time / 1000 AS write_sec,
    checkpoint_sync_time / 1000 AS sync_sec,
    buffers_checkpoint,
    buffers_clean,
    buffers_backend,            -- Если много: bgwriter не успевает → тюнинг bgwriter
    buffers_backend_fsync,      -- НЕ ноль = ПРОБЛЕМА: backend делает fsync сам
    buffers_alloc
FROM pg_stat_bgwriter;

-- Если buffers_backend > 0 — увеличить bgwriter_lru_maxpages:
-- bgwriter_lru_maxpages = 200     (дефолт 100)
-- bgwriter_lru_multiplier = 4.0   (дефолт 2.0)
-- bgwriter_delay = 50ms           (дефолт 200ms)

Скрипт ежедневного health-check

-- Сохранить как daily_healthcheck.sql и запускать через cron

\echo '=== PostgreSQL Daily Health Check ==='
\echo ''

\echo '--- Database Sizes ---'
SELECT datname,
       pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database
WHERE datname NOT IN ('postgres', 'template0', 'template1')
ORDER BY pg_database_size(datname) DESC;

\echo ''
\echo '--- Top 10 Largest Tables ---'
SELECT schemaname || '.' || tablename AS table,
       pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) AS total_size
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC
LIMIT 10;

\echo ''
\echo '--- Tables with High Dead Tuple Ratio (> 10%) ---'
SELECT relname,
       n_live_tup,
       n_dead_tup,
       round(n_dead_tup::numeric / nullif(n_live_tup + n_dead_tup, 0) * 100, 1) AS dead_pct,
       last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup::numeric / nullif(n_live_tup + n_dead_tup, 0) > 0.1
  AND n_live_tup > 1000
ORDER BY dead_pct DESC;

\echo ''
\echo '--- Replication Lag ---'
SELECT application_name, replay_lag, sync_state
FROM pg_stat_replication;

\echo ''
\echo '--- Long-Running Transactions (> 1 hour) ---'
SELECT pid,
       usename,
       now() - xact_start AS duration,
       left(query, 100) AS query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
  AND now() - xact_start > INTERVAL '1 hour'
  AND pid != pg_backend_pid()
ORDER BY duration DESC;

\echo ''
\echo '--- Unused Indexes (0 scans) ---'
SELECT schemaname, tablename, indexname,
       pg_size_pretty(pg_relation_size(indexrelid)) AS size
FROM pg_stat_user_indexes
WHERE idx_scan = 0
  AND pg_relation_size(indexrelid) > 10 * 1024 * 1024  -- > 10 МБ
ORDER BY pg_relation_size(indexrelid) DESC
LIMIT 10;

Глава 9. Новинки PostgreSQL 16/17/18

PostgreSQL 16 (2023)

Логическая репликация от standby — теперь можно публиковать изменения не только с primary, разгружая мастер.

Параллельный COPY — загрузка данных через COPY стала параллельной.

Улучшения планировщика для GROUP BY с параллелизмом.

pg_stat_io — новая системная вьюшка для детальной статистики I/O:

-- PostgreSQL 16+: детальная I/O статистика
SELECT backend_type, object, context, reads, writes, extends,
       op_bytes,
       hits,
       evictions,
       reuses,
       fsyncs,
       read_time, write_time
FROM pg_stat_io
ORDER BY reads + writes DESC;
-- Особенно полезно: сравнить hits vs reads для разных backend_type

COPY FROM ... WHERE — фильтрация при загрузке данных:

-- Загружаем только нужные строки
COPY orders FROM '/tmp/orders.csv' CSV HEADER
WHERE status = 'completed' AND total > 100;

PostgreSQL 17 (2024)

MERGE стал намного мощнее — поддержка RETURNING, DO NOTHING:

-- PostgreSQL 17: MERGE с RETURNING
MERGE INTO inventory AS target
USING incoming_stock AS source
    ON target.product_id = source.product_id
WHEN MATCHED THEN
    UPDATE SET quantity = target.quantity + source.quantity
WHEN NOT MATCHED THEN
    INSERT (product_id, quantity) VALUES (source.product_id, source.quantity)
RETURNING target.product_id, target.quantity, merge_action();
-- merge_action() → 'INSERT' или 'UPDATE'

Incremental sorting улучшен — быстрее для DISTINCT и ORDER BY.

pg_stat_statements получил toplevel — разделение top-level vs вложенных запросов.

Vacuum improvements — улучшена скорость заморозки (freeze), меньше I/O.

VACUUM (SKIP_DATABASE_STATS) — ускорение вакуума многих мелких таблиц.

Размер WAL записей уменьшен — меньше I/O при интенсивной записи.

PostgreSQL 18 (2025, в разработке / ранние беты)

Встроенный асинхронный I/O (io_method = io_uring) — огромный прирост для NVMe SSD, особенно при высоком параллелизме:

# postgresql.conf (PostgreSQL 18 при использовании Linux io_uring)
io_method = io_uring     # Дефолт: sync; альтернатива: worker

Планировщик с ML-hints — работа над улучшением кардинальности оценок.

GRANT/REVOKE для роли по умолчанию — улучшена система безопасности.

Глава 10. Практические кейсы: реальные проблемы и их решения

Кейс 1: «Запросы стали медленнее после VACUUM»

-- Симптом: autovacuum отработал, но запросы стали медленнее.
-- Причина: устаревшая статистика. VACUUM не обновляет статистику!

-- Решение 1: Принудительный ANALYZE
ANALYZE VERBOSE orders;

-- Или для всей БД:
-- vacuumdb --analyze-only --all

-- Решение 2: Увеличить точность статистики для проблемных колонок
ALTER TABLE orders
    ALTER COLUMN status SET STATISTICS 500,
    ALTER COLUMN region SET STATISTICS 500;

ANALYZE orders;

-- Проверить статистику после:
SELECT attname, n_distinct, correlation
FROM pg_stats
WHERE tablename = 'orders'
  AND attname IN ('status', 'region', 'created_at');

Кейс 2: «Диск заполнился WAL файлами»

-- Причина 1: Зависший логический слот репликации
SELECT slot_name, active, wal_status,
       pg_size_pretty(
           pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
       ) AS retained_wal
FROM pg_replication_slots
WHERE wal_status != 'reserved';

-- Если слот неактивен и держит WAL — удалить после согласования с командой:
SELECT pg_drop_replication_slot('stale_slot_name');

-- Причина 2: archive_command не успевает
-- Проверить:
SELECT last_archived_wal, last_failed_wal, last_failed_time
FROM pg_stat_archiver;

-- Временная мера: уменьшить max_wal_size
-- Постоянная: починить archive_command или увеличить место

-- Причина 3: Слишком агрессивные checkpoint
-- Уменьшить wal_keep_size если репликация живая

Кейс 3: «Connection pool переполнен, приложение не может подключиться»

-- Диагноз: смотрим pg_stat_activity
SELECT state, count(*), left(query, 50) AS sample_query
FROM pg_stat_activity
WHERE datname = 'myapp_db'
GROUP BY state, left(query, 50)
ORDER BY count(*) DESC;

-- Частая причина: idle in transaction (транзакция открыта и забыта)
SELECT pid, now() - xact_start AS idle_duration, query
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND now() - xact_start > INTERVAL '5 minutes'
ORDER BY idle_duration DESC;

-- Быстрое решение: убить зависшие idle in transaction
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND now() - xact_start > INTERVAL '10 minutes';

-- Постоянное решение: idle_in_transaction_session_timeout
-- postgresql.conf:
-- idle_in_transaction_session_timeout = 5min
-- idle_session_timeout = 30min  (PG 14+)

Кейс 4: «Таблица растёт несмотря на DELETE»

-- Table bloat: место от удалённых строк не возвращается OS.
-- PostgreSQL помечает строки как "мёртвые", VACUUM освобождает их
-- для ПОВТОРНОГО ИСПОЛЬЗОВАНИЯ, но не возвращает OS (кроме pg_toast).

-- Проверить bloat:
SELECT
    relname,
    pg_size_pretty(pg_total_relation_size(oid)) AS total_size,
    n_dead_tup,
    n_live_tup
FROM pg_stat_user_tables
JOIN pg_class USING (relid)
WHERE relname = 'your_table';

-- Решение 1: VACUUM FULL (блокирует таблицу! Используйте в окно обслуживания)
VACUUM FULL ANALYZE your_table;

-- Решение 2: pg_repack (без блокировки!)
-- Устанавливается отдельно: https://github.com/reorg/pg_repack
-- pg_repack -d mydb -t your_table

-- Решение 3: для партиционированных таблиц — просто удалить старую партицию
-- ALTER TABLE events DETACH PARTITION events_2022_01;
-- DROP TABLE events_2022_01;  -- Мгновенное освобождение места!

Заключение: чеклист production PostgreSQL

КОНФИГУРАЦИЯ
□ shared_buffers = 25-40% RAM
□ effective_cache_size = 50-75% RAM
□ work_mem настроен с учётом max_connections × parallel_workers
□ random_page_cost = 1.1-1.5 для SSD/NVMe
□ huge_pages = on (при shared_buffers > 8 ГБ, настроен в Linux)
□ max_wal_size = 2-8 ГБ (зависит от нагрузки)
□ wal_compression = lz4 (PG 15+)
□ idle_in_transaction_session_timeout = 5min
□ statement_timeout = установлен разумный лимит

МОНИТОРИНГ
□ pg_stat_statements включён и регулярно анализируется
□ Алерт на cache hit ratio < 95%
□ Алерт на replication lag > 60s
□ Алерт на bloat > 30% для критичных таблиц
□ Алерт на неактивные replication slots
□ Ежедневный health check запрос

AUTOVACUUM
□ autovacuum_max_workers = 4-6
□ autovacuum_vacuum_cost_delay = 2ms (SSD)
□ autovacuum_vacuum_cost_limit = 800-2000
□ Scale factor снижен для горячих таблиц
□ Мониторинг n_dead_tup и xid_age

СОЕДИНЕНИЯ
□ PgBouncer в transaction mode
□ max_connections ≤ 300 (больше — через пул)
□ Настроен pool_size в PgBouncer
□ Мониторинг cl_waiting в PgBouncer

ИНДЕКСЫ
□ Аудит неиспользуемых индексов (pg_stat_user_indexes)
□ Составные индексы с правильным порядком колонок
□ INCLUDE для покрывающих индексов
□ BRIN для append-only больших таблиц

РЕПЛИКАЦИЯ
□ Мониторинг replay_lag
□ Мониторинг pg_replication_slots на утечку WAL
□ Проверка wal_status всех слотов
□ hot_standby_feedback = on на репликах

БЕЗОПАСНОСТЬ
□ scram-sha-256 в pg_hba.conf
□ Минимальные привилегии для каждого пользователя
□ ssl = on + проверка сертификатов
□ log_connections/log_disconnections для аудита

PostgreSQL — невероятно мощная система, которая «из коробки» даёт примерно 20% своего потенциала. Правильная конфигурация, индексная стратегия и мониторинг превращают её в продукт, который выдерживает тысячи транзакций в секунду на десятках терабайт данных — без дорогостоящих «облачных» альтернатив.

С чего начинается тюнинг

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

Плохая новость: многие "гайды по тюнингу" в интернете — копипаста десятилетней давности, без понимания что и зачем. Параметры для Nginx 1.8 на 2-ядерном сервере копируют на 32-ядерный продакшен под highload — и удивляются что не помогает или становится хуже.

Этот материал — о том, как думать о тюнинге Nginx: что делает каждый параметр, какие компромиссы он несёт, и как проверить что оптимизация действительно работает.

Версии в статье: Nginx 1.24+ / 1.25+ (mainline). Большинство конфигов работают с 1.18+.

Диагностика перед тюнингом: что измерять

Тюнинг без метрик — гадание на кофейной гуще. Сначала измеряем, потом меняем, потом снова измеряем.

Текущее состояние Nginx

# Версия и скомпилированные модули
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'version|with-|without-'

# Активная конфигурация (проверка синтаксиса)
nginx -t

# Рабочие процессы и их нагрузка
ps aux | grep nginx
top -p $(pgrep -d',' nginx)

# Открытые соединения
ss -s
ss -tnp | grep nginx | wc -l

# Статус (если включён stub_status)
curl -s http://127.0.0.1/nginx_status
# Active connections: 847
# server accepts handled requests
#  12340582 12340582 28473910
# Reading: 12 Writing: 84 Waiting: 751

# Лимиты файловых дескрипторов
cat /proc/$(pgrep -f 'nginx: master')/limits | grep 'open files'
ulimit -n

Нагрузочное тестирование

# wrk — современный HTTP benchmarker
# Установка: apt install wrk / brew install wrk
wrk -t12 -c400 -d30s --latency http://your-server/api/endpoint

# Параметры:
# -t12   — 12 потоков (= число ядер)
# -c400  — 400 конкурентных соединений
# -d30s  — 30 секунд
# --latency — показать перцентили задержек

# Вывод:
# Running 30s test @ http://your-server/
#   12 threads and 400 connections
#   Thread Stats   Avg    Stdev   Max   +/- Stdev
#     Latency    23.45ms  8.12ms  890ms  92.34%
#     Req/Sec    1.45k   312.45   2.10k  68.23%
#   Latency Distribution
#      50%   21.23ms
#      75%   28.45ms
#      90%   35.67ms
#      99%   78.90ms    ← 99-й перцентиль важнее среднего!
#   521245 requests in 30.00s, 2.34GB read
#   Requests/sec: 17374.83
#   Transfer/sec: 79.92MB

# ab (Apache Benchmark) — встроен везде, но хуже wrk
ab -n 10000 -c 100 http://your-server/

# hey — ещё один вариант (Go)
hey -n 50000 -c 200 http://your-server/

Мониторинг в реальном времени

# Топ запросов по времени ответа (из access_log)
awk '{print $NF, $7}' /var/log/nginx/access.log | sort -rn | head -20

# Количество запросов в секунду (live)
tail -f /var/log/nginx/access.log | pv -l -i 1 > /dev/null

# Распределение кодов ответов за последний час
awk -v d="$(date -d '1 hour ago' '+%d/%b/%Y:%H')" \
  '$4 ~ d {print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

# Топ IP по количеству запросов
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Уровень 1: Системные настройки Linux

Nginx ограничен операционной системой. Без правильной настройки Linux все оптимизации Nginx упрутся в системный потолок.

Файловые дескрипторы

# /etc/security/limits.conf
nginx   soft    nofile  65535
nginx   hard    nofile  65535
root    soft    nofile  65535
root    hard    nofile  65535

# Для systemd (приоритет над limits.conf):
# /etc/systemd/system/nginx.service.d/override.conf
[Service]
LimitNOFILE=65535

sudo systemctl daemon-reload
sudo systemctl restart nginx

# Проверка:
cat /proc/$(cat /var/run/nginx.pid)/limits | grep 'open files'

Сетевой стек (sysctl)

# /etc/sysctl.d/99-nginx.conf

# ===== TCP буферы =====
# Увеличиваем буферы приёма/передачи
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max     = 16777216
net.core.wmem_max     = 16777216
net.ipv4.tcp_rmem     = 4096 87380 16777216
net.ipv4.tcp_wmem     = 4096 65536 16777216

# ===== Очередь соединений =====
# Размер очереди для accept() — важно при всплесках трафика
net.core.somaxconn     = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# ===== TCP оптимизации =====
# Быстрое переиспользование TIME_WAIT соединений
net.ipv4.tcp_tw_reuse    = 1

# Алгоритм управления перегрузкой
# BBR — лучший выбор для большинства продакшен-сценариев (ядро 4.9+)
net.core.default_qdisc    = fq
net.ipv4.tcp_congestion_control = bbr

# Уменьшаем время FIN_WAIT2 (2 минуты по умолчанию — слишком долго)
net.ipv4.tcp_fin_timeout  = 15

# Максимальное число открытых TCP соединений
net.ipv4.tcp_max_tw_buckets = 1440000

# Разрешаем bind на порт без TIME_WAIT
net.ipv4.tcp_timestamps  = 1

# ===== Очередь обработки пакетов =====
net.core.netdev_max_backlog = 65535

# ===== Локальный диапазон портов =====
# Для upstream keepalive нужно много эфемерных портов
net.ipv4.ip_local_port_range = 1024 65535

# Применить:
sudo sysctl -p /etc/sysctl.d/99-nginx.conf

# Проверить BBR:
sysctl net.ipv4.tcp_congestion_control
# должно быть: net.ipv4.tcp_congestion_control = bbr

Прозрачные hugepages и планировщик I/O

# Для высоконагруженных серверов — отключить transparent hugepages
# (могут вызывать latency spikes)
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# В /etc/rc.local для постоянства:
echo 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' >> /etc/rc.local
echo 'echo never > /sys/kernel/mm/transparent_hugepage/defrag'  >> /etc/rc.local

# Планировщик I/O для SSD (none или mq-deadline быстрее cfq)
echo mq-deadline > /sys/block/sda/queue/scheduler
# Проверить: cat /sys/block/sda/queue/scheduler

Уровень 2: Базовый конфиг Nginx — Worker и Events

# /etc/nginx/nginx.conf

# ===== WORKER PROCESSES =====
# Правило: 1 воркер на 1 физическое ядро CPU
# auto — Nginx сам определяет количество ядер (рекомендуется)
worker_processes auto;

# Привязка воркеров к ядрам (CPU affinity)
# Уменьшает cache miss у процессора, повышает производительность ~5-10%
# Для 4 ядер:
# worker_cpu_affinity 0001 0010 0100 1000;
# Для auto (Nginx 1.9+):
worker_cpu_affinity auto;

# Приоритет процесса (от -20 до 20, меньше = выше приоритет)
# -5 даёт небольшое преимущество без ущерба системе
worker_priority -5;

# Файловые дескрипторы на воркер (должно совпадать с ulimit -n)
worker_rlimit_nofile 65535;

# PID файл
pid /var/run/nginx.pid;

# ===== ERROR LOG =====
# warn в продакшене (info/debug — слишком verbose для highload)
error_log /var/log/nginx/error.log warn;

# ===== EVENTS =====
events {
    # Максимум соединений на воркер
    # Итого соединений = worker_processes × worker_connections
    # Не ставьте больше 65535 — ограничение Linux
    # Реально для highload: 4096-16384
    worker_connections 10240;

    # epoll — единственный правильный выбор на Linux
    # (Nginx выбирает автоматически, но явно лучше)
    use epoll;

    # Принимать все ожидающие соединения за один вызов accept()
    # ОБЯЗАТЕЛЬНО для highload! Без этого воркер обрабатывает по 1 соединению
    multi_accept on;

    # Принимать мьютекс для accept() (устарело в современных ядрах,
    # но оставляем для совместимости)
    # accept_mutex off;  # Можно отключить на ядрах 3.9+
}

Уровень 3: HTTP блок — основные оптимизации

http {
    # ===== БАЗОВЫЕ MIME ТИПЫ =====
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    # ===== SENDFILE: ZERO-COPY ПЕРЕДАЧА ФАЙЛОВ =====
    # Передаёт файлы напрямую из файловой системы в сокет
    # минуя user space — экономит копирование данных в памяти
    # ОБЯЗАТЕЛЬНО для статики!
    sendfile on;

    # Отправлять заголовки и начало файла в одном TCP-пакете
    # Работает только совместно с sendfile on
    tcp_nopush on;

    # Отключить алгоритм Nagle — не буферизировать маленькие пакеты
    # Уменьшает latency для интерактивных запросов
    # tcp_nopush и tcp_nodelay вместе: сначала накапливаем (nopush),
    # потом сразу отправляем последний пакет (nodelay)
    tcp_nodelay on;

    # ===== KEEPALIVE =====
    # Время жизни keepalive соединения с клиентом
    # 65s стандарт, 75s — максимум до таймаута прокси (Cloudflare = 90s)
    keepalive_timeout 65;

    # Максимум запросов через одно keepalive соединение
    # После этого — закрываем и открываем новое
    # 1000 — хороший баланс между переиспользованием и памятью
    keepalive_requests 1000;

    # ===== БУФЕРЫ =====
    # Эти настройки критически важны для производительности proxy!

    # Размер хэш-таблицы имён серверов
    server_names_hash_bucket_size 128;
    server_names_hash_max_size    1024;

    # Буфер для чтения заголовков запроса клиента
    # 16k достаточно для большинства запросов, включая большие cookie
    client_header_buffer_size 16k;
    large_client_header_buffers 4 32k;

    # Максимальный размер тела запроса (загрузка файлов)
    # 0 — отключить ограничение (не рекомендуется!)
    client_max_body_size 64m;

    # Таймаут на чтение тела запроса
    client_body_timeout 30s;

    # Таймаут на чтение заголовков запроса
    client_header_timeout 15s;

    # Таймаут на отправку ответа клиенту
    # (между двумя последовательными операциями send)
    send_timeout 30s;

    # Буфер для тела запроса в памяти (если больше — пишем на диск)
    client_body_buffer_size 256k;

    # ===== ТИПЫ ХЭШЕЙ =====
    types_hash_max_size 4096;
    types_hash_bucket_size 128;

    # ===== БЕЗОПАСНОСТЬ: УБИРАЕМ ВЕРСИЮ NGINX =====
    server_tokens off;

    # ===== ЛОГИ =====
    # Формат логов с временем обработки запроса — важно для анализа!
    log_format main '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    'rt=$request_time uct=$upstream_connect_time '
                    'uht=$upstream_header_time urt=$upstream_response_time';

    # Расширенный формат для детальной диагностики:
    log_format detailed '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        'rt=$request_time '
                        'urt="$upstream_response_time" '
                        'uct="$upstream_connect_time" '
                        'uht="$upstream_header_time" '
                        'cs=$upstream_cache_status '
                        'host=$host '
                        'xff="$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main buffer=64k flush=5s;
    # buffer=64k  — буферизация логов (не пишем на диск каждую строку)
    # flush=5s    — сбрасываем буфер каждые 5 секунд

    # Для максимальной производительности — отключить access_log на статике
    # (настраивается в location блоках)

    # ===== ВКЛЮЧАЕМ ПОДКОНФИГИ =====
    include /etc/nginx/conf.d/*.conf;
}

Уровень 4: Gzip и Brotli — сжатие ответов

http {
    # ===== GZIP =====
    gzip on;

    # Не сжимать ответы для IE6 (исторический артефакт, можно убрать)
    gzip_disable "msie6";

    # Сжимать ответы для всех клиентов, в т.ч. через прокси
    # any — сжимать независимо от заголовка Via
    gzip_proxied any;

    # Уровень сжатия: 1-9
    # 1 — быстро, мало сжатие (~60%)
    # 6 — баланс (рекомендуется для продакшена ~70%)
    # 9 — максимум, но тратит значительно больше CPU (~72%, но в 3-5 раз медленнее 6)
    gzip_comp_level 6;

    # Минимальный размер для сжатия (не сжимать маленькие файлы — смысла нет)
    gzip_min_length 1024;

    # Буферы для сжатия
    gzip_buffers 16 8k;

    # HTTP версия (сжимать и для HTTP/1.0 клиентов — редко нужно)
    gzip_http_version 1.1;

    # Типы контента для сжатия
    # text/html сжимается всегда (по умолчанию)
    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/json
        application/javascript
        application/xml
        application/xml+rss
        application/x-javascript
        application/x-font-ttf
        application/vnd.ms-fontobject
        font/opentype
        image/svg+xml
        image/x-icon;

    # Добавить заголовок Vary: Accept-Encoding
    # Указывает прокси-серверам хранить сжатые и несжатые версии отдельно
    gzip_vary on;

    # ===== BROTLI (требует модуль ngx_brotli) =====
    # Brotli на 15-25% эффективнее gzip при тех же CPU-затратах
    # Поддерживается всеми современными браузерами

    # Установка модуля (Ubuntu/Debian):
    # apt install libnginx-mod-http-brotli-filter
    # Или из исходников: https://github.com/google/ngx_brotli

    # load_module modules/ngx_http_brotli_filter_module.so;
    # load_module modules/ngx_http_brotli_static_module.so;

    brotli on;
    brotli_comp_level 6;       # 0-11, 6 — хороший баланс
    brotli_min_length 1024;
    brotli_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/json
        application/javascript
        application/xml
        application/xml+rss
        image/svg+xml;

    # Brotli static — отдавать предкомпрессированные .br файлы
    # Нужно сгенерировать: find /var/www -name "*.js" | xargs -I{} brotli {}
    brotli_static on;

    # ===== GZIP STATIC — предкомпрессированные .gz файлы =====
    # Если файл app.js.gz существует — отдаём его без CPU на сжатие
    gzip_static on;
}

Предварительное сжатие статики (экономит CPU)

#!/bin/bash
# Скрипт для предкомпрессии статических файлов
STATIC_DIR="/var/www/html"

find "$STATIC_DIR" \
    \( -name "*.js" -o -name "*.css" -o -name "*.html" -o -name "*.json" \
       -o -name "*.xml" -o -name "*.svg" \) \
    -type f | while read file; do

    # gzip (только если .gz не существует или файл новее)
    if [ ! -f "${file}.gz" ] || [ "$file" -nt "${file}.gz" ]; then
        gzip -9 -k "$file"
    fi

    # brotli
    if command -v brotli &> /dev/null; then
        if [ ! -f "${file}.br" ] || [ "$file" -nt "${file}.br" ]; then
            brotli -q 11 -k "$file"
        fi
    fi
done

echo "Предкомпрессия завершена: $(find $STATIC_DIR -name '*.gz' | wc -l) gz файлов"

Уровень 5: Кэширование — proxy_cache и FastCGI cache

Proxy Cache (для проксирования на upstream)

http {
    # ===== ЗОНА КЭША =====
    # keys_zone=cache_name:10m  — зона памяти для хранения ключей
    # levels=1:2                — структура директорий (более эффективный поиск)
    # inactive=60m              — удалять неиспользуемые файлы через 60 минут
    # max_size=10g              — максимальный размер кэша на диске
    # use_temp_path=off         — не использовать временный путь (быстрее)
    proxy_cache_path /var/cache/nginx/proxy
        levels=1:2
        keys_zone=proxy_cache:50m
        inactive=60m
        max_size=10g
        use_temp_path=off;

    server {
        location /api/ {
            proxy_pass http://backend;

            # ===== PROXY БУФЕРЫ =====
            # Буферизировать ответ от upstream в памяти
            # Важно: без буферизации Nginx держит соединение с upstream
            # пока клиент не скачает весь ответ (медленные клиенты = занятые воркеры)
            proxy_buffering on;

            # Количество и размер буферов для тела ответа
            # proxy_buffers × proxy_buffer_size = RAM на соединение
            # 32 × 16k = 512k на соединение
            proxy_buffers         32 16k;
            proxy_buffer_size     16k;   # Для заголовков ответа

            # Если ответ не помещается в proxy_buffers — пишем во временный файл
            proxy_max_temp_file_size 0;   # 0 = отключить (пишем всё в память)
            # или установить лимит: proxy_max_temp_file_size 1024m;

            # Буфер для занятых соединений (busy = клиент читает медленно)
            proxy_busy_buffers_size 64k;

            # ===== PROXY ТАЙМАУТЫ =====
            # Таймаут установки соединения с upstream
            proxy_connect_timeout 5s;

            # Таймаут между двумя последовательными операциями чтения от upstream
            proxy_read_timeout 60s;

            # Таймаут передачи данных к upstream
            proxy_send_timeout 60s;

            # ===== ЗАГОЛОВКИ К UPSTREAM =====
            proxy_set_header Host               $host;
            proxy_set_header X-Real-IP          $remote_addr;
            proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto  $scheme;
            proxy_http_version 1.1;             # HTTP/1.1 для keepalive!
            proxy_set_header Connection "";     # Убрать заголовок Connection для keepalive

            # ===== КЭШИРОВАНИЕ =====
            proxy_cache            proxy_cache;
            proxy_cache_valid      200 302  10m;  # Кэшировать 200/302 на 10 минут
            proxy_cache_valid      404      1m;   # 404 — на 1 минуту
            proxy_cache_valid      any      30s;  # Остальное — 30 секунд

            # Ключ кэша (что уникально идентифицирует запрос)
            proxy_cache_key "$scheme$request_method$host$request_uri";

            # Методы для кэширования (по умолчанию только GET и HEAD)
            proxy_cache_methods GET HEAD;

            # Кэшировать ответы с заголовком Set-Cookie
            # (осторожно — персональные данные!)
            # proxy_ignore_headers Set-Cookie;

            # Stale cache — отдавать устаревший кэш пока upstream недоступен
            # Спасает от "пятистотки" при временных проблемах с бэкендом
            proxy_cache_use_stale error timeout updating
                                   http_500 http_502 http_503 http_504;

            # Блокировка одновременных запросов к upstream (coalescing)
            # Один запрос идёт к upstream, остальные ждут результата в кэше
            proxy_cache_lock on;
            proxy_cache_lock_timeout 5s;
            proxy_cache_lock_age     5s;

            # Фоновое обновление кэша (stale-while-revalidate)
            # Отдаём устаревший кэш и одновременно запускаем фоновое обновление
            proxy_cache_background_update on;

            # Добавляем заголовок X-Cache-Status для отладки
            add_header X-Cache-Status $upstream_cache_status always;
        }

        # ===== СТАТИКА: МАКСИМАЛЬНЫЙ КЭШ =====
        location ~* \.(jpg|jpeg|png|gif|ico|svg|webp|woff|woff2|ttf|eot)$ {
            expires     1y;
            add_header  Cache-Control "public, immutable, max-age=31536000";
            access_log  off;  # Не логировать статику (экономит I/O)
            tcp_nodelay off;  # Для больших файлов nopush важнее nodelay
            sendfile    on;
            aio         on;   # Асинхронный I/O для больших файлов
        }

        location ~* \.(js|css)$ {
            expires     1y;
            add_header  Cache-Control "public, immutable, max-age=31536000";
            access_log  off;
        }

        location ~* \.(html|htm)$ {
            expires     1h;
            add_header  Cache-Control "public, max-age=3600, must-revalidate";
        }
    }
}

FastCGI Cache (для PHP-FPM)

http {
    # Зона FastCGI кэша
    fastcgi_cache_path /var/cache/nginx/fastcgi
        levels=1:2
        keys_zone=fastcgi_cache:20m
        inactive=60m
        max_size=5g
        use_temp_path=off;

    # Глобальная переменная для определения статуса кэша
    map $request_method $no_cache_method {
        default 0;
        POST    1;
        PUT     1;
        DELETE  1;
        PATCH   1;
    }

    server {
        set $skip_cache 0;

        # Не кэшировать авторизованных пользователей (например, WordPress)
        if ($http_cookie ~* "wordpress_logged_in|woocommerce_cart") {
            set $skip_cache 1;
        }

        # Не кэшировать POST запросы
        if ($request_method = POST) {
            set $skip_cache 1;
        }

        # Не кэшировать URL с query string (можно убрать если кэш по полному URL)
        # if ($query_string != "") {
        #     set $skip_cache 1;
        # }

        # Не кэшировать admin/личный кабинет
        if ($request_uri ~* "^/admin|^/wp-admin|^/login") {
            set $skip_cache 1;
        }

        location ~ \.php$ {
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.2-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

            # ===== FastCGI БУФЕРЫ =====
            fastcgi_buffers         16 16k;
            fastcgi_buffer_size     32k;
            fastcgi_busy_buffers_size 64k;

            # Таймауты
            fastcgi_connect_timeout  5s;
            fastcgi_read_timeout    60s;
            fastcgi_send_timeout    60s;

            # ===== КЭШ =====
            fastcgi_cache            fastcgi_cache;
            fastcgi_cache_key        "$scheme$request_method$host$request_uri";
            fastcgi_cache_valid       200  5m;
            fastcgi_cache_valid       301 302  1m;
            fastcgi_cache_valid       404  30s;
            fastcgi_cache_bypass     $skip_cache;
            fastcgi_no_cache         $skip_cache;
            fastcgi_cache_use_stale  error timeout updating
                                     http_500 http_503;
            fastcgi_cache_lock       on;
            fastcgi_cache_background_update on;

            add_header X-FastCGI-Cache $upstream_cache_status;
        }
    }
}

Инвалидация кэша

# Очистить весь кэш proxy
find /var/cache/nginx/proxy -type f -delete

# Очистить конкретный URL (через модуль ngx_cache_purge):
# location ~ /purge(/.*) {
#     fastcgi_cache_purge fastcgi_cache "$scheme$request_method$host$1";
# }
# curl -X PURGE http://your-server/api/products/123

# Мониторинг кэша:
# X-Cache-Status значения:
# HIT       — ответ из кэша 

✅

# MISS — кэш не нашёл, запрос к upstream

# BYPASS — кэш пропущен (skip_cache = 1)

# EXPIRED — кэш устарел, запрошен свежий ответ

# STALE — отдан устаревший кэш (upstream недоступен)

# UPDATING — отдан устаревший кэш пока фоновое обновление

# REVALIDATED — кэш подтверждён (304 от upstream)

Уровень 6: Upstream Keepalive и балансировка

http {
    # ===== UPSTREAM С KEEPALIVE =====
    upstream backend {
        # Алгоритм балансировки
        # least_conn — меньше соединений = меньше задержка (лучше для long-poll)
        # ip_hash    — один клиент всегда на один сервер (сессии)
        # По умолчанию: round-robin
        least_conn;

        server 10.0.0.10:8080 weight=3;  # Тройной вес (мощнее)
        server 10.0.0.11:8080 weight=1;
        server 10.0.0.12:8080 weight=1 backup;  # Резервный (включается при падении основных)

        # Параметры health check (требует nginx plus или upstream_check_module):
        # server 10.0.0.10:8080 max_fails=3 fail_timeout=30s;

        # ===== KEEPALIVE ПУЛА К UPSTREAM =====
        # Количество keepalive соединений в пуле (на воркер!)
        # НЕ максимальное число соединений — это пул переиспользуемых!
        # Правило: (RPS / worker_count) × avg_response_time_sec × 1.5
        # При 10000 RPS, 4 воркерах, 20мс ответе: 10000/4 × 0.02 × 1.5 = 75
        keepalive 128;

        # Таймаут keepalive соединения с upstream
        keepalive_timeout 60s;

        # Максимум запросов через одно keepalive соединение к upstream
        keepalive_requests 10000;
    }

    server {
        location / {
            proxy_pass http://backend;

            # КРИТИЧЕСКИ ВАЖНО для upstream keepalive!
            # HTTP/1.1 поддерживает keepalive (1.0 — нет)
            proxy_http_version 1.1;

            # Убираем заголовок Connection: close (стандарт для HTTP/1.0 прокси)
            proxy_set_header Connection "";
        }
    }
}

Уровень 7: SSL/TLS — производительность без потери безопасности

http {
    # ===== SSL СЕССИИ =====
    # Кэш SSL сессий (повторное использование TLS handshake)
    # 1m ≈ 4000 сессий. Для highload: 50m-100m
    ssl_session_cache   shared:SSL:50m;

    # Время жизни кэшированной SSL сессии
    ssl_session_timeout 1d;   # 24 часа — максимум рекомендуемый

    # SSL Session Tickets (альтернатива session cache, статeful у клиента)
    # Для идеальной forward secrecy — отключить
    # Для максимальной производительности — включить
    ssl_session_tickets off;   # Безопаснее, но чуть медленнее

    # ===== ПРОТОКОЛЫ И ШИФРЫ =====
    # Только TLS 1.2 и 1.3 (1.0 и 1.1 — уязвимы и устарели)
    ssl_protocols TLSv1.2 TLSv1.3;

    # Шифры (Mozilla Modern конфигурация)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    # Сервер выбирает шифр (не клиент) — важно для безопасности
    ssl_prefer_server_ciphers off;   # off для TLS 1.3 (там нет выбора шифра)

    # ===== ECDH КРИВАЯ =====
    ssl_ecdh_curve X25519:prime256v1:secp384r1;

    # ===== STAPLING =====
    # OCSP Stapling: сервер сам проверяет сертификат и включает ответ в TLS handshake
    # Клиенту не нужно делать отдельный запрос к CA — быстрее!
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 1.1.1.1 valid=300s;
    resolver_timeout 5s;

    # ===== DH параметры (для DHE шифров) =====
    # Генерировать: openssl dhparam -out /etc/nginx/dhparam.pem 2048
    # ssl_dhparam /etc/nginx/dhparam.pem;

    server {
        listen 443 ssl;

        # ===== HTTP/2 =====
        # Мультиплексирование запросов — один TCP для множества запросов
        # Сжатие заголовков (HPACK) — экономит трафик
        # Server Push — отправка ресурсов до запроса (редко нужен)
        listen 443 ssl http2;

        ssl_certificate     /etc/nginx/ssl/fullchain.pem;
        ssl_certificate_key /etc/nginx/ssl/privkey.pem;

        # ===== HSTS =====
        # Браузер не будет делать HTTP запросы — сразу HTTPS
        # Включать только когда уверены что HTTPS работает корректно!
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

        # ===== SECURITY ЗАГОЛОВКИ =====
        add_header X-Frame-Options           "SAMEORIGIN"   always;
        add_header X-Content-Type-Options    "nosniff"      always;
        add_header X-XSS-Protection          "1; mode=block" always;
        add_header Referrer-Policy           "strict-origin-when-cross-origin" always;
        add_header Permissions-Policy        "geolocation=(), microphone=()" always;
    }

    # Редирект HTTP → HTTPS
    server {
        listen 80;
        server_name example.com www.example.com;

        # 301 для всего кроме .well-known (Let's Encrypt)
        location /.well-known/acme-challenge/ {
            root /var/www/html;
        }

        location / {
            return 301 https://$host$request_uri;
        }
    }
}

Измерение времени TLS handshake

# Проверка SSL без кэша (первое соединение)
curl -w "\n=== Timing ===\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
     --no-keepalive -s -o /dev/null https://your-server/

# С session resumption (второе соединение)
curl -w "TLS Resumption Total: %{time_total}s\n" \
     --no-keepalive -s -o /dev/null https://your-server/ \
     --tls-session-info

# Проверка OCSP Stapling:
echo QUIT | openssl s_client -connect your-server:443 -status 2>/dev/null | \
    grep -A 17 'OCSP response'

Уровень 8: Rate Limiting — защита и QoS

http {
    # ===== ЗОНЫ RATE LIMITING =====

    # Ограничение по IP адресу
    # zone=name:10m — 10МБ памяти (~160 000 IP адресов)
    # rate=100r/s — 100 запросов в секунду с одного IP
    limit_req_zone $binary_remote_addr zone=api_limit:20m rate=100r/s;

    # Ограничение для авторизации (жёстче!)
    limit_req_zone $binary_remote_addr zone=auth_limit:10m rate=5r/m;

    # Ограничение по URL + IP (для конкретных эндпоинтов)
    limit_req_zone "$binary_remote_addr$uri" zone=upload_limit:10m rate=5r/m;

    # Ограничение одновременных соединений
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    # Лог уровень для rejected запросов (warn — не засорять error.log)
    limit_req_log_level warn;

    # Код ответа при превышении лимита (429 = Too Many Requests)
    limit_req_status 429;
    limit_conn_status 429;

    server {
        # ===== API ENDPOINT =====
        location /api/ {
            # burst=200  — разрешить всплески до 200 запросов сверх лимита
            # nodelay    — не задерживать burst запросы, обрабатывать немедленно
            #              (без nodelay — запросы ставятся в очередь и задерживаются)
            limit_req zone=api_limit burst=200 nodelay;

            # Максимум 100 одновременных соединений с одного IP
            limit_conn conn_limit 100;

            proxy_pass http://backend;
        }

        # ===== АВТОРИЗАЦИЯ: СТРОГИЙ ЛИМИТ =====
        location /api/auth/ {
            limit_req zone=auth_limit burst=10 nodelay;
            limit_conn conn_limit 10;
            proxy_pass http://backend;
        }

        # ===== ЗАГРУЗКА ФАЙЛОВ =====
        location /upload/ {
            limit_req zone=upload_limit burst=2 nodelay;
            limit_conn conn_limit 5;
            client_max_body_size 100m;
            proxy_pass http://backend;
        }
    }
}

Белые списки для rate limiting

http {
    # Карта: 0 = применять limit, 1 = пропустить
    geo $limit {
        default         1;       # Ограничивать всех
        10.0.0.0/8      0;       # Доверенная внутренняя сеть — без ограничений
        192.168.0.0/16  0;       # Локальная сеть — без ограничений
        1.2.3.4         0;       # Конкретный IP (мониторинг, партнёры)
    }

    # Если $limit = 0 — пустой ключ, limit_req не применяется
    map $limit $limit_key {
        0 "";
        1 $binary_remote_addr;
    }

    limit_req_zone $limit_key zone=api_limit:20m rate=100r/s;
}

Уровень 9: Open File Cache и другие детали

http {
    # ===== OPEN FILE CACHE =====
    # Кэшировать информацию об открытых файлах:
    # файловые дескрипторы, размеры, время модификации, ошибки
    # Особенно важно при большом количестве файлов статики!

    # max=10000 — максимум 10000 записей в кэше
    # inactive=30s — удалять если не обращались 30 секунд
    open_file_cache max=10000 inactive=30s;

    # Сколько раз файл должен быть запрошен за inactive период
    # чтобы остаться в кэше
    open_file_cache_min_uses 2;

    # Проверять актуальность кэша каждые 60 секунд
    open_file_cache_valid 60s;

    # Кэшировать ошибки (файл не найден, нет прав)
    open_file_cache_errors on;

    # ===== SENDFILE + AIO для больших файлов =====
    # Для файлов > 8MB — асинхронный I/O эффективнее
    aio threads;  # AIO через thread pool (Nginx 1.7.11+)
    # или aio on; # POSIX AIO (старый вариант, хуже)

    directio 8m;  # Файлы > 8MB: читать напрямую, минуя page cache
                  # Полезно для больших видеофайлов которые не нужно кэшировать

    # ===== OUTPUT BUFFERS =====
    # Размер буфера вывода (используется с sendfile)
    output_buffers 2 512k;

    # ===== ПЕРЕМЕННЫЕ =====
    # Кэш переменных (для complex map и geo директив)
    variables_hash_max_size 2048;
    variables_hash_bucket_size 128;

    # ===== MAP HASH =====
    map_hash_max_size 2048;
    map_hash_bucket_size 128;
}

Уровень 10: Полный production конфиг сервера

# /etc/nginx/conf.d/example.com.conf

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    root /var/www/html;
    index index.html index.php;

    # SSL
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Логи с детальным форматом
    access_log /var/log/nginx/example.com.access.log detailed buffer=64k flush=5s;
    error_log  /var/log/nginx/example.com.error.log warn;

    # Скрываем .git, .env и другие служебные файлы
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }

    location ~* \.(env|log|sh|sql|conf|config|bak|backup|swp|tmp)$ {
        deny all;
    }

    # ===== СТАТИКА: МАКСИМАЛЬНАЯ ОТДАЧА =====
    location ~* \.(jpg|jpeg|png|gif|ico|svg|webp|avif|woff|woff2|ttf|eot|otf)$ {
        expires     1y;
        add_header  Cache-Control "public, immutable";
        add_header  Vary Accept-Encoding;
        access_log  off;
        log_not_found off;
        gzip_static on;
        brotli_static on;
    }

    location ~* \.(js|css|map)$ {
        expires     1y;
        add_header  Cache-Control "public, immutable";
        access_log  off;
        gzip_static on;
        brotli_static on;
    }

    # ===== FAVICON И ROBOTS =====
    location = /favicon.ico {
        access_log off;
        log_not_found off;
        expires 1y;
    }

    location = /robots.txt {
        access_log off;
        log_not_found off;
    }

    # ===== API =====
    location /api/ {
        limit_req zone=api_limit burst=200 nodelay;
        limit_conn conn_limit 100;

        proxy_pass         http://backend;
        proxy_http_version 1.1;
        proxy_set_header   Connection "";
        proxy_set_header   Host               $host;
        proxy_set_header   X-Real-IP          $remote_addr;
        proxy_set_header   X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto  $scheme;

        proxy_cache            proxy_cache;
        proxy_cache_valid      200 5m;
        proxy_cache_valid      404 30s;
        proxy_cache_use_stale  error timeout updating http_500 http_502 http_503 http_504;
        proxy_cache_lock       on;
        proxy_cache_background_update on;

        add_header X-Cache-Status $upstream_cache_status always;
    }

    # ===== PHP =====
    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;

        fastcgi_buffers          16 16k;
        fastcgi_buffer_size      32k;
        fastcgi_read_timeout     60s;

        fastcgi_cache            fastcgi_cache;
        fastcgi_cache_valid      200 5m;
        fastcgi_cache_bypass     $skip_cache;
        fastcgi_no_cache         $skip_cache;
        fastcgi_cache_use_stale  error timeout updating http_500 http_503;
        fastcgi_cache_lock       on;

        add_header X-FastCGI-Cache $upstream_cache_status;
    }

    # ===== КОРЕНЬ =====
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Диагностика и мониторинг в продакшене

Stub Status модуль

server {
    listen 127.0.0.1:8080;

    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        allow 10.0.0.0/8;      # Сеть мониторинга
        deny all;
    }
}

# Парсинг nginx_status:
curl -s http://127.0.0.1:8080/nginx_status
# Active connections: 1247
# server accepts handled requests
#  87354291 87354291 245912847
# Reading: 12 Writing: 847 Waiting: 388

# Интерпретация:
# Active    = Reading + Writing + Waiting
# Waiting   = keepalive соединения (ждут следующего запроса)
# Writing   = активно пишем ответ клиенту
# Reading   = читаем запрос от клиента

# Если Waiting >> Writing — много keepalive соединений, это нормально
# Если Reading >> 0 постоянно — клиенты медленно отправляют запросы
# Если Writing = worker_processes × worker_connections — всё занято!

# accepts == handled — нет dropped connections. Если differs — проблема!

Анализ логов

# Медленные запросы (> 1 секунды)
awk '$NF > 1' /var/log/nginx/access.log | \
    awk '{print $NF, $7}' | sort -rn | head -20

# HIT rate кэша
grep -o 'cs=[A-Z]*' /var/log/nginx/access.log | \
    sort | uniq -c | sort -rn
# 94521 cs=HIT      ← 87% HIT rate — хорошо!
# 12305 cs=MISS
# 1823  cs=BYPASS
# 289   cs=EXPIRED

# Ошибки upstream
grep 'upstream timed out\|connect() failed\|upstream prematurely' \
    /var/log/nginx/error.log | tail -50

# Топ 5xx ошибок
awk '$9 ~ /^5/' /var/log/nginx/access.log | \
    awk '{print $9, $7}' | sort | uniq -c | sort -rn | head -20

Чеклист тюнинга: финальная проверка

#!/bin/bash
# Быстрая проверка ключевых параметров

echo "=== NGINX PERFORMANCE CHECKLIST ==="

# 1. Worker processes
WP=$(nginx -T 2>/dev/null | grep 'worker_processes' | tail -1 | awk '{print $2}')
CORES=$(nproc)
echo "Worker processes: $WP (cores: $CORES)"

# 2. Worker connections
WC=$(nginx -T 2>/dev/null | grep 'worker_connections' | tail -1 | awk '{print $2}')
echo "Worker connections: $WC"

# 3. File descriptors
FD=$(cat /proc/$(cat /var/run/nginx.pid 2>/dev/null || echo 1)/limits \
     2>/dev/null | grep 'open files' | awk '{print $4}')
echo "File descriptors limit: $FD"

# 4. sendfile
SF=$(nginx -T 2>/dev/null | grep -E '^\s+sendfile' | tail -1)
echo "Sendfile: $SF"

# 5. gzip
GZ=$(nginx -T 2>/dev/null | grep -E '^\s+gzip ' | tail -1)
echo "Gzip: $GZ"

# 6. SSL session cache
SSL=$(nginx -T 2>/dev/null | grep 'ssl_session_cache' | tail -1)
echo "SSL session cache: $SSL"

# 7. BBR
echo "TCP congestion: $(sysctl -n net.ipv4.tcp_congestion_control)"

# 8. Тест конфигурации
nginx -t && echo "Config: OK" || echo "Config: ERROR!"

echo ""
echo "=== ТЕКУЩАЯ НАГРУЗКА ==="
curl -s http://127.0.0.1:8080/nginx_status 2>/dev/null || echo "stub_status недоступен"

Типичные ошибки и мифы

Миф 1: "worker_processes 4096 увеличит производительность" Нет. Оптимум — по одному воркеру на ядро. Больше воркеров = больше переключений контекста = хуже.

Миф 2: "worker_connections 65535 — максимум соединений" Нет. Это максимум на один воркер. Итого: worker_processes × worker_connections. При 4 воркерах и 10240 соединениях = 40960 одновременных соединений.

Миф 3: "keepalive_timeout 0 ускорит сервер" Наоборот. Keepalive экономит TLS handshake и TCP установку соединения. Отключение keepalive нагрузит сервер больше.

Миф 4: "gzip_comp_level 9 — лучше" Нет. Разница в размере между уровнями 6 и 9 — 1-3%. Разница в CPU — в 3-5 раз. Используйте gzip_comp_level 6.

Ошибка: proxy_cache без proxy_cache_use_stale При недоступности upstream без use_stale клиенты получат 502. С use_stale error timeout — получат устаревший кэш пока upstream восстанавливается. Всегда включайте!

Ошибка: не настроен upstream keepalive Без keepalive в блоке upstream каждый запрос создаёт новое TCP соединение к backend. При 1000 RPS — 1000 новых TCP handshake в секунду. С keepalive 64 — переиспользуются 64 соединения.

Заключение

Тюнинг Nginx — это итеративный процесс. Хороший порядок:

1. Системный уровень: sysctl, ulimit, BBR — без этого упрётесь в ОС

2. Workers и events: worker_processes auto, multi_accept on, epoll

3. Буферы и таймауты: адаптируйте под характер трафика (размер ответов, скорость клиентов)

4. Кэш: proxy_cache или fastcgi_cache — самый большой прирост производительности

5. Upstream keepalive: критично для высоких RPS

6. SSL оптимизация: session cache + stapling + HTTP/2

7. Сжатие: gzip + brotli_static для предкомпрессии

8. Rate limiting: защита без ущерба для легитимного трафика

Измеряйте до и после каждого изменения. Доверяйте цифрам, а не интуиции. И помните: лучший тюнинг — тот, который решает вашу конкретную проблему, а не скопированный из статьи.