Linuxoid.pro

Сообщество разработчиков программного обеспечения и IT-специалистов

Руководство по ведению журнала с помощью системного журнала в Linux

Содержание:

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

В большинстве случаев вы работаете не с одной машиной, а с множеством разных машин Linux , каждая из которых имеет собственное локальное хранилище журналов.

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

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

Но что, если бы у нас был централизованный способ хранения журналов на удаленной машине?

Что, если бы мы могли получить доступ к файлам журналов из одной точки?

Разве не было бы проще и надежнее?

В этом подробном руководстве мы собираемся создать централизованную систему ведения журналов с использованием Syslog в системах Linux .

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

I — что вы узнаете?

Как всегда, давайте начнем с того, что посмотрим на все, что вы собираетесь изучить, если будете следовать руководству до конца.

С помощью этого урока вы узнаете:

  • Как ведение журнала Linux работает на отдельном экземпляре, где искать журналы;
  • Как выглядит централизованная архитектура журналирования: преимущества и недостатки ее использования;
  • Как настроить перенаправление rsyslog с клиента на централизованный сервер;
  • Как защитить пересылку журналов с помощью протокола TLS ;
  • Как отправлять журналы с помощью надежных механизмов, таких как очереди действий .

Это длинная программа, но вы можете пропустить некоторые разделы, если вы уже знакомы с некоторыми концепциями, описанными в этой статье.

II — Как ведение журнала Linux работает на одном экземпляре?

Начнем с истории ведения журналов Linux.

a — Общие концепции ведения журналов Linux

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

По умолчанию ваша операционная система Linux ведет журналы о многих событиях, происходящих на вашем компьютере.

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

Системный журнал можно использовать как сервер (на котором размещаются журналы) или как клиент (пересылка журналов на удаленный сервер).

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

Если вы используете современный дистрибутив Linux (например, компьютер с Ubuntu, CentOS или RHEL), по умолчанию используется сервер системного журнала rsyslog .

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

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

б — Где хранятся журналы в файловой системе Linux?

Короче говоря, журналы хранятся в / var / log / вашей файловой системы.

В этом месте вы должны увидеть несколько файлов журналов, каждый из которых имеет имя, описывающее, что они на самом деле хранят.

Для быстрого обзора вы можете выполнить следующую команду:

$ ls -l /var/log
-rw-r----- 1 syslog adm 120999 Jul 24 18:04 auth.log
-rw-r--r-- 1 root root 127503 Jul 20 06:35 dpkg.log
-rw-r----- 1 syslog adm 0 Jul 15 06:25 kern.log
drwxrwxr-x 2 logstash root 4096 Jul 8 18:33 logstash
drwxr-xr-x 2 root root 4096 Sep 10 2018 lxd
drwxr-xr-x 2 mongodb mongodb 4096 Jul 8 06:25 mongodb

Как видите, у вас есть специальные файлы журналов для аутентификации или журналов, связанных с ядром .

/ var / log не содержит только файлы, но также содержит специальные папки, которые поставщики создают при установке приложения.

Как видите, на моем экземпляре запущена база данных MongoDB.

Как следствие, у меня в папке журнала есть папка MongoDB.

Но зачем я вам все это рассказываю?

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

Предположим, что три машины отправляют журналы на мой сервер, каждая машина будет иметь свои собственные файлы auth.log, kern.log или dpkg.log.

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

Вот архитектура папок на стороне сервера.

III — Проектирование централизованной архитектуры ведения журналов в Linux

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

Как описано в первом разделе, каждая машина в нашем пуле уже ведет журналы через rsyslog.

Однако изначально наши машины настроены как экземпляры системного журнала клиент-сервер .

Они создают журналы, но хранят их локально в файловой системе.

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

Чтобы быть законченной, наша архитектура должна:

  • Будьте осторожны : вот почему мы собираемся реализовать TLS в пятом разделе;
  • Будьте надежны : если вся сеть выйдет из строя на минуту, все журналы за этот период потеряны навсегда? Не с очередями действий.

В чем преимущества такой архитектуры?

  • Вы можете проверять все свои журналы из одного места : вы не полагаетесь на индивидуальное подключение к каждой машине в пуле, вы можете напрямую просматривать журналы из одной и той же файловой системы.
  • У вас есть доступ к журналам, даже если хост недоступен: если на одной из машин возникли проблемы и она не может быть достигнута, вы не сможете пройти через файловую систему для просмотра журналов. С централизованным сервером журналов у вас есть возможность просматривать журналы без какого-либо физического доступа к клиентской машине .
  • Вы можете настроить полную инфраструктуру мониторинга журналов: если вы заинтересованы в визуализации журналов с помощью таких инструментов, как Kibana, я написал об этом полное руководство.

