Gathering the data - system log

The program as developed so far is fine for a real-time view of the status of a list of servers but useless if what you want are statistics on availability.

The solution is, of course, to add a recording facility that writes the data to disk. There are two difficulties to solve with this - the first is to minimise the volume of data and the second is to find a good location for the data. We could simply write the status to disk every time the availability of the server is checked but this would generate more data than necessary. All that is needed is a record of the time that a server’s status changes – from online to offline and from offline to online. This is very easy to arrange and all we have to do is trigger a write on a change of status.

The problem of where to write the data is more difficult. You could create a special file to write the data to, but custom files tend to be messy and the user has the problem of trying to find them when they lose the documentation you provide. A better solution is to store such small amounts of transient data in a system-provided location – the Log File. This has the advantage that the user can inspect the results using the Event Viewer and can manage the custom log in the same way as any other log. It also has the advantage that, for the right sort of data, it’s very easy to use.

The reason that it’s easy to use is that .NET provides an EventLog component. This allows you to create a custom EventLog on a specified machine. The only complication is that you have to register the source of the events that the EventLog will handle and once you have registered that source it can only send events to that particular EventLog.

To create a custom event log all we have do is add an eventlog component using the toolbar and add to the end of the form’s constructor are the two lines:

  eventLog1.Log = "SiteStatus";
  eventLog1.Source = "SiteScanner";

This either opens an existing log called “SiteStatus” or creates a new one if it doesn’t already exist. It then registers “SiteScanner” as a source of events. Notice that you can register any name as a source and it doesn’t have to be the name of the program writing to the log. You can also register multiple sources with a log and you can register custom sources in the existing standard system log. However it seems simpler from the user’s point of view to group all of the custom event messages into their own log.

If you accidentally create the wrong log, or no longer need it, then you can remove it using:

if (System.Diagnostics.EventLog.
              Exists("MyCustomLog"))
{
  System.Diagnostics.EventLog.
                 Delete("MyCustomLog");
}

Similarly if you accidentally register, or no longer want, a source associated with a log you can remove it using:

if (System.Diagnostics.EventLog.
       SourceExists("Source1"))
{
  System.Diagnostics.EventLog.
         DeleteEventSource("Source1");
}

Now that we have created the event log we can write some data to it. Place the following code immediately following the DoPing instruction:

if(row.Cells["Status"].Value.ToString()!= 
          reply.Status.ToString())
{
  eventLog1.WriteEntry(
   row.Cells["Address"].Value.ToString()+
   "," + reply.Status.ToString()+
   "," + reply.RoundtripTime.ToString());
}

If the status of the server has changed since the last time it was checked then an event consisting of the server address, status and roundtrip time is written to the log.

There is one remaining problem. Suppose that a server has been on since SiteScan started work. All that there will be in the log is a single record reporting its state as “on” at the time SiteScan started. If you try to process the data to work out the percentage of time the server has been on then you can’t know if SiteScan is still running or if it stopped some days ago and this makes a difference to what you think the total time monitored is.

There are many solutions to the problem but the simplest is to write a final event record when SiteScan is closed. To mark this as a final event we can set the event type code to one instead of the default value of zero.

Change the Finish Scan button’s event handler to:

private void button2_Click(
         object sender, EventArgs e)
{
  timer1.Enabled = false;
  foreach (DataGridViewRow row 
                 in dataGridView1.Rows)
  {
    if (row.Cells["Address"].Value != 
                                  null)
    {
      eventLog1.WriteEntry(
        row.Cells["Address"].
                 Value.ToString()+
          "," + row.Cells["Status"].
                 Value.ToString()+
            "," + row.Cells["Time"].
                 Value.ToString(),
              EventLogEntryType.
                      Information,1);
     }
   }
 }

This writes a final event record to the log when the scan is stopped. To make this work we have to add to the start of the program:

using System.Diagnostics;

Now we have two types of event record. Event type zero indicates that either a server has changed state and an event type one indicates that the monitoring has stopped.

If you now run the program you will discover that a new log file has been created and events are written to it when a server connects or disconnects.You need to give the application administrator permissions otherwise it simply fails because it can't access the log files.

The log file

You can view the log file via the EventViewer which you can find in the Control Panel under Administrative Tools. This also allows you to save a copy of the log file, clear it and set up custom views.

<ASIN:1590598733>

<ASIN:1555583156>

<ASIN:1590597907>