Ведение журнала многоуровневого сервера
У меня есть многоуровневое приложение, состоящее из множества серверов в разных подсетях (каждая из этих подсетей выделена для целей приложения, которые они предоставляют, без других серверов, независимых от приложения). Это windows, debian, freebsd, а в будущем могут появиться и другие.
Я хочу иметь централизованный механизм ведения журнала для своих систем. Проблема в том, что я хочу, чтобы данные сначала собирались в демилитаризованной зоне, а затем к ним обращался сервер журналов, который будет находиться в другой локальной сети.
Мне также нужна регистрация для моих сетевых устройств, но это может быть совершенно другой сервер регистрации для всего, что мне небезразлично (хотя было бы лучше, если бы это было не так).
Как бы вы внедрили этот тип ведения журнала? Эта архитектура многоуровневая в целях безопасности и не изменится.
Я уже видел Scribe и Logstash как жизнеспособные решения. Вы бы порекомендовали их для такого дела, как описанное ранее?
Можно ли реализовать скрипты с использованием механизма ssh?
Вы можете сделать это с любым из современных серверов системного журнала (я бы рекомендовал syslog-ng потому что я знаком с этим, но rsyslog это еще один вариант).
Практически каждая система тем или иным образом поддерживает системный журнал (каждый маршрутизатор / коммутатор профессионального уровня, с которым я работал, поддерживает машины Unix, и я считаю, что Windows может даже отправлять сообщения журнала событий на серверы системного журнала), что делает его довольно хорошим вариантом .
Протокол syslog традиционно представляет собой незащищенные дейтаграммы UDP, но современные серверы syslog имеют поддержку TCP, и я знаю syslog-ng также поддерживает SSL / TLS.
Что касается того, как вы собираете данные журнала, стратегии реализации различаются.
Один из вариантов - просто разрешить всем вашим хостам подключаться к серверу системного журнала и заставить их отправлять туда свои сообщения журнала. Это относительно просто, но потенциально менее безопасно (вам нужно пробить много дыр в брандмауэре или позволить всей вселенной взаимодействовать с вашим сервером журналов).
Другой вариант - локальные агрегаторы журналов, которые пересылаются на центральный сервер журналов (аналогично архитектуре, которую вы описываете в своем вопросе). Обычно это считается лучшим вариантом по двум основным причинам:
Легче обеспечить
Центральному серверу журналов нужно только принимать подключения от «авторизованных» клиентов, а локальным серверам журналов нужно принимать подключения только из своей локальной сети.Он предлагает вам некоторую избыточность
Если центральный сервер журналов отключен для обслуживания, вы по-прежнему собираете журналы на локальных серверах, и они могут быть отправлены вместе, когда центральный сервер снова станет доступен.