In the world of processing, Syslog is the standard for Message Logging. Logfile also refers to a file that stores events occurring in an operating system or software that runs, as well as messages between users in a communication software. Logging also means keeping a log. In the simplest case, these messages are stored in a single logfile. As mentioned, Syslog is a standard protocol, so it is defined for that RFC and its RFC number is 5424. https://tools.ietf.org/html/rfc5424
Many devices and operating systems and software that we deal with daily may be used to record incidents from the Syslog protocol as standard. Such as: routers, printers, message receivers or message receivers, etc. As a result of the use of a standard, logging data can be combined from different systems in a central repository, which makes it easy to manage and review them.
Information generated by a Syslog message builder includes facility code and severity level. Also, components such as the Process ID of the Originator, a timestamp, and an IP address or a drive address are also sent to the Syslog Receiver. The Facility code is used to identify the type of program that stores the Log message. So, with messages that have different Facility codes, they are treated differently. Facility codes are also defined in RFC 3164 at https://tools.ietf.org/html/rfc3164 . For example, the Facility Code is zero (0) for log messages generated in the kernel. Or the Facility Code is two (2) related to the Mail system logs.
In RFC 3164, other than Facility codes, there is also a list of different severity levels. As you know, the severity level determines the importance of each log. For example, an Emergency grade of zero is of the highest importance, meaning that the system is unusable, and it is clear that these logs are never produced by Applications. Again, as an example, an Alert value of 1 (the lower the value is, the importance of the log is higher) relates to an event log that needs to be resolved very quickly: such as interrupting the communication with the main ISP on routers, except Alerts is considered.
S yslog architecture :
Syslog architecture is very simple. As you can see in the screenshot, Syslog Messages are sent to the Syslog server as a Central Repository. Syslog Server also sends alerts to administrators, and Administrators also work to fix reported issues.
The first problem that you might be able to get from Syslog is that this protocol does not have the basics for the format of the error messages it sends. So developers work in this way. For example, some developers mention the message in detail and even its method of correction, and others do not care about its readability, and the user is forced to read the documentation about how to identify the cause of the particular Developer's error message.
The second objection is to use Syslog from the UDP protocol. Because UDP is a Connectionless protocol, so no confirmation that the message is received by the Syslog Server is not sent to the message sender, and therefore there is no guarantee to ensure that all error messages are received and that the administrator who uses the Syslog Server may That will lose some of the logs.
Finally, Syslog Messages do not have Authentication. As a result, you can imagine that a hacker will be able to send fake Syslog messages to you or create other security issues.
One of the Syslog compatibility monitoring software is ManageEngine's OPManager, SolarWinds Orion NPM, and OpenNMS. In the future, we will review the Syslog user's manual and its use and configuration for VMware in separate articles.