WinSyslog

The Enhanced Syslog Server

Tag Archives: syslog server

How To Configure a Syslog Server

Posted on by

This article is also available as an interactive guide. Simply follow this link:
How to configure a Syslog Server – Interactive Tutorial
Macromedia Flash Player is needed.

1. Right Click on Services -> Add Service -> Syslog Server

2. Give some name of this Syslog Server. I will be using the default name which is “Syslog Server 1”. Click on “Next” and then click on “Finish”

3. Now you will see a new node in the Tree View on the left hand side under the “Running Services” node with a name “Syslog Server 1”. Click on it. It will open up the configuration page for this service on the right hand side as shown below:

4. Now change the protocol type to UDP (if you are reading the step by step guide for configuring with PIX). Change the port to 514 as shown below:

5. Once you make these changes, you will see a yellow highlighted text that says “You have changed but not saved”. Press the Save button on its right to save the settings.

6. Now click on the play button at the top as shown below:

Forwarding NT Event Logs to a Syslog Server

Posted on by

Last updated 2016-09-28 by Pascal Withopf, using Winsyslog 13.3.

In this scenario, an event log monitor is used to forward all events written to the NT Event Log to a syslog server. This can either be another instance of MonitorWare or any standard syslog server, for example on a UNIX platform. The data will be forwarded in the EventReporter compatible format, as the processes running on the syslog server require that format (this is just an assumption).

This is a scenario often used together with UNIX based management solutions. The event log monitor is used here to forward events into a central repository, where it will be analyzed using pre-existing procedures.

Please note that if the data is to be forwarded to another instance of a MonitorWare Agent, we highly recommend using the SETP protocol instead of syslog, but this is beyond the scope of this scenario here.

Step 1 – Defining a Rule Set for Syslog Forwarding

The rule set specifies what action to carry out. You might be tempted to define the service first, but starting with the rule set makes things easier as it already is present when the service will be defined later and needs to be bound to a rule set.

To define a new rule set, right click “Rules”. A pop up menu will appear. Select “Add Rule Set” from this menu. On screen, it looks as follows:

Then, a window opens. Change the name of the ruleset to whatever name you like. We will use “Forward To Syslog Server” in this example. Select “Syslog Forwarding”. Do not select any other options for this sample. Also, select the “Create a Rule for each of the following actions” setting. Click “OK”. The screen looks as follows:

The window closes and the client shows a newly created rule set. Please expand it in the tree view until you have the following screen contents:

As you can see, we have a “Forward Syslog” action configured. We will review the settings just for your information. Click on “Filter Conditions”:

As you can see, no filter conditions are selected. This means that the all information units (the event log information) will be matched by these filter conditions. As such, the rules for the “Forward Syslog” action will always be carried out.

Now let us check the “Syslog” action itself. Please select it in the tree view:

As you can see, some useful defaults are already there. It forwards syslog messages via the standard UDP protocol to the standard port of 514. These values are specified by the syslog standard and most syslog servers will expect them. Only change them if you definitely know that the syslog server is configured to use other values. If in doubt, use the default ones.

However, there are also some things that need to be completed and changed for this scenario.

Obviously, the syslog server to receive the message needs to be specified. You can use either a system name or IP address. In our sample, we will use the IP address, because this is faster and more reliable as it does not depend on DNS name resolution. Our target syslog server is on address 10.0.0.1.

After the changes, the dialog looks as follows:

Now you have a workable rule set for forwarding event monitor data to the syslog server.

Step 2 – Create an Event Log Monitor Service

Now we need to define an “event log monitor” service. It is the process that monitors the Windows event log for new entries and creates information units as soon as a new entry is found. These information units are then passed to the rule set which in turn forwards them to the syslog server configured in step 1.

To define the event log monitor, right click on “Services”, then select “Add Service” and the “Event Log Monitor”:

There, you will see the newly created service beneath the “Services” part of the tree view:

As you can see, the service has been created with the default parameters. As such, it monitors all event logs that are present on the system. It also has some protection against overruns of the receiving system or intermediary routers. It monitors the event log in a 60 second interval (sleep time of 60.000 milliseconds), which is the recommended value for typical installations.

Please note that the “Forward To Syslog Server” rule set has been automatically assigned as the rule set to use. This is the case because we already created it and it is the only rule set. By default, the wizard will always assign the first rule set visible in the tree view to new services. If that is not the intended rule set, you need to change it to the correct one here in the service definition.

Also, please note that the wizard uses the default properties from the “Service Defaults”. Obviously, if these are changed, the default properties for new services will differ.

Finally, we review the log specific advanced properties. As a sample, we will go over the application log advanced properties. To do so, click the “Event Channels” button:

