Централизованные логи с 5 площадок

Пока площадка одна, логи обычно смотрят прямо на месте: зашли на сервер, открыли журнал, нашли ошибку. Когда площадок пять, такой подход начинает разваливаться. Интернет в одном филиале моргает, в другом касса не достучалась до API, в третьем сотрудники жалуются на медленную 1С, а в четвертом ночью перезагружался роутер. Если каждый журнал лежит локально, расследование превращается в обход кабинетов.

Централизованные логи нужны не для красоты и не только для «большой безопасности». Они помогают быстро понять, что случилось, где началось, повторяется ли проблема на других точках и кто должен реагировать. Для малого бизнеса это особенно полезно, потому что ИТ-команда или подрядчик редко сидит в каждом филиале.

Какие логи стоит собирать

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

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

Второй слой - сетевое оборудование: VPN, firewall, маршрутизаторы, точки доступа, контроллеры Wi-Fi. Здесь важны разрывы туннелей, ошибки авторизации, блокировки, изменения конфигурации, перегрузки.

Третий слой - прикладные сервисы: 1С, веб-серверы, API киосков, телефония, интеграции с платежами или CRM. Не всегда надо собирать каждый технический след, но ошибки подключения, таймауты и критичные исключения должны быть доступны централизованно.

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

Канал важнее красивой схемы

Для филиалов ключевой вопрос - как логи доедут до центра. Если площадки связаны VPN, можно отправлять журналы по защищенному каналу на центральный сервер. Если VPN нестабилен или его нет, используют агенты с буфером: связь пропала, логи копятся локально, связь вернулась - доотправились.

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

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

Объем и ретеншн

Ретеншн - это срок хранения логов. Ошибка малого ИТ в том, что срок выбирают случайно: «пусть лежит, пока диск не закончится». В итоге нужные события уже стерлись, а мусор занимает место.

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

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

Что писать обязательно

Есть события, без которых расследование почти бессмысленно.

Кто вошел в систему и откуда. Какие ошибки авторизации были. Кто менял конфигурации firewall, VPN, серверов, пользователей. Когда сервисы запускались и падали. Какие интеграции возвращали ошибки. Когда пропадала связь с филиалом. Когда истекали сертификаты или не проходили бэкапы.

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

Централизованные логи хорошо дополняют мониторинг инфраструктуры. Мониторинг отвечает «что сейчас плохо», логи помогают понять «почему и когда началось».

Доступы и ответственность

Логи могут содержать чувствительную информацию. Поэтому доступ к ним не должен быть общим «для всех ИТ». Нужны роли: кто смотрит технические ошибки, кто видит события безопасности, кто может удалять или менять настройки сбора.

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

Хорошая практика - отдельный владелец процесса со стороны бизнеса. Не для чтения каждого сообщения, а для решений: сколько хранить, какие сервисы критичны, кто получает отчеты, как действовать при инциденте.

С чего начать без большого проекта

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

Затем добавьте остальные площадки по шаблону. Если конфигурация филиалов похожа, здесь помогают инструменты автоматизации вроде Ansible. Но даже вручную лучше делать однотипно: одинаковые имена источников, одинаковые теги площадок, одинаковые правила хранения.

После запуска полезно провести учебное расследование: «вчера в филиале пропадал интернет, что мы увидим?» Если ответ все еще «надо зайти на роутер», система не готова.

Вместо заключения

Централизованные логи для пяти площадок - это не роскошь, а способ перестать искать ошибки вслепую. Собирайте только полезное, следите за каналом, задайте срок хранения и ограничьте доступы. Тогда логи будут помогать поддержке, а не лежать мертвым архивом.

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