Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
Appearance settings
Typically network devices store event messages on the device itself. However, you can configure it to send to a specific server. The server, henceforth, is called a Syslog server. The network sends all the event messages to the Syslog server specified where you can make certain rules for different types of messages. To be able to do this, we will be using the Kiwi Syslog Server tool from SolarWinds. SolarWinds has developed several software that can be used for managing systems, networks etc.
Installation of the Kiwi Syslog Server
To set up a syslog server, first, you will have to download the Kiwi Syslog Server tool from SolarWinds official site. The link to the tool can be found here or you can take a look at the best syslog servers here.. Once downloaded, run the installation file. During the installation, it will ask you to whether to install the utility as a service or as an application. You are going to want to install it as a service since it will allow the Kiwi Syslog to process messages even when the user is not logged in. The rest of the installation is straightforward and there’s nothing that needs explanation.
Setting up the Kiwi Syslog Server
Now, once you have installed the Kiwi Syslog Server on the system, you are going to need someone to walk you through the options available. Don’t worry, we are going to cover all the important features that are provided in the free edition of Kiwi Syslog Server. Follow the given instructions:
- Go to the Start Menu and open up the Kiwi Syslog Server.
- Now, one of the first things you need to do when you install a syslog server is to set up filters and actions. Press Ctrl + P or simply click File > Setup to get the setup window.
- Basically, filters are used to decide what will happen when a message is received. With the tool, you can filter a message based upon priority, IP address range, the content of the message, the source of the message AKA hostname etc. You can set a filter by creating a new rule or in the rules created by Default. To create a new rule, right-click Rules and select Add rule. Then, highlight Filter, right-click and select Add filter.
Adding New Filter - You can rename the filter whatever you want, however, a name that suggests what the filter is for is recommended. You can set the filter type by choosing from the drop-down list in front of Field. As an example, we’ll select IP address.
Choosing Filter Type - After that, you have Actions. Actions basically tell the server what to do when a specific Filter has been met. It can display the received messages, store them in a log file, play a sound etc. However, in the free edition, there are limitations to the actions that you can perform. To set an action, highlight Actions, right-click and select Add action.
- You can choose what it does by choosing from the drop-down menu in front of Action.
Choosing Action Type - There are tons of things that you can do with this utility. You can change how the messages are displaying by going to Display, set alarms when certain conditions are met etc.
- With this utility, you can also receive traps. SNMP Traps are sort of similar to syslog in that they are real-time notifications that notify you when you have a network problem.
- You can make the utility listen for SNMP traps by going to SNMP under Inputs.
Listening to SNMP Traps - By default, the utility listens to all the messages sent to the server on the UDP port 514. You can also make it listen for TCP Syslog messages by enabling the feature.
Enabling Listen to TCP - Once done, all the messages sent to the server on the UDP port 514 or any other that you have configured will be displayed.
- If you want to save all the Rules, filters and actions that you have created, you can do so by going to Defaults/Import/Export. There, click on ‘Export Settings and Rules to INI file’.
Exporting Settings to INI File - Save the file anywhere you like.
- You can also reset all the Rules and settings by clicking ‘Load default Rules and Settings’.
Loading Default Settings
Kevin Arrows
Kevin Arrows is a highly experienced and knowledgeable technology specialist with over a decade of industry experience. He holds a Microsoft Certified Technology Specialist (MCTS) certification and has a deep passion for staying up-to-date on the latest tech developments. Kevin has written extensively on a wide range of tech-related topics, showcasing his expertise and knowledge in areas such as software development, cybersecurity, and cloud computing. His contributions to the tech field have been widely recognized and respected by his peers, and he is highly regarded for his ability to explain complex technical concepts in a clear and concise manner.
Simple Syslog server setup in Windows and Ubuntu
syslog_server_setup
Table of Contents
In this post we will setup a simple syslog server in windows and Debian based systems like Ubuntu
What is Syslog
- Syslog is a standard protocol to send logs or event messages to a logs storage server
Simple Syslog server setup in windows
- There are many paid and free syslog server solutions for windows
- Syslog Watcher is a free Syslog listener for windows that can view logs from various syslog sources that can be downloaded from here
- Configure the Syslog Watcher to listen for syslogs at UDP port 514 as shown in the below image
Syslog server setup in Ubuntu or Debian based systems
- rsyslog server is a robust production-ready opensource syslog server in ubuntu that can store logs in log files
- rsyslog can be installed in ubuntu using the following command
sudo apt-get install rsyslog -y or sudo apt install rsyslog -y
- rsyslog server can be started and enabled to start at system startup using the following commands
sudo systemctl start rsyslog
sudo systemctl enable rsyslog
- rsyslog server can be configured using the configuration file located at
/etc/rsyslog.conf - Make sure the following lines are present in the configuration file for listening at UDP port 514
module(load="imudp")
input(type="imudp" port="514")
- Make sure the following lines are present in the configuration file below the listener configuration for specifying the logs storage files location
$template remote-incoming-logs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?remote-incoming-logs
& ~
- rsyslog server can be restarted after configuration changes using the following command
sudo systemctl restart rsyslog
- rsyslog server status can be checked using the following command
sudo systemctl status rsyslog
- If firewall is used in the server, allow listening on UDP 514 port using the following command
sudo ufw allow 514/udp
Video
The video for this post can be seen here
References
- Syslog Watcher download page — https://ezfive.com/syslog-watcher/downloads/
- Install and configure rsyslog server in Ubuntu — https://computingforgeeks.com/configure-rsyslog-centralized-log-server-on-ubuntu/
Table of Contents
This article takes a look at what you need to know about syslog and how to configure your Windows Servers to send syslog.
Introduction
Are you a Windows Admin who doesn’t know a lot about syslog? That’s pretty common as Windows Servers use “events”, not the IETF standard RFC3164 and RFC5424 syslog. Still, the Windows OS can use syslog if taking the right steps. Here’s what you need to know about syslog and how to configure your Windows Servers to send syslog.
Advertisement
What is Syslog?
An industry-standard standard system log reporting system, syslog, is used by most devices and operating systems in the datacenter. It includes messages related to systems management, security, debugging, and OS or application errors. Not only is syslog supported by all Linux and Unix-based operating systems but it is also supported by network devices (like routers, switches, and firewalls), storage devices, and even devices like printers. Because of its wide adoption, syslog is a great way to consolidate logging data from across the datacenter in a single place both for preservation and analysis. Analysis of syslog data is critical for security auditing, troubleshooting, and identifying misconfigurations. However, in many cases it is even useful for troubleshooting storage configurations, storage security, and even storage performance. Many devices in the datacenter (such as Cisco routers and switches) do not store historical syslog messages and, thus, it is crucial to consolidate them. If that syslog data is lost when the router looses power or crashes, it may be difficult or impossible to troubleshoot the issue with the device.
With syslog, every device sending syslog messages uses an agent to do so. Those messages from the agents are sent to a central syslog server. Every syslog message is sent with a particular “facility code”, used to identify the type of software that generated the message. Default syslog message are – auth, authpriv, daemon, cron, ftp, lpr, kern, mail, news, syslog, user, uucp, local0 – local7. Those messages are assigned a severity using one of the following classifications – Emergency, Alert, Critical, Error, Warning, Notice, Info, or Debug. In Linux, the syslog messages are usually stored in /var/log and most Linux operating systems offer a command line tool to send data to the log file calledlogger.
Syslog and the Windows Server OS
So what does all this have to do Windows Server 2012, you ask? With most other devices in the datacenter sending syslog messages to a centralized syslog server, what about Windows? The problem is that, unlike Linux, the Windows OS doesn’t include a syslog agent that is capable of sending syslog data to a syslog server. Without a syslog agent, not only can’t the Windows OS send syslog messages to a syslog server but it also can’t send syslog messages from any applications running in the Windows OS (like a web server or database).
I discovered this while testing the new syslog consolidation and analysis tool from VMware – vCenter Log Insight. Log Insight is a syslog server that performs not only consolidation but also real-time analysis of any logging data sent to it. It’s ideally suited for VMware vSphere virtual infrastructure as it connects directly to your vCenter server and ESXi hosts. It understands the statistics that it collects from the vSphere infrastructure and is a great tool for analyzing system logs and identify errors before they affect end users.
Syslog Agent Options for Windows 2012
If you use your favorite search engine and you do a search for “windows syslog agent”, you’ll get number of syslog agents to choose from (most of them being free). Here are some of the options that I found:
- Intersect Alliance Syslog (enterprise and open source)
- Datagram SyslogAgent
- Balabit Software, syslog-ng
- Rsyslog agent
- NTsyslog agent
- Correlog Windows Syslog Agent
Please note:
I did not test any of these syslog agents except for one – Datagram SyslogAgent – (which happened to be the first one that I picked and tested below). Thus, I’m not saying that the one I selected was better or worse than the others, it just happened to be the one I used.
Also note that you shouldn’t confuse syslog servers with syslog agents. Syslog servers (or syslog hosts) collect syslog data and agents send that data. For Windows Server, you need an agent, not a collector (or server). For example,Solarwinds syslog server (formerly Kiwi syslog server) is a syslog server, not a syslog agent. If you don’t have a syslog server already, then that is a good option for general use or vCenter Log Insight is a good option if you are already using VMware vSphere.
Downloading and Installing Datagram Syslog Agent
For my testing, I selected the free Datagram SyslogAgent. From the product page, I clicked the Download and then selected the Datagram Syslog Agent 64-bit download (don’t choose the Syslog Server at the top of the page). Note that you can either go to this webpage directly from the server where you want to install the syslog agent on or you can download it on your local computer and then transport it the Windows server via the network or USB key.
If you extract the 2MB Syslog file that you downloaded, there are a few files but the only three important files are the PDF user’s manual, the SyslogAgent configuration tool, and the SyslogAgent that you need to install on the server.
Figure 1: SyslogAgent Installation Files
In the sense of a traditional Windows application install, there is not one for the SyslogAgent service. You just run the SyslogAgentConfig tool and click Install under the Service Status section at the top.
Figure 2: Installing the SyslogAgent Service
This will create the Windows service for the SyslogAgent.
Before you get too excited and start the service, let’s first configure it.
The minimum configuration would be:
- That the service is install
- A syslog server IP and port are configured
- That either event or application logs are selected to be sent to the syslog host (for whatever type of events and/or applications you choose)
- And that the syslog agent service is started.
To select where the log data from your Windows host will be sent, enter the IP address of the syslog host, as you see in the graphic, Figure 2, above. In my case, the Log Insight syslog server’s IP address was 10.0.1.120 and we were using UDP port 514.
With this enabled, I checked the Event Logs option and selected what type of event logs I wanted. For system monitoring, I would recommend sending “system logs” but you are welcome to send any type of logs you want such as security logs for
auditing purposes.
Figure 3: Selecting the Event Logs to Send to the Syslog Host
Optionally, you can configure the application log events to forward and even customize their facility and severity, as you see in Figure 4.
Figure 4: Customizing Facility and Severity
Optionally, you can choose to send events from specific Windows applications to the syslog host, even specifying the executable for the custom application (as you see at the bottom of Figure 2).
Once you’ve got it configured, click Start Service.
You are welcome to double check your Windows services to see that the SyslogAgent is added and running as you see below in Figure 5.
Figure 5: SyslogAgent Running in Services
With the syslog agent running, let’s go check our syslog server to see if it is receiving messages from our Windows 2012 Server.
Testing Syslog with VMware vCenter Log Insight
Let’s assume that your syslog server was installed and is running fine, at the IP address you specified on the agent. In my case, I am using the new VMware vCenter Log Insight as my syslog host but there are numerous options.
Over on the vCenter Log Insight console, indeed, I was quickly able to identify syslog traffic coming from my Windows 2012 Server (with a DNS name of HV1).
Figure 6: Windows Server Syslog Message on vCenter Log Insight
The graphic shows that the syslog server is reporting administrative user logins and logouts (at least in this part of the log) – something that would be very valuable for security audit purposes. Keep in mind that the syslog entries from Windows won’t just be security info. They’ll contain important system and application events as well.
Please Note: This article is valid for EventReporter in addition to WinSyslog!
Windows NT/2000/XP/2003/Vista/2008/Windows 7 systems monitoring is really important for all small to large sized enviroments. MonitorWare line of products helps to accomplish this important task. This article is to help you establish a small setup to monitor your Windows systems.
This article is strictly task focused. It does not describe why the systems should be monitor nor does it provide any further background. Please see the respective backgrounders or each of the products documentation on this. This article is a step-by-step description of what you need to do in order to centrally monitor your Windows systems.
Centralized Event Reports
In this step-by-step guide, EventReporter is configured to work together with Adiscon’s WinSysLog and MoniLog to automatically generate event summaries for the monitored servers and other devices.
This guide focuses on a typical small to medium business topography with a single geographical location and 5 Windows clients and a central hub server. All systems are well connected via a local Ethernet. Event reports from all machines should be stored in a log file. The administrator shall receive daily consolidated event reports.
What you need
In this guide, I am focusing on building a solution with Adiscon’s EventReporter, WinSyslog and MoniLog. This combination allows you to centralize all your event logs and report events from them. Free 30 day trial versions are available at the respective product sites (links below), so you can try the system without the need to buy anything.
You need to run the following products:
- one EventReporter for each system that is to be monitored. In our scenario, this means 6 copies, one for each client and one for the central hub server to be monitored. (if you want to monitor the hub server as well.)
- one WinSyslog to receive and store event reports from the EventReporter monitoring agents.
- one MoniLog to automatically generate consolidated reports based on the gathered log data in a file.
Note: Please note that to deliver MoniLog reports, you need a local web server (for example Microsoft’s IIS or Apache) and a mail server capable of talking SMTP (most modern servers support this). Make sure that you log on to each machine with a sufficiently privileged user account.
MonitorWare Console
MonitorWare Console can also be used with EventReporter and WinSyslog. MonitorWare Console is a very strong and comprehensive tool that will help you out in carrying out sophisticated analysis of your system. For more information about MonitorWare Console, please refer to its manual and to have a clear idea about Monilog and MonitorWare Console reporting features, please visit Comparision of Monilog Report and System Status Report of MonitorWare Console.
Step 1 – Download Software
Please check the web sites for new versions of respective products if you downloaded your copies a while ago. Security and monitoring is a short lived business, and new product versions can appear quickly.
Please visit www.eventreporter.com/en/download and www.winsyslog.com/en/download to download the latest versions of EventReporter and WinSyslog respectively. In addition to these, you also need the MoniLog product. A free, full-featured 30 day trial is available at www.monilog.com/en/download/.
Step 2 – Install WinSyslog
Identify the system on which WinSyslog (and probably MoniLog) should run on. Take a note of its IP address or host name. You’ll need this value when configuring the EventReporter clients. For our example, I assume this system has an IP address of 192.168.1.0.
Run the WinSyslog setup with default parameters. When setup has finished, WinSyslog automatically is configured to operate as a simple Syslog server. However, it does not yet use file logging as we need that. We’ll later setup WinSyslog to write data into a file and also to configure Syslog server service, if you do not have it.
Step 3 – Install EventReporter
Run the EventReporter setup program on all systems that should be monitored. This means you need to run it on all 5 clients and the central hub server.
For larger installations (with many more servers) there are ways to set it up in a simpler fashion, but in a scenario like ours, it is faster to install it on each machine manually. You can install it with the default settings. When setup has finished, the program automatically is configured to operate as a simple EventReporter. However, it does not yet forwards the log to Syslog server. So we will go ahead and change this on each of the machines or by launching it on one machine and remotely connecting to the others. It is your choice. In this sample, I use the EventReporter on each machine (it is easier to follow). We will also see configuring an event log monitor service, if you do not have it.
Step 4 – Install Monilog
A standard setup program installs the application. The install set (the ZIP file you downloaded) contains a standard setup program and it’s necessary helper files. Please unzip the archive to any directory you like. After unzipping, simply double-click “setup.exe” and follow the onscreen instructions.
There are also self extracting exe files available for download. If you downloaded these versions, there is no need to separately unzip the program. The self extracting version might also start the setup process automatically. If you have Windows Installer already present on the target system, you can also setup the product by simply double clicking the .MSI file. Windows Installer is present on all Windows 2000 systems.
Step 5 – Create a RuleSet to Forward by Syslog (EventReporter)
Please note that delete the previous services or rules sets to follow or save those to registry file not binary for later use. To save your settings follow the link and just dont zip & send that file to us.
The steps to configure the EventReporters are as follows (repeat this on each of the 5 client machines). This step needs not to be done on the central hub server as well!:
1. Start EventReporter.
2. Select your language – in this example, I use English, so it might be a good idea to choose English even if that is not your preference. You can change it any time later, but using English makes it much easier to follow this guide here.
3. Then define a new rule set, right click “RuleSets”. A pop up menu appears. Select “Add RuleSet” from this menu as shown below:
4. Then, a wizard starts. Change the name of the rule to whatever name you like. We will use “Forward Syslog” in this example. The screen looks as follows:
Click “Next”. A new wizard page appears.
5. Select only Forward by Syslog. Do not select any other options for this example. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”. You will see a confirmation page. Click “Finish” to create the rule set.
6. As you can see, the new Rule Set “Forward Syslog” is present. Please expand it in the tree view until the action level of the “Forward Syslog” Rule and select the “Forward by Syslog” action to configure.
7. Replace the message format from the original syslogformat to MoniLog format. To do so, click on “Insert” and then “Replace with MoniLog Format”. Also, please uncheck “Add Syslog Source when forwarding to other Syslog servers” Option and type the IP address or host name of our central hub server in the “Syslog Server” field:
8. Make sure you press the “Save” button – otherwise your changes will not be applied.
Step 6 – Create an EventLog Monitor to get all the Events from the Machine (EventReporter)
1. First, please rightclick on “Running Services” node in the left treeview (TOC). Select “Add Service” and then “Event Log Monitor” in the opened popup menu:
2. A wizard should open up, which looks like the screenshot below. Here type the name of the “Event Log Monitor” (In our case we will name it “My EventLog Monitor”). Then click on “Finish”:
3. Now the properties tab of the newly created “EventLog Monitor” will open up. Please leave it at default settings and still change the “Rule Set to use” to our above created “Forward Syslog” RuleSet. Please do not forget to save the changes.
Step 7 – Create a simple Syslog server on WinSyslog
Please note that delete the previous services or rules sets to follow or save those to registry file not binary for later use. To save your settings follow the link and just dont zip & send that file to us.
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 8 – 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 “Rules”. 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:
Click”Next”. A new wizard page appears:
There,select file logging. Do not select any other options for this example. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”.
This is just a confirmation page. Click “Finish” to create the rule set.
The wizard closes and the client shows 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 Logging” action configured. We will review the settings just for your information. Click on “Filter Conditions”:
As you can see, none of the filter conditions are enabled. This means that 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.
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 Logging” action itself. Please select it in the tree view:
Please enter a “File Base Name”. In our case we will name it “EventReporter”, cause all the Data comes from EventReporter’s. Its also important to make sure that 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, last but not the least, do not forget to save the changes you do.
Note:Do NOT change anything else in the “WriteToFile-Action Configuration”!
Now you have a workable rule set for logging incoming messages to a text file.
Step 9 – 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 new wizard starts:
Again, you can use either the default name or any one you like. We will use “My Syslog Server” in this example. Leave the “Use default settings” selected and press “Next”:
As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client. There, you will see the newly created service beneath the “Services” part of the tree view:
To check its parameters, select it:
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. By default, the wizard will always assign the first rule set visible in the tree view to new services. If another one is to be used, you need to change it to the correct one here in the service definition.
Also, 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.
This procedure completes the configuration of the Syslog server. Please do not forget to click save button and changes will start working after application restarts.
Monilog for Reporting
To deliver MoniLog reports, you need a local web server (for example Microsoft’s IIS or Apache) and a mail server capable of talking SMTP (most modern servers support this). Please make sure you log on with a sufficiently privileged user account.
Preparing Web Server for MoniLog
MoniLog publishes its reports through the local web server (central hub server).
To avoid confusion, we recommend creating a separate directory on the web server for MoniLog. Let us assume you use Microsoft Internet Information Server and run it in the default configuration. Then, you web pages are stored in the c:\inetpub\wwwroot directory. Create a subdirectory “monilog” directly beneath this directory.
Configuring Monilog
When setup has finished, start MoniLog, select your language (I have used English for this tutorial) and perform the following steps:
1. First, switch to the “General” tab.
2. “Logs Location” expects the DSN or Location where logs are dumped. You specify the location for your log file. Here we specify location of log file.
3. Select your “Select Syslog server type”.
4. Change the “Log prefix/Log name label” to the prefix you defined in your “WriteToFile” action in WinSyslog. In our case we named it “EventReporter”.
5. Next is to check the “Process Non-Windows Syslog messages” box. Leave all other options by default. Now it should look as follow:
Figure 1: General Tab Settings Form – For Log Files
Click “Apply” after making your changes!
5. This has already enabled MoniLog reporting. Now, we can verify the installation. To do so, switch back to the “Profiles” tab. Click the “New Profile” button and enter a name. In this example I use the name “Profile 1”.
Figure 2: Creating New Profile
Click “OK” button to create a new profile.
6. Under “Reports Location”, enter the directory where MoniLog reports should be stored. In our sample, we use “c:\inetpub\wwwroot”. Leave all other settings as default. The tab should look like this one:
Figure 3: Configuring Reports Location
Click “Apply” to save your changes!
7. Next step is to set your report options. To do so, click “Report Options”. A new window opens. Check Success Audit and Information. Now it should looks like this one:
Figure 4: Report Options Form
Click on “OK” to close the windows by using default options.
8. Click “Analyze now” to test it. After a short while, a browser window with a MoniLog report will appear. The actual content of this report varies greatly. It depends on which events have been forwarded while setting up the agents. Probably, your report will be empty. This simply indicates that there was not yet any data to be analyzed. Immediately after setup, this is OK. If you don’t receive any data after some hours then of course there is something wrong. If that is the case, check the steps done before. A typical report looks like follows:
Figure 5: A typical Monilog report
9. Now we have verified the system is working. Next, we can schedule the automatic report. To do so, we need to check “Enable Schedule” and also “Enable Email delivery”. A quick reminder: we would like to receive a pointer to the report via email each working day. We first need to set the web directory the reports are to be stored to and enable email delivery. It is all done in the following screenshot:
Figure 6: Enabling Email delivery and report scheduling options
The “Email Options” and “Scheduled Options” become colored and are now available.
10. Now we need to configure the email options. Click “Email Options…”. We assume the web server (192.168.0.1) is also acting as a mail server. The emails should be sent to “admins@sample.adiscon.com”. With that, the dialog looks like follows:
Figure 7: Configuring Email notification settings
Important: make sure the values match your configuration! This is vitally important because otherwise MoniLog is incapable of sending email correctly. Click “OK” to apply the new settings.
11. Next, click the “Report Options…” button. As we schedule reports only on working days, we need to tell MoniLog that it should include all those events occurred since its last run into the reports. We cannot leave the default of 24 hours, as this would exclude the weekend’s events. So change the “Report Type” option to “From last run till now” as seen below.
Figure 8: Setting Report Options form
Click “OK” to apply the setting.
12. Lastly, click on “Schedule Options” to set a schedule. As long as no schedule is set, no reports will be generated automatically. In our sample, we let MoniLog generate reports each working day at 8:00 in the morning. Weekends are not enabled. The dialog looks like this:
Figure 9: Configuring report generation schedule
13. Click on “OK” to apply the settings.The MoniLog service has not yet been started. It generates the scheduled reports (so you don’t need to run the client in foreground).
14. To conclude your configuration of MoniLog, start the service. To do so, select “Service”, then “Start Service” from the menu. This will start the service. During setup, the service is set to start automatically with system startup. So there is no need to manually restart the service after a reboot.
MoniLog is now completely configured. You will not immediately receive reports, because they will only be generated at 8 am each working day. So you need to wait for the next morning. If you would like to change the schedule to have an immediate feedback, please go to “Schedule” and change the time to be a few minutes in the future. Then click “OK” and restart the service. This can be done via the “Service” menu. A restart is necessary because the service reads changed parameters at startup, only.
Please Note: The only difference between configuring your reports to be generated either from Log Files or on underlying database is Step 2. From Step 3 onwards settings are the same.
You are done!
Well, this is all you need to do to configure the basic operations. Once you are comfortable with the basic setup, you can enhance the system with local pre-filtering of event, enhanced logging and alerting (with EventReporter and WinSyslog ) and changing report options (with MoniLog / MonitorWare Console).
What is recommended setting for MoniLog and Why?
Let’s quote Rainer Gerhards, design lead for the overall MonitorWare line of products, here:
Typically, MoniLog should work with Log Files, and not with the database. As using files is the recommended way with MoniLog. Why is it recommended? Because it is much faster! Why do we support database, too? Because this allows easier integration e.g. with the Web Interface! Would I recommend MoniLog and database if a customer also needs to run the Web Interface? In most cases: No! From a performance point of view its better to create both text files and database content.