Syslog-сбор
MikroTik и серверы отдают журналы в одну точку по syslog: события сети и систем оказываются рядом, а не по разным углам инфраструктуры.
События маршрутизаторов, серверов и сервисов — в одной точке: собрать, сохранить и найти нужную запись тогда, когда она нужна. Работаем с компаниями в Москве и Московской области — большинство задач решаем удалённо.
Журналы в небольшой инфраструктуре обычно размазаны: что-то пишет маршрутизатор MikroTik в собственную память, что-то остаётся на отдельных серверах, что-то не пишется вовсе. Единого места, где события можно посмотреть вместе, нет.
Последствия ощущаются именно в момент сбоя. Восстановить хронологию неоткуда: часть записей уже затёрлась, часть лежит там, куда никто не заглядывает, а спорные вопросы решаются по памяти участников. Со временем версии расходятся, и восстановить картину становится окончательно невозможно.
Централизованное логирование закрывает эту дыру: события со всех устройств попадают в одну точку и хранятся там столько, сколько решено, — а не пока хватает памяти на конкретном устройстве.
Направление собирается из четырёх частей — от сбора событий до правил хранения.
MikroTik и серверы отдают журналы в одну точку по syslog: события сети и систем оказываются рядом, а не по разным углам инфраструктуры.
События и данные журналов — в контуре мониторинга, рядом с метриками и уведомлениями: часть картины видна на графиках, часть — в записях.
Централизованное хранение, поиск и анализ: кто, когда и что сделал. Поиск по всем источникам сразу — вместо ручного перечитывания по устройствам.
Сколько и где хранятся журналы, что вращается, а что уходит в архив, — определяется заранее: записи не исчезают внезапно и не растут бесконечно.
Инструменты подбираются под инфраструктуру: где-то достаточно событий в контуре Zabbix, где-то нужен отдельный стек хранения и поиска. Решение выбирается под задачу и бюджет — после аудита, а не по привычке. Комбинации тоже нормальны: события критичных устройств — в мониторинг, полный поток — в отдельное хранилище.
Сценарии, в которых централизованные журналы окупаются, — обычные рабочие ситуации, а не редкие катастрофы.
Когда что-то сломалось, у каждой стороны своя версия. Единая хронология показывает: с чего началось, что за чем следовало, сколько длилось. Разбор превращается из спора в чтение.
Поиск по записям всех устройств сразу — по времени, источнику, событию. Причина находится там, где она зафиксирована, а не там, где предположили.
Кто заходил, что менял, когда перезапускался сервис, — записи об этом сохраняются. Это факт, на который можно сослаться, а не впечатление.
Записи перестают затираться внезапно: место и срок хранения известны заранее. История инфраструктуры не обрывается вместе с памятью одного устройства.
Работа идёт по общей схеме: аудит — понимаем, какие источники событий есть и каких не хватает; проектирование схемы логирования — что собираем, куда, как долго храним; настройка источников и приёмника; затем проверка, документирование и — при желании — сопровождение.
Форматы те же, что в остальных направлениях: разовая настройка, работа в составе проекта по инфраструктуре или абонентское сопровождение с регулярным пересмотром правил хранения.
По итогам система описана в документации: какие источники собраны, где приёмник, сколько хранится каждая категория событий. Это делает схему воспроизводимой — для вас, для нас и для любого другого подрядчика.
Начать можно с малого: собрать события с критичных устройств и добавить остальное по мере надобности. Важно, чтобы схема была спроектирована и описана, а не выросла сама.
Оба решения решают одну задачу — централизованное хранение, поиск и анализ журналов. Выбор зависит от инфраструктуры, требований и бюджета: после аудита предлагаем вариант, который проще сопровождать в вашем случае.
Метрики и записи показывают разное: мониторинг отвечает на вопрос «что случилось», журналы — «почему и как». Они не заменяют друг друга: события в контуре мониторинга и отдельное хранение записей дополняют одно другое.
Зависит от требований компании и объёма событий: где-то достаточно короткого рабочего хранения, где-то нужен долгий архив. Сроки проектируются и фиксируются в документации, а не берутся «по умолчанию».
Объёмы проектируются, а не складываются как получится: состав источников, состав событий и периодичность передачи определяются при настройке — чтобы записи собирались, не мешая рабочему трафику.
Зависит от количества источников и выбранного решения. Ориентир даём после аудита — когда понятно, что собираем и где храним.
Мониторинг, сети и настройка MikroTik, администрирование серверов, IT-аудит. Все направления — в разделе «Услуги».
Расскажите, какие устройства и сервисы должны оставлять след и как долго его хранить. Спроектируем схему журналов под вашу задачу.