Getting Started With Monitis PHP SDK

 

contributed by Ali Gajani

 

While Monitis offers a nice dashboard with drag n’ drop UI components for a centralized monitoring experience, it also helps to learn that there’s an API for building your own custom data feeds. Today, we are going to look at the PHP SDK in particular, which is a wrapper around the REST API.

 

Generating Data

 

Before we dive into the technical details, let us create some sample data to work with.

 

 

 

 

 

 

Now we have two distinct Uptime Monitors fetching data from an endpoint of our choice. Let’s move forward and see if we can fetch this using PHP SDK.

Setting Up

 

To tap into Monitis API, we must first generate an API key, as shown below. Next up, you must download the PHP SDK files from here and open a text editor of your choice.

 

 

Fetching Stats from HTTP Monitor

The current documentation and specification for fetching dashboard monitor data are very much vague, and until this blog post, you would have had to learn using SDK by trial and error.

 

 

 

By intuition, to fetch HTPP(S) stats, you would utilize the MHttpMonitor class in PHP SDK, but turns out it’s not the case.

 

The correct class here would be to use MExternalMonitor. This offers access to most of the Uptime monitors in Monitis. 

 

Now, create a file called httpMonitor.php inside the src/ folder of the downloaded SDK package. Place the below require files as they are complimentary for our exercise and fill in the API and Secret keys.

 

 

 

require_once(‘monitis/utils/Request.class.php’);

require_once(‘monitis/MApi.class.php’);

require_once(‘monitis/monitors/MBase.class.php’);

require_once(‘monitis/monitors/MExternalMonitor.class.php’);

require_once(‘monitis/monitors/MInternalMonitor.class.php’);

 

$apiKey = ‘YOUR_API_KEY_HERE’;

$secretKey = ‘YOUR_SECRET_KEY_HERE’;

To obtain a list of all active monitors on your dashboard for programmatic access, we utilize the MExternalMonitor class as shown below, invoking the requestMonitors() method which returns as a multidimensional array. 

 

$externalMonitorInstance = new MExternalMonitor($apiKey, $secretKey);

$externalMonitors = $externalMonitorInstance->requestMonitors();

 

foreach ($externalMonitors as $e) {

  foreach ($e as $i) {

      print_r($i[‘type’] . ‘, ‘ . $i[‘id’]);

      echo PHP_EOL;

  }

}

 

The snippet above loops through the list of such monitors and outputs their type (ping, https) and their IDs. These IDs are crucial in the remaining exercise and will remain fixed unless you delete or add a new monitor. 

 

Once we have the unique identifiers for our monitors, we can get the meat of the task by invoking the requestMonitorResults() method that spits out time series data for uptime monitor types.

 

 

 

 

 

 

 

 

This method takes in 3 main arguments which are: Monitor ID (the unique identifier we retrieved in the earlier step), MInternalMonitor:: PERIOD_* instance and GMT offset. 

 

$httpMonitorResponse = $externalMonitorInstance->requestMonitorResults(1158002, null,null,null, MInternalMonitor::PERIOD_LAST_24_HOURS, 0);

foreach ($httpMonitorResponse as $location) {

  print_r($location);

}

 

Running the above code will output a plethora of data, which, at the top level, is segmented into locations. For instance, if you set the HTTPS Uptime Monitor to track your site from 3 locations or regions, the response will look like this:

Array

(

   [locationName] => USA-MID

   [data] => Array

       (

           [0] => Array

               (

                   [0] => 2017-05-23 00:00

                   [1] => 637

                   [2] => OK

               )

       )

 

   [trend] => Array

       (

           [oksum] => 207939

           [okcount] => 378

           [min] => 457

           [max] => 684

           [nokcount] => 0

       )

 

   [id] => 53

)

Visualizing this data is beyond the scope of this tutorial, but if you take note, the main points of interest in the dataset above are data and trend, accessible by keys of the same name. data contains time series data for every specific interval, with the third array element [2] portraying the uptime signal which can be either OK or NOK. Next, the trend is useful for a snapshot, e.g. a UI module on a central monitoring screen.

 

 

Fetching Stats from PING Monitor

 

This step is identical to what we achieved earlier, with the only change being the unique monitor ID. Here’s the code snippet below for your interest.

 

$pingMonitorResponse = $externalMonitorInstance->requestMonitorResults(1157880, null,null,null, MInternalMonitor::PERIOD_LAST_24_HOURS, 0);

foreach ($pingMonitorResponse as $location) {

  print_r($location);

}

 

Conclusion

 

Monitis’ own dashboard UI is fairly fulfilling in many ways, offering a range of UI components and customizations, but sometimes, you just need the raw data to DIY. This is where it’s API comes in handy, as we have demonstrated in this blog post today.  Whether it is displaying monitoring stats on TV, feeding data into internal CRM systems or just for custom workflow tools, there is a Monitis SDK at your disposal.

 

As a closing remark, it is recommended to create monitors and agents right from the dashboard first and then fetch data via the request APIs. This ensures you don’t have to write custom code to create monitors, something which is easily done via a few clicks on the GUI. Lastly, please access this GitHub repository for the code written during this tutorial and star/watch/follow it for future goodness.

 

 

 

 

You might also like