One advantage of using Monitis to monitor your systems and applications is the flexibility to use either the native agent or custom monitor code written in virtually any language. For custom monitors, the REST API provides the basic foundation to interface programmatically with Monitis. For many popular languages, there are open source SDKs available to make the process of interfacing with Monitis even easier. You can find links to Java, Perl, PHP, Ruby, C#, PowerShell, and VisualBasic SDKs and example scripts at http://monitis.com/api/api.html#sdk.

Website visitors have a low attention span. We’ve mentioned many times how crucial it is not to let page load times exceed 2-3 seconds. This was demonstrated by a test done at Amazon which showed that every 100ms increase in load time resulted in a 1% drop in sales. With Amazon’s annual turnover close to $50B, that would result in lost sales of $5B if the site took just 1 second longer to load.

We analyzed our own website, which is based on Joomla Content Management System, and our blog, based on WordPress. We found that even from monitoring locations closest to our servers, there’s a 100ms wait to get first byte. That may sound reasonable, but if the browser is making multiple requests to your website (for media files or javascript, etc.) it reduces full page load times significantly.

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!

Monitoring out of Paper with Monitis (Printer Monitoring)

Last time, we scratched the surface of what you can do with performance counters and Monitis.  Today, we’ll show you a fun performance counter to help automate your office, and also show you how you can use the Monitis module to make and updating custom monitors a lot simpler.

One of the fun sets of performance counters are the printer counters:

Monitoring Removable Disks on Many Computers with Monitis and PowerShell

In the last articles, we talked about how to use Register-WMIEvent and with custom monitors to track when a user connects to a shared folder.   Today, we’ll use the same techniques to cover a very common systems administrator need:  Knowing when a USB drive has been plugged in.

The basic pattern of this script is the same as the one we did last time:

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.

Apache is the most popular webserver, and M3 (Monitis Monitor Manager) is one very powerful Monitis tool. It’s a no-brainer to bring them together.

In this short document, first we will look briefly at how Apache presents its logs. Next we will define the way to measure the speed of a webserver, and finally we will learn how we can present results with Monitis (using M3).

Inventory Windows Installations with Monitis and PowerShell

In the previous articles, we talked about how you can use WMI, PowerShell, and custom monitors to monitor a wealth of information with Monitis.  Today, we’ll revisit the subject, and show how you can monitor windows skus and serial numbers with the same general technique.

Remember, to easily monitor anything with Monitis and PowerShell, you need to download our PowerShell module.    We’ll start with a complete script, and break it up line by line:

This is the 4rd article in our Active Directory series. Previously we discussed the structure of Active Directory and provided best practices for Active Directory-integrated DNS. In this article we’ll talk about replication.

Those of you who administered a Windows NT domain are familiar with the concept of a Primary Domain controller (PDC) with one or more Backup Domain Controllers (BDC). The primary domain controller was responsible for managing the master copy of the domain database. It was responsible for replicating any changes to the backup domain controllers. All changes had to be performed on the PDC who then replicated these changes to the BDCs. In effect this meant that when the PDC was unavailable, no changes were made to the domain database, obviously a limitation.