С другой стороны, в чем будут для нас недостатки такой архитектуры?

  • Вы рискуете перегрузить свой сервер системного журнала: с этой архитектурой вы отправляете журналы на удаленный сервер. Как следствие, если одна машина сойдет с ума и начнет отправлять тысячи журналов, вы рискуете перегрузить сервер журналов. (если вам нужен надежный контроль обратного давления, вы можете проверить Filebeat by Elastic)
  • Если ваш сервер журналов выходит из строя, вы теряете возможность просматривать все журналы, отправленные клиентами . Более того, если сервер выйдет из строя, клиенты начнут хранить сообщения локально, пока сервер снова не станет доступным, таким образом заполняя дисковое пространство на стороне клиента.

IV — Настройте rsyslog для пересылки журналов на централизованный сервер

а — Предпосылки

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

$ sudo systemctl status rsyslog

Если служба неизвестна на вашем компьютере, вы можете установить ее, запустив:

$ sudo apt-get update && apt-get install rsyslog 
$ sudo systemctl enable rsyslog 
$ sudo systemctl start rsyslog

a — Настройте свой сервер rsyslog

Прежде всего, вы должны настроить свой сервер rsyslog, чтобы он принимал входящие журналы на порт 514 .

Мы собираемся использовать TCP для передачи журналов, но вы можете использовать UDP, если вас не особо заботит надежность.

На сервере перейдите в папку /etc/rsyslog.d.

Это каталог, в котором хранятся шаблоны, а также файлы, содержащие правила rsyslog .

В этом каталоге должен быть файл 50-default.conf .

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

Таким образом, наш файл конфигурации имеет приоритет над файлом по умолчанию.

$ sudo touch 01-server.conf

# Listen for TCP
$ModLoad imtcp
# Listen on port 514
$InputTCPServerRun 514

$template RemoteServer, "/var/log/%HOSTNAME%/%SYSLOGFACILITY-TEXT%.log"
*.* ?RemoteServer

Наше первое правило!

С помощью этого синтаксиса наши файлы журналов будут сгруппированы по имени хоста (также известному как имя компьютера, отправляющего журнал), а затем по средствам системного журнала (kern, user, auth и т. Д.)

Перезагрузите сервер rsyslog и убедитесь, что он теперь прослушивает порт 514 для TCP.

$ sudo systemctl restart rsyslog
$ netstat -tna | grep :514
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN
tcp6 0 0 :::514 :::* LISTEN

Примечание : с этим файлом конфигурации журналы вашего сервера теперь больше хранятся напрямую в / var / log, но в / var / log / hostname, где hostname является текущим именем вашего хоста (в моем случае / var / log / schkn-ubuntu )

$ uname -a
Linux schkn-ubuntu 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

б — Настройте свой клиент rsyslog

Пришло время настроить rsyslog в качестве клиента на нашем экземпляре.

Теперь, когда у нас есть rsyslog, перейдите в /etc/rsyslog.d.

Аналогично процедуре, выполняемой на стороне сервера, создайте файл 01-client.conf .

$ sudo vi 01-client.conf

*.* @@distant-server-ip:514

Конфигурация на стороне клиента довольно проста, простая пересылка .

Перезагрузите сервер rsyslog и убедитесь, что:

  • У вас нет ошибок на стороне клиента
$ sudo systemctl restart rsyslog
$ journalctl -f -u rsyslog
  • Теперь на вашем сервере есть журналы от клиента.

Моя клиентская машина называется «antoine-Virtualbox» в моей текущей настройке, поэтому я ищу / var / log / antoine-Virtualbox.

Потрясающие! Удаленные журналы теперь корректно хранятся на нашем сервере.

Однако у меня для вас плохие новости.

Поскольку мы используем TCP для передачи журналов, это означает, что сообщения между клиентом и сервером не шифруются .

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

Это то, что мы называем человеком в средней атаке.

В качестве доказательства вот экземпляр Wireshark, который обнюхивает мою сеть и прослушивает очень конкретный IP-адрес.

Как видите, сообщение хорошо видно и гласит: «Привет, это тестовое сообщение».

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