Most importantly, we can select the syslog facility that is to be used for the generated information units here. In our sample, we leave it as local. We also leave the “Report Truncated Log” option checked. This option will generate a warning message if the respective Windows log is truncated, for example by operator request. If that happens during day-to-day operations in you environment, you might want to uncheck it.

This procedure completes the configuration of the event log monitor.

Step 3 – (Re-)Start the MonitorWare Agent Service

MonitorWare Agent cannot dynamically read changed configurations. As such, it needs to be restarted after such changes. In our sample, the service was not yet started, so we simply need to start it. If it already runs, you need to restart it.

Service control can be done with both the respective operating system capabilities (like service manager MMC) or with the configuration client. These are shown in the red surrounded area in the following screen shot:

The buttons resemble Windows service manager – start, stop and restart. In this sample, stop and restart are grayed out because the service is not running.

After service restarts, the new definitions are active and MonitorWare Agent will forward all events from the Windows event log to the configured syslog server. Please note that on the first run, all already existing events will be forwarded. Therefore, this might take a little while. On all successive service start, only new events will be forwarded.

Creating a simple Syslog Server

Posted on by

Last updated 2016-08-26 by Jan Gerhards, using Winsyslog 13.2.

In this scenario, a simple Syslog server will be created. No other services are configured. The Syslog server will operate as a standard Syslog server on the default port of 514/UDP. All incoming data will be written to a single text file.

Step 1 – Defining a Rule Set for File Logging

The rule set specifies what action to carry out. You might be tempted to define the service first, but starting with the rule set makes things easier as it will be already present when the service is defined later and needs to be bound to a rule set.

To define a new rule set, right click “RuleSets”. A pop up menu will appear. Select “Add Rule Set” from this menu. On screen, it looks as follows:

Then, a wizard starts. Change the name of the rule set to whatever name you like. We will use “Write Syslog Log File” in this example. The screen looks as follows:

After that, select “Add a Rule for each of these Actions”. You should then be able to change settings in the before greyed-out area. There, select “File Logging” (subitem of “Storing Actions”). Your screen should now look like this:

After that, click “OK” and the wizard will close. The client will now show a newly created rule set.

As you can see, the “Write Syslog Log File” rule set is now present. Please expand it in the tree view until you have the following screen contents:

As you can see, we have a “File” action configured. We will review the settings just for your information. Click on “Filters”:

As you can see, none of the filter conditions are enabled. This means that the all information units (incoming messages) will be matched by these filter conditions. As such, the rules for the “File Logging” action will always be carried out for all messages.

Please note that this also means that all Syslog priorities and facilities will be written to the same file.

Now let us check the “File” action itself. Please select it in the tree view:

As you can see, it has been created with the default parameters. Each day, a file will be created in the C:\temp directory and its base name will be MonitorWare (meaning the name of the generated file will be MonitorWare-*date*, i.e. “MonitorWare-2016-08-26.log”). It will include all information items in the file (you can select the information items that will be in the file by scrolling down and ticking the boxes).

If you would like to store it into a separate directory or change the file name, here is the place to do it. Important: please make sure the directory you specify exists! If it does not yet exist, please create it before you start the service. If the directory does not exist, the service is not able to store any files.

In our example, we would like to save it to “C:\logfiles” with a base name of “Syslog”. Therefore, we change these properties.

After doing so, please remember to save your changes. To do so press “Save” (upper left corner).

Now you have a useable rule set for logging incoming messages to a text file.

Step 2 – Create a Syslog Server Service

Now we need to define a Syslog server service. A Syslog server is also sometimes called a “Syslog daemon”, “Syslogd” or “Syslog listener”. It is the process that receives incoming messages.

To define it, right click on “Services”, then select “Add Service” and the “Syslog Server”:

Once you have done so, a configuration pane opens.

Also, you will see a newly created service beneath the “Services” part of the tree. View and can rename it if you want (in this example, we will name it “My Syslog Server”). After this, press save.

Your screen should now look like this:

As you can see, the service has been created with the default parameters. As such, it operates as a RFC compliant standard Syslog server.

Please note that the “Write Syslog Log File” has been automatically assigned as the rule set to use. This is the case because we already created it and it is the only rule set. If another one is to be used, you can change it to another ruleset here (you might have to scroll down to view the option):

This procedure completes the configuration of the Syslog server.

Step 3 – (Re-) Start the Service

The application cannot dynamically read changed configurations. As such, it needs to be restarted after such changes. In our example, the service was not yet started, so we simply need to start it. If it’s already running, you need to restart it.

