Unleashing the power of M3 & timers
During the lifespan of M3 (Monitis Monitor Manager) there has always been something lacking – timers.
M3 execution procedure was outlined in this previous article.
The execution mentioned in the latter was a one-time-execution, whereas server monitoring requires periodic invocation of monitors in order to actually provide counters over time, graphing performance.
The periodic invocation method suggested up until today was to integrate M3 with crontab.
Crontab, in a nutshell, is a Linux/Unix service for periodic invocation of executables. Implementing M3 with crontab properly meant M3 would run every X minutes, producing a Monitis counter update every X minutes, should everything run properly.
In the following article I’ll outline the changes done to support timers in M3.
In this article we’ll create a Monitis custom monitor to measure your network bandwidth or throughput. The monitor will support multiple network adapters and should be intelligent enough to only collect results for the network adapters that are active.
First, let’s take a look at the performance counters we used for this monitor and the information each metric provides.
In this article we’ll go into VDI (virtual desktop interface) monitoring on Windows Server Hyper-V and in particular what and where to monitor and what counters to utilize to determine of your virtual machine is overloaded and what resources are used. This article focuses on measuring networking, storage, and CPU usage.
Windows Hyper-V has three main components, each of which can be monitored; the virtstack, devices, and the hypervisor. When Windows 2008 boots the system it launches the virtstack and hypervisor. The virtstack handles the emulated devices, manages virtual machines, services I/O, etc. The Hypervisor schedules the virtual processors, manages interrupts, services timers, and controls other chip-level functions.
Pluggable M3 (Monitis Monitor Manager) Framework
Who needs an introduction about M3? – Perhaps no one!
After gaining some reputation with M3, providing extra-easy integration of any monitor into Monitis it was time to take it to the next level.
Generally speaking, the work flow of M3 was described in detail in this article.
After some thought and design, we’ve decided it’d be best if M3 was pluggable. Pluggable in terms of being able to easily add execution and parsing plugins.
The interface and behavior of M3 stayed exactly the same, however now it is much easier to obtain data from any source and parse the data the way you want it.
Saying that, it was time to put the new design for a test. We tried to integrate the DBI support into M3.
Guess what – it was much easier than expected!
This whitepaper on Microsoft ISA Server discusses best practices specific to ISA Server, Health Monitoring in general, and how to monitor your ISA Server with Monitis. Included is a VBScript that creates a custom monitor in Monitis.
The Microsoft website offers links to documentation on the different versions of ISA Server. A good starting point is the Microsoft Technet website. Note that Microsoft ISA Server is now called Forefront. The Microsoft website contains links to all versions of ISA Server.
We’ll start with a general overview of the specific functionality ISA Server offers and then we’ll go into best practices.
In a previous article we discussed monitoring Exchange Server with Monitis and provided a custom monitor written in PowerShell.
In this article we’ll go over the available and relevant metrics for Exchange Server 2003. We’ve categorized the performance counters in the following groups:
1. Exchange Message Counters
2. Exchange Services Counters
3. Memory Monitoring
4. Network Monitoring
The Message and Service counters are the ones we’ll discuss in this article. Memory and Network monitoring will be covered in a follow-up article.
In our previous article “Monitoring SharePoint 2010: Configuring the Usage Database”, we discussed the available performance counters and what they tell you. In this article we’ll discuss bottlenecks; how to detect them; and how to resolve them.
In general terms bottlenecks are the result of insufficient resources to service transaction request. Bottlenecks can be physical hardware, operating system, or application related. More often than not though you will find that a bottleneck is caused by ‘homegrown’ code or 3rd party solutions. Reviewing custom code could yield better results than simply adding more hardware to solve the issue. Another common issue that creates bottlenecks is an incorrect configured server or, an incorrect configured farm. Bottlenecks can also be caused by an inefficient design of the data structures causing those to require more resources than necessary.
For a system administrator, it is essential to manage bottlenecks by constantly monitoring performance. When you identify a performance issue, you must assess the best resolution for removing the bottleneck. The performance counters and other performance monitoring applications are key when analyzing problems.
This is the second article in a series about Exchange Server that follows up on the article monitoring Exchange Server with Monitis.
In the previous post we discussed the Exchange Message and Service Counters. In this article we’ll go over the Memory and Network Monitoring metrics.
In previous articles we introduced the command-line utility “Monitis-Top”, written in VBScript. Monitis Top is a tool that can be used to query your active monitors from the command-line. We promised that we would provide the code of this client utility in C# in addition to the VBScript source, and here it is. The code utilizes Microsoft .NET Framework 4.0, so that is a requirement if you want to use this software or want to make modifications.
We’ll go over the source code below. The complete source code – including the Visual Studio 2010 solution – can be downloaded from Monitis’ Github open source repository.
M3 (Monitis Monitor Manager) framework usage and examples were outlined in a few previous articles:
M3 – introduction
Planning your vacation / HTTP extraction
However we’ve never explained the bits and bytes behind it and what was the initial motivation for implementing it.
This article will outline the motivation, design, implementation and perhaps also the future road map for M3.
Rereading my previous articles I realized that I generated a somewhat steep learning curve for using M3 with the complex examples provided, just because M3 can handle these complex scenarios.
However M3 was created in order to simplify things. I’m going to use an extremely simple example in the following article to explain the way M3 works this time, I promise!