Вот почему мы собираемся настроить TLS , что позволит нам шифровать трафик между клиентом и сервером.

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

V — Шифрование сообщений rsyslog с помощью TLS

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

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

С помощью этого протокола клиент и сервер сначала гарантируют, что они правильно разговаривают друг с другом (поскольку на пути нет никого с поддельной идентификацией), а затем они перейдут к шифрованию своих сообщений .

Когда клиент и сервер обмениваются своими ключами, они могут расшифровывать сообщения на лету.

В нашей настройке у нас будет центр сертификации, подписывающий ключи .

Связь между хостами и центром сертификации, очевидно, тоже зашифрована, поэтому нам нужно сначала создать пару ключей для центра сертификации .

Если вы только тестируете, вы можете использовать свой сервер rsyslog в качестве центра сертификации.

а — Настройка вашего центра сертификации

На сервере перейдите в / etc / ssl и создайте каталог rsyslog.

$ sudo mkdir /etc/ssl/rsyslog
$ cd /etc/ssl/rsyslog

Установите пакет gnutls-utils (который может быть gnutls-bin для некоторых дистрибутивов), который включает SSL API на вашем сервере.

$ sudo apt-get install gnutls-utils 
(или) 
$ sudo apt-get install gnutls-bin

Сгенерируйте закрытый ключ для центра сертификации:

$ sudo certtool --generate-privkey --outfile CA-key.pem
$ sudo chmod 400 CA-key.pem

Сгенерируйте открытый ключ в центре сертификации:

$ sudo certtool --generate-self-signed --load-privkey CA-key.pem --outfile CA.pem
# Common name: authority.devconnected.com
# The certificate will expire in (days): 3650
# Does the certificate belong to an authority? (Y/N): y
# Will the certificate be used to sign other certificates? (Y/N): y
# Will the certificate be used to sign CRLs? (y/N): y

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

б — Генерация приватных / публичных ключей для сервера

Теперь, когда у нашего центра сертификации есть ключи для подписи других ключей, давайте создадим один для сервера rsyslog.

Сначала создайте закрытый ключ для своего сервера.

$ sudo certtool --generate-privkey --outfile server-key.pem --bits 2048

Создайте запрос сертификата для вашего сервера.

$ sudo certtool --generate-request --load-privkey server-key.pem --outfile server-request.pem

Создайте сертификат для своего сервера rsyslog и импортируйте в него ключи доверенного центра сертификации.

$ sudo certtool --generate-certificate --load-request server-request.pem --outfile server-cert.pem --load-ca-certificate CA.pem --load-ca-privkey CA-key.pem

# The certificate will expire in (days): 3650
# Is this a TLS web client certificate? (Y/N): y
# Is this also a TLS web server certificate? (y/N): y
# Enter a dnsName of the subject of the certificate: server.linuxoid.pro

c — Генерировать приватные / публичные ключи для клиента

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

Создайте закрытый ключ для клиента.

$ sudo certtool --generate-privkey --outfile client-key.pem --bits 2048

Сгенерируйте запрос сертификата для клиента.

$ sudo certtool --generate-request --load-privkey client-key.pem --outfile client-request.pem

Создайте сертификат (открытый ключ) для своего клиента и импортируйте сертификаты центра сертификации внутрь.

$ sudo certtool —generate-certificate —load-request client-request.pem —outfile client-cert.pem —load-ca-certificate CA.pem —load-ca-privkey CA-key.pem

# The certificate will expire in (days): 3650
# Is this a TLS web client certificate? (Y/N): y
# Is this also a TLS web server certificate? (y/N): y
# Enter a dnsName of the subject of the certificate: client.linuxoid.pro

Потрясающие! Теперь у нас есть пары ключей как для нашего клиента, так и для сервера.

d — отправить сгенерированные ключи вашим хостам

Теперь, когда ваши ключи сгенерированы в центре сертификации, безопасно отправьте ключи на целевые хосты .

Для этого вы можете использовать scp.

Для сервера (просто переключитесь на «клиент», если вы хотите отправить ключи клиенту)

$ sudo -u root scp -i ~/.ssh/id_rsa CA.pem server-* root@server_ip_here:/etc/ssl/rsyslog/

e — Настройте свой сервер rsyslog.

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

Сначала установите драйвер gtls на свой сервер.

$ sudo apt-get install rsyslog-gnutls

Напоминаем, что в предыдущей главе мы создали файл 01-server.conf.

