Syslog что это за программа

void openlog(const char * ident , int option , int facility );
void syslog(int priority , const char * format , . );
void closelog(void);

void vsyslog(int priority , const char * format , va_list ap );

ОПИСАНИЕ

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

openlog() устанавливает связь с программой, ведущей системный журнал. Строка ident добавляется к каждому сообщению и обычно представляет собой название программы. Аргумент option указывает флаг управляющий работой openlog() и соответствующих вызовов syslog() . Аргумент facility устанаваливает значение по умолчанию если не указываются соответствующие параметры при вызовах syslog() . Значения option и facility приводятся ниже. Использование openlog() тоже необязательно, оно при необходимости автоматически будет вызвано функцией syslog() , и в этом случае значение ident будет установлено равным NULL.

syslog() создает сообщение для журнала, которое передается syslogd (8). priority получаеся при логическом сложении facility и level , описанных в следующей главе. Остаются аргументы format (как и в printf (3)) и аргументы для format , кроме того, что сочетание %m будет заменено сообщением об ошибке strerror ( errno ) и будет добавлен завершающий символ новой строки.

ПАРАМЕТРЫ

Этот раздел описывает параметры, используемые для установки значений option , facility и priority .

option

Аргумент option , относящийся к функции openlog() , имеет значение ИЛИ для следующих выражений: LOG_CONS — написать сообщение об ошибке прямо на консоли, если была ошибка при записи данных в системный журнал; LOG_NDELAY — устанавливать соединение немедленно (обычно оно устанавливается только при поступлении первого сообщения); LOG_NOWAIT — не ожидает дочерние процессы которые могут быть созданы во время отправки этого сообщения. (Библиотека GNU C не создает в это время дочерних процессов, поэтому эта опция не будет иметь эффекта в Linux.) LOG_ODELAY — обратно от LOG_NDELAY ; открытие соединения откладывается до вызова syslog() . LOG_PERROR — посылать сообщение еще и в поток stderr (отсутствует в SUSv3); LOG_PID — добавлять к каждому сообщению идентификатор

facility .

Аргумент facility используется для указания типа программы, записывающей сообщения. Это позволяет файлу конфигурации указывать, что сообщения от различных программ будут по-разному обрабатываться. LOG_AUTH — сообщения о безопасности/авторизации (РЕКОМЕНДУЕТСЯ использовать вместо него LOG_AUTHPRIV ). LOG_AUTHPRIV — сообщения о безопасности/авторизации (частные); LOG_CRON — демон часов ( cron и at ); LOG_DAEMON — другие системные демоны; LOG_KERN — сообщения ядра; LOG_LOCAL0 до LOG_LOCAL7 зарезервированы для определения пользователем; LOG_LPR — подсистема принтера; LOG_MAIL — почтовая подсистема; LOG_NEWS — подсистема новостей USENET; LOG_SYSLOG — сообщения, генерируемые syslogd ; LOG_USER (по умолчанию) — общие сообщения на уровне пользователя ; LOG_UUCP — подсистема UUCP

level ,

определяющая степень важности сообщения. Далее значения приводятся по понижению степени их важности: LOG_EMERG — система остановлена; LOG_ALERT — требуется немедленное вмешательство; LOG_CRIT — критические условия; LOG_ERR — ошибки; LOG_WARNING — предупреждения; LOG_NOTICE — важные рабочие условия; LOG_INFO — информационные сообщения; LOG_DEBUG — сообщения об отладке.

Функция setlogmask (3) может использоваться для ограничения доступа на указанные уровни.

СООТВЕТСТВИЕ СТАНДАРТАМ

Функции openlog() , closelog() , и syslog() (но не vsyslog() ) описаны в SUSv2 и POSIX 1003.1-2001. POSIX 1003.1-2001 описывает только значения LOG_USER и LOG_LOCAL* для facility . Кроме значений LOG_AUTHPRIV и LOG_FTP , другие значения facility присутствуют в различных системах Unix. Значение LOG_PERROR для option не описано в POSIX 1003.1-2001, но присутствует в большинстве версий Unix.

ПРИМЕЧАНИЯ ПО ИСТОРИИ

Функция syslog появилась в BSD 4.2. BSD 4.3 описывает openlog (), syslog (), closelog (), и setlogmask (). 4.3BSD-Reno описывает vsyslog (). разумеется ранние версии функций v* использовали механизм , не совместимый с .</</p>

ЗАМЕЧАНИЯ

Аргумент ident функции openlog() , по-видимому, заносится один в один. Поэтому, если строка, на которую он указывает, меняется, то syslog() может начать подготавливать измененную строку. В случае же, когда строка уже не существует, результаты неопределены. Наиболее переносимо будет использовать строковую константу.

Никогда не передавайте строку с предоставленным пользователем форматом, лучше используйте syslog(«%s», string);

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

Краткое описание стандартных форматов сообщений syslog.

Форматы Syslog

В настоящее время существует два стандартных формата сообщений syslog:

• BSD-syslog или унаследованные сообщения syslog
• IETF-syslog сообщения

Формат SD-syslog (RFC 3164)

Общий размер сообщения не может быть больше 1024 байт.

Сообщение BSD-syslog состоит из следующих частей:

• PRI — представляет Facility и Severity сообщения. Это вычисляемое значение: Facility * 8 + Severity
• HEADER — содержит метку времени и имя хоста (без имени домена) или IP-адрес устройства.
• MSG — содержит имя программы или процесса, сгенерировавшего сообщение, и текст самого сообщения.

Пример сообщения BSD-syslog:

