OpenSearch вместо Elasticsearch для офисных логов: почему мы всем клиентам ставим форк
Привет! Меня зовут Семёнов Евгений Сергеевич, я директор в компании АйТи Фреш. У нас с 2022 года действует одно строгое правило: новым клиентам мы ставим не Elasticsearch, а исключительно OpenSearch. По функционалу, конечно, разница невелика, буквально копеечная. Но вот с юридической, лицензионной и, что немаловажно, финансовой стороны это совершенно другой мир, поверьте.
История «лицензионной драмы» Elasticsearch
Если говорить совсем коротко, то до января 2021-го Elasticsearch спокойно жил под полностью свободной лицензией Apache 2.0. Amazon этим активно пользовался, зарабатывая солидные деньги на своём AWS Elasticsearch Service, при этом не отчисляя Elastic ни копейки. Естественно, Elastic посчитал это несправедливым и решил изменить лицензию на SSPL (Server Side Public License) в связке с Elastic License 2.0. Важно понимать, что эти новые лицензии абсолютно несовместимы с Open Source Definition, и, по сути, они запрещают конкурентам Elastic предлагать ES в качестве managed-сервиса.
Что же сделал Amazon в ответ? Он взял последнюю версию под Apache (это была 7.10) и форкнул её, дав ей имя OpenSearch. С того момента OpenSearch и Elasticsearch пошли совершенно разными путями: у них теперь разные команды разработчиков, хотя API-фундамент пока остаётся общим. И что самое главное, OpenSearch остаётся полностью open source под Apache 2.0, и так будет навсегда.
Для SMB это важно вот почему:
- Многие функции, которые в ES требуют платной подписки X-Pack (SIEM, алерты, reporting), в OpenSearch бесплатные.
- В РФ после 2022 года купить Elastic-подписку почти невозможно — OpenSearch снимает этот вопрос полностью.
- OpenSearch переведён на русский (Dashboards), стабильно живёт на железе российских провайдеров, беспроблемно устанавливается.
Что собирается в OpenSearch у типичного SMB-клиента
Когда мы разворачиваем стек, собираем:
| Источник | Что даёт |
|---|---|
| Windows Event Logs | События входа, изменения AD, запуск служб |
| Sysmon | Детальный аудит запуска процессов, сетевых соединений |
| Linux syslog + journald | Системные события на серверах |
| Nginx/Apache access/error | Трафик на внутренних веб-сервисах |
| Логи 1С (technological journal) | Ошибки, медленные запросы, блокировки |
| Postfix/Dovecot | Почтовый трафик, спам, деливерабельность |
| Firewall (pfSense, Mikrotik) | Сетевые потоки, заблокированные соединения |
| PostgreSQL/MSSQL | Медленные запросы, dead tuples, ошибки |
| Audit Docker/Kubernetes | Запуски контейнеров, изменения deployments |
Архитектура, которую мы поставили клиенту
Наш клиент — это транспортная компания, где работают 45 сотрудников. У них 8 серверов: 3 Windows-сервера для AD, 1С и файлов, плюс 5 Linux-серверов под веб, мониторинг и 1С-базы. Мы решили собрать однонодовый кластер. Честно говоря, городить multi-node для 45 РМ просто не имеет смысла, ведь hardware overhead был бы слишком большой. Мы всегда стараемся оптимизировать.
- VPS 1 — OpenSearch Node: 8 vCPU, 24 ГБ RAM, 500 ГБ NVMe, хранит индексы последних 90 дней.
- VPS 2 — Cold Storage: 2 vCPU, 4 ГБ RAM, 2 ТБ HDD. Сюда уходят индексы старше 90 дней через Index State Management (ISM).
- Fluent Bit на каждом сервере — агент сбора логов, гораздо легче, чем Logstash. На Windows — через WinLogBeat (ES-совместимый) с редиректом в OpenSearch.
- OpenSearch Dashboards — веб-интерфейс на той же VPS 1, доступ через nginx с Basic Auth и VPN.
Инфраструктура обходится в 8 400 ₽ в месяц. Никаких лицензий. Никаких годовых подписок. Только аренда железа.
Что мы сразу нашли в логах
Вот вам первая показательная история, которая меня очень впечатлила: буквально через 48 часов после запуска системы клиент увидел в логах нечто, о чём он не подозревал целых 2 года! Представьте себе, на контроллере домена обнаружились регулярные попытки подбора паролей (это events 4625), причём с одного из рабочих мест бухгалтерии. Когда мы начали разбираться, оказалось, что к ноутбуку сотрудницы был подключён старенький принтер с очень древней прошивкой, который, как выяснилось, упорно пытался авторизоваться паролем, сохранённым в нём ещё 4 года назад. Вот такие сюрпризы OpenSearch умеет подкидывать!
А вот второе открытие: логи 1С вдруг показали, что отчёт «Остатки склада на дату» выполняется аж по 40 секунд! Причина банальна — отсутствие индекса. До этого момента никто даже и не задумывался об этом, пока логи не вытащили на свет 38 таких запросов в час от одного-единственного сотрудника. Мы тут же починили SQL-индекс, и всё заняло каких-то 10 минут.
И третье, тоже очень интересное: наш nginx на внутреннем портале компании каждый божий день фиксировал от 3 до 4 тысяч обращений к совершенно несуществующим путям, вроде /.env, /admin.php, /wp-login.php. Оказалось, это боты сканировали из интернета. Портал изначально задумывался как сугубо внутренний, для своих, но почему-то «торчал» наружу, и никто его толком не защищал. Мы быстро закрыли эту лазейку, настроив ограничение по IP через nginx и добавив fail2ban. Проблема решена.
Дашборды, которые получил директор
Через неделю мы собрали в Dashboards три ключевые панели для руководства:
- Безопасность. Количество неудачных логинов по часам, топ-10 пользователей по ошибкам, карта географии IP, новые пользователи в AD, привилегированные операции.
- Здоровье 1С. Медленные запросы >5 сек, блокировки, ошибки ошибок пользователей с расшифровкой «почему так плохо работает».
- Инфраструктура. Загрузка CPU/RAM/диск по серверам, очередь принтеров, состояние бэкапов (Veeam пишет логи — они тоже в OpenSearch), последние перезагрузки.
Что изменилось? Теперь директор каждое утро понедельника открывает эту самую страницу и буквально заваливает нас вопросами по аномалиям за прошедшую неделю. И что самое удивительное, в 80% случаев такая аномалия — это реально серьёзная проблема, которая без OpenSearch так бы и осталась незамеченной. Это бесценно.
Оповещения и алерты
OpenSearch Alerting — это отдельный плагин, идёт в комплекте. Настроили правила:
- 5+ неудачных логинов одной учётки за 2 минуты → Telegram.
- Новый запуск PowerShell с -EncodedCommand → Telegram + SMS.
- Ошибки базы 1С >10 в минуту → Telegram.
- Место на диске осталось <10% → Telegram.
- Файрвол заблокировал 500+ попыток с одного IP → Telegram.
- Bandwidth входящий >80% от канала офиса → Telegram.
В среднем, в наш Telegram прилетает от 2 до 4 алертов в сутки. Для автоматики, конечно, это многовато — часть из них можно было бы автодопустить или автоподавить. Но практически в каждом таком сообщении есть действительно полезная информация, которую стоит анализировать.
Что делает OpenSearch, а что не делает
Важно понимать, OpenSearch — это не совсем мониторинг в классическом его понимании, как Zabbix или Prometheus. Это, скорее, мощное хранилище, предназначенное для поиска и глубокой аналитики по логам. В чём же ключевое отличие, спросите вы?
- Zabbix/Prometheus собирают метрики (CPU, память, задержка) и алёртит по пороговым значениям.
- OpenSearch собирает сырые события (логи, аудит) и даёт по ним поиск, аналитику, ретроспективный разбор.
Как правило, нужны оба. В нашем кейсе Zabbix уже стоял, а OpenSearch мы добавили сверху. Они не конкуренты — они дополняют друг друга.
Стоимость и сроки
| Этап | Срок | Стоимость |
|---|---|---|
| Проектирование и подбор серверов | 0.5 дня | 8 000 ₽ |
| Установка OpenSearch + Dashboards | 0.5 дня | 10 000 ₽ |
| Настройка Fluent Bit/WinLogBeat на всех хостах | 1 день | 22 000 ₽ |
| Парсеры логов 1С, Nginx, файрвола | 1 день | 22 000 ₽ |
| Дашборды для директора + 3 для админа | 1 день | 20 000 ₽ |
| Настройка алертов в Telegram | 0.5 дня | 10 000 ₽ |
| Обучение и документация | 0.5 дня | 3 000 ₽ |
| Итого | 5 дней | 95 000 ₽ |
Грабли, на которые наступили
- WinLogBeat с Defender. На трёх рабочих станциях Windows 11 Defender блокировал сам процесс beats — пришлось добавить в исключения через GPO.
- Heap size. По умолчанию Java-heap OpenSearch поднимается как 1 ГБ — это мало. Выставили 12 ГБ (половину RAM VPS), тормоза ушли.
- Cold storage и retention. Первая версия ISM-policy выкидывала индексы на 30 дней — потом юрист сказал, что логи нужно хранить 180 дней. Переделали.
- Обрушение в момент переезда. Из-за того что поставили один узел без реплики, при первом же VPS-перезагрузе мы потеряли 12 часов индексации логов. Решение — регулярные снапшоты в S3 каждые 6 часов.
Что мы ведём на абонентке
- Обновление OpenSearch и Dashboards раз в квартал.
- Разбор алертов ежедневно, эскалация директору еженедельно.
- Настройка новых источников логов по мере появления (новое железо, новые сервисы).
- Мониторинг места на дисках, ротация индексов.
- Снапшоты в S3 для восстановления в случае краха.
Хотите посмотреть, что происходит в ваших логах?
Если хотите, я могу установить вам бесплатный тестовый OpenSearch на 7 дней. Мы вместе посмотрим, что на самом деле происходит в вашей инфраструктуре. Мой опыт показывает, что часто уже за первые 2–3 дня всплывает от 3 до 5 серьёзных проблем, которые раньше никто не видел. Аудит провожу по Москве и МО.
Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш
FAQ
- Чем OpenSearch отличается от Elasticsearch?
- OpenSearch — форк Elasticsearch 7.10, поддерживаемый Amazon и сообществом. Функционально идентичен ES 7.10, плюс Security, Alerting, Anomaly Detection бесплатно.
- Почему не ставить свежий Elasticsearch?
- С 7.11 Elasticsearch под SSPL/Elastic License. Платная подписка от $16 за узел в час. Для SMB — бессмысленно.
- Сколько места нужно под логи офиса на 45 человек?
- Около 4 ГБ/день в индексе с репликой. За 90 дней — ~360 ГБ. Укладывается в 500 ГБ NVMe.
- Сколько стоит проект в АйТи Фреш?
- Базовое внедрение на 45 РМ и 8 серверов — 95 000 ₽, срок 4–5 дней. Сопровождение на абонентке.