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.

The existing Monitis Java SDK (that uses the Monitis Open API functionality) provides almost every opportunity to create any internal monitoring agent that a user could want. It is really very easy to build a monitor by using Monitis Open API and Monitis Java SDK. 

Below we’ll describe possible ways to build a custom monitor for monitoring Memcached server health in real-time – based on improved Monitis Java SDK.

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 3^rd 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.

This article is the second article in our series about SharePoint. In our first article we provided a few SharePoint basic system performance counters that you can use to monitor the overall health of the server itself that is running SharePoint; a requirement before you can monitor SharePoint effectively and detect and identify possible bottlenecks. In this article we’ll discuss SharePoint monitoring more in depth and provide some best practices.

SharePoint 2010 offers a number of built-in monitoring features for diagnosing problems and performance. By default diagnostic logging is enabled and while most of the time these default settings will be sufficient, there might be times when you want to make changes to these settings. For example, if you are making a major change to your environment, you can configure a more verbose level of logging to track more closely if everything is working as planned.

Monitoring MongoDB is very similar to monitoring a normal relational database.  If it’s on its own machine then you need to care about things like how much CPU it’s taking up, how much RAM, how fast are the disks etc.   If Mongo starts grinding on any of your core compute resources then guess what, you’ve got a problem!

A good Database Administrator, which hopefully we all aspire to be, needs to monitor more then just the basics.  A good Database Administrator needs to monitor the actual database.  Not to mention in many cases especially with Mongo you will need to monitor a cluster of databases, not just one instance.  You’re in luck with Mongo, because fortunately the folks at 10gen, the makers of MongoDB, have written some excellent documentation for how to properly administer and performance tune MongoDB.

In previous articles, we learned how to access Performance Counters metrics, how to access SQL Server data, and also how to add a Monitis page with multiple External Monitors. In this article we will put everything together and create a Monits page with the most important parameters for monitoring an SQL Server in production.
When monitoring an SQL Server installation, it is important to keep monitored the most basic metrics such as Processor and Disk. There are also several important metrics specific to SQL Server, as well as the size and the usage of databases and logs.

There is no need to remind you that performance monitoring is an important aspect of managing a network environment.  As a network administrator you covered all the bases and are on top of monitoring your network not only for outages but for performance bottlenecks as well… right?

Adding SharePoint to your network environment adds new requirements to your performance monitoring needs.  One method of monitoring SharePoint servers is by examining the performance counter logs which contains several critical counters that are used when evaluating performance issues. There are a number of primary counters that we’ll look at and they include metrics for CPU, memory, and disk performance.

HTTP what?

Yes, HTTP extraction. Imagine you have a web page you would like to probe for parameters. Such as the number of your twitter subscribers, or the temperature somewhere – and profile it in Monitis.
Or another scenario could be to probe the responsiveness of your website – how fast is it?
Was it compromised and defaced?
I think you get the point – it is needed and important.

In the previous article we’ve shown how easy it is to integrate popular Nagios server monitoring commands, or plugins, with Monitis M3 monitoring framework.

However, given the fact you have a working Nagios configuration, which is vast and complex – I can sympathize with your unwillingness to actually migrate to Monitis.