Как проверить, работает ли удаленный rsyslog клиент

Короткий ответ: Вы не делаете.

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

6
26.05.2014, 14:58
1 ответ
[1180850] Неплохая идея. Чтобы немного улучшить это, возможно, каждый из клиентов можно было бы настроить на отправку сообщения с регулярным интервалом (обеспечивая "сердцебиение" или "метку"). В случае с Rsyslog директивой является [1181142]$ActionWriteAllMarkMessages[1181143] [1181144][on|off][1181145]. Но обратите внимание на man page:
Обратите внимание, что эта опция автоматически сбрасывает значение "off", поэтому если вы собираетесь использовать ее с несколькими действиями, то она должна быть указана перед всеми строками селекторов, которые должны обеспечить эту функциональность.
Что, если на сервере Syslog есть не обнаруженная конфигурационная проблема, которая приводит к тому, что сообщения направляются в неожиданное место, например, в файл, который вы отслеживаете, чтобы показать, что клиент жив? Возможно, более строгой проверкой может быть (grep/awk) "сердцебиение" или "пометка" сообщений, предоставленных [1181148]$ActionWriteAllMarkMessages[1181149], ищущих время сообщения с определенного хоста.
Для проверки работы удаленного Syslog-сервера можно использовать netcat ([1181150]nc[1181151]) с переключателями [1181152]-z[1181153] и [1181154]-u[1181155]. Из руководства:
-u Использовать UDP вместо опции TCP по умолчанию.
-z Указывает, что nc должен просто сканировать на наличие прослушивающих демонов, не посылая им никаких данных. [...]

-z Например, с пятисекундным таймаутом ([1181160]-w5[1181161]):

Или, если Syslog-сервер также использует TCP, то можно опустить переключатель [1181162]-u[1181163], чтобы воспользоваться надежностью TCP, хотя бы для этой цели. При этом проверяется, что Syslog-сервер прослушивает и доступен из места расположения сервера, выполняющего проверку подключения. Есть еще одна грань, имеющая не меньшее значение: дисковое пространство. (Если на Syslog-сервере не хватает места для записи сообщений, то Syslog-сервер может также считаться неработоспособным)
Учитывая, что UDP может быть "ненадежным" по своей конструкции, рассчитывать на сообщение "mark" или "heartbeat" может не всегда работать в перегруженной сети или на Syslog-сервере. Другим подходом может быть установка скрипта на каждом клиенте. Сценарий (BASH, Python, или любой другой) может возвращать любой код ошибки, который вы придумали (например: Процесс Syslog не запущен? верните 1 или попробуйте сначала запустить процесс Syslog, или разработайте другие тесты, такие как тесты подключения и т.д.). Используйте [1181164]xinetd[1181165] для запуска скрипта с [1181166]/etc/xinetd.d/name_script[1181167] (на RHEL/CentOS):
На RHEL командой restart является [1181168]service xinetd restart[1181169]. Отредактируйте [1181170]/etc/services[1181171], чтобы дать имя порту 6777. Мне нравится использовать [1181172]iptables[1181173] для дополнения [1181174]только_из[1181175] строфы. Кстати, порт 6777 был использован только для иллюстрации.[1180867].

5
27.01.2020, 20:29

Теги

Похожие вопросы