Замените содержимое следующей конфигурацией.

# Listen for TCP
$ModLoad imtcp
# GTLS driver
$DefaultNetstreamDriver gtls
# Certificates
$DefaultNetstreamDriverCAFile /etc/ssl/rsyslog/CA.pem
$DefaultNetstreamDriverCertFile /etc/ssl/rsyslog/server-cert.pem
$DefaultNetstreamDriverKeyFile /etc/ssl/rsyslog/server-key.pem
# Authentication mode
$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverPermittedPeer *.linuxoid.pro
# Only use TLS
$InputTCPServerStreamDriverMode 1
# Listen on port 514
$InputTCPServerRun 514

$template RemoteServer, "/var/log/%HOSTNAME%/%SYSLOGFACILITY-TEXT%.log"
*.* ?RemoteServer

Как видите, мы добавляем AuthMode, в данном случае x509 / name.

Это означает, что мы собираемся использовать сертификат, в котором содержится «имя».

Помните, когда мы объявляли, что были «client.linuxoid.pro» или «server.linuxoid.pro», когда создавали сертификаты?

Это как раз та информация, которую будет использовать аутентификация, и вы получите сообщение об ошибке, если имя не совпадает.

Не забудьте перезапустить rsyslog, чтобы изменения были сохранены.

$ sudo systemctl restart rsyslog

f — Настройте свой клиент rsyslog

На клиенте у нас было простое правило переадресации в файле 01-client.conf.

Опять же, установите драйвер gtls на свой клиент.

$ sudo apt-get install rsyslog-gnutls

Замените содержимое следующей конфигурацией.

# GTLS driver
$DefaultNetstreamDriver gtls
# Certificates
$DefaultNetstreamDriverCAFile /etc/ssl/rsyslog/CA.pem
$DefaultNetstreamDriverCertFile /etc/ssl/rsyslog/client-cert.pem
$DefaultNetstreamDriverKeyFile /etc/ssl/rsyslog/client-key.pem
# Auth mode
$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer server.devconnected.com
# Only use TLS
$ActionSendStreamDriverMode 1
# Forward everything to server.devconnected.com
*.* @@distant-server-ip:514

Перезагрузите клиент rsyslog.

$ sudo systemctl restart rsyslog

Потрясающие! Теперь ваши журналы должны быть отправлены на ваш удаленный сервер. Запустите эту команду и убедитесь, что у вас нет ошибок (если вы это сделаете, у меня есть раздел для этого в конце)

$ $ journalctl -u -n 100 rsyslog

Обещание — это обещание, вот мой Wireshark между моим сервером и моим клиентом с шифрованием TLS между ними.

Вы не можете расшифровать сообщение.

Поворот сюжета : я снова отправил «Привет, это тестовое сообщение».

VI — Надежная отправка сообщений журнала с очередями действий

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

В нашей архитектуре клиент и сервер очень тесно связаны.

Что это значит?

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

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

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

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

Чтобы решить эту проблему, нам нужно добавить развязку в эту архитектуру.

Если вы читали книгу Грегора Хопе «Шаблоны интеграции предприятий», надежность — это очереди .

a — Проектирование надежности сообщений

Во-первых, давайте разберемся с парочкой концепций, связанных с очередями сообщений rsyslog.

В rsyslog есть несколько способов создания очередей, но в конечном итоге появляются три основные категории:

  • Прямой : это своего рода режим «без очереди», в котором сообщения напрямую передаются от производителя к потребителю. Определенно не тот режим, который мы хотели бы реализовать в нашем случае;
  • Дисковые очереди : в этом случае, когда сообщения передаются в очередь, они надежно записываются на диск. В этом случае вы в большей безопасности, когда дело доходит до полного случайного выключения машины, но процесс занимает больше времени, чем очереди памяти. Запись на диск дороже, чем запись в ОЗУ;
  • Очереди памяти : эти очереди будут удерживать сообщения в памяти в течение заданного времени и в течение заданного количества ограниченного пространства. Через некоторое время они будут записаны на диск. Эта альтернатива быстрее дисковых очередей.

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

В файле 01-client.conf добавьте следующие строки в файл конфигурации.