Service control can be done with both the respective operating system capabilities or with the configuration client. These are highlighted in the screenshot below:

The buttons resemble Windows service manager – start, stop and restart. In this example, stop and restart are grayed out because the service is not running.

After service restart, the new definitions are active and the application is ready to accept and store incoming messages.

Step 4 – Configure your Syslog-Enabled Devices

Even though application is now ready, it can only receive messages if some devices send them. Remember, Syslog is a protocol where the server is passively waiting for incoming messages. As long as no device sends message, the Syslog server will not log anything.

Since there are a large variety of devices, we unfortunately cannot provide device specific instructions. However, almost all devices need to be configured with their specific configuration tool. Typically, only two settings need to be made: one to activate Syslog messages at all and one with the Syslog server IP address or name.

Remember: the computer running application now acts as a Syslog server. As such, you need to find out its IP address or name and supply it to the device as the Syslog server. Please note that not all devices can operate with computer names. Use the IP address, if in doubt.

Performance Optimizing Syslog Server

Posted on by

Performance Optimizing Syslog Server

Do you want to receive syslog in a Windows environment? Take a look at WinSyslog!

Receive, process and store your syslog data from routers, firewalls or linux/unix servers with this easy to configure application in your Windows environment. Troubleshoot network problems or be alerted, all quickly and easily.

Take a Quick Tour to WinSyslog to know more about its exciting features or directly download the free and full-featured 30 day trial version.

We are quite often asked how many syslog message per second MonitorWare Agent can receive. The answer is not as simple as it may look. It largely depends. So I finally thought I write this brief article on the factors that influence syslog server performance. Obviously, you can also use it as a rough guide to optimizing your setup.

Let me try to outline a few factors influencing the performance.

To get started, you should know that MonitorWare Agent is optimized for large traffic bursts. A little understanding on how it is done helps to understand hardware sizing issues. MonitorWare Agent is multithreaded. There are threads that receive messages and there are threads that process them. These two thread types are loosely coupled via an in-memory queue. The receiver threads (by default) have a higher priority than the processing threads. So what happens when a lot of traffic comes in is that the receiver threads very fast receive the messages and store them in memory. The messages are only processed by the processing threads when no receiving thread is using the system. So on a busy system, an in-memory queue of received but unprocessed messsages is build up. Obviously, if the machine continously receives messages at a very high rate the in-memory buffer fills up and received data begins to get lost. However, this design guarantees that as many messages can be received as the machine is capable of. At least for traffic bursts, this de-couples the receive ability from the speed of the rule set actions.

This – the rule set – is another very important factor in deciding how many messages a given system can process. Naturally, writing received messages to a file is much less performance-intense than writing to a database. A small rule set with only a single rule, no filters and a single action is also faster to process than a complex rule set with many rules, complex filters and actions. Of course, MonitorWare Agent is optimized to process complex rule sets quickly… but even this takes time. So If you would like to squeeze the most out of a given machine (or need to process vast amounts of incoming messages), it is worth tweaking the rule set. If you would like to build a high-traffic central syslog server for creating a central archive… just do that. Create a rule set with a single rule, no filters and just a “write to file” (NOT “write to database”!) action. This will give you the optimal performance.

For a highest performance, you will obviously dedicate a machine just to MonitorWare Agent. Most importantly, if you must log to a database, make sure the database server is on a different hardware! Database server software needs considerable CPU ressources and you will definitely not like to take them away from your syslog server. If you use a remote database, however, you will make sure that the network connection to it is well. So you should invest in a good 1 GB ethernet board and create an exclusive connection between your syslog and your database server (you may use an otherwise not connected ethernet switch).

OK, now we have arrived at hardware. Of course, the faster the box, the better. Add plenty of memory to take care for traffic bursts. The more physical memory the machine has, the better it can process traffic bursts. If you do not expect traffic bursts, memory is not that important. However, it is advisable to add some extra memory just for the case of unusual amounts of messages, e.g. caused by a malware outbreak or other exceptional situations.

A fast CPU is obviously important. Multiple fast CPUs are better. Due to our threading nature, multiple CPUs are very efficiently used. However, do not add CPUs without reason. If you have a central server wich just runs one syslog service (eg at standard port 514) and one rule that writes the messages to a file, you actually have 2 “real” threads running (plus a little overhead). So it obviously is a good idea to have at least two CPUs. A third CPU may bring some extra performance, but I would expect only a moderate increase. A fourth or any more CPU will not do any good – at best, they idle, at worst they add OS overhead. So for a typical configuration, a dual-CPU system is the best fit. If you run multiple listeners, additional CPUs help to improve performance greatly. They scale more or less one-to-one. Adding CPUs does not equally well work to improove complex ruleset performance. This stems back to some of the internal ordered queue handling and the need to keep things in order. So as another general adivse, it is good to add CPUs for additional listeners but does seldomly make sense to take care of for complex rule set.

