Журнал syslog используется для nix систем windows ad - Доктор Windows

From Wikipedia, the free encyclopedia

Syslog

Original author(s)	Eric Allman
Initial release	1980s
Operating system	Unix-like
Type	System logging
Website	datatracker.ietf.org/wg/syslog/charter/

In computing, syslog is a standard for message logging. It allows separation of the software that generates messages, the system that stores them, and the software that reports and analyzes them. Each message is labeled with a facility code, indicating the type of system generating the message, and is assigned a severity level.

Computer system designers may use syslog for system management and security auditing as well as general informational, analysis, and debugging messages. A wide variety of devices, such as printers, routers, and message receivers across many platforms use the syslog standard. This permits the consolidation of logging data from different types of systems in a central repository. Implementations of syslog exist for many operating systems.

When operating over a network, syslog uses a client-server architecture where a syslog server listens for and logs messages coming from clients.

History[edit]

Syslog was developed in the 1980s by Eric Allman as part of the Sendmail project.^[1] It was readily adopted by other applications and has since become the standard logging solution on Unix-like systems.^[2] A variety of implementations also exist on other operating systems and it is commonly found in network devices, such as routers.^[3]

Syslog originally functioned as a de facto standard, without any authoritative published specification, and many implementations existed, some of which were incompatible. The Internet Engineering Task Force documented the status quo in RFC 3164 in August of 2001. It was standardized by RFC 5424 in March of 2009.^[4]

Various companies have attempted to claim patents for specific aspects of syslog implementations.^[5]^[6] This has had little effect on the use and standardization of the protocol.^{[citation needed]}

Message components[edit]

The information provided by the originator of a syslog message includes the facility code and the severity level. The syslog software adds information to the information header before passing the entry to the syslog receiver. Such components include an originator process ID, a timestamp, and the hostname or IP address of the device.

Facility[edit]

A facility code is used to specify the type of system that is logging the message. Messages with different facilities may be handled differently.^[7] The list of facilities available is described by the standard:^[4]^: 9

Facility code	Keyword	Description
0	kern	Kernel messages
1	user	User-level messages
2	mail	Mail system
3	daemon	System daemons
4	auth	Security/authentication messages
5	syslog	Messages generated internally by syslogd
6	lpr	Line printer subsystem
7	news	Network news subsystem
8	uucp	UUCP subsystem
9	cron	Cron subsystem
10	authpriv	Security/authentication messages
11	ftp	FTP daemon
12	ntp	NTP subsystem
13	security	Log audit
14	console	Log alert
15	solaris-cron	Scheduling daemon
16–23	local0 – local7	Locally used facilities

The mapping between facility code and keyword is not uniform in different operating systems and syslog implementations.^[8]

Severity level[edit]

The list of severities is also described by the standard:^[4]^: 10

Value	Severity	Keyword	Deprecated keywords	Description	Condition
0	Emergency	`emerg`	`panic`^[9]	System is unusable	A panic condition.^[10]
1	Alert	`alert`		Action must be taken immediately	A condition that should be corrected immediately, such as a corrupted system database.^[10]
2	Critical	`crit`		Critical conditions	Hard device errors.^[10]
3	Error	`err`	`error`^[9]	Error conditions
4	Warning	`warning`	`warn`^[9]	Warning conditions
5	Notice	`notice`		Normal but significant conditions	Conditions that are not error conditions, but that may require special handling.^[10]
6	Informational	`info`		Informational messages	Confirmation that the program is working as expected.
7	Debug	`debug`		Debug-level messages	Messages that contain information normally of use only when debugging a program.^[10]

The meaning of severity levels other than Emergency and Debug are relative to the application. For example, if the purpose of the system is to process transactions to update customer account balance information, an error in the final step should be assigned Alert level. However, an error occurring in an attempt to display the ZIP code of the customer may be assigned Error or even Warning level.

The server process which handles display of messages usually includes all lower (more severe) levels when display of less severe levels is requested. That is, if messages are separated by individual severity, a Warning level entry will also be included when filtering for Notice, Info and Debug messages.^[11]

Message[edit]

In RFC 3164, the message component (known as MSG) was specified as having these fields: TAG, which should be the name of the program or process that generated the message, and CONTENT which contains the details of the message.

Described in RFC 5424,^[12] «MSG is what was called CONTENT in RFC 3164. The TAG is now part of the header, but not as a single field. The TAG has been split into APP-NAME, PROCID, and MSGID. This does not totally resemble the usage of TAG, but provides the same functionality for most of the cases.» Popular syslog tools such as Rsyslog conform to this new standard.

The content field should be encoded in a UTF-8 character set and octet values in the traditional ASCII control character range should be avoided.^[13]^[14]

Logger[edit]

Generated log messages may be directed to various destinations including console, files, remote syslog servers, or relays. Most implementations provide a command line utility, often called logger, as well as a software library, to send messages to the log.^[15]

To display and monitor the collected logs one needs to use a client application or access the log file directly on the system. The basic command line tools are tail and grep. The log servers can be configured to send the logs over the network (in addition to the local files). Some implementations include reporting programs for filtering and displaying of syslog messages.

Network protocol[edit]

When operating over a network, syslog uses a client-server architecture where the server listens on a well-known or registered port for protocol requests from clients. Historically the most common transport layer protocol for network logging has been User Datagram Protocol (UDP), with the server listening on port 514.^[16] Because UDP lacks congestion control mechanisms, Transmission Control Protocol (TCP) port 6514 is used; Transport Layer Security is also required in implementations and recommended for general use.^[17]^[18]

Limitations[edit]

Since each process, application, and operating system was written independently, there is little uniformity to the payload of the log message. For this reason, no assumption is made about its formatting or contents. A syslog message is formatted (RFC 5424 gives the Augmented Backus–Naur form (ABNF) definition), but its MSG field is not.

The network protocol is simplex communication, with no means of acknowledging the delivery to the originator.

Outlook[edit]

Various groups are working on draft standards detailing the use of syslog for more than just network and security event logging, such as its proposed application within the healthcare environment.^[19]

Regulations, such as the Sarbanes–Oxley Act, PCI DSS, HIPAA, and many others, require organizations to implement comprehensive security measures, which often include collecting and analyzing logs from many different sources. The syslog format has proven effective in consolidating logs, as there are many open-source and proprietary tools for reporting and analysis of these logs. Utilities exist for conversion from Windows Event Log and other log formats to syslog.

Managed Security Service Providers attempt to apply analytical techniques and artificial intelligence algorithms to detect patterns and alert customers to problems.^[20]

Internet standard documents[edit]

The Syslog protocol is defined by Request for Comments (RFC) documents published by the Internet Engineering Task Force (Internet standards). The following is a list of RFCs that define the syslog protocol:^[21]

The BSD syslog Protocol. RFC 3164. (obsoleted by The Syslog Protocol. RFC 5424.)
Reliable Delivery for syslog. RFC 3195.
The Syslog Protocol. RFC 5424.
TLS Transport Mapping for Syslog. RFC 5425.
Transmission of Syslog Messages over UDP. RFC 5426.
Textual Conventions for Syslog Management. RFC 5427.
Signed Syslog Messages. RFC 5848.
Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog. RFC 6012.
Transmission of Syslog Messages over TCP. RFC 6587.

References[edit]

^ «Eric Allman». Internet Hall of Fame. Retrieved 2017-10-30.
^ «3 great engineering roles to apply for this week». VentureBeat. 2021-08-06. Retrieved 2021-08-16.
^ «Efficient and Robust Syslog Parsing for Network Devices in Datacenter Networks».{{cite web}}: CS1 maint: url-status (link)
^ ^a ^b ^c Gerhards, Rainer. The Syslog Protocol. doi:10.17487/RFC5424. RFC 5424.
^ «LXer: Patent jeopardizes IETF syslog standard».
^ «IETF IPR disclosure on HUAWEI’s patent claims».
^ «Syslog Facility». Retrieved 22 November 2012.
^ «The Ins and Outs of System Logging Using Syslog». SANS Institute.
^ ^a ^b ^c «syslog.conf(5) — Linux man page». Retrieved 2017-03-29.
^ ^a ^b ^c ^d ^e «closelog, openlog, setlogmask, syslog — control system log». Retrieved 2017-03-29.
^ «Severity Levels for Syslog Messages». docs.delphix.com. Retrieved 2021-08-16.
^ Gerhards, Rainer (March 2009). «RFC 5424 — The Syslog Protocol». doi:10.17487/RFC5424. This document describes a layered architecture for syslog. The goal of this architecture is to separate message content from message transport while enabling easy extensibility for each layer.
^ «Transmission of Syslog Messages over TCP». www.ipa.go.jp. Retrieved 2021-08-16.
^ Gerhards, Rainer (March 2009). «rfc5424». datatracker.ietf.org. Retrieved 2021-08-16.
^ «logger Command». www.ibm.com. Retrieved 2021-08-16.
^ «Syslog Server». www.howtonetwork.com. Retrieved 2021-08-16.{{cite web}}: CS1 maint: url-status (link)
^ Gerhards, Rainer (March 2009). «RFC 5424 — The Syslog Protocol». doi:10.17487/RFC5424.
^ Fuyou, Miao; Yuzhi, Ma; Salowey, Joseph A. (March 2009). Miao, F; Ma, Y; Salowey, J (eds.). «RFC 5425 — TLS Transport Mapping for Syslog». doi:10.17487/RFC5425.
^ «ATNA + SYSLOG is good enough». Healthcare Exchange Standards. 2 January 2012. Retrieved 2018-06-06.
^ Yamanishi, Kenji; Maruyama, Yuko (2005-08-21). «Dynamic syslog mining for network failure monitoring». Proceedings of the Eleventh ACM SIGKDD International Conference on Knowledge Discovery in Data Mining. KDD ’05. Chicago, Illinois, USA: Association for Computing Machinery: 499–508. doi:10.1145/1081870.1081927. ISBN 978-1-59593-135-1. S2CID 5051532.
^ «Security Issues in Network Event Logging (syslog)». IETF.

External links[edit]

Internet Engineering Task Force: Datatracker: syslog Working Group (concluded)
SANS Institute: «The Ins and Outs of System Logging Using Syslog» (white paper)
National Institute of Standards and Technology: «Guide to Computer Security Log Management» (Special Publication 800-92) (white paper)
Network Management Software: «Understanding Syslog: Servers, Messages & Security»
Paessler IT Explained — Syslog
MonitorWare: All about Syslog

Источник

From Wikipedia, the free encyclopedia

Syslog

Original author(s)	Eric Allman
Initial release	1980s
Operating system	Unix-like
Type	System logging
Website	datatracker.ietf.org/wg/syslog/charter/

When operating over a network, syslog uses a client-server architecture where a syslog server listens for and logs messages coming from clients.

History[edit]

Message components[edit]

Facility[edit]

Facility code	Keyword	Description
0	kern	Kernel messages
1	user	User-level messages
2	mail	Mail system
3	daemon	System daemons
4	auth	Security/authentication messages
5	syslog	Messages generated internally by syslogd
6	lpr	Line printer subsystem
7	news	Network news subsystem
8	uucp	UUCP subsystem
9	cron	Cron subsystem
10	authpriv	Security/authentication messages
11	ftp	FTP daemon
12	ntp	NTP subsystem
13	security	Log audit
14	console	Log alert
15	solaris-cron	Scheduling daemon
16–23	local0 – local7	Locally used facilities

The mapping between facility code and keyword is not uniform in different operating systems and syslog implementations.^[8]

Severity level[edit]

The list of severities is also described by the standard:^[4]^: 10

Value	Severity	Keyword	Deprecated keywords	Description	Condition
0	Emergency	`emerg`	`panic`^[9]	System is unusable	A panic condition.^[10]
1	Alert	`alert`		Action must be taken immediately	A condition that should be corrected immediately, such as a corrupted system database.^[10]
2	Critical	`crit`		Critical conditions	Hard device errors.^[10]
3	Error	`err`	`error`^[9]	Error conditions
4	Warning	`warning`	`warn`^[9]	Warning conditions
5	Notice	`notice`		Normal but significant conditions	Conditions that are not error conditions, but that may require special handling.^[10]
6	Informational	`info`		Informational messages	Confirmation that the program is working as expected.
7	Debug	`debug`		Debug-level messages	Messages that contain information normally of use only when debugging a program.^[10]

Message[edit]

The content field should be encoded in a UTF-8 character set and octet values in the traditional ASCII control character range should be avoided.^[13]^[14]

Logger[edit]

Network protocol[edit]

Limitations[edit]

The network protocol is simplex communication, with no means of acknowledging the delivery to the originator.

Outlook[edit]

Managed Security Service Providers attempt to apply analytical techniques and artificial intelligence algorithms to detect patterns and alert customers to problems.^[20]

Internet standard documents[edit]

The BSD syslog Protocol. RFC 3164. (obsoleted by The Syslog Protocol. RFC 5424.)
Reliable Delivery for syslog. RFC 3195.
The Syslog Protocol. RFC 5424.
TLS Transport Mapping for Syslog. RFC 5425.
Transmission of Syslog Messages over UDP. RFC 5426.
Textual Conventions for Syslog Management. RFC 5427.
Signed Syslog Messages. RFC 5848.
Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog. RFC 6012.
Transmission of Syslog Messages over TCP. RFC 6587.

References[edit]

^ «Eric Allman». Internet Hall of Fame. Retrieved 2017-10-30.
^ «3 great engineering roles to apply for this week». VentureBeat. 2021-08-06. Retrieved 2021-08-16.
^ «Efficient and Robust Syslog Parsing for Network Devices in Datacenter Networks».{{cite web}}: CS1 maint: url-status (link)
^ ^a ^b ^c Gerhards, Rainer. The Syslog Protocol. doi:10.17487/RFC5424. RFC 5424.
^ «LXer: Patent jeopardizes IETF syslog standard».
^ «IETF IPR disclosure on HUAWEI’s patent claims».
^ «Syslog Facility». Retrieved 22 November 2012.
^ «The Ins and Outs of System Logging Using Syslog». SANS Institute.
^ ^a ^b ^c «syslog.conf(5) — Linux man page». Retrieved 2017-03-29.
^ ^a ^b ^c ^d ^e «closelog, openlog, setlogmask, syslog — control system log». Retrieved 2017-03-29.
^ «Severity Levels for Syslog Messages». docs.delphix.com. Retrieved 2021-08-16.
^ Gerhards, Rainer (March 2009). «RFC 5424 — The Syslog Protocol». doi:10.17487/RFC5424. This document describes a layered architecture for syslog. The goal of this architecture is to separate message content from message transport while enabling easy extensibility for each layer.
^ «Transmission of Syslog Messages over TCP». www.ipa.go.jp. Retrieved 2021-08-16.
^ Gerhards, Rainer (March 2009). «rfc5424». datatracker.ietf.org. Retrieved 2021-08-16.
^ «logger Command». www.ibm.com. Retrieved 2021-08-16.
^ «Syslog Server». www.howtonetwork.com. Retrieved 2021-08-16.{{cite web}}: CS1 maint: url-status (link)
^ Gerhards, Rainer (March 2009). «RFC 5424 — The Syslog Protocol». doi:10.17487/RFC5424.
^ Fuyou, Miao; Yuzhi, Ma; Salowey, Joseph A. (March 2009). Miao, F; Ma, Y; Salowey, J (eds.). «RFC 5425 — TLS Transport Mapping for Syslog». doi:10.17487/RFC5425.
^ «ATNA + SYSLOG is good enough». Healthcare Exchange Standards. 2 January 2012. Retrieved 2018-06-06.
^ Yamanishi, Kenji; Maruyama, Yuko (2005-08-21). «Dynamic syslog mining for network failure monitoring». Proceedings of the Eleventh ACM SIGKDD International Conference on Knowledge Discovery in Data Mining. KDD ’05. Chicago, Illinois, USA: Association for Computing Machinery: 499–508. doi:10.1145/1081870.1081927. ISBN 978-1-59593-135-1. S2CID 5051532.
^ «Security Issues in Network Event Logging (syslog)». IETF.

External links[edit]

Internet Engineering Task Force: Datatracker: syslog Working Group (concluded)
SANS Institute: «The Ins and Outs of System Logging Using Syslog» (white paper)
National Institute of Standards and Technology: «Guide to Computer Security Log Management» (Special Publication 800-92) (white paper)
Network Management Software: «Understanding Syslog: Servers, Messages & Security»
Paessler IT Explained — Syslog
MonitorWare: All about Syslog

Источник

Syslog — это стандарт для отправки и получения уведомлений в определенном формате от различных сетевых устройств. Сообщения включают временные метки, сообщения о событиях, серьезность, IP-адреса хостов, диагностику и многое другое. Что касается встроенного уровня серьезности, то он может передавать сообщения в диапазоне от уровня 0 — аварийный, уровня 5 — предупреждение, нестабильность системы, критический и уровней 6 и 7 — информационный и отладочный.

linux

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

Протокол Syslog был первоначально написан Эриком Оллманом и определен в RFC 3164. Сообщения отправляются через IP-сети на сборщики сообщений о событиях или серверы syslog. Syslog использует для связи протокол User Datagram Protocol (UDP), порт 514. Хотя серверы syslog не отправляют подтверждение о получении сообщений. С 2009 года syslog стандартизирован IETF в RFC 5424.