$ ActionQueueType LinkedList 
$ ActionQueueFileName rsyslog_backup 
$ ActionQueueS$ActionQueueType LinkedList
$ActionQueueFileName rsyslog_backup
$ActionQueueSaveOnShutdown on
$ActionResumeRetryCount -1
...
# Parameters from the TLS section
$ActionSendStreamDriverAuthMode x509/nameaveOnShutdown в $ ActionResumeRetryCount

  • LinkedList : мы хотим, чтобы распределение памяти происходило на лету, а не через фиксированный массив. Это приведет к увеличению накладных расходов, но вы выиграете от этого, получив больше места ;
  • Имя файла очереди : это файл, в который будут записываться данные, если данные в конечном итоге будут сохранены на диске. Путь к нему — $ WorkDirectory / rsyslog_backup, где WorkDirectory — это переменная, определенная в вашем файле rsyslog.conf;
  • Экономия при выключении : если машина должна была выключиться, журналы памяти сначала записывались на диск;
  • Возобновить счетчик повторов : при потере модуля пересылки rsyslog будет пытаться повторно подключиться к нему на неопределенный срок.

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

Перезапустите rsyslog и убедитесь, что у вас нет ошибок.

$ sudo systemctl restart rsyslog 
$ sudo journalctl -f -u rsyslog.service

б — Демонстрация надежности сообщения

Хорошо, теперь, когда у нас есть надежность сообщений, давайте проверим это.

На стороне сервера закомментируйте все строки в файле 01-server.conf и перезапустите rsyslog. С этого момента ваш клиент должен потерять соединение с сервером.

На клиенте:

$ sudo journalctl -f -u rsyslog.service

На клиенте вручную запустите событие журнала.

$ logger -p 'auth.crit' 'Critial auth message, lost?'

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

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

Перейдите на сервер, удалите комментарии для всех строк и перезапустите сервер rsyslog.

Оттуда, ваш клиент будет автоматически повторно включить модуль переадресации.

Но получил ли наш сервер сообщение, которое было сохранено в памяти клиента? Это сработало!

Поздравляем, вы разработали (безопасную!) Надежность сообщений между клиентами rsyslog и сервером rsyslog.

Общие ошибки

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

  • omfwd: ошибка TCPSendBuf -2027, разрушение TCP-соединения xxxx

Решение : если у вас есть эта ошибка в разделе TLS, вероятно, ваша конфигурация TLS неверна. Либо вы неправильно настроили сертификаты, либо у вас неправильная конфигурация сервера.

  • Невозможно подключиться к xxxx: сеть недоступна.

Решение : убедитесь, что IP-адрес доступен с клиентского хоста. Вы можете пропинговать это своим примером.

$ ping 142.93.103.142
PING 142.93.103.142 (142.93.103.142) 56(84) bytes of data.
64 bytes from 142.93.103.142: icmp_seq=1 ttl=64 time=0.023 ms
64 bytes from 142.93.103.142: icmp_seq=2 ttl=64 time=0.056 ms
64 bytes from 142.93.103.142: icmp_seq=3 ttl=64 time=0.033 ms
--- 142.93.103.142 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2047ms
  • Имя сверстника не авторизовано: не разрешено с ним разговаривать. Имена CN: name.domain.com

Убедитесь, что в файле конфигурации rsyslog правильно установлен $ ActionSendStreamDriverPermittedPeers.

Бонус: несколько слов о протоколах противодавления

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

а — Архитектурные улучшения

Архитектуру, которую мы разработали вместе, можно рассматривать как « выталкивающую » архитектуру. По сути, мы отправляем журналы с клиента на серверы.

А это рискованно.

Почему?

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

Вот несколько мыслей о том, как с этим справиться:

  • Используйте параметр rsyslog dequeueSlowDown, чтобы отложить выполнение сообщения, по сути устанавливая темп для всех отправляемых сообщений. Вот ссылка на него.
  • Используйте сторонний продукт противодавления, например Filebeat. Filebeat может быть интересен, если вы уже все вместе работаете со стеком ELK. Он реализует собственный протокол обратного давления, чтобы вы могли установить скорость при отправке журналов.

б — Системы регистрации Push vs Pull

Мы уже рассмотрели разницу между системами push и pull, по крайней мере, когда речь идет о решениях для мониторинга с открытым исходным кодом.

Мы увидели преимущество создания активного решения для мониторинга, но не могли бы мы применить те же принципы, когда дело касается централизованных систем ведения журналов?

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

Знаете ли вы о такой системе?

Вывод

Этим последним пунктом завершается подробное руководство по централизованному ведению журнала для систем Linux.

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

Я надеюсь, что вы сегодня чему-то научились.

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