If your store data locally, you would obviously like to have as fast hard disk as you like. If you plan for highest performance, stay away from raid-5 arrays. They have bad write performance. Use RAID 0 + 1 instead. Use it at the hardware level! Make sure that the disk is defragmented – this is often overlooked. On a fast, defragmented disk, MonitorWare Agent’s file monitor can actually “stream” messages right to the hardware. It does not need to seek ondisk, so you can expect performance close to the disk’s physical maximum.

You intend to shuffle a lot of data through the system – make sure you motherboard is well designed. We have seen bad motherboards slowing down an otherwise well-capable system.

Most importantly, make sure the system can talk nicely to the network. Use a brand, high performance busmastering NIC (network interface card). I am in favor of brand hardware because of the drivers. Most brand products come with drivers that actually allow you to leaverage the hardware. Some (but definitely not all) non-brand cards may come with more or less the same hardware, but too slow drivers. If you expect high traffic make sure your card can handle this. If in doubt, add a second or third card. If you do, make sure it is connected to a different switch, otherwise the switch may become the bottleneck.

In general, make sure that the network is capable of carrying the traffic. This is especially important if log data is flowing in via the WAN.

Another factor greatly influencing MonitorWare’s performance is the syslog protocol used. UDP provides the lowest overhead, but for obvious reasons messages which can not be received are lost. TCP based logging comes with some overhead, but it will guarantee that all messages are received – at least until the sender is internally overrun). So TCP based protocols lower the absolute reception rate, but are often a better choice because they offer a much better guarantee that no data is lost (there is no 100% guarantee, but this is finally beyond the scope of this discussion). Please note that there are multiple options for TCP delivery nowadays – “plain” TCP (not standardized) and RFC 3195 compliant “syslog-reliable”. The later is more reliable but unfortunately very seldomly found in actual devices today. Even “plain” TCP is implemented only in few devices, so this may limit your choices to UDP in the actual case. Keep in mind, however, that MonitorWare Agent can run multiple listeners. So you could, for example, run three listeners, one for RFC 3195, one for “plain” TCP and one for UDP (as a reminder, a 4 CPU system would play nicely with that). Using multiple listeners brings you the best of all worlds. Please note that by default the TCP based listeners have a lower thread priority, so this alsov gives you a little more headroom when it comes to UDP bursts.

Finally, think about the message sender (the “device”, may of course also be another server emiting syslog messages). In rare circumstances (worm outbreak) it may happen that the sender itself exhausts its ressources and is not capable to actually send all messages over the network. With UDP, this may simply happen because the (not very large) IP stack send buffer overflows. Even with TCP it can happen – it just can’t happen at the protocol level. But the application emiting syslog messages may overlflow its internal buffers so that the data never makes it to the TCP queue. While sender overrun is seldomly experienced (and even more seldomly detected as such!), it has happened in reality and may happen to you.

The esepcially bad thing about an sender emiting massive amounts of data is that it may also overrun other parts of the whole network, thus affecting otherwise unaffected systems. Recent Internet worms have provided good examples of this in the wild. So if you can tune the sender, try to place some safeguards in there. For example, you could limit the amount of messages of a specific type that are sent within a specific period of time. Or, as another example, you can set MonitorWare’s Windows event log monitor to emit only 10 messages per second. If you do this, you may loose some message from the Windows box in case some malware takes it over, but you keep the rest of your syslog system healthy.

I hope this clarifies at least many of the important factors behind syslog server performance. And now back to the basic question: how many messages can MonitorWare Agent handle? Honestly, I don’t know. You may now better understand why I do not. It depends on what you do with it. I know, however, that we have quite some customers processing vast amounts of data, including burst traffic with our products. On the other extreme, in our lab, I have configured MonitorWare Agent to write log data to an Microsoft Access database on a diskette drive… It could handle large bursts, but it took hours to write the messages to the database… 😉

Syslog Server for Windows Released

Posted on by

Today, NTSLog has been released. NTSLog is a syslog server tool for Windows. It works like the Unix syslogd part. NTSLog was envisioned during Internet consulting projects, where the lack of syslog functionality on Windows NT had been identified as a problem area. A prototype was developed and has prooven to be quite useful. So I decided to create a shareware application out of it. To the best of my knowledge, NTSLog is the world’s first implementation of a syslog server under Windows. I hope it will be useful.

[Editor Note: NTSLog was later renamed to “WinSyslog”]