Содержание

Преимущества ведения журналов
Компоненты серверов Syslog
Как это работает
Серверы Syslog
Формат Syslog
Сообщения Syslog
Наиболее важные файлы журналов для отслеживания и мониторинга
Плюсы и минусы Syslog
Лучшие практики

Преимущества ведения журналов

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

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

Сокращение количества заявок на устранение неполадок
Сокращение времени простоя
Снижение количества перерывов в работе
Содействие профилактическому устранению неисправностей

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

Компоненты серверов Syslog

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

Слушатель Syslog — слушатель собирает и обрабатывает данные syslog, отправленные через UDP порт 514. Однако, получение подтверждения не предусмотрено, и поступление сообщений не гарантируется.
База данных — серверыyslog нуждаются в базах данных для хранения огромного количества данных для быстрого доступа.
Программное обеспечение для управления и фильтрации — поскольку объем данных может быть огромным, поиск определенных записей в журнале может занять слишком много времени. Серверу syslog требуется помощь для автоматизации работы, а также для фильтрации для просмотра определенных сообщений журнала. Для примера, он может извлекать сообщения на основе определенных параметров, таких как критическое событие или имя устройства. Вы также можете использовать фильтр, чтобы не видеть определенные типы записей с помощью правила Negative Filter. Если вы хотите, вы можете показать все критические сообщения журнала от брандмауэра.

Как это работает

В стандарте Syslog существует три различных уровня, а именно: Назначение сообщения Syslog

Содержание Syslog (информация, содержащаяся в сообщении о событии)
Приложение Syslog (генерирует, интерпретирует, маршрутизирует и хранит сообщения)
Транспорт Syslog (передает сообщения).

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

Аппаратные ошибки
Сбои в работе приложений
Потеря контакта
Неправильная конфигурация .

Кроме того, сигналы тревоги могут быть настроены на отправку уведомлений через SMS, всплывающие сообщения, электронную почту, HTTP и многое другое. Поскольку процесс автоматизирован, ИТ-команда получит немедленное уведомление о внезапном отказе любого из устройств.

Серверы Syslog

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

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

Сервер Kiwi Syslog Server. Этот сервер прост в установке и генерирует отчеты в виде обычного текста или HTML. Программное обеспечение обрабатывает Syslog и SNMP, даже с хостов Linux и UNIX. Он совместим с Win XP 32/64, Win 2003 32/64, Windows Vista 32/64, Win7 32/64, Windows 2008 R2 32/64, Windows 8, Windows Server 2012 & 2012 R2.
PRTG. Добавляет датчик к мониторингу PRTG для включения возможности Syslog. Он ориентирован на данные протоколов SNMP и Syslog. Он совместим с любой 64-разрядной средой Windows с Windows Server 2012 R2.
SNMPSoft Sys-log Watcher. Это специализированный сервер syslog для широкого спектра устройств. Он также может анализировать и управлять нестандартными Syslog. Он совместим с Windows XP до Windows 10.
Dude. Эта система используется для общего управления сетью со встроенным сервером syslog. Кроме того, она оснащена функцией удаленного протоколирования через RouterOS. Она совместима с Windows 2000 или более новыми версиями. Однако она также работает на Linux или MacOS с помощью Wine/Darwine.
Visual Syslog Server. Это более легкий вариант syslog, который рассматривает предупреждения в режиме реального времени. Пороговые значения могут быть настроены для запуска как скриптов, так и программ. Он совместим с Windows XP, Vista, 7, 8, 8.1, а также Windows Server 2003, 2008, 2012.
Datagram. Эта программа предлагает функциональность уровня предприятия. Она хорошо работает в больших средах. Она получает и хранит данные Syslog. Более того, она совместима с Windows 2000 и более новыми версиями.

Формат Syslog

Syslog имеет стандартное определение и формат сообщения журнала, определенный RFC 5424. В результате оно состоит из заголовка, структурированных данных (SD) и сообщения.

В заголовке вы увидите описание типа, например:

Приоритет (Priority)
Версия (Version)
Временная метка (Timestamp)
Имя хоста (Hostname)
Приложение (Application)
Идентификатор процесса (Process id)
Идентификатор сообщения (Message id)

Затем вы увидите структурированные данные, которые содержат блоки данных в формате «ключ=значение» в квадратных скобках. После SD вы увидите подробное сообщение журнала, которое закодировано в UTF-8.

Например, следующее сообщение:

<34>1 2022-08-18T10:14:15.003Z machine.example.com su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8

Соответствует следующему формату:

<priority>VERSION ISOTIMESTAMP HOSTNAME APPLICATION PID MESSAGEID STRUCTURED-DATA MSG

Сообщения Syslog

Сообщения Syslog используются для сообщения об уровнях «Авария» и «Предупреждение» в отношении программных или аппаратных проблем. Для примера, перезагрузка системы будет отправлена через уровень Notice. Перезагрузка системы будет передана через уровень Informational. Если выводятся отладочные команды, они передаются через уровень Debug.

Вот уровни сообщений Syslog:

Аварийные сообщения — система недоступна и непригодна для использования (может быть состояние «паники» из-за стихийного бедствия).
Тревожные сообщения — действия должны быть предприняты немедленно (пример — потеря резервного соединения с интернет-провайдером)
Критические сообщения — критические условия (это может быть потеря основного соединения с провайдером)
Сообщения об ошибках — условия ошибки (должны быть устранены в течение определенного периода времени)
Предупреждающие сообщения — условия предупреждения (указывает на возможность возникновения ошибки, если не принять меры)
Уведомляющие сообщения — все в норме, но это все еще значительное состояние (немедленные действия обычно не требуются)
Информационные сообщения-Информационные сообщения (для отчетности и измерений)
Отладочные сообщения — сообщения уровня отладки (предлагает информацию об отлаживаемых приложениях)

Наиболее важные файлы журналов для отслеживания и мониторинга

Мониторинг файлов журналов очень важен, поскольку он помогает справиться с любыми ошибками в работе вашей ОС. Некоторые типы релевантной информации, которую вы сможете получить, включают:

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

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

/var/log/messages — содержит большинство системных сообщений
/var/log/secure — сообщения аутентификации
/var/log/cron — Журнал регистрации действий задания Cron
/var/log/maillog — почтовые транзакции.

Если бы вы заглянули в /var/log/messages, вы бы обнаружили:

Метку времени
Имя хоста выполняющей программы
Имя утилиты, вызвавшей сообщение
Действие, которое было выполнено

Плюсы и минусы Syslog

Одним из проблемных сценариев является заполнение файла /var/log/messages из-за неправильной конфигурации журнала. Кроме того, бывают случаи, когда ведение журнала в системе приводит к непредвиденным проблемам. Вот почему необходимо понимать, как контролировать ведение журнала и где сохраняются журналы. Кроме того, при больших объемах сетевого трафика может происходить потеря пакетов.

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

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

Лучшие практики

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

Более того, во всех брандмауэрах между вами и UDP/514 нужно открывать только порт syslog. Если у вас географическая сеть, то вам следует иметь локальный логхост в каждом месте, который отправляет данные на центральный логхост.

Вы также можете повернуть файл журнала, когда он достигнет определенного размера. Тем не менее, утилита UNIX logrotate будет продолжать записывать информацию журнала в новый файл после ротации старого файла. Вот ключи, которые следует использовать:

/usr/sbin/logrotate — Команда logrotate
/etc/cron.daily/logrotate — сценарий оболочки, который ежедневно выполняет команду logrotate.
/etc/logrotate.conf — используется в качестве ротации журнала для всех записей журнала в этом файле
/etc/logrotate.d — для отдельных пакетов.

Чтобы ротировать файл журнала на каждый 1 КБ, используйте приведенный ниже logrotate.conf

$ cat logrotate.conf
/tmp/output.log {
size 1k
create 700 bala bala
rotate 4
}

Это дает вам три варианта:

size 1k-logrotate запускается только в том случае, если размер файла равен или больше этого размера
create- повернуть исходный файл и создать новый файл с настроенными пользователями, группами и разрешениями
rotate- сохраняет только последние четыре файла журнала.

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

Перебор файлов по отдельности сведет вас с ума. Вот несколько бесплатных и платных инструментов:

Retrace — один из инструментов разработчика Stackify и единственный инструмент разработчика, который объединяет APM, ошибки, метрики и мониторинг с протоколированием, чтобы обеспечить полностью интегрированный, многосредовой инструмент, который дает вам суперсилу производительности приложений.
Loggly — это облачный поставщик услуг управления и аналитики, который имеет бесплатный и платный тарифный план стоимостью от $49 в месяц. Благодаря их динамическому исследователю полей вы получаете обзор журналов с высоты птичьего полета. Он также включает в себя мощный полнотекстовый поиск.
GoAccess — это терминальный анализатор журналов, позволяющий просматривать статистику веб-сервера в режиме реального времени. Он также имеет открытый исходный код и бесплатен в использовании. Кроме того, он доступен на Github.
logz.io — у этого инструмента есть бесплатные и платные тарифные планы от $89 в месяц. Он имеет интерфейс на базе Kibana, который позволяет легко искать по миллионам записей. Вы также можете фильтровать результаты с помощью пользовательских параметров.
Splunk — это популярный инструмент, который существует с 2003 года. Он также поставляется в бесплатном и платном вариантах. Цена платного плана зависит от объема обрабатываемых вами данных. Кроме того, он поставляется с мощной системой сверления, которая позволяет вернуться в прошлое с помощью специальных запросов.
Logstash — это бесплатный инструмент с открытым исходным кодом для управления и сбора событий и журналов. Кроме того, вы можете использовать его вместе с Kibana.
AWStats — этот бесплатный инструмент анализа имеет сообщество из тысяч пользователей. Это связано с тем, что он позволяет создавать оптимизированные отчеты, а также экспортировать данные журналов в различных форматах для анализа в автономном режиме. Кроме того, его можно запустить практически на любой популярной платформе.
Deep Log Analyzer — этот инструмент может анализировать файлы журналов, созданные IIS и даже веб-сервером Apache. Удобный интерфейс позволяет создавать пользовательские отчеты. Вы также можете экспортировать разобранные данные в формат HTML или Excel.
BareTail — с помощью этого инструмента вы можете анализировать и читать информацию в режиме реального времени. Вы также можете подключиться к удаленному веб-серверу. Если вам нужно перейти к определенному моменту, вы можете сделать это немедленно.

Источник

Содержание

Система Syslog и журналы логов в Linux
Как устроена система регистрации событий?
log файлы и их расположение в Linux
Некоторые специальные файлы журналов
Использование syslog
Примеры настроек syslog.conf
Настройка syslog для iptables
ИТ База знаний
Полезно
Навигация
Серверные решения
Телефония
Корпоративные сети
Курс по сетям
Что такое Active Directory и LDAP?
Погружение в Iptables – теория и настройка
Ноу-хау: разбираемся в преимуществах виртуализации
Composer – Моцарт для вашего PHP
DevSecOps – кратко о том, как улучшить жизнь
HyperText Transfer Protocol (HTTP)
Syslog серверы
Syslog сообщения
Содержание
История
Компоненты сообщения
Средство
Уровень опасности
Сообщение
Регистратор
Сетевой протокол
Ограничения
Outlook
Стандартные документы Интернета
Перенаправление событий Windows (Event Log) на сервер syslog Linux
Вступление
Описание
Настройка
Заключение
Видео

Система Syslog и журналы логов в Linux

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

Как устроена система регистрации событий?

Опытные системные администраторы знают, что просматривать и анализировать журналы (файлы) регистраций необходимо регулярно и с особой тщательностью. Информация, содержащаяся в журналах очень часто помогает быстро решить возникающие неполадки или выявить скрытые проблемы в конфигурации системы. Для отслеживания событий системой, проверки журналов, учёта, хранения, архивирования и удаления информации из этих журналов должен быть разработан и утверждён специальный регламент для организации, эксплуатирующей и/или обслуживающей системы, серверы и сети.

Основным инструментом регистрации событий в UNIX и Linu до сих пор остаётся демон syslogd системы Syslog. Но следует иметь в виду также и то, что на протяжении длительного времени из-за многообразия всевозможных ответвлений UNIX и версий Linux множество программных пакетов, служебных скриптов, сетевых демонов используют свои собственные журналы, порой отличающимся экзотическим форматом.

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

Журналы регистрации легко просматривать, поскольку они являются обычными текстовыми файлами. Для эффективной работы с журналами используются самые стандартные инструменты из базовой поставки любого дистрибутива — команды cat и grep. Если нужно «ворошить» очень большие и сложные по формату журналы, то можно (и даже нужно) вместо утилиты grep использовать другой, гораздо более производительный и гибкий в подобных задачах инструмент — утилиту awk. Язык обработки текста Perl также очень хорошо подходит для этого.

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

В данном случае можно видеть, что в одном из журналов Syslog собраны события из нескольких источников: программы sbathd, pingem, pop-proxy. Также можно видеть, что события регистрируются для нескольких хостов, взаимодействующих с данной системой: backup, system, office и service.

log файлы и их расположение в Linux

Как уже отмечалось, в системах UNIX и Linux нет чётких соглашений о том, где и как должны храниться журналы регистрации. Они могут быть разбросаны хоть по всей файловой системе, поэтому для каждого администратора важно сразу разобраться, где и для каких пакетов и демонов находятся соответствующие файлы журналов. Но несмотря на отсутствие чётких формальных регламентов относительно мест хранения журналов, всё же существует традиционно сложившееся правило, что эти файлы должны находиться в каталогах /var/log, /var/log/syslog, а также в /var/adm.

Как правило, доступ для чтения файлов в указанных каталогах предоставляется только суперпользователю, однако нет ничего страшного, если для часто просматриваемых журналов, в которых также нет важной системной информации настроить более «демократический» режим доступа. Обычно к такому варианту также прибегают для удобства и экономии времени, когда нужно часто и регулярно изучать некоторые журналы, например для веб-сервера Apache, которые обычно находятся в /var/log/apache2 или /var/log/httpd.

Стоит также помнить и о том, что бывают случаи, когда (особенно на сбойных конфигурациях) общий объём файлов журналов резко увеличивается, при этом велик риск «уложить» систему. Для удобства контроля за свободным пространством на устройствах хранения, а также для надёжности каталог /var часто выносят в отдельную файловую систему на отдельном разделе.

Некоторые специальные файлы журналов

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

