Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Simple production monitoring for .net web applications
JavaScript C# CSS XSLT PowerShell ASP

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
.nuget
builds/local/artifacts
lib
packages
source
.gitignore
Readme.md
ZocMon.All.sln
default.ps1
license.txt
psake.bat

Readme.md

Overview

ZocMon is a project designed to make monitoring live sites easier. It is a tool which allows you to establish a baseline for how your application is running and determine system/application health as a result.

It does this by allowing you to create buckets to log both business and code events. For each given bucket, the events that have been recorded are aggregated together. The resulting analytical data then allows you to see if your system is performing as expected.

Usage

When using ZocMon, the basic setup requires you to "inform" the system that you wish bucket events to be recorded and what exact events your are interested in collecting. The former typically setup via additional code in your application start and the latter occurs with the placement of strategic ZocMon.Record(...); placed throughout your code.

Registering Events

ZocMon doesn't require you to explicitly create a bucket. By simply registering an event occurrence ZocMon is able to determine whether the Bucket previously existed and create it if it doesn't exist.

Simple example of how you register an event for users logging into your system (as mentioned, when this line is executed, if this is the first time it has run it will create the bucket record in the database):

ZocMon.Record("UserLogin", MonitorReductionType.DefaultAccumulate);

Registering ZocMon

In addition to recording that events have occurred within your system, you need to tell the system to initialize ZocMon. This initialization is done through code (typically placed in your global.asax) and the settings of ZocMon can configured incode or via the web.config.

Simple example of what code could be placed in the App_start of your global.asax:

protected void Application_Start()
{
    ZocMon.Settings.Enabled = true;   //Optional configuration code
    ZocMon.Settings.Initialize();     //Mandatory code you must have 
}

Alternatively, if you want to configure things via the web.config, here is what a simple example would look like:

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="zocmon" type="ZocMonLib.ConfigSectionZocMon, ZocMonLib" />
    ...
  </configSections> 
  ...
  <zocmon enabled="true" />
  ...
</configuration>

Note, you can use the web.config in conjunction with the global.asax approach. If there is a conflict between what you request each to do, the settings in the global.asax will be the ones used.

How it works

ZocMon works off the basic premiss that as data is collected, over time trends in data can be detected. From an analysis point of view, ZocMon cares when trends outside "normal" tolerance boundaries occur - typically when they are trending abnormally downwards.

For example, if you created a bucket to registers user signups, ZocMon might tell you that by this time today, we should have 50 signups. We know that because this time last we we had 40 signups at this time and the the week before that we had 60 signups at this time. If however, we only had 10 signups, we could infer that something might be wrong in the system.

Why care

This style of monitoring becomes very important as you release to production. In todays world, we are releasing to production more frequently than ever before. Whilst this is great for our users it also means that our risk of introducing a bug is also increased. The aim is to be able to move to a place where you have no fear about deploying to production.

Traditional to get to this point, we rely on finding "all" bugs before we release. This involves large amounts of unit tests, automated integration testing, user acceptance testing, etc. But even with this, we still can't be sure that a bug wont get passed.

So taking a pragmatic approach - assuming we have performed due diligence in testing before releasing - if we accept that bugs will occur in production, we need a way of being able to detect bugs when then occur.

Typically we rely on our users reporting problems or errors logs and alerts, but as fate would have it, most bugs won't be logged and our users aren't always as proactive as we would like them to be when we are trying ensure business continuity.

Hence, ZocMon is design to try and catch this class of bugs. It will detect changes in the way that your application is performing and alert you as when unpredicted events occur. With the advent of ZocMon, you have more assurance than ever before in knowing that bugs will be caught when they slip through.

Core Workings

Coming soon.

Something went wrong with that request. Please try again.