Aug 11 14:09:07 webserver syslogd: restart

Формат IETF-syslog (RFC 5424)

Сообщение IETF-syslog состоит из следующих трех частей:

[Заголовок] [Структурированные данные] [Сообщение]

Заголовок

• PRI — представляет Facility и Severity сообщения. Это вычисляемое значение: Facility * 8 + Severity
• VERSION — номер версии стандарта протокола syslog. В настоящее время это значение может быть только 1.
• ISOTIMESTAMP — Время создания сообщения в формате ISO 8601 (yyyy-mm-ddThh:mm:ss+-ZONE).
• HOSTNAME — Устройство, которое первоначально отправило сообщение.
• APPLICATION — Устройство или приложение, которое сгенерировало сообщение.
• PID — Имя процесса или идентификатор процесса приложения, отправившего сообщение.
• MESSAGEID — Идентификационный номер сообщения.

Структурированные данные

Часть сообщения может содержать мета-информацию о сообщении syslog или специфическую для приложения информацию, такую как счетчики трафика или IP-адреса. Структурированные данные состоят из блоков данных, заключенных в скобки ([]). Каждый блок включает в себя идентификатор блока и одну или несколько пар имя=значение.

[exampleSDID@0 iut="3" eventSource="Application" eventID="1011"][examplePriority@0 ]

Сообщение

Часть Сообщение (MSG) содержит текст самого сообщения. Набор символов, используемый в сообщении должен бытьбыть UNICODE, закодированный с помощью UTF-8. Если приложение syslog кодирует MSG в UTF-8, строка должна начинаться с маски порядка байтов Юникода (BOM).

Пример сообщения IETF-syslog:

1 2003-10-11T22:14:15.003Z machine application 1234 ID47 [example@0 ] BOMmyapplication is started

Примечания: APPLICATION, PID, MESSAGEID и Структурированные данные могут быть NULL, что представлено символом тире «-«. Часть сообщения может быть абсолютно пустой (например, отправляется только Структурированные данные):

1 2003-10-11T22:14:15.003Z machine application - - - BOMmyapplication started

What is Syslog? An Introduction to the System Logging Protocol

You may have seen the term «Syslog» bandied about, and it may register to you as one of those tech words you probably don’t need to understand. But it’s actually extremely useful to learn about it, so we’ve put together this introductory guide to the «System Logging Protocol,» also known as Syslog.

As its name suggests it is used for devices such as routers, switches, firewalls, Wi-Fi access points and Linux servers to generate their own logs. Windows servers use Event Logs but they can be used in conjunction with Syslog servers. Its function is to store events or log messages locally inside of the device of choice and promptly send the Event or Log Information to a Syslog Server in order to get, sort, and filter all the logs and data therein.

In simple terms, a network device or server that is already in a company’s network can be configured in such a way that allows it generate Syslog messages and then forward them to a Syslog server or Daemon. What this does is allow network administrator to monitor and accurately track the devices hooked up to the network, and properly asses issues or problems that they might need to fix whenever they show up in the logs.

After that, a message is sent from the initial device to the server (also referred to as collector) using UDP, which is protocol that does not require connection. For the sake of swiftness and easy understanding, these messages are sent as short texts that don’t go over the 1024 byte threshold.

However, since UDP is used to send the message, the originator doesn’t get any kind of receipt of transmission or arrival. This means that packets could potentially get lost during the transmission forever.

This complication can be easily circumvented by using a server (or Daemon) to collect, sort, classify and setup alert for events and their location inside of the network

A Server/Daemon allows you to collect, filter, organize, setup alerts for certain events from one location within your network. Thus, having tools such as Syslog and its log of information data gives businesses the possibility of elaborating reports, diagrams and charts to accurately visualize elements and aspects of systems and get better IT infrastructure visualization.

When is Syslog used?

Perhaps the biggest question for people who are used to using SNMP might be “What’s the use of Syslog if SNMP traps are already a thing and they have similar functionality?” There is some truth to this, since they are both used to send alerts and messages to central servers without the need of polls. Just as an event happens, messages are sent without having to wait for servers to poll them for status.

However there is a pretty big difference and it’s that SNMP traps have special predefined formats contained in a MIB file. In the occurrence that an interface on a switch goes down, the MIB file instantaneously defines an “ifDown” trap message that communicates important information that includes but is not limited to things such as the specific interface that went down, for example. This provides the software users to know in advance what info the message will have have in its content . However, this is not always the case.

SNMP traps are best suited for events that are well defined, such as interface resets or some very specific devices hooked up to the network. Syslog events, on the other hand, are much better for events that are, by nature, broader and more general in scope, and thus harder to predict.

However, while he broad nature of syslog messages is a huge advantage, it can also be a great hinderance. It can be quite challenging to parse through impossibly long and numerous events in logs from so many different systems from various vendors and simultaneously make sense of all of them. How can one know which messages represent certain functions? Which ones are about just informational messages and which ones are critical events that must be tended to immediately?

To deal with these questions, the Syslog protocol (which is defined in RFC 5424) provides these free-form messages with special fields called “facility” and “severity,” which have their own codes of identification for easier parsing.

Facility and Severity codes

The severity value is pretty straightforward: a single number somewhere between 0 and 7 shows the level of importance a message has.

Numerical Code

Severity

Meaning

При подготовке материала использовались источники:
https://www.opennet.ru/man.shtml?topic=syslog&category=3
https://g-soft.info/articles/3080/format-soobscheniy-syslog/
https://blog.invgate.com/what-is-syslog