Now that the syslog implementation for the upcoming LogMeister v5 release is functionally complete, I thought it would be a good time to take a look at how it all fits together.
Note: this screenshot shows how the interface appears on Windows 10 TH2; different Windows operating systems will impart a different “look”.
Above is the first and most important screen you’ll see when enabling syslog reception in LogMeister, as it defines which incoming channels will be active. As you can see, syslog messages can be received via UDP and/or TCP, and a further option of secure messaging using SSL/TLS is also available. Obviously the TLS option requires that the computer running LogMeister has a valid certificate, both to verify its identity to the client and to provide the tools for message encryption. Optionally LogMeister can also be set to require a certificate at the client end of the connection, for mutual identity verification.
Once the appropriate doors have been opened for incoming syslog messages, the next step is to define where to put them. In keeping with LogMeister’s model, you do this by defining one or more “feeds”.
The very first page of the syslog feed wizard lets you decide which channel, or combination of channels, can provide incoming messages. This opens up the possibility of segregating messages into different feeds by delivery protocol. As with existing LogMeister feeds from Windows event logs, text logs and so on, a later page in the wizard lets you build up sophisticated rules to further constrain which messages a feed will accept. For example, you could create a feed that deals only with messages from specific clients, be they servers, client PCs or hardware firewalls or similar devices. Alternatively you could just as easily create a feed that records and reacts to “Emergency” level messages only. The bottom line is that you can organize and filter the incoming messages in pretty much any way that makes sense to you, and that’s the power of LogMeister’s way of doing things.
Incoming messages are only part of the syslog implementation; LogMeister v5 has also added syslog transmission as one of its “notification” options. As you would expect this enables forwarding of log data from Windows event logs, text logs and of course received syslog messages, but it goes further than that; it also allows you to generate your own custom syslog messages in reaction to seeing a particular situation developing on one of your servers. To make use of this new facility, you must first define one or more syslog destinations as shown in the screenshots below.
Each destination specifies the address (network name or ip address), protocol and port used for syslog transmission. Mirroring the incoming side of things, UDP, TCP and secure TCP protocols are available. Additionally you have control over the format of the messages sent to this destination. In an ideal world we’d be using the newer (RFC5424) format (together with a frame-count prefix) for all our syslog messages, but not all syslog servers can cope with this, so LogMeister gives you control over which format is sent out to a particular server.
Once the necessary destinations have been defined you can proceed to use them in your outgoing syslog notification messages. As you can see below, each message is a blend of your own text together with fields drawn from the original log data (whether from syslog, eventlogs, text logs etc)
As with the other notification types, you can also decide what merits the sending of your syslog notifications. For example you might wish to forward a range of eventlog messages as a matter of course, or send a certain message only in response to a very specific set of circumstances; the choice is yours.
That concludes the first look at the syslog implementation coming to the major new release of LogMeister. In later posts I’ll focus on new features coming to both LogMeister and its eventlog-only sister product, EventMeister. We’re now expecting the first v5 release to be made early in the new year, but don’t forget that customers who buy the existing v4 releases will get an automatic upgrade to v5 when it is released.