Файл	Программа	Место	Частота	Системы	Назначение
acpid	acpid	Ф	64к	RZ	События, связанные с системой питания
auth.log	sudo и прочие	S	М	U	Информация об авторизации
apache2/*	httpd или apache2	Ф	Д	ZU	Журналы веб-сервера Apache
apt*	APT	Ф	М	U	Установщики пакетов
boot.log	Сценарии запуска системы	Ф	М	R	Логи сценариев запуска
boot.msg	Ядро	В	—	Z	Образ буфера сообщений ядра
cron, cron/log	cron	S	Н	RAH	Логи и сведения о работе демона cron
cups/*	CUPS	Ф	Н	ZRU	Сообщения, связанные с системой печати (CUPS)
daemon.log	Разное	S	Н	U	Сообщения средств демонов
debug	Разное	S	Д	U	Сообщения для отладки
dmesg	Ядро	В	—	RU	Образ буфера сообщений ядра
dpkg.log	dpkg	Ф	М	U	Установщики пакетов
faillog	login	Н	Н	RZU	Информация о неудачных попытках авторизации
apache2/*	Httpd или apache2	Ф	Д	R	Журналы веб-сервера Apache для каталога /etc
kern.log	login	В	—	RZ	Все сообщения средств ядра
lastlog	login	В	—	RZ	Время последней регистрации в системе каждого пользователя (этот файл бинарный)
mail*	Программы электронной почты	S	Н	Все	Сообщения средств электронной почты
messages	Разное	S	Н	RZUS	Основной системный журнальный файл
rpmpkgs	cron.daily	В	Д	R	Список установленных RPM-пакетов
samba/*	smbd и прочие	Ф	Н	—	Сведения о работе сервера Samba
secure	sshd и прочие	S	М	R	Конфиденциальные авторизационные сообщения
sulog	su	Ф	—	SAH	Сведения об удачных и неудачных попыток использования команды su
syslog*	Разное	S	H	SUH	Основной системный журнальный файл
warn	wpar	S	H	Z	События уровня системных предупреждений/ошибок
wpars/*	wpar	Ф	—	А	Сведения о событиях загрузочных разделов
wtmp	login	В	M	Все	Сообщения о регистрации в системе (бинарный файл)
xen/*	Xen	Ф	1m	RZU	Информация от монитора виртуальных машин Xen
Xorg.n.log	Xorg	Ф	Н	RS	Сообщения об ошибках сервера X Windows
yum.log	yum	Ф	М	R	Журнал управления пакетом

Для данной таблицы действуют следующие обозначения: S — Syslog, В — встроенное имя, Ф — конфигурационный файл, Д — ежедневно, Н — еженедельно, М — ежемесячно, NN[km] — размер в килобайтах или мегабайтах, Z — SUSE, R — Red Hat и CentOS, S — Solaris, H — HP-UX, A — AIX. В столбце «Частота» указывается частота, с которой удаляется устаревшая информация, связанная со временем или с объёмом файла. В столбце «Программа» указывается программа, создающая файл.

Следует отметить также, что большая часть сообщений для представленных в таблице файлов направляется в систему Syslog. Уровень критичности и программа, создающая файл задаются в конфигурационном файле /etc/initlog.conf. — так работает система Syslog. Файл faillog является двоичным, и поэтому может быть прочтён утилитой failog.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Использование syslog

Протокол syslog прост: отправитель посылает короткое текстовое сообщение, размером меньше 1024 байт получателю сообщения. Получатель при этом носит имя «syslogd», «syslog daemon», либо же, «syslog server». Сообщения могут отправляться как по UDP, так и по TCP. Как правило, такое сообщение отсылается в открытом виде. Тем не менее, используя специальные средства (такие, как Stunnel, sslio или sslwrap), возможно шифрование сообщений и отправка их по SSL сертификаты для для сайта, почты/TLS. Syslog используется для удобства администрирования и обеспечения информационной безопасности. Он реализован под множество платформ и используется в множестве устройств. Поэтому, использование syslog позволяет обеспечить сбор информации с разных мест и хранение её в едином репозитории.

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

Примеры настроек syslog.conf

Файл syslog.conf служит для настройки протокола Использование syslog. После любых изменений в конфигурационном файле демон syslogd должен быть перезапущен, например так

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

Настройка syslog для iptables

По умолчанию Правила iptables логи записывает в журналы /var/log/messages, /var/log/syslog, и /var/log/kern.log. Настроим протоколирование iptables в отдельный файл iptables.log. Уровень протоколирования выбран –log-level INFO

Алгоритм изменений syslog:

Для удобства введем общий префикс IPT: для правил iptables. По этому префиксу демон syslog будет определять что эта искомая строка и запишет согласно правилу в нужный нам файл iptables.log.

Создадим правила в /etc/rsyslog.d/iptables.conf

говорит о том что дальнейшую обработку записи производить не надо, следовательно она не попадет в другие файлы логов «IPT: » — log-prefix — критерий с которого начинается запись лога, чтобы rsyslog смог ее отловить и перенаправить в нужный файл. Его можно сделать разным для каждого правила, но если правило не одно, то удобнее иметь общий префикс для всех правил. /var/log/iptables.log — файл в который писать лог. rsyslogd Property-Based Filters

Крупнейшая в Европе школа английского языка

Промокоды, акции и подарки, чтобы Ваше обучение было не только интересным, но и выгодным. Закажите пробный урок уже сейчас!

Онлайн школа английского языка

Английский по скайпу от 680р за урок, без заучивания правил. Эффективно! Удобно! Выгодно! Начните обучение прямо сейчас.

Школа английского языка по Skype

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

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Курс по сетям

Что такое Active Directory и LDAP?

Погружение в Iptables – теория и настройка

Ноу-хау: разбираемся в преимуществах виртуализации

Composer – Моцарт для вашего PHP

DevSecOps – кратко о том, как улучшить жизнь

HyperText Transfer Protocol (HTTP)

Еженедельный дайджест

Обучайся в Merion Academy

Пройди курс по сетевым технологиям

Большинство сетевых устройств, таких как маршрутизаторы и коммутаторы, могут отправлять сообщения системного журнала. Кроме того, серверы *nix также могут генерировать данные системного журнала, как и большинство брандмауэров, некоторые принтеры и даже веб-серверы, такие как Apache. Серверы на базе Windows изначально не поддерживают Syslog, но большое количество сторонних инструментов позволяет легко собирать данные журнала событий Windows или IIS и пересылать их на сервер Syslog.

Syslog серверы

Syslog сообщения

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

Системный журнал использует концепцию, называемое “facility”, чтобы идентифицировать источник сообщения на любом компьютере. Например, facility “0” будет сообщением ядра, а facility «11» будет сообщением FTP. Это восходит своими корнями к syslog’а UNIX. В большинстве сетевых устройств Cisco используются коды объектов «Local6» или «Local7».

0	Emergency	Система не работоспособна
1	Alert	Система требует немедленного вмешательства
2	Critical	Состояние системы критическое
3	Error	Сообщения об ошибках
4	Warning	Предупреждения о возможных проблемах
5	Notice	Сообщения о нормальных, но важных событиях
6	Informational	Информационные сообщения
7	Debug	Отладочные сообщения

Недостатки syslog

У протокола syslog есть несколько недостатков.

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

Несмотря на это, многие администраторы считают, что syslog является ценным инструментом, и что его недостатки относительно незначительны.

Источник

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

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

Содержание

История

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

Компоненты сообщения

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

Средство

Код средства используется для указания типа программы, которая регистрирует сообщение. Сообщения с разными возможностями могут обрабатываться по-разному. Перечень имеющихся объектов определен стандартом:

Сопоставление кода объекта и ключевого слова неодинаково в разных операционных системах и реализациях системного журнала.

Уровень опасности

Список степени серьезности также определен стандартом:

Ценить	Строгость	Ключевое слово	Устаревшие ключевые слова	Описание	Условие
0	Чрезвычайная ситуация	emerg	panic	Система непригодна для использования	Состояние паники.
1	Тревога	alert	Действия должны быть предприняты немедленно	Состояние, которое следует исправить немедленно, например повреждение системной базы данных.
2	Критический	crit	Критические условия	Ошибки жесткого устройства.
3	Ошибка	err	error	Условия ошибки
4	Предупреждение	warning	warn	Условия предупреждения
5	Уведомление	notice	Нормальные, но важные условия	Условия, которые не являются ошибочными, но могут потребовать особой обработки.
6	Информационная	info	Информационные сообщения
7	Отлаживать	debug	Сообщения уровня отладки	Сообщения, которые содержат информацию, обычно используемую только при отладке программы.

Сообщение

Регистратор

Сетевой протокол

При работе по сети syslog использует архитектуру клиент-сервер, в которой сервер прослушивает хорошо известный или зарегистрированный порт для запросов протокола от клиентов. Исторически наиболее распространенным протоколом транспортного уровня для ведения сетевых журналов был протокол дейтаграмм пользователя (UDP), при этом сервер прослушивал порт 514. Поскольку в UDP отсутствуют механизмы контроля перегрузки, в реализациях требуется поддержка Transport Layer Security, которая рекомендуется для общего использования при передаче Порт протокола управления (TCP) 6514.

Ограничения

Outlook

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

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

Стандартные документы Интернета

Протокол системного журнала определяется документами запроса комментариев (RFC), опубликованными инженерной группой Интернета ( стандарты Интернета ). Ниже приведен список RFC, определяющих протокол системного журнала:

Источник

Перенаправление событий Windows (Event Log) на сервер syslog Linux

Вступление

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

В ней описывается простой и надежный способ (даже скорее простая и надежная сторонняя утилита) для передачи системных событий из Event Log’ов серверов на базе Windows в Linux syslog для удобства централизованного хранения и обработки.

Реалии таковы, что в нынешней корпоративной среде самое эффективное и надежное решение основывается на смешении серверных операционных систем из-за качества и способов решаемых ими задач. Рабочие станции, и, следовательно, групповое ими управление и администрирование проще делать на Active Directory; веб сервер, прокси сервер надежнее поставить на линукс; роутером быстрее сделать что-то из Cisco. Эта объективная реальность, с которой работают администраторы многих средних компаний (особенно знакомые с линуксом, от винды так или иначе им все равно не уйти и зачастую в фирме стоят домен-контроллеры на винде и прокси-сервер и роутер на линуксе) — в мелких фирмах можно обойтись одной виндой, в крупной фирме скорее всего раздельно существует администратор линуксоид и администратор виндузятник умело отвечающие за свои сектора. Так или иначе, эта статья не теоретизирование и не исследование на эту тему, эта статья про конкретную задачу, которая практически всегда приходит в голову любому администратору работающему в таком окружении, а вступление что-то затянулось.

Описание

Каждый работающий с серверами знает и ежедневно пользуется системой логов на своих машинах и каждый знает как они устроены — syslog на Linux и Event Log на винде.

До эры Windows Server 2008 Event Log был странной системой созданной как-будто не для серверов — каждый компьютер писал и хранил свои события локально и удобных механизмов для передачи их по сети для централизованного просмотра или хотя бы хранения не было вообще. Ну, впрочем, всем это известно. Просмотр логов для серверов напоминал квест в MMORPG — исследуй несколько локаций и собери несколько предметов в каждой. Начиная с Windows Vista был сделан шаг навстречу людям и создана система форварда локальных событий на другие Windows >Vista компьютеры. Это хорошо и прогрессивно и это именно то чего не хватало, но реальность такова что на данный момент осталось и не устарело много серверов с Windows 2003 для которых таких механизмов так и нет или они есть, но отталкивают своей монстроузной реализацией.

С другой стороны существует простая и надежная система syslog для Linux которая изначально разработана для распределённой передачи и приёма логов и содержит в себе всё что для этого необходимо. Она настолько хорошо делает своё дело что возможность отправлять логи по этому протоколу встраивают и в хардварные роутеры и в кучу разных других устройств и вполне реально сделать в сети сервер который будет собирать все логи со всех устройств в сети: серверов, роутеров, коммутаторов, принт-серверов, кофеварок, кулеров, ой что-то я разошелся… Кроме Windows. Врядли найдётся человек которому не приходила в голову мысль что если бы Windows мог отправлять свои логи в syslog это было бы идеальным решением для централизации логохранилища. Как удобно было бы все иметь в одном месте — можно было бы и хранить годами, архивируя текстовые файлы (они отлично ужимаются), и обрабатывать, разбирая один текстовый файл от нескольких серверов вылавливая одно критическое событие сразу для нескольких машин.

Задался таким вопросом и я. Задался я им несколько лет назад и потерпел неприятное фиаско — утилит позволяющих это сделать-то довольно много, но выглядят они все как кошмар профессионального администратора — какие-то ужасные утилиты иногда на C# размеров в 100 мегабайт с тысячей кнопочек и чекбоксов и что самое неприятно — _все платные_. Не знаю в чем прикол, но несколько лет назад Google был переполнен ссылками на коммерческий софт с таким функционалом. При этом софт не высокого качества, судя по стремным сайтам и скриншотам. Переполнен он ими и сейчас, и, по моим собственным наблюдениям, многие отнюдь не ленивые и не тупые администраторы способные с успехом для собственного удобства использовать такой функционал так и не нашли того что им нужно и не знают что такое бывает. По крайней мере за мой совет и ссылку меня не раз благодарили, и теперь я хотел бы поделиться и с вами. А именно некоторое время назад (довольно давно, это статью я решил написать только сейчас), мне удалось найти проект идеально подходящий под мои нужды и требования:

Добавлю от себя что во-первых вот уже полгода как эта программа на 8-ми моих серверах и 2003 и 2008 просто работает, после установки я _ни разу_ ни на одном из них не проверял, не перезапускал обвалившийся, не ковырял, не изменял и даже не смотрел в сторону этого сервиса, который так же никак не повлиял ни на одно другое приложение, он просто делает своё дело после установки — безустанно шлёт эвенты туда куда ему сказали. А во-вторых что программа очень динамично развивалась не так давно набирая функционал, после чего стабилизировалась и теперь достаточно регулярно, но не слишком часто, выходят билды которые причесывают функционал и фиксят мелкие редковоспроизводимые баги.

Перейдём к ещё большей конкретике.

Настройка

Затем вам наверняка не очень понравится если логи линуксов, роутеров и винды будут смешиваться в одном файле и превращаться в трудновоспринимаемую кашу. Для этого в системе syslog есть несколько разделов (facility) и приходящие на отдельные facility сообщения можно писать в разные файлы. Так как логи от винды не особо подходят ни под kernel, ни под mail, специально для этого в syslog есть несколько “безличных” facility которые называются local. Чтобы вынести например local1 в отдельный файл надо добавить в /etc/syslog.conf строку:

ну и запомнить что это local под номером 1. точно так же можно разделить остальные local от local0 до local7.
Обращаю ваше внимание что это простейшая конфигурация syslog которая позволит просто складывать логи от винды в отдельный файл, тонкая конфигурация syslog позволяет довольно замысловато распределить сообщения приходящие к демону, но всё это описано в мануале к syslog и скорее всего известно любому знакомому с линуксом администратору.
Установка evtsys на Windows.

Параметры evtsys.exe:
-i Установить сервис
-u Удалить сервис
-d Дебаг. Запуститься как консольная программа
-h host Имя хоста куда отправлять логи
-b host Имя второго хоста кому дублировать логи
-f facility Facility логов
-l level Минимальный уровень отсылаемых сообщений
0=Всё, 1=Критические, 2=Ошибки, 3=Предупреждение, 4=Информация
-n Отправлять только эвенты включенные в конфиге
-p port Номер порта syslog
-q bool Опросить DHCP чтобы получить имя хоста syslog и порт
(0/1 = включить/выключить)
-s minutes Интервал между сообщениями. 0 = Отключить

0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)

Если вы хотите исключить какое-то событие из отправки в syslog, например огромную кучу мусора появляющуюся по поводу каждого подключения к компьтеру по сети в разделе Security, можете создать файл (или открыть, если уже запустили сервис) %WINDIR%System32evtsys.cfg и забить в него события которые вас не интересуют в формате EventSource:EventID. Например строка “Security-Auditing:*” полностью отключит отправку раздела Security на Windows >Vista, строка “Security-Auditing:4624” отключит отправку только события с кодом 4624 (интерактивный доступ из сети к компьютеру, браузинг его кем-то из сети). Грустная ирония такова что при разработке нового Event Log’а для нового поколения серверных ОС Микрософт полностью сменила названия разделов и коды, а так же переписала и стандартные сообщения и вообще все события, так что на поколении Windows 2003 и поколении Windows 2008 названия разделов и номера событий будут кардинально различаться. Впрочем зачастую у них будет одинаковый смысл. Какое событие что значит и какие у них названия и номера удобно узнавать с сайта http://www.eventid.net/.

После чего можно открывать список сервисов Windows и запускать сервис под названием “Eventlog to Syslog” и логи начнут появляться в файле на сервере с syslogd примерно в таком виде:

Заключение

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

Для себя я написал на perl зацикленный парсер идущего лога который из всё-таки не совсем удобочитаемой простыни лога:
а) выкусывает события которые меня не интересуют: например всё те же обращения к компьютеру из сети (любой браузинг в сети одного компа вызывает на всех компах которые он у себя в сетевом окружении увидит сообщение об этом, а это реально большая куча сообщений на серверах, особенно если сразу с нескольких). У меня ушёл всего один день на то чтобы создать список таких “не интересующих меня” событий.
б) подкрашивает события которые меня интересуют и переводит их из технического вида в человеческий, например логин на сервер по RDP окрашивается синим и пишется не полная строка из лога, навроде той что я привёл выше из которой ещё надо понять кто на ком стоял, а в виде “Remote login by ‘xxx’ (ip: x.x.x.x) to ‘XXX’”.

В результате чего я получил консольную утилиту в которой то что меня интересует всегда выделенно, а всё что произошло кроме этого будет написано так что это реально разобрать, понять и быстро отреагировать. Можно просто изредка посматривать на протяжении дня на консоль в которой довольно редко появляется текст, зато если что-то пойдёт — это сразу можно поймать. Например недавно у меня начал подходить к концу пул DHCP, и я сразу узнал об этом увидев в консоли сообщение от DHCP (стоящем на домен контроллере) о том что DHCP-pool is 90% full, а не придя на работу через два-три дня и узнав что кто-то не может попасть в сеть.

Кроме того, утилита позволяет записывать в базу те события которые я хочу хранить и как-то обрабатывать.
Например недавно тут (на хабре) была статья о том как сделать статистику того, кто что распечатал, с дикой чехардой по SNMP. В моем же случае эта незначительная проблема входящая в общую решаемую задачу централизированного логирования, если принтер подключен к серверу и расшарен, и на нём включено логирование того что напечатано, не просто решается, а решается более чем полно. Ведь в логи кроме количества страниц и ip адреса, пишется:

— кто распечатал (логин)
— имя документа

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

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

Источник

Видео

LPIC 108.2 часть первая. Журналирование событий: syslog

Как настроить протокол syslog: эффективное журналирование событий на Cisco IOS

01-Graylog. Обзор. Центральный лог сервер для Linux и Windows отчетов.

Логи Linux. Всё о логах и журналировании

Сбор журналов событий с Windows и Unix систем

Управляем журналами событий и syslog с NetWrix Event Log Manager

Настройка устройств FTD для отправки системного журнала в Splunk

Rsyslog — сервис управления логами

LPIC 108.2 часть пятая. Журналирование событий: syslog-ng

LPIC 108.2 часть четвертая. Журналирование событий: rsyslog

Источник

IT Explained:

What is Syslog?

Syslog stands for System Logging Protocol and is a standard protocol used to send system log or event messages to a specific server, called a syslog server. It is primarily used to collect various device logs from several different machines in a central location for monitoring and review.

The protocol is enabled on most network equipment such as routers, switches, firewalls, and even some printers and scanners. In addition, syslog is available on Unix and Linux based systems and many web servers including Apache. Syslog is not installed by default on Windows systems, which use their own Windows Event Log. These events can be forwarded via third-party utilities or other configurations using the syslog protocol.

Syslog is defined in RFC 5424, The Syslog Protocol, which obsoleted the previous RFC 3164.

Syslog components

On any given device various events are generated by the system in response to changing conditions. These events are typically logged locally where they can be reviewed and analyzed by an administrator. However, monitoring numerous logs over an equally numerous number of routers, switches, and systems would be time consuming and impractical. Syslog helps solve this issue by forwarding those events to a centralized server.

Syslog transmission

Traditionally, Syslog uses the UDP protocol on port 514 but can be configured to use any port. In addition, some devices will use TCP 1468 to send syslog data to get confirmed message delivery.

Syslog packet transmission is asynchronous. What causes a syslog message to be generated is configured within the router, switch, or server itself. Unlike other monitoring protocols, such as SNMP, there is no mechanism to poll the syslog data. In some implementations, SNMP may be used to set or modify syslog parameters remotely.

The syslog message format

The syslog message consists of three parts: PRI (a calculated priority value), HEADER (with identifying information), and MSG (the message itself).

The PRI data sent via the syslog protocol comes from two numeric values that help categorize the message. The first is the Facility value. This value is one of 15 predefined values or various locally defined values in the case of 16 to 23. These values categorize the type of message or which system generated the event.

Number	Facility description
0	Kernel messages
1	User-level messages
2	Mail System
3	System Daemons
4	Security/Authorization Messages
5	Messages generated by syslogd
6	Line Printer Subsystem
7	Network News Subsystem
8	UUCP Subsystem
9	Clock Daemon
10	Security/Authorization Messages
11	FTP Daemon
12	NTP Subsystem
13	Log Audit
14	Log Alert
15	Clock Daemon
16 — 23	Local Use 0 — 7

The second label of a syslog message categorizes the importance or severity of the message in a numerical code from 0 to 7.

Code	Severity	Description
0	Emergency	System is unusable
1	Alert	Action must be taken immediately
2	Critical	Critical conditions
3	Error	Error conditions
4	Warning	Warning conditions
5	Notice	Normal but significant condition
6	Informational	Informational messages
7	Debug	Debug-level messages

The values of both labels do not have hard definitions. Thus, it is up to the system or application to determine how to log an event (for example, as a warning, notice, or something else) and on which facility. Within the same application or service, lower numbers should correspond to more severe issues relative to the specific process.

The two values are combined to produce a Priority Value sent with the message. The Priority Value is calculated by multiplying the Facility value by eight and then adding the Severity Value to the result. The lower the PRI, the higher the priority.

(Facility Value * 8) + Severity Value = PRI

In this way, a kernel message receives lower value (higher priority) than a log alert, regardless of the severity of the log alert. Additional identifiers in the packet include the hostname, IP address, process ID, app name, and timestamp of the message.
The actual verbiage or content of the syslog message is not defined by the protocol. Some messages are simple, readable text, others may only be machine readable.

Syslog messages are typically no longer than 1024 bytes.

Example of a syslog message

<165>1 2017-05-11T21:14:15.003Z mymachine.example.com appname[su] - ID47 [[email protected] iut="3" eventSource=" eventID="1011"] BOMAn application log entry...

Parts of the syslog message:

Part	Value	Information
PRI	165	Facility = 20, Severity = 5
VERSION	1	Version 1
TIMESTAMP	2017-05-11T21:14:15.003Z	Message created on 11 May 2017 at 09:14:15 pm, 3 milliseconds into the next second
HOSTNAME	mymachine.example.com	Message originated from host «mymachine.example.com»
APP-NAME	su	App-Name: «su»
PROCID	—	PROCID unknown
MSGID	ID47	Message-ID: 47
STRUCTURED-DATA	[[email protected] iut=»3″ eventSource=» eventID=»1011″]	Structured Data Element with a non-IANA controlled SD-ID of type «[email protected]», which has three parameters
MSG	BOMAn application log entry…	BOM indicates UTF-8 encoding, the message itself is «An application log entry…»

The Syslog Server

The Syslog Server is also known as the syslog collector or receiver.

Syslog messages are sent from the generating device to the collector. The IP address of the destination syslog server must be configured on the device itself, either by command-line or via a conf file. Once configured, all syslog data will be sent to that server. There is no mechanism within the syslog protocol for a different server to request syslog data.

While most Unix implementations and network vendors, like Cisco, have their own barebones syslog collectors, there are several others available as well.

Paessler’s PRTG monitoring software offers a built-in Syslog Receiver Sensor. The receiver collects all Syslog messages delivered. To use the function, the administrator needs to add the Syslog Receiver and then configure the IP address of that server as the destination server for syslog data on all devices to be monitored.

Once gathered, the dashboard shows:

The number of received syslog messages per second.
The number of messages categorized as “warning” per second.
The number of messages categorized as “error” per second.
The number of dropped packets per second.

The syslog protocol can generate a lot of messages. Syslog simply forwards messages as quickly as it generates them. As a result, the most important ability for a syslog server is the ability to properly filter and react to incoming syslog data.

The PRTG Syslog Receiver Sensor offers the ability to set filtering rules. These rules allow syslog messages to be included or excluded as warnings or errors, regardless of how they were originally generated on the device. This filtering ensures that administrators get notified about all the errors they want to know about without being overwhelmed by less important errors.

Security

The syslog protocol offers no security mechanism. There is no authentication built-in to ensure that messages are coming from the device claiming to be sending them. There is no encryption to conceal what information is being sent to the server. It is particularly susceptible to so-called “playback attacks” where an attacker generates a previous stream of warnings to illicit a response.

Syslog design

Device configuration

Most syslog implementations are configurable with respect to which facilities and which severity numbers will generate syslog events that are forwarded to the syslog server. It is important to configure this properly to avoid flooding the server (and the network) with unnecessary traffic. For example, Debug should never be set to send messages except during testing.

It is advisable to set the syslog parameters to require the highest possible (lowest numbered) facility and severity to minimize traffic. While a router error might indicate that an interface is down and thus definitely needs to be reported, a less important network printer might be configured to only generate syslog traffic for critical events.

Windows

Windows systems do not implement syslog within the standard Event Log system. The events generated within the Windows logging system can be gathered and forwarded to a syslog server using third-party utilities. These utilities monitor the Event Log, use the information to create a syslog formatted event, and forward the events using the standard syslog protocol.

Limitations

One major limitation of the syslog protocol is that the device being monitoring must be up and running and connected to the network to generate and send a syslog event. A critical error from the kernel facility may never send an error at all as the system goes offline. In other words, syslog is not a good way to monitor the up and down status of devices.

Syslog usage

While syslog is not a good way to monitor the status of networked devices, it can be a good way to monitor the overall health of network equipment. While network monitoring software like PRTG offers a suite of utilities to watch over a network, nothing tells an administrator that there is a problem faster than an event log filling up with warnings. Properly configured syslog monitoring will detect the sudden increase in event volume and severity, possibly providing notice before a user-detectable problem occurs.

Security/authorization/auditing

The average corporate network contains numerous devices that no one should be trying to gain access to on an average day. If a remote switch that only gets logged into once per audit cycle suddenly has daily login attempts (successful or otherwise), it bears checking out. On these types of devices, syslog can be set to forward authentication events to a syslog server, without the overhead of having to install and configure a full monitoring agent.

Syslog also provides a way to ensure that critical events are logged and stored off the original server. An attacker’s first effort after compromising a system is to cover the tracks left in the log. Events forwarded via syslog will be out of reach.

Application monitoring

There are plenty of ways to monitor how an application is running on a server. However, those monitors can overlook how the application is affecting other processes on the server. While high CPU or memory utilization is easy enough to detect with other monitors, logged events can help show more possible issues. Is an application continuously trying to access a file that is locked? Is there an attempted database write generating an error? Events like these may go undetected when caused by applications that do a good job of working around errors, but they shouldn’t be ignored. Syslog will make sure those logged events get the attention they deserve.

Syslog as part of overall network monitoring

Complete network monitoring requires using multiple tools. Syslog is an important pillar in network monitoring because it ensures that events occurring without a dramatic effect do not fall through the cracks. Best practice is to use a software that combines all the tools to always have an overview of what is happening in the network.

References

Источник

Если вы системный администратор или просто обычный пользователь Linux, есть очень большая вероятность, что вы хотя бы однажды работали с Syslog.

В вашей системе Linux практически все, что связано с протоколированием системы, связано с протоколом Syslog.

Разработанный в начале 80-х годов Эриком Оллманом (из университета Беркли), протокол syslog – это спецификация, определяющая стандарт для регистрации сообщений в любой системе.

Да… на любой системе.

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

Если вы хотите узнать больше о syslog и о протоколировании в Linux в целом, это руководство, которое вам стоит прочитать.

Здесь собрано все, что вам нужно знать о Syslog.

Содержание

Какова цель Syslog?
Что такое архитектура Syslog?
Какой формат сообщений Syslog?
Что такое уровни объектов Syslog?
Что такое уровни серьезности Syslog?
Что такое часть PRI?
Что такое часть HEADER?
Как работает доставка сообщений Syslog?
Что такое пересылка syslog?
Syslog использует TCP или UDP?
Каковы текущие реализации Syslog?
Заключение

Какова цель Syslog?

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

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

В дальнейшем логи могут быть проанализированы и визуализированы на серверах, называемых Syslog-серверами.

Вот еще несколько причин, по которым протокол syslog был разработан в первую очередь:

Определение архитектуры: это будет подробно описано позже, но если syslog является протоколом, то он, вероятно, будет частью полной сетевой архитектуры, с множеством клиентов и серверов. Как следствие, нам необходимо определить роли, короче говоря: вы собираетесь получать, производить или передавать данные?
Формат сообщений: syslog определяет способ форматирования сообщений. Очевидно, что это необходимо стандартизировать, поскольку журналы часто анализируются и хранятся в различных системах хранения. Как следствие, нам необходимо определить, что клиент syslog сможет производить и что сервер syslog сможет получать;
Определение надежности: syslog должен определить, как он обрабатывает сообщения, которые не могут быть доставлены. Будучи частью стека TCP/IP, syslog, очевидно, будет иметь мнение о том, какой сетевой протокол (TCP или UDP) выбрать;
Работа с аутентификацией или подлинностью сообщений: syslog нужен надежный способ убедиться, что клиенты и серверы общаются безопасным способом и что полученные сообщения не изменены.

Теперь, когда мы знаем, зачем вообще нужен Syslog, давайте посмотрим, как работает архитектура Syslog.

Что такое архитектура Syslog?

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

Некоторые из них будут генерировать сообщения журнала, и они будут называться “устройствами” или “клиентами syslog”.

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

Наконец, есть несколько экземпляров, которые будут получать и хранить данные логов, они называются “коллекторами” или “серверами syslog”.

Зная эти понятия, мы уже можем утверждать, что автономная машина Linux сама по себе действует как “клиент-сервер syslog”: она производит данные журнала, они собираются rsyslog и сохраняются прямо в файловой системе.

Вот набор примеров архитектуры, основанной на этом принципе.

В первом примере у вас есть одно устройство и один коллектор.

Это самая простая форма архитектуры ведения логов.

Добавьте еще несколько клиентов в вашу инфраструктуру, и вы получите основу архитектуры централизованного протоколирования.

📜 Настройка централизованного сервера логов с помощью Rsyslog в CentOS / RHEL 8

Несколько клиентов производят данные и отправляют их на централизованный сервер syslog, который отвечает за агрегацию и хранение данных клиентов.

Если мы хотим усложнить нашу архитектуру, мы можем добавить “релей”.

Примерами ретрансляторов могут быть, например, экземпляры Logstash, но они также могут быть правилами rsyslog на стороне клиента.

Эти релеи в большинстве случаев действуют как “маршрутизаторы на основе содержимого”

Это означает, что на основе содержимого журнала данные будут перенаправлены в разные места.

Данные также могут быть полностью отброшены, если они вас не интересуют.

Теперь, когда мы подробно рассмотрели компоненты Syslog, давайте посмотрим, как выглядит сообщение Syslog.

Какой формат сообщений Syslog?

Формат syslog делится на три части:

Часть PRI: в которой подробно описываются уровни приоритета сообщения (от отладочного сообщения до экстренного), а также уровни средств (mail, auth, core);
Часть HEADER: состоит из двух полей – TIMESTAMP и HOSTNAME, имя хоста – это имя машины, которая отправляет лог;
часть MSG: эта часть содержит фактическую информацию о произошедшем событии. Она также делится на поле TAG и поле CONTENT.

Перед тем как подробно описать различные части формата syslog, давайте кратко рассмотрим уровни серьезности syslog, а также уровни объектов syslog.

Что такое уровни объектов Syslog?

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

По умолчанию некоторые части вашей системы имеют уровни объектов, например, ядро использует объект kern, или ваша почтовая система использует объект mail.

Если сторонний пользователь хочет выпустить журнал, он, вероятно, будет использовать зарезервированный набор уровней объектов с 16 по 23, называемый “локальным использованием”.

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

Короче говоря, если мой сервер Apache запущен пользователем “apache”, то журналы будут храниться в файле под названием “apache.log” (<user>.log).

Ниже приведены уровни Syslog, описанные в таблице:

Числовой код	Ключевое слово	Название объекта
0	kern	Сообщения ядра
1	user	Сообщения на уровне пользователя
2	mail	Почтовая система
3	daemon	Системные демоны
4	auth	Сообщения о безопасности
5	syslog	Сообщения Syslogd
6	lpr	Подсистема линейного принтера
7	news	Подсистема сетевых новостей
8	uucp	Подсистема UUCP
9	cron	Часовой демон
10	authpriv	Сообщения о безопасности
11	ftp	FTP демон
12	ntp	Подсистема NTP
13	security	Аудит журнал безопасности
14	console	Предупреждения журнала консоли
15	solaris-cron	Журналы планирования
16-23	local0 to local7	Объекты местного использования

В системе Linux, по умолчанию, файлы разделяются по имени объекта, что означает, что у вас будет файл для auth (auth.log), файл для ядра (kernel.log) и так далее.

Пример на Kali Linux:

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

Что такое уровни серьезности Syslog?

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

Аналогично уровням объектов Syslog, уровни серьезности делятся на числовые категории от 0 до 7, причем 0 – это самый критический аварийный уровень.

Ниже приведены уровни серьезности Syslog, описанные в таблице:

Значение	Серьезность	Ключевое слово
0	Emergency	`emerg`
1	Alert	`alert`
2	Critical	`crit`
3	Error	`err`
4	Warning	`warning`
5	Notice	`notice`
6	Informational	`info`
7	Debug	`debug`

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

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

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

Что такое часть PRI?

Часть PRI – это первая часть, которую вы сможете прочитать в сообщении формата syslog.

PRI хранит “Значение приоритета” между угловыми скобками.

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

Запомните это, если вы захотите расшифровать сообщение syslog в будущем.

Как уже говорилось, часть HEADER состоит из двух важнейших данных: части TIMESTAMP и части HOSTNAME (которая иногда может быть преобразована в IP-адрес).

Часть HEADER следует непосредственно за частью PRI, сразу после угловой скобки.

Следует отметить, что часть TIMESTAMP имеет формат “Mmm dd hh:mm:ss”, “Mmm” – это первые три буквы месяца года.

Когда речь идет о HOSTNAME, оно часто задается при вводе команды hostname.

Если оно не найдено, ему будет присвоен либо IPv4, либо IPv6 хоста.

Как работает доставка сообщений Syslog?

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

Конечно, Syslog имеет свое мнение на этот счет, и вот несколько ответов на эти вопросы.

Что такое пересылка syslog?

Syslog forwarding заключается в отправке журналов клиентов на удаленный сервер для их централизации, что облегчает анализ и визуализацию журналов.

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

Как следствие, очень распространена практика отправки журналов на удаленную машину, называемую централизованным сервером регистрации, с использованием различных протоколов связи, таких как UDP или TCP.

Syslog использует TCP или UDP?

Как указано в спецификации RFC 3164, клиенты syslog используют UDP для доставки сообщений на серверы syslog.

Более того, Syslog использует порт 514 для связи по UDP.

Однако в последних реализациях syslog, таких как rsyslog или syslog-ng, у вас есть возможность использовать TCP (Transmission Control Protocol) в качестве безопасного канала связи.

Например, rsyslog использует порт 10514 для связи по TCP, гарантируя, что ни один пакет не будет потерян по пути.

Более того, вы можете использовать протокол TLS/SSL поверх TCP для шифрования пакетов Syslog, что гарантирует, что никакие атаки типа “человек посередине” не смогут подсмотреть ваши журналы.

Каковы текущие реализации Syslog?

Syslog – это спецификация, но не фактическая реализация в системах Linux.

Вот список текущих реализаций Syslog в Linux:

Демон Syslog: опубликованный в 1980 году, демон syslog, вероятно, является первой реализацией, которая поддерживает только ограниченный набор функций (таких как передача UDP). В Linux он наиболее известен как демон sysklogd;
Syslog-ng: опубликованный в 1998 году, syslog-ng расширяет набор возможностей оригинального демона syslog, включая TCP-пересылку (что повышает надежность), шифрование TLS и фильтры на основе содержимого. Вы также можете сохранять журналы в локальных базах данных для дальнейшего анализа.
Презентационная карта Syslog-ng
Rsyslog: выпущенный в 2004 году Райнером Герхардсом, rsyslog поставляется как реализация syslog по умолчанию в большинстве актуальных дистрибутивов Linux (Ubuntu, RHEL, Debian и т.д.). Он предоставляет тот же набор функций, что и syslog-ng для пересылки, но позволяет разработчикам получать данные из большего количества источников (например, Kafka, файл или Docker).

Заключение

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

Однако есть время для теории, а есть время для практики.

Так куда же вам двигаться дальше? У вас есть несколько вариантов.

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

см. также:

🙀 Настройка NXLog для пересылки системных журналов на Rsyslog Server в Ubuntu 18.04
📨 Как отправить выбранные события аудита в определенные файлы или хосты с помощью rsyslog & auditd
Централизованный мониторинг сервера RSYSLOG
⚓ Геолокация хакеров, взламывающих по SSH в режиме реального времени
🐧 Как фильтровать логи systemd с помощью journalctl с примерами
🐧 Руководство для начинающих по системным логам в системах Linux
👀 Обнаружение изменений критических файлов на Linux с помощью Auditbeat и ELK
🐧 Как отобразить статистику процесса на Linux

Источник

Содержание

Перенаправление событий Windows (Event Log)
Перенаправление сообщений из EventLog Windows на удалённый syslog
ИТ База знаний
Полезно
Навигация
Серверные решения
Телефония
Корпоративные сети
Syslog серверы
Syslog сообщения
Cбор логов с rsyslog, именами файлов в тегах, многострочными сообщениями и отказоустойчивостью
Задача
Выбор софта
Формат сообщений и legacy
Альтернатива протоколу syslog: RELP
Конфигурация rsyslog
Обработка сообщений
Примеры конфигурации
Клиент: пересылка логов с сохранением имени файла
Чтение лог-файлов, заданных через wildcard
Многострочные сообщения
Сервер
Надёжная доставка сообщений. Очереди
Отказоустойчивость
Взаимодействие с logrotate
Логи, которые пишет сам rsyslog
Логи, записываемые приложением и считываемые rsyslog
Перенаправление событий Windows (Event Log) на сервер syslog Linux
Вступление
Описание
Настройка
Заключение

Перенаправление событий Windows (Event Log)

В данной заметке я покажу как настроить перенаправление событий системы Windows 7 на централизованный сервер хранения логов поднятый в одной из заметок на моём блоге.

В моём, случае я разберу установку для архитектуры x86

Узнать используемую у Вас ось можно, к примеру через консоль командной строки, для этого введите следующую строку:

C:Usersekzorchik>Wmic os get osarchitecture

По указанной ниже ссылке скачиваем пакет применительно к Вашей архитектуре :

Распаковываем скачанный файл и копируем файлы evtsys.dll & evtsys.exe в каталог c:windowssystem32

C:Usersekzorchik>cd /d c:windowssystem32

Checking ignore file…

Jan 29 12:26:43 WTEST Error opening file: evtsys.cfg: The system cannot f

ind the file specified.

Jan 29 12:26:43 WTEST Creating file with filename: evtsys.cfg — И создаётся также конфигурационный файл evtsys.conf

Command completed successfully

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

Старт – Панель управления – Администрирование – Службы и видим, появилась служба

“Eventlog to Syslog”, запускаем её:

Либо через командную строку:

c:WindowsSystem32>net start evtsys

Служба «Eventlog to Syslog» запускается.

Служба «Eventlog to Syslog» успешно запущена.

Данная служба работает по принципу пересылки событий журнала Windows.

Размер журнала пересылаемого на централизованный сервер редактируется через ветку реестра : — HKLMSOFTWAREECNEvtSys3.0

Min send packets: (из доки Reame.rtf)

The maximum size of a Syslog message is defined as 1024 bytes. Anything beyond this threshold is truncated.

The “Eventlog to Syslog” service polls for messages every 5 seconds.

MaxMessageSize 0x00000400 (1024)

Max send Packets: (из доки Reame.rtf)

The maximum size of a Syslog message is defined as 1024 bytes. Anything beyond this threshold is truncated.

The “Eventlog to Syslog” service polls for messages every 5 seconds.

MaxMessageSize 0x00001000 (4096)

После перезагрузки (или ручного запуска сервиса evtsys) все журналы Windows будут передаваться в rsyslog нашего сервера и, соответственно, будут доступны в веб-интерфейсе LogAnalyzer.

К примеру, создадим в ручную событие в системе через командную строку:

C:Usersekzorchik>eventcreate /L Application /so TestMessage /t error /id 1 /d

«Тестовое сообщение с системы Windows 7 x86″

УСПЕХ: событие ‘error’ создано в журнале ‘Application’ с источником ‘TestMessage

Открыв web интерфейс консоли мониторинга видим сообщение :

Щелкаем по нему и видим подробную информацию

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

Вот собственно и весь процесс установки. На этом всё, удачного мониторинга.

Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:

Поблагодари автора и новые статьи

будут появляться чаще 🙂

Карта МКБ: 4432-7300-2472-8059

Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.

Источник

Перенаправление сообщений из EventLog Windows на удалённый syslog

В предыдущей статье было показано как можно настроить сбор логов с различных серверов под управлением Linux и FreeBSD на один используя syslog. Однако что делать если в сети есть ещё и машина под Windows?

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

Самым удобным решением этой задачи является вариант с отсылкой сообщений из EventLog Windows в syslog на сервере сбора логов. Для этого можно использовать инструмент evtsys, разработанный в Purdue Univercity.

Для установки нужно скачать архив со страницы проекта и распаковать его в директорию %systemroot%system32 (Обычно это C:Windowssystem32).

Первыми двумя командами осуществляется переход в директорию с файлами утилиты, третья устанавливает evtsys как системную службу (она получит имя «Eventlog to Syslog»). Последняя команда запускает эту службу.

После этого системные логи из EventLog начнут дублироваться в удалённый Syslog.

Если по какой-то причине нужно удалить evtsys то в командной строке нужно выполнить следующие команды:

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

Отдельно нужно оговориться о том, что в русской версии Windows сообщения пересылаются в кодировке cp1251, потому для чтения логов на сервере сбора логов имеет смысл воспользоваться примерно такой командой:

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Онлайн курс по Linux

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

laptop

Syslog серверы

Syslog сообщения

	Emergency	Система не работоспособна
1	Alert	Система требует немедленного вмешательства
2	Critical	Состояние системы критическое
3	Error	Сообщения об ошибках
4	Warning	Предупреждения о возможных проблемах
5	Notice	Сообщения о нормальных, но важных событиях
6	Informational	Информационные сообщения
7	Debug	Отладочные сообщения

Недостатки syslog

У протокола syslog есть несколько недостатков.

Онлайн курс по Linux

Источник

Cбор логов с rsyslog, именами файлов в тегах, многострочными сообщениями и отказоустойчивостью

Задача

Передавать лог-файлы на центральный сервер:

Условия: в инфраструктуре используются только Linux-сервера.

Выбор софта

Зачем вообще нужен syslog-сервер, когда есть elastic beats, logstash, systemd-journal-remote и ещё много новых блестящих технологий?

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

Формат сообщений и legacy

Syslog появился в 80-х, и быстро стал стандартом логирования для Unix-like систем и сетевого оборудования. Стандарта не было, все писали по принципу совместимости с существующим софтом. В 2001 IETF описал текущее положение вещей в RFC 3164 (статус «informational»). Т. к. реализации очень отличаются, то в частности в этом документе сказано «содержание любого IP пакета отправленного на UDP порт 514 должно рассматриваться как сообщение syslog». Потом попробовали стандартизировать формат в RFC 3195, но документ получился неудачным, для него в данный момент нету ни одной живой реализации. В 2009 приняли RFC 5424, определяющий структурированные сообщения, но этим редко кто пользуется.

Вот тут можно прочитать, что обо всём этом думает автор rsyslog Рейнер Герхард (Rainer Gerhards). Фактически, по-прежнему все реализуют syslog как попало, и задача интерпретировать всё это разнообразие ложиться на syslog-сервер. Например, в rsyslog включен специальный модуль для разбора формата, используемого CISCO IOS, ну и для самых плохих случаев начиная с пятой версии можно определять собственные парсеры.

Сообщения syslog при передаче по сети выглядят примерно так:

Альтернатива протоколу syslog: RELP

Если сообщения пересылаются между хостами, использующими rsyslog, можно вместо plain TCP sysog использовать RELP — Reliable Event Logging Protocol. Был создан для rsyslog, сейчас поддерживается и некоторыми другими системами. В частности, его понимают Logstash и Graylog. Для транспорта использует TCP. Может опционально шифровать сообщения с помощью TLS. Надёжнее plain TCP syslog, не теряет сообщения при разрыве соединения. Решает проблему с многострочными сообщениями.

Конфигурация rsyslog

В отличии от второй распространённой альтернативы, syslog-ng, rsyslog совместим с конфигами исторического syslogd:

Начиная с шестой версии, появился си-подобный формат RainerScript, позволяющий задавать сложные правила обработки сообщений.

Т. к. всё это делалось постепенно и с учётом совместимости со старыми конфигами, то в итоге получилась пара неприятных моментов:

Чтобы не спотыкаться об эти тонкости (да, в документации они описаны, но кто же её целиком читает?), стоит следовать простым правилам:

Подробнее про формат конфига здесь.

Обработка сообщений

Примеры конфигурации

Клиент: пересылка логов с сохранением имени файла

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

Теперь создадим Input, читающий лог-файл, и присоединим к нему этот RuleSet.

В случае, если какое-то приложение пишет в общий syslog с определённым тегом, и мы хотим как сохранять это в файл, так и пересылать по сети:

Последний stop нужен, чтобы прекратить обрабатывать эти сообщения, иначе они попадут в общий syslog. Кстати, если приложение умеет выбирать другой unix socket для syslog, кроме стандартного /dev/log (nginx и haproxy так умеют), то можно с помощью модуля imuxsock сделать для этого сокета отдельный Input и прицепить к нему нужный RuleSet, не разбирая логи из общего потока по тегам.

Чтение лог-файлов, заданных через wildcard

Программист: Не могу найти на лог-сервере логи somevendor.log за начало прошлого месяца, посмотри плиз.
Девопс: Эээ… а мы разве пишем такие логи? Предупреждать же надо. Ну в любом случае всё старше недели логротейт потёр, если мы его не сохраняли — значит уже нету.
Программист: бурно возмущается

Вайлдкарды поддерживаются только в режиме работы imfile inotify (это режим по-умолчанию). Начиная с верcии 8.25.0, вайлдкарды поддерживаются как в имени файла, так и пути: /var/log//.log.

Многострочные сообщения

Для работы с лог-файлами, содержащими многострочные сообщения, модуль imfile предлагает три варианта:

Сервер

Надёжная доставка сообщений. Очереди

Для некоторых Actions выполнение может иногда тормозить или приостанавливаться, например пересылка логов по сети или запись в базу. Чтобы не терять сообщение и не мешать работать следующим Actions, можно использовать очереди. Каждому Action всегда сопоставлена очередь сообщений, по умолчанию это Direct Queue нулевого размера. Ещё есть основная очередь для поступивших из всех Input сообщений, её тоже можно настраивать.

RuleSet на клиенте с очередью будет выглядеть так:

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

ВНИМАНИЕ: При передачи сообщений из очереди после восстановления сети их относительный порядок может нарушаться (спасибо zystem за комментарий). Автор rsyslog ответил, что это ожидаемое поведение, подробнее можно почитать тут: http://www.gerhards.net/download/LinuxKongress2010rsyslog.pdf (section 7 «Concurrency-related Optimizations»). Вкратце: попытка сохранить строгий порядок сообщений при многопоточной обработке очереди приводила к падению производительности из-за необходимости блокировок потоков; понятие строгой последовательности сообщений может не иметь смысла для некоторых типов транспорта, многопоточных генераторов и приёмников сообщений.

Отказоустойчивость

Можно настроить Action для выполнения только в случае, если предыдущее Action было приостановлено: описание. Это позволяет настраивать failover конфигурации. Некоторые Actions используют транзакции для увеличения производительности. В таком случае, успех или неудача будут известны только после завершения транзакции, когда сообщения уже обработаны. Это может приводить к потере части сообщений без вызова failover Action. Чтобы такого не происходило, надо ставить параметр queue.dequeuebatchsize=»1″ (по-умолчанию 16), что может снизить производительность.

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

Взаимодействие с logrotate

Логи, которые пишет сам rsyslog

Логи, записываемые приложением и считываемые rsyslog

Для приложений, способных переоткрывать файлы по запросу(SIGHUP или что-нибудь ещё), дополнительная конфигурация не требуется. rsyslog заметит изменения inode файла и переоткроет его.

Получилась достаточно гибкая и удобная конфигурация. Логи передаются как из файлов, так и из syslog. Многострочные сообщения передаются корректно. Перезагрузка лог-сервера не вызывает потерю данных. Для добавления новых логов достаточно обновить конфигурацию клиента, сервер трогать не надо.

Работает для rsyslog v8, на более ранних версиях не проверялась. Для Ubuntu есть официальный ppa adiscon/v8-stable. Для CentOS/RHEL можно использовать официальный репозиторий.

UPD: Добавлено замечание о нестрогом сохранении порядка сообщений при использовании очередей, спасибо zystem.

UPD2: Добавлена секция о взаимодействии с logrotate.

Источник

Перенаправление событий Windows (Event Log) на сервер syslog Linux

Вступление

Описание

Перейдём к ещё большей конкретике.

Настройка

Заключение

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

— кто распечатал (логин)
— имя документа

Источник

Bog BOS: syslog — сетевой системный журнал

Последнее изменение файла: 2022.03.02

Скопировано с www.bog.pp.ru: 2023.02.06

Протокол syslog и программные средства поддержки обеспечивают
запись информации о событиях в системный журнал (журналы, системную консоль),
а также передачу их на сервер журнализации по сети,
сортировку и обработку в зависимости от источника и важности сообщений.
В статье описывается протокол syslog, его реализация в Solaris и Linux
(syslogd), Cisco IOS, а также вспомогательные средства: logrotate, logwatch.
Первый стандарт (RFC 3164) был сформулирован через 10 лет практического использования.

Оглавление:

Архитектура системы журнализации
Протокол syslog (RFC 3164)
Протокол syslog-conn (RFC 3195)
Протокол syslog (RFC 5424)
syslogd — «стандартная» реализация протокола syslog в Unix
Настройка syslog.conf
Особенности syslogd в Linux
rsyslog (отдельная статья)
Особенности syslogd в Solaris
Использование syslog в Cisco IOS
klogd — журнализация сообщений ядра
logger — утилита записи в журнал
syslog API
logrotate — ротация, сжатие и удаление старых журналов
logwatch — получение отчетов из журналов
Местные особенности
Ссылки

Компонентами системы являются генератор сообщений
(устройство или процесс, device), протокол обмена, коллектор сообщений (collector, syslog server),
релей (relay, принимает сообщения от одного или нескольких генераторов и
передает одному или нескольким коллекторам или следующим релеям).
Генератор (или релей при передаче) не знает является
ли приемник релеем или коллектором, может передавать одно сообщение
нескольким приемникам, может обрабатывать сообщение самостоятельно
(например, записывая в файл).

Протокол syslog (RFC 3164) не содержит никаких средств защиты от подделок
сообщений. Хуже того, использование протокола UDP позволяет злоумышленникам
посылать сообщения от имени любого хоста. Локальная сеть должна быть
защищена экраном (IOS ACL,
iptables) от приема пакетов с поддельными
локальными адресами (хотя это не помешает посылать поддельные сообщения
изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp.
Известны случаи переполнения диска ложными сообщениями.

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

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

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

Средства защиты от зацикливания передачи сообщений
неправильно настроенными релеями не предусмотрены.

RFC 3195 (2001 год) предлагает новый протокол над TCP (порт 601 — syslog-conn),
обеспечивающий гарантированную доставку в правильной последовательности.
Чудовищная смесь XML, команд и кодов возврата в стиле SMTP
и заголовков MIME (BEEP), в которую заворачиваются сообщения стандартного
формата syslog. Используется два режима — RAW (аналог нынешнего UDP протокола)
и COOKED (сообщения структурированы по полям). BEEP позволяет обеспечить
аутентификацию, целостность и конфиденциальность (SASL, TLS).

Проект RFC syslog-sign предлагает обеспечить аутентификацию,
упорядоченность, целостность сообщений и обнаружение пропавших сообщений
за счет генерации специальных сообщений, содержащих цифровую подпись
(signature) блока предыдущих сообщений с сохранением стандартного протокола
и формата syslog и использованием UDP. Используется SHA1, OpenPGP DSA.

В 2009 году вышел RFC 5424 (The Syslog Protocol, UTF-8, структурированные данные, время) и его дополнения:

RFC 5425 (использование TLS, TCP/6514)
RFC 5426 (использование UDP, UDP/514)
RFC 5427 (кодировка источника и важности в формате MIB)

В том же 2009 году вышли RFC, привязывающие syslog к SNMP:

RFC 5674 (Alarms in Syslog)
RFC 5675 (Mapping SNMP Notifications to SYSLOG Messages)
RFC 5676 (Definitions of Managed Objects for Mapping SYSLOG Messages to SNMP Notifications)

В 2010 вышли RFC, усиливающие безопасность передачи:

RFC 5848 (Signed Syslog Messages); цифровая подпись, упорядоченность, обнаружение пропавших сообщений
RFC 6012 (Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog)

В 2012 отчаявшись перевести всех на RFC 5424/RFC 5425 была описана сложившаяся практика использования TCP без TLS в виде RFC 6587.

Для приема сообщений используется порт 514/UDP.
Рекомендуется также использовать исходный порт 514 для передачи сообщений.
Сообщение представляет собой текстовую строку и не может иметь длину более
1024 байт, в противном случае его разрешается обрезать или даже выбрасывать.
Даже неправильно сформированное сообщение, посланное на 514 порт,
должно рассматриваться как сообщение syslog. Однако, если релей передает
сообщение дальше, то он должен добавить к нему стандартные заголовки (при этом,
возможно обрезав его до 1024 байт) — USER, NOTICE, свое локальное время и
простое имя источника сообщения.

Сообщение начинается с поля PRI, которое в закодированном виде
содержит информацию об источнике сообщения (facility) и уровне серьезности (Severity level)
сообщения. Сразу за ним идёт заголовок (HEADER), содержащий время (TIMESTAMP), пробел, имя или IP
адрес хоста в десятичной записи (HOSTNAME). За заголовком идёт пробел и тело сообщения (MSG),
произвольный текст в US-ASCII (0x20 — 0x7e).

Источник сообщения кодируется числом
от 0 до 23:

0 — KERN (сообщения ядра)
1 — USER (сообщения пользовательских программ)
2 — MAIL (почтовая система)
3 — DAEMON (прочие демоны)
4 — AUTH (безопасность/права доступа)
5 — SYSLOG (генерируемые самим syslog)
6 — LPR (подсистема печати)
7 — NEWS (Netnews, USENET)
8 — UUCP
9 — CRON (clock daemon)
10 — AUTHPRIV (безопасность/права доступа — защищенный режим)
11 — FTP
12 — NTP (существует не везде)
13 — security, log audit (существует не везде)
14 — console, log alert (существует не везде)
15 — solaris-cron, clock daemon (существует не везде)
с 16 по 23 зарезервированы для локального использования (LOCAL0 — LOCAL7)

Уровень серьезности кодируется числом
от 0 до 7:

0 — EMERG (система неработоспособна, старое название PANIC)
1 — ALERT (требуется немедленное вмешательство)
2 — CRIT (критическое состояние)
3 — ERR (ошибка, старое название ERROR)
4 — WARNING (предупреждение, старое название WARN)
5 — NOTICE (все нормально, но важно)
6 — INFO (информационное сообщение)
7 — DEBUG (отладочная печать)

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

Время (местное!) записывается в формате: Feb 13 21:12:06.
Если номер дня является однозначным числом, то перед ним ставится
дополнительный пробел (не 0!). Заметьте отсутствие года и зоны в дате, что
необходимо учесть при долговременном хранении. Для того, чтобы время
в сообщении было правильным, устройство должно быть синхронизовано
(например, по NTP).

Имя хоста (простое по STD 13 (RFC 1034 и RFC 1035), не FQDN!) записывается так, как оно
известно генератору сообщения. Если устройство имеет несколько интерфейсов
с различными IP-адресами, то в качестве имени или адреса хоста может быть
использовано любое из них.

Текст сообщения (MSG) обычно содержит этикетку (TAG), указывающую
на программу или процесс, выдавшую это сообщение и тело сообщения (CONTENT) в ASCII-7.
Этикетка может содержать латинские буквы и цифры. Начало тела сообщения
определяется по первому специальному символу — обычно двоеточие или
открывающая квадратная скобка. Например, Cisco IOS в качестве этикетки
использует последовательный номер сообщения и двоеточие, а Unix — простое
имя программы (тело сообщения начинается с номера процесса в квадратных
скобках и двоеточия).

Релей не должен прверять достоверность заголовка (время и хост).

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

Релей должен добавлять PRI равный 13 и заголовок в пересылаемое сообщение, если не обнаружил PRI во входящем сообщении.2

Год рекомендуется заносить в содержимое сообщения.

FQDN и IP рекомендуется заносить в содержимое сообщения.

RFC 3195 использует ту же архитектуру, что и RFC 3164 (источники, релеи, коллекторы)
и фреймворк протоколов BEEP (Blocks Extensible Exchange Protocol) для описания асинхронных соединений (TCP/601, syslog-conn), профили:

RAW — аналог UDP протокола из RFC 3164, упорядоченная надёжная поставка в рамках каждого канала, MIME Content-Type типа application/octet-stream;
слушатель ждёт соединения, инициатор открывает соединение, слушатель сообщает о готовности («RPY 0 0 . 0 201»)
и ожидаемом формате (текст в XML), инициатор сообщает о готовности и используемом формате (MIME+XML, затем пронумерованные
сообщения в формате похожем на RFC 3164, но не совсем — многострочность, «END»
COOKED — MIME Content-Type типа application/beep+xml;
представление источника (iam: тип — device, relay или collector; FQDN имя; IP адрес) с подтверждением;
структурированные сообщения (entry: facility, severity, timestamp, hostname, tag, deviceFQDN, deviceIP) с подтверждением,
маршрут прохождения сообщения (path: fromFQDN, fromIP, toFQDN, toIP, pathID, linkprops (сильная и слабая приватность, пользователь
аутентифицирован с помощью SASL или TLS, использован слой аутентификации, защита от повторных сообщений, защита от модификации,
защита от потери)) позволяет отлавливать циклы

Возможно использование алгоритма DNS SRV для автоматического получения адреса коллектора (сервис syslog, протокол tcp).

RFC 5424 замещает RFC 3164. Отдельно описывает формат сообщений, отдельно — механизм транспортировки.
Стандарт поделён на слои:

содержимое сообщения
транспортировка сообщений
приложения: создание, интерпретация, маршрутизация, хранение

В дополнение к генератору сообщений (originator), коллектору (collector) и релею (relay)
определяются транспортный отправитель (transport sender) и транспортный получатель (transport receiver),
которые передают (получают) сообщения в транспортный протокол.

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

Защиты от повторного проигрывания не предусмотрена.

Защита цельности сообщений не предусмотрена, всё на откуп транспортому механизму.

Защита приватности не предусмотрена, всё на откуп транспортому механизму.

Защита от ошибок настройки, в частности, от циклов маршрутизации не предусмотрена.

Сообщение состоит из заголовка (HEADER), пробела, структурированных данных, пробела и тела сообщения (MSG).

Максимальная длина определяется транспортным механизмом, но не менее 480 октетов.
Слишком длинные сообщения обрезаются или отбрасываются.

Заголовок состоит из

поля PRI (см. RFC 3164); RFC 5427 определяет MIB модуль для Facility и Severity (syslogTCMIB как { mib-2 173 })
версии (до 3 цифр), «1» для RFC 5424
пробела
отметки времени (TIMESTAMP)
пробела
имени хоста генератора сообщения (HOSTNAME, FQDN, строка US-ASCII или «-«), может содержать IP адрес, простое имя
пробела
имени приложения или устройства (APP-NAME — строка US-ASCII или «-«)
пробела
идентификатор процесса (PROCID — строка US-ASCII или «-«), позволяет отслеживать перезапуски приложения
пробела
идентификатора типа сообщения (MSGID — строка US-ASCII или «-«)

Отметка времени — «-» или «ГОД-МЕСЯЦ-ДЕНЬ»||»T»||»ЧАС:МИНУТА:СЕКУНДА»||».»||»МИКРОСЕКУНД»||»СМЕЩЕНИЕ»
(где ГОД — 4 цифры, МЕСЯЦ — 2 цифры, ДЕНЬ — 2 цифры, микросекунды — до 6 цифр — опциональны, СМЕЩЕНИЕ — «Z» (UTC) или «{+|-}ЧАСОВ:МИНУТ»).

Стуктурированные данные — «-» или последовательность SD элементов (без пробелов!), где SD элемент — это ‘[ИМЯ-SD ИМЯ-ПАРАМЕТРА=»ЗНАЧЕНИЕ» …]’,
где ЗНАЧЕНИЕ — это строка UTF-8. SD делятся на

пользовательские содержат «@» в имени
предопределённые
- timeQuality — параметры
  - tzKnown=»1″
  - isSynced=»1″
  - syncAccuracy=»микросекунд»
- origin (источник сообщения) — параметры
  - ip (возможен список)
  - enterpriseId (SMI Network Management Private Enterprise Code — iso.org.dod.internet.private.enterprise
  - software (требуется enterpriseId)
  - swVersion
- meta
  - sequenceId — последовательный номер
  - sysUpTime (см. RFC 3418)
  - language (см. RFC 4646, BCP 47)

Тело сообщения — BOM (0xEFBBBF) и строка UTF-8 или произвольная последовательность октетов (байт).

Транспортные протоколы описываются отдельными RFC:

RFC 5425 — TLS 1.2 (RFC 5246) с TLS_RSA_WITH_AES_128_CBC_SHA, по умолчанию, порт TCP/6514 (syslog-tls);
для взаимной аутентификации могут использоваться сертификаты (RFC 5280): проверка цепочки сертификатов (PKI) или проверка отпечатка (fingerprints,
что сводит шифрование к ситуации «с известным ключом»);
сообщение получается из сообщения RFC 5424 добавлением в начало длины (строка) и пробела;
транспорт TLS обеспечивает приватность и достоверность данных;
подтверждений и полной упорядоченности не обеспечивается
RFC 5426 — UDP, привычный по RFC 3164, порт UDP/514;
каждое сообщение в отдельном пакете и ничего более; приёмник должен принимать сообщения длиной 480 октетов для IPv4;
отправителю не рекомендуется создавать пакеты более 576 октетов;
не разрешается отключать создание контролльных сумм;
подтверждений нет, приватность, достоверность, упорядоченность не обеспечиваются;
RFC 6587 — TCP, по традиции используется порт TCP/514, хотя официально он используется для других целей!;
десятилетия, потраченные на попытки стандартизовать syslog, были потрачены зря!
люди продолжают пользоваться стихийно сложишимся протоколом, описанным в RFC 3164, просто заворачивая его в TCP;
но ничего! мы их железной рукой…;
устройства (генераторы сообщений) делятся на устаревшие (legacy) и соответствующие стандарту (RFC 5424, standardized);
подтверждений нет; приватность, достоверность, упорядоченность не обеспечиваются, кроме как средствами TCP;
кодировка US-ASCII с использованием NVT (Network Virtual Terminal, RFC 5198),
но коллектор д.б. готов принять сообщения в различной кодировке от одного и того же релея;
TCP приёмник слушает порт, TCP отправитель начинает сессию, TCP приёмник не посылает данные, в случае проблем просто закрывает соединение;
TCP отправитель посылает поток сообщений по одному в TCP кадре одним из способов (можно отличить по первому символу — цифра или «<«):
- Octet Counting — сообщение получается из сообщения RFC 5424 добавлением в начало длины (строка) и пробела
- Non-Transparent-Framing — сообщение помещается в TCP кадр и завершается символом LF (или NUL, или CRLF)
RFC 6012 — DTLS (Datagram Transport Layer Security, RFC 4347, TLS_RSA_WITH_AES_128_CBC_SHA) поверх UDP (нет защиты от потерь, UDP/6514) или DCCP (RFC 4340);
приватность и достоверность данных, взаимная аутентификация, защита от повторногой посылки;
сообщение получается из сообщения RFC 5424 добавлением в начало длины (строка) и пробела;
сообщения могут разбиваться на кадры или сливаться в один кадр

RFC 5848 (syslog-sign) описывает возможность обеспечить аутентификацию, неизменяемость, устойвость к повторным передачам,
упорядоченность и обнаружение пропавших сообщений за счёт посылки подписантом (signer) выделенных сообщений, содержащих блок подписи (Signature Block)
для ранее посланных сообщений (Signature Group). Подписант может совпадать или не совпадать с генератором (отправителем) сообщений.
Подписантов может быть много. Дополнительно посылается блок с сертификатами (Certificate Blocks), позволяющими проверить подписи.
Используется механизм структурированных данных (элементы ssign и ssign-cert).

syslogd осуществляет прием сообщений с порта 514/UDP
и от местных источников (сокет /dev/log),
их маршрутизацию в зависимости от источника сообщений и уровня серьезности.
Позволяет выводить сообщения в журнал, выводить на консоль,
на терминал, посылать на другой сервер.
Вводится дополнительный тип источника MARK (регулярные отметки, info)

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

дата в стандартном текстовом формате (поле TIMESTAMP из сообщения syslog)
имя хоста (fqdn или сокращенное, поле HOSTNAME из сообщения syslog)
текст сообщения (поля TAG и CONTENT из сообщения syslog)

Параметры запуска:

-a дополнительный-прослушиваемый-сокет
(полезен для демонов, делающих chroot; может быть несколько; до 19)
-d (отладочный режим)
-f имя-конфигурационного-файла (по
умолчанию, /etc/syslog.conf)
-h (изменить обычное поведение, при котором сообщения, принятые от
удаленных хостов, не передаются дальше для записи на удаленном хосте
во избежание зацикливания)
-l список-хостов (список хостов, имена которых должны
записываться в простом виде, а не FQDN; разделяются двоеточием)
-m минут (интервал для регулярных временных записей; по
умолчанию — 20; если 0, то не делать вообще)
-n (не уходить в фоновый режим; необходим для запуска из init)
-p прослушиваемый-сокет (по умолчанию: /dev/log)
-r (разрешить принимать сообщения от
удаленных хостов; firewall д.б. приоткрыт; в /etc/services д.б.
определен syslog для 514/udp)
-s список-доменов (обрезать из имен хостов имена указанных
доменов; разделяются двоеточием; по умолчанию обрезается домен, совпадающий
с доменом сервера syslog)
-v (показать версию и закончить работу)
-x (запретить определять имя хоста по его адресу, предотвращает
deadlock при работе на одном хосте с сервером DNS)

Используемые файлы:

/etc/syslog.conf — конфигурационный файл (изменяется при запуске
параметром -f)
/dev/log — сокет, с которого читаются локальные сообщения
(изменяется при запуске параметром -p)
/var/run/syslogd.pid — идентификатор процесса

Реакция на сигналы:

SIGHUP — реинициализация (закрывает все файлы, читает заново файл
конфигурации)
SIGTERM — завершение работы
SIGINT, SIGQUIT — завершение работы, если выключена отладка
SIGUSR1 — включить/выключить отладку (только при использовании ключа -d)

Запускается с правами root.
Не меняет права доступа к файлам. Если вынужден
создавать файл, то делает его с правами 644. При необходимости
ограничить доступ к журналу, соответствующий файл надо создать
вручную (или поменять права доступа). Особые проблемы создает logrotate.

Представляет собой набор правил маршрутизации сообщений.
Комментарии начинаются с символа ‘#’. Обратная косая черта в конце строки
означает продолжение правила на следующей строке.
Каждое правило состоит из селектора и действия, которые разделяются
табуляциями (в старых системах — Solaris 5) или пробелами (Linux).
Получив сообщение для записи в журнал (от klogd, от локальной или удаленной
программы), syslogd для каждого правила проверяет не подходит ли
сообщение под шаблон, определяемый селектором. Если подходит, то
выполняется указанное в правиле действие.
Для одного сообщения м.б. выполнено произвольное количество действий
(т.е. обработка сообщения не прекращается при первом успехе).

Селектор состоит из двух частей, разделенных точкой:
источник сообщения и уровень серьезности.
Прописные и строчные буквы не различаются.
Можно также использовать числа (см. /usr/include/syslog.h).
Кроме определенных в syslog(3) источников, можно указывать mark
(регулярные временные метки), security
(устаревший синоним для auth).
Кроме определенных в syslog.h уровней серьезности можно
использовать warn (синоним для warning), error
(синоним для err), panic (синоним для emerg).
Сообщения с уровнем, равным или выше указанного в селекторе,
и источником, равным указанному в селекторе, считается подходящим.
Звездочка перед точкой соответствует любому источнику
(кроме daemon и syslog!),
после точки — любому уровню.
Слово none после точки — никакому уровню для данного источника.
Можно указывать несколько источников в одном селекторе (через запятую).
В этом случае приоритет можно указывать только для последнего источника.
В одной строке можно указывать несколько селекторов через ‘;’.
Семантика не ясна: если использовать
позитивные селекторы, то выполняется логическое ИЛИ,
если негативные (none и восклицательный знак), то логическое
И.

В новом syslogd (linux)
перед уровнем можно поставить знак равенства — селектору будут
соответствовать только сообщения с указанным уровнем (но не с высшим);
восклицательный знак — не будут соответствовать сообщения с
уровнем равным или большим; восклицательный знак и равенство — не будут
соответствовать сообщения с уровнем, равным указанному.

В качестве действия можно указывать:

имя обычного файла (полный путь от корня), минус
перед именем отключает синхронизацию записи (ускорение на порядок и более!)
поименованные каналы — fifo (перед именем ставится
вертикальная черта), сам канал д.б. создан перед
запуском syslogd командой mkfifo
терминал или консоль (/dev/console)
@имя-хоста (передать сообщений для удаленной
журнализации)
список пользователей (через запятую), на терминалы которых будет послано
сообщение
звездочка для посылки сообщения на все терминалы (wall)

Включен в состав пакета sysklogd (RH 6.2: sysklogd-1.3.31-16,
RH 7.0: sysklogd-1.3.33-8, RH 7.2: sysklogd-1.4.1-4).
Также в этот пакет входит klogd.

Процедура запуска, остановки, перезапуска (syslogd и klogd):
/etc/rc.d/init.d/syslog (символьные ссылки на нее из директорий
/etc/rc.d/rc?.d/). Ключи запуска считывает из файла
/etc/sysconfig/syslog (начиная с RH 7.2).
Статус определяется по наличию файла /var/lock/subsys/syslog.
Номер процесса хранится в /var/run/syslogd.pid.

При разборе файла конфигурации syslogd сравнивает адрес
loghost (определяется в /etc/hosts, не через DNS) с адресом своего
компьютера и при совпадении определяет переменную LOGHOST.
После этого syslog.conf пропускается через макропроцесссор m4(1).
В основном, это используется для того, чтобы один и тот же
конфигурационный файл можно было использовать на
клиентских и серверном (с точки зрения syslog) хостах.

Процедура запуска и остановки:
/etc/init.d/syslog (ссылки на нее из директорий
/etc/rc?.d). Номер процесса хранится в /etc/syslog.pid.

Использование syslog в Cisco IOS.

klogd читает сообщения ядра (либо через /proc/kmsg, либо с
помощью системных вызовов), определяет уровень,
преобразует адреса команд в имена программ и передает сообщение syslogd.

Параметры запуска:

-c уровень (сообщения данного уровня и менее серьезные будут
передаваться syslog, а более серьезные —
выводиться на консоль; по умолчанию — 7; 0 указывать нельзя)
-d (отладочный режим)
-f имя-файла (журнализовать в указанный файл вместо syslog)
-i (перезагрузить символы модулей в уже работающем klogd,
необходимо использовать при каждой загрузке или выгрузке модуля;
надеюсь, что текущие версии insmod, rmmod и modprobe делают это
самостоятельно)
-I (перезагрузить символы ядра и модулей в уже работающем klogd)
-k имя-файла (использовать указанный файл как
таблицу символов ядра вместо /boot/System.map)
-n (не уходить в фоновый режим; необходим для запуска из init)
-o (одноразовый режим — журнализовать все сообщения,
скопившиеся в буфере ядра и завершить работу)
-p (на всякий случай перезагружать таблицу символов модулей
в момент преобразования адресов — ядро может оказаться не в состоянии
сделать это)
-s (использовать только системные вызовы и не
обращаться к /proc/kmsg для получения исходных сообщений)
-v (показать версию и закончить работу)
-x (не преобразовывать адреса в имена)
-2 (сообщения аварийного завершения ядра — Oops! -выдаются дважды:
до преобразования адресов в имена — для ksymoops — и после)

Уровни сообщений ядра (определяется по цифре в угловых скобках и преобразуется
в уровень серьезности syslog, при выводе в файл не изменяется):

KERN_EMERG — 0 (system is unusable)
KERN_ALERT — 1 (action must be taken immediately)
KERN_CRIT — 2 (critical conditions)
KERN_ERR — 3 (error conditions)
KERN_WARNING — 4 (warning conditions)
KERN_NOTICE — 5 (normal but significant condition)
KERN_INFO — 6 (informational)
KERN_DEBUG — 7 (debug-level messages)

Реакция на сигналы:

SIGINT, SIGKILL, SIGTERM and SIGHUP — завершение работы
SIGTSTP — остановить журнализацию
SIGCONT — возобновить, возможно выбрав другой

источник сообщений (/proc/kmsg или системные вызовы)

SIGUSR1 — перезагрузить символы модулей
SIGUSR2 — перезагрузить символы ядра и модулей

Номер процесса хранится в /var/run/klogd.pid.

Слит в sysklog. Заменён в rsyslog.

logger — запись сообщения в журнал из
командной строки (sh, bash и др.). Входит в состав пакета util-linux.
Параметры:

[-i] (включать номер процесса в сообщение)
[-s] (дублировать сообщение на stderr)
[-f имя-файла] (сохранять сообщение в указанном файле)
[-p facility.level] (по умолчанию: user.notice; kern преобразуется в user)
[-t tag] (задать поле TAG)
[-u socket] (записывать в указанный сокет, вместо
обращения к syslogd)
текст сообщения

Инициализация записи в журнал: openlog — указывается
стандартный префикс, добавляемый ко всем последующим сообщениям (обычно имя
программы, номер процесса в квадратных скобках и
двоеточие); источник и опции. closelog —
завершить запись в журнал. syslog — запись в журнал
(указывается источник, уровень серьезности и формат строки как в printf).

logrotate (версия 3.2-1/3.3.2-1/3.5.9/3.6.9/3.7.1/3.8.6) —
борьба с растущими
журналами: ротация (создание версий), сжатие, удаление и отправка по почте.
Запускается ежедневно cron-ом (/etc/cron.daily/logrotate) и позволяет
обрабатывать журналы, если они превысили указанный размер или с указанным
временным интервалом. Позволяет обрабатывать не только журналы syslog, но
и любых других программ.
Параметры:

-?
—verbose (без этого ключа не выводятся сообщения об ошибках)
-d (отладочный режим, реальных изменений не производится)
-f (производить изменения,
даже если logrotate не видит необходимости —
используется при изменениях в списке обрабатываемых журналов)
-s имя-файла-состояния (текущее состояние журналов
хранится в этом файле между
запусками, по умолчанию — /var/lib/logrotate.status или /var/lib/logrotate/logrotate.status)
-m имя-почтовой-программы («/bin/mail -s»; на вход
ей подаётся текст письма, первый параметр — тема письма, второй —
получатель)
имена-конфигурационных-файлов
(имена через пробел;
порядок имеет значение;
если указано имя каталога, то каждый файл в ней считается конфигурационным;
владельцем файла д.б. root
в RH используется файл /etc/logrotate.conf
и каталог /etc/logrotate.d)

Конфигурационный файл определяет глобальные параметры
(по одному на строке), задающие параметры по умолчанию для всех журналов.
Для каждой серии обрабатываемых журналов задаются локальные параметры:
указывается базовое имя файла, а затем в фигурных скобках локальные параметры
по одному на строке.
Имя файла может быть заключено в кавычки по правилам shell, если оно содержит
пробелы и другие специальные символы.
Можно указывать несколько имен файлов или шаблонов имен файлов через пробел
(шаблоны также по правилам shell).
Обработка каждой секции рассматривается как единое действие.
Строки, начинающиеся с символа «#» являются комментариями.
Параметры, указанные в следующем конфигурационном файле перекрывают
значение параметров, указанных в предыдущем файле. Локальные параметры имеют
приоритет над глобальными.
Порядок файлов в конфигурационной директории не определен.

Параметры:

compress | nocompress (старые версии сжимаются или не сжимаются с помощью gzip)
compresscmd (задает программу сжатия, по умолчанию — gzip)
uncompresscmd (задает программу разжатия, по умолчанию — ungzip)
compressext (задает суффикс для сжатых файлов, «.gz»)
compressoptions (задает параметры программы сжатия; по умолчанию — «-6», т.е. максимальное сжатие для gzip)
copy | nocopy (копировать журнал не трогая исходный)
copytruncate | nocopytruncate (обычно старая версия
переименовывается и создается новая версия журнала; при
задании этого параметра logrotate копирует журнал в новый файл, а затем
обрезает старый; используется,
если программа, создающая журнал, не умеет его закрывать; теряются записи,
сделанные в промежутке между копированием и обрезанием;
а поможет ли,
если создающая журнал программа вместо режима append просто
пишет в файл, используя внутренний указатель?)
create [[права-доступа] владелец группа] | nocreate (сразу после
переименования старой версии журнала и до вызова postrotate
создается новый журнал с указанными атрибутами — права доступа
задаются в восьмеричном виде, как в chmod.2; если
атрибуты не указаны, то берутся от старого журнала)
createolddir права-доступа владелец группа | nocreateolddir
daily (смена версий в серии происходит ежедневно)
delaycompress | nodelaycompress
(некоторые программы не сразу закрывают журнал, в этом случае сжатие надо
отложить до следующего цикла)
dateext | nodateext (старые версии получают суффикс в виде «-YYYYMMDD» вместо номера)
dateformat формат-суффикса (позволяет задать формат в стиле strftime(3),
но только %Y %m %d %H и %s; по умолчанию «-%Y%m%d» или «-%Y%m%d%H»;
формат должен обеспечивать правильную сортировку файлов)
dateyesterday (использовать вчерашнюю дату в dateext)
errors email (кому направлять сообщения об ошибках; удалён в версии ?)
extension суффикс (задается суффикс, добавляемый
к именам файлов при ротации перед суффиксом сжатия — mylog.1.foo.gz вместо mylog.foo.1.gz)
hourly (ежечасно, подсистема cron daily к этому не готова)
ifempty | notifempty (смена версий даже если файл пуст; действует по умолчанию)
include имя-файла | имя-rfnfkjuf
(текстуально подставить файл или все файлы из указанного каталога; не
включаются подкаталоги, специальные файлы и файлы с суффиксами из списка
исключений tabooext; нельзя использовать внутри секции)
mail адрес | nomail (когда смена версий приводит к необходимости удалить старый журнал, то послать его по указанному адресу)
mailfirst (посылать не удаляемую версию журнала, а первую)
maillast (посылать удаляемую версию журнала; действует по умолчанию)
maxage дней (удалять файлы старше указанного)
maxsize байт (смена версии происходит, если размер журнала
превысил указанное число или подошло время; можно использовать суффиксы «k» —
килобайт — и «M» — мегабайт)
minsize байт (смена версии происходит, если размер журнала
превысил указанное число и подошло время; можно использовать суффиксы «k» —
килобайт — и «M» — мегабайт)
missingok | nomissingok (не посылать сообщения об ошибке, если журнал отсутствует)
monthly (смена версий происходит ежемесячно)
olddir каталог | noolddir (во время смены версий журнал перемещается в указанный
каталог; д.б. на том же физическом устройстве, если не исполльзуется режимы copy, copytruncate или renamecopy)
postrotate (все дальнейшие строчки до строки endscript
исполняются как команды shell после процесса смены версии; абсолютный путь к журналу передаётся как первый параметр скрипта)
prerotate (все дальнейшие строчки до строки endscript
исполняются как команды shell перед процессом смены версии; абсолютный путь к журналу передаётся как первый параметр скрипта)
firstaction (все дальнейшие строчки до строки endscript
исполняются как команды shell перед процессом смены версии первого файла в группе; шаблон группы файлов передаётся как первый параметр скрипта)
lastaction (все дальнейшие строчки до строки endscript
исполняются как команды shell после процесса смены версии последнего файла в группе; шаблон группы файлов передаётся как первый параметр скрипта)
preremove (все дальнейшие строчки до строки endscript
исполняются как команды shell перед удалением журнала; абсолютный путь к журналу передаётся как первый параметр скрипта)
rotate число (сколько старых версий хранить; если 0, то ни одной)
size байт (смена версии происходит, если размер журнала
превысил указанное число и наступило его время; можно использовать суффиксы «k» —
килобайт — и «M» — мегабайт)
sharedscripts | nosharedscripts
(выполнять команды prerotate и postrotate только один раз для всех файлов, описанных в секции)
shred | noshred (использовать для удаления файла утилиту shred вместо unlink)
shredcycles число
start число (начинать нумерацию поколений с указанного числа; количество версий отсчитывать от него же)
su имя-пользователя группа (работать от имени указанного пользователя)
tabooext [+] список-суффиксов (задание
списка суффиксов-исключений для include; если указан знак «плюс», то
дополнение, иначе замена; по умолчанию: .rpmorig, .rpmsave, .rpmnew, .disabled, .dpkg-old, .dpkg-dist, .dpkg-new, .cfsaved, .ucf-old, .ucf-dist, .ucf-new,
«,v», .swp, .cfsaved, .rhn-cfg-tmp-* и «~»)
weekly [день] (смена версий происходит еженедельно; день 0 — воскресенье)
yearly (смена версий происходит ежегодно)

В поставке RH /etc/logrotate.conf описывает глобальные
параметры и параметры для /var/log/wtmp и /var/log/lastlog и ссылается на
директорию /etc/logrotate.d, в которую каждый пакет записывает локальные
параметры для своих журналов.

Пример для центрального сервера syslog (текущий журнал в /var/log/syslog/current,
архив в /var/log/syslog/old):

/var/log/syslog/alltext {
    create
    daily
    dateext
    compress
    compresscmd /usr/bin/xz
    compressoptions "-T0"
    compressext .xz
    nodelaycompress
    olddir /var/log/syslog/old
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    rotate 28
    sharedscripts
}
/var/log/syslog/current/host/*.log {
    weekly
    dateext
    compress
    compresscmd /usr/bin/xz
    compressoptions "-T0"
    compressext .xz
    nodelaycompress
    olddir /var/log/syslog/old/host
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    rotate 4
    sharedscripts
}
/var/log/syslog/current/*.log {
    create
    weekly
    dateext
    compress
    compresscmd /usr/bin/xz
    compressoptions "-T0"
    compressext .xz
    nodelaycompress
    olddir /var/log/syslog/old/
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    rotate 4
    sharedscripts
}
/var/log/syslog/current/backup/*.log {
    weekly
    dateext
    compress
    compresscmd /usr/bin/xz
    compressoptions "-T0"
    compressext .xz
    nodelaycompress
    olddir /var/log/syslog/old/backup
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    rotate 4
    sharedscripts
}
...

logwatch представляет собой платформу (framework) для
написания программ (называемых фильтрами) извлечения полезной информации
из многочисленных, больших и разноформатных журналов (не только syslog)
и формирования отчётов с указанной детализацией за указанный период времени, посылаемых по email.

Фильтры могут быть написаны на любом языке программирования,
но автор пакета предпочитает perl 5.8 и новее. Фильтры должны быть написаны так,
что читают данные с stdin и выводят результат на stdout.
Перед вызовом фильтра устанавливаются переменные окружения:
LOGWATCH_DATE_RANGE, LOGWATCH_DETAIL_LEVEL, LOGWATCH_TEMP_DIR, LOGWATCH_DEBUG.
Основная программа также написана на perl:
/usr/share/logwatch/scripts/logwatch.pl (ранее — до версии 7 — /etc/log.d/scripts/logwatch.pl, /etc/log.d/logwatch и /usr/sbin/logwatch
и /etc/cron.daily/0logwatch (или /etc/cron.daily/00-logwatch) — это символьные ссылки на нее).

Каталог /usr/share/logwatch/default.conf/logfiles (ранее /etc/log.d/conf/logfiles/) содержит
конфигурационные файлы групп журналов, в которых хранятся записи обслуживаемых сервисов.
Каждая группа журналов описывается отдельным файлом имя-группы.conf, в котором задаются:

LogFile = имя файла, содержащего журнал, или шаблон имен;
можно задавать несколько имен или шаблонов;
имена м.б. относительно LogDir
Archive = имя файла, созданного logrotate архивной версии журнала, или шаблон имен;
можно задавать несколько имен или шаблонов; можно использовать суффиксы сжатых файлов;
имена м.б. относительно LogDir
имена фильтров (только по одному разу, хотя в показано другое!)
из /usr/share/logwatch/scripts/shared/ в виде
*имя-фильтра = параметры, например, чтобы
отфильтровать журнал по дате, если она записана в стандартном формате
syslog, надо использовать строку:
*ApplyStdDate =

Каталог /usr/share/logwatch/dist.conf/logfiles/ содержит изменения настроек групп журналов для дистрибутива (пусто в RHEL7).

Каталог /etc/logwatch/conf/logfiles (ранее /etc/log.d/conf/logfiles/) содержит локальные изменения настроек групп журналов.

Каталог /usr/share/logwatch/default.conf/services/ (ранее /etc/log.d/conf/services/) содержит
конфигурационные файлы сервисов, чьи записи в журналах logwatch будет
обрабатывать. Каждый сервис описывается отдельным файлом
имя-сервиса.conf, в котором задаются:

# комментарий
LogFile = имя группы журналов
имена фильтров из /usr/share/logwatch/scripts/shared/ в виде
*имя-фильтра = параметры, запускаемых до
фильтра сервиса
$имя-переменной окружения = значение
Detail=уровень

Каталог /usr/share/logwatch/dist.conf/services/ содержит изменения настроек сервисов для дистрибутива (пусто в RHEL7).

Каталог /etc/logwatch/conf/logfiles (ранее /etc/log.d/conf/logfiles/) содержит локальные изменения настроек сервисов.

Каталог /usr/share/logwatch/scripts/logfiles/ (ранее /etc/log.d/scripts/logfiles/) содержит
фильтры обработки групп журналов: при обработке группы журналов все файлы в
каталоге /usr/share/logwatch/scripts/logfiles/имя-группы
используются как фильтры.

Каталог /usr/share/logwatch/scripts/services/ содержит
фильтры обработки записей конкретных сервисов.

Каталог /usr/share/logwatch/scripts/shared/ содержит
общие фильтры, используемые в конфигурационных файлах групп журналов:

applystddate — фильтрует журнал по требуемой дате, если он записан
в формате syslog (здесь и в приватных фильтрах по дате навставлять
LANG= перед вызовом date, а то Mar никак не совпадает с Мар
expandrepeat — превращает строки «last message repeated» в
соответствующее число строк с текстом сообщения из предыдущей
строки
onlycontains — оставляет только те строки журнала, которые
содержат указанную строку (я поставил кавычки вокруг «$*»)
onlyservice — выделяет из журнала в формате syslog строки,
относящиеся к указанному сервису (имя сервиса передается как параметр)
remove — оставляет только те строки журнала в формате syslog, которые
не содержат указанную строку (я поставил кавычки
вокруг «$*»
и наделал remove1, remove2 и т.д. так как не понял как указать
несколько подшаблонов для egrep в одной строке;
кстати, параметры подставляются в shell, так что спецсимволы
тоже нельзя использовать)
removeheaders — удаление стандартных полей (дата, время, имя хоста,
этикетка сервиса и номер процесса)
removeservice — выделяет из журнала в формате syslog строки, не
относящиеся к указанному сервису (имя сервиса передается как параметр)

Параметры по умолчанию хранятся в файле /usr/share/logwatch/default.conf/logwatch.conf (параметры от разработчика),
/usr/share/logwatch/dist.conf (параметры дистрибутива, пусто в RHEL) и /etc/logwatch/conf/logwatch.conf (локальные параметры,
ранее /etc/log.d/conf/logwatch.conf, /etc/log.d/logwatch.conf есть символьная ссылка на него):

LogDir — каталог, относительно которого рассматриваются имена файлов
MailTo — кому отправлять отчет
Print — вместо посылки отчета по почте выдать его на stdout
Save — вместо посылки отчета по почте сохранит его в указанном файле
Archives — использовать версии журналов, созданных logrotate
Range — рассматриваемый временной интервал: All, Today, Yesterday (вчерашние календарные сутки)
Detail — уровень подробности отчета: от 0 до 10 или Low, Med, High
Service — All или имя фильтра из /etc/log.d/scripts/services/ (можно указывать несколько фильтров)
LogFile — All или имя группы журналов (можно указывать несколько групп)

В дополнение к logwatch.conf каждый из 3 каталогов содержит подкаталоги services и logfiles,
которые позволяют задать параметры для конкретных групп файлов (имя-группы-журналов.conf) и сервисов (имя-сервиса.conf), а также
ignore.conf (содержит регулярные выражения, описывающие строки, которые не должны появиться в отчётах) и override.conf.

Ключи запуска:

—-help
—detail уровень (уровень продробности отчета: high (10), med (5) или low (0))
—logfile группа-журналов (обрабатывать только журналы
данной группы; группа задается символическим именем в конфигурационном
файле; можно задавать несколько групп)
—service имя-сервиса (обрабатывать только те записи
в журналах, которые относятся к данному сервису; сервис задается
символическим именем в конфигурационном файле;
можно задавать несколько сервисов; имя All вызывает обработку
записей для всех сервисов)
—output {stdout|mail|file} (по умолчанию, stdout)
—format {text|html} (по умолчанию, text)
—print (выдавать отчет на stdout; отсутствует с версии ?)
—save имя-файла (записать отчет в указанный файл; отсутствует с версии ?)
—mailto адрес (послать отчет по указанному адресу)
—filename имя-файла (сохранить отчёт в файл)
—range интервал-дат (обрабатывать только те записи
в журналах, которые относятся к данному интервалу времени, даты в формате Date::Manip (по умолчанию ‘Yesterday’),
период задаёт размер интервала (по умолчанию ‘for that day’):
Yesterday, Today, All, дата[ период],
between дата1 and дата2[ период], since дата[ период],
Help — рассказывает о синтаксисе)
—archives (обрабатывать не только текущие версии журналов, но и созданные logrotate старые копии)
—hostlimit имя-хоста[,…] (ограничиться информацией с указанных хостов)
—hostname имя-хоста (указать имя хоста в журнале)
—html_wrap число (число символов в строке для вывода в формате HTML)
—numeric (не преобразовывать IP в доменные имена)
—debug уровень (от 0 до 100)
—logdir каталог
—no-oldfiles-log (не информировать о старых дурналах во временном каталоге)

Основной способ использования состоит во включении
файла 00-logwatch или 0logwatch (начинается с «00», чтобы выполняться до logrotate)
в каталог /etc/cron.daily, что вызывает ежедневное выполнение
logwatch с параметрами по умолчанию.

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

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

Соответствие между формальным именем источника и реальным
устройством или программой:

local0 — Cisco и прочие железки
local1 — bind и DNS
local3 — ftp/snort (есть специальное имя источника, но Solaris 2.5 его не знает)
local4 — squid
local5 — POP3/IMAP
local6 — tac_plus
local7 — загрузка Linux

На сервере должен быть открыт экран для порта 514/udp (можно ограничить
исходные адреса пакетов, но это поможет только от случайностей).
Запуск syslogd (параметры в /etc/rc.d/init.d/syslog или /etc/sysconfig/syslog)
должен быть с ключами «-r -m 0» (и еще «-x», если на этом же компьютере работает
сервер DNS). Запуск klogd с ключами «-2 -c 1». Настройка syslog.conf:

*.crit — сообщения уровня серьезности CRIT и выше выдавать на терминалы
и записывать в отдельный файл (chmod 600), свои сообщения посылать
на запасной сервер; sendmail считает критическими сообщения о проблемах
с приемом письма
kern — создать файл kern для сообщений всех уровней (chmod 600)
mail — создать файл mail для сообщений всех уровней (без
синхронизации)
auth, authpriv — создать файл secure для сообщений всех уровней (chmod
600)
news — в директории news создать для каждого уровня серьезности отдельный
файл (debug без синхронизации)
cron — создать файл cron для сообщений всех уровней (cron в RH 6.2
и Solaris 2.5 не умеют использовать syslog)
local0 — в директории cisco создать для каждого уровня серьезности
отдельный файл (err и ниже без синхронизации)
local1 — в директории bind создать для каждого уровня серьезности
отдельный файл (err и ниже без синхронизации)
local3 — в директории ftp создать для каждого уровня серьезности
отдельный файл (info и debug без синхронизации)
local5 — создать файл imap.log для сообщений всех уровней
local6 — создать файл tac_plus.log для сообщений всех уровней
local7 — файл boot.log (сообщения при загрузке системы и запуске или
остановке syslogd и klogd)
все сообщения уровня INFO и выше, не попавшие в один из определенных
выше файлов, записывать в файл messages (chmod 600)

На клиентских компьютерах настраиваем syslog так, чтобы все
сообщения передавались на сервер syslog, сообщения об ошибках
дублировались в /var/log/syslog, сообщения о критическом состоянии
дублировались на консоль, терминалы пользователей.
На компьютерах с linux также сбрасывать в локальный файл сообщения о
загрузке (local7, boot.log). Запасной сервер syslog должен принимать
сообщения критического уровня из сети и записывать их в файл
(дырка в экране, ключ запуска «-r»).

logrotate: хранить вечно, менять версии по возможности реже
(ежемесячно, кроме squid), сбрасывать в отдельные
директории (кроме squid) и сжимать (в
отложенном режиме, кроме ftpd, linuxconf, sendfax),
[ошибки и удаляемые файлы посылать мне]. Привести в
соответствие параметры для файла syslog.

Настроить /etc/logwatch/scripts и /usr/share/logwatch/.

в т.ч. systemd-journal-upload, systemd-journal-remote

RFC 3164. C. Lonvick, The BSD Syslog Protocol, August 2001.
RFC 3195. D. New, M. Rose, Reliable Delivery for syslog, November 2001.
RFC 5424. R. Gerhards, The Syslog Protocol, March 2009
RFC 5425. F. Miao, Y. Ma, J. Salowey, Transport Layer Security (TLS) Transport Mapping for Syslog, March 2009
RFC 5426. A. Okmianski, Transmission of Syslog Messages over UDP, March 2009
RFC 5427. G. Keeni, Textual Conventions for Syslog Management, March 2009
RFC 5674. S. Chisholm, R. Gerhards, Alarms in Syslog, October 2009
RFC 5675. V. Marinov, J. Schoenwaelder, Mapping SNMP Notifications to SYSLOG Messages, October 2009
RFC 5676. J. Schoenwaelder, A. Clemm, A. Karmakar, Definitions of Managed Objects for Mapping SYSLOG Messages to SNMP Notifications, October 2009
RFC 5848. J. Kelsey, J. Callas, A. Clemm, Signed Syslog Messages, May 2010
RFC 6012. J. Salowey, T. Petch, R. Gerhards, H. Feng, Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog, October 2010
RFC 6587. R. Gerhards, C. Lonvick, Transmission of Syslog Messages over TCP, April 2012
sysklogd («стандартный» syslogd и klogd)
logwatch
logrotate
swatch — Tool for actively monitoring log files
Syslog Device Configuration MIB (draft-ietf-syslog-device-mib-00.txt)
syslog-ng (RFC 3164 и RFC 5424;
маршрутизация сообщения в зависимости от источника, текста сообщения, использование TCP; генерация имени журнала в зависимости от даты, сжатие, шифрование;
выдача журнала на stdin запускаемой программы и много других полезных вещей; версия 3.5.6 в RHEL 7.5)
eventlog (стуктурированный журнал, дополнение к syslog-ng)
Cryptographic Support for Secure Logs on Untrusted Machines

Epylog (разбор журналов с множества серверов, сброшенных в общий loghost)

Bog BOS: syslog — сетевой системный журнал

Источник

From Wikipedia, the free encyclopedia

Syslog

Original author(s)	Eric Allman
Initial release	1980s
Operating system	Unix-like
Type	System logging
Website	datatracker.ietf.org/wg/syslog/charter/

When operating over a network, syslog uses a client-server architecture where a syslog server listens for and logs messages coming from clients.

History[edit]

Message components[edit]

Facility[edit]

Facility code	Keyword	Description
0	kern	Kernel messages
1	user	User-level messages
2	mail	Mail system
3	daemon	System daemons
4	auth	Security/authentication messages
5	syslog	Messages generated internally by syslogd
6	lpr	Line printer subsystem
7	news	Network news subsystem
8	uucp	UUCP subsystem
9	cron	Cron subsystem
10	authpriv	Security/authentication messages
11	ftp	FTP daemon
12	ntp	NTP subsystem
13	security	Log audit
14	console	Log alert
15	solaris-cron	Scheduling daemon
16–23	local0 – local7	Locally used facilities

The mapping between facility code and keyword is not uniform in different operating systems and syslog implementations.^[8]

Severity level[edit]

The list of severities is also described by the standard:^[4]^: 10

Value	Severity	Keyword	Deprecated keywords	Description	Condition
0	Emergency	`emerg`	`panic`^[9]	System is unusable	A panic condition.^[10]
1	Alert	`alert`		Action must be taken immediately	A condition that should be corrected immediately, such as a corrupted system database.^[10]
2	Critical	`crit`		Critical conditions	Hard device errors.^[10]
3	Error	`err`	`error`^[9]	Error conditions
4	Warning	`warning`	`warn`^[9]	Warning conditions
5	Notice	`notice`		Normal but significant conditions	Conditions that are not error conditions, but that may require special handling.^[10]
6	Informational	`info`		Informational messages	Confirmation that the program is working as expected.
7	Debug	`debug`		Debug-level messages	Messages that contain information normally of use only when debugging a program.^[10]

Message[edit]

The content field should be encoded in a UTF-8 character set and octet values in the traditional ASCII control character range should be avoided.^[13]^[14]

Logger[edit]

Network protocol[edit]

Limitations[edit]

The network protocol is simplex communication, with no means of acknowledging the delivery to the originator.

Outlook[edit]

Managed Security Service Providers attempt to apply analytical techniques and artificial intelligence algorithms to detect patterns and alert customers to problems.^[20]

Internet standard documents[edit]

The BSD syslog Protocol. RFC 3164. (obsoleted by The Syslog Protocol. RFC 5424.)
Reliable Delivery for syslog. RFC 3195.
The Syslog Protocol. RFC 5424.
TLS Transport Mapping for Syslog. RFC 5425.
Transmission of Syslog Messages over UDP. RFC 5426.
Textual Conventions for Syslog Management. RFC 5427.
Signed Syslog Messages. RFC 5848.
Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog. RFC 6012.
Transmission of Syslog Messages over TCP. RFC 6587.

References[edit]

^ «Eric Allman». Internet Hall of Fame. Retrieved 2017-10-30.
^ «3 great engineering roles to apply for this week». VentureBeat. 2021-08-06. Retrieved 2021-08-16.
^ «Efficient and Robust Syslog Parsing for Network Devices in Datacenter Networks».{{cite web}}: CS1 maint: url-status (link)
^ ^a ^b ^c Gerhards, Rainer. The Syslog Protocol. doi:10.17487/RFC5424. RFC 5424.
^ «LXer: Patent jeopardizes IETF syslog standard».
^ «IETF IPR disclosure on HUAWEI’s patent claims».
^ «Syslog Facility». Retrieved 22 November 2012.
^ «The Ins and Outs of System Logging Using Syslog». SANS Institute.
^ ^a ^b ^c «syslog.conf(5) — Linux man page». Retrieved 2017-03-29.
^ ^a ^b ^c ^d ^e «closelog, openlog, setlogmask, syslog — control system log». Retrieved 2017-03-29.
^ «Severity Levels for Syslog Messages». docs.delphix.com. Retrieved 2021-08-16.
^ Gerhards, Rainer (March 2009). «RFC 5424 — The Syslog Protocol». doi:10.17487/RFC5424. This document describes a layered architecture for syslog. The goal of this architecture is to separate message content from message transport while enabling easy extensibility for each layer.
^ «Transmission of Syslog Messages over TCP». www.ipa.go.jp. Retrieved 2021-08-16.
^ Gerhards, Rainer (March 2009). «rfc5424». datatracker.ietf.org. Retrieved 2021-08-16.
^ «logger Command». www.ibm.com. Retrieved 2021-08-16.
^ «Syslog Server». www.howtonetwork.com. Retrieved 2021-08-16.{{cite web}}: CS1 maint: url-status (link)
^ Gerhards, Rainer (March 2009). «RFC 5424 — The Syslog Protocol». doi:10.17487/RFC5424.
^ Fuyou, Miao; Yuzhi, Ma; Salowey, Joseph A. (March 2009). Miao, F; Ma, Y; Salowey, J (eds.). «RFC 5425 — TLS Transport Mapping for Syslog». doi:10.17487/RFC5425.
^ «ATNA + SYSLOG is good enough». Healthcare Exchange Standards. 2 January 2012. Retrieved 2018-06-06.
^ Yamanishi, Kenji; Maruyama, Yuko (2005-08-21). «Dynamic syslog mining for network failure monitoring». Proceedings of the Eleventh ACM SIGKDD International Conference on Knowledge Discovery in Data Mining. KDD ’05. Chicago, Illinois, USA: Association for Computing Machinery: 499–508. doi:10.1145/1081870.1081927. ISBN 978-1-59593-135-1. S2CID 5051532.
^ «Security Issues in Network Event Logging (syslog)». IETF.

External links[edit]

Internet Engineering Task Force: Datatracker: syslog Working Group (concluded)
SANS Institute: «The Ins and Outs of System Logging Using Syslog» (white paper)
National Institute of Standards and Technology: «Guide to Computer Security Log Management» (Special Publication 800-92) (white paper)
Network Management Software: «Understanding Syslog: Servers, Messages & Security»
Paessler IT Explained — Syslog
MonitorWare: All about Syslog

Источник

History[edit]

Message components[edit]

Facility[edit]

Severity level[edit]

Message[edit]

Logger[edit]

Network protocol[edit]

Limitations[edit]

Outlook[edit]

Internet standard documents[edit]

See also[edit]

References[edit]

External links[edit]

History[edit]

Message components[edit]

Facility[edit]

Severity level[edit]

Message[edit]

Logger[edit]

Network protocol[edit]

Limitations[edit]

Outlook[edit]

Internet standard documents[edit]

See also[edit]

References[edit]

External links[edit]

Преимущества ведения журналов

Компоненты серверов Syslog

Как это работает

Серверы Syslog

Формат Syslog

Сообщения Syslog

Наиболее важные файлы журналов для отслеживания и мониторинга

Плюсы и минусы Syslog

Лучшие практики

Система Syslog и журналы логов в Linux

Как устроена система регистрации событий?

log файлы и их расположение в Linux

Некоторые специальные файлы журналов

Использование syslog

Примеры настроек syslog.conf

Настройка syslog для iptables

Крупнейшая в Европе школа английского языка

Онлайн школа английского языка

Школа английского языка по Skype

ИТ База знаний

Полезно

Навигация

Серверные решения

Телефония

Корпоративные сети

Популярное и похожее

Курс по сетям

Что такое Active Directory и LDAP?

Погружение в Iptables – теория и настройка

Ноу-хау: разбираемся в преимуществах виртуализации

Composer – Моцарт для вашего PHP

DevSecOps – кратко о том, как улучшить жизнь

HyperText Transfer Protocol (HTTP)

Еженедельный дайджест

Syslog серверы

Syslog сообщения

Недостатки syslog

Содержание

История

Компоненты сообщения

Средство

Уровень опасности

Сообщение

Регистратор

Сетевой протокол

Ограничения

Outlook

Стандартные документы Интернета

Перенаправление событий Windows (Event Log) на сервер syslog Linux

Вступление

Описание

Настройка

Заключение

Видео

What is Syslog?