For those who have a bit more patience before jumping to integration, bear with me for a moment and I can walk you through both the motivation triggering the need for API creation.

I will also give you a specific example of how to put the API to good use.

Motivation

The way monitoring solutions are deployed tends to be heavily environment-specific. Based on our experience, we see Plumbr rarely being the only solution monitoring the digital assets of the business. There is almost always “something else”, be it something as simple as Pingdom or Nagios or something as complex as CA APM, we rarely see us being the one and only monitoring solution for the customer.

One trigger is technology – rarely you will have a solution suitable for all possible technology stacks large companies are supporting. Be it evolution, market pressure or acquisition – there are multiple ways how a mature company can and will end up with almost all technology stacks imaginable. As Plumbr is currently monitoring only Java Virtual Machine based deployments, we clearly are not suitable for monitoring the health of your LAMP or .NET stacks.

Another cause for the variety of tools is the different purpose of them. Whereas Nagios, for example, focuses on system monitoring, Plumbr’s job is to monitor actual end user experience in regards to performance and availability. Both are necessary and in a sense complement one another.

These two causes, accompanied with the increasing number of votes on the corresponding feature request have given us a clear motivation to publish Plumbr API. With the REST API present, it is now possible to use Plumbr just as data gathering and analytics service with the UI being embedded to any dashboard used to aggregate information. Be it a DataDog dashboard you are happy with or NewRelic deployment you just miss certain information at – adding information from JVMs monitored by Plumbr is now as easy as you can see in the following example.

Example

In the example, a list of services along with their health is retrieved from Plumbr. The API in question is accessed via a call to “/api/v2/service” URL. The call can, for example, look like the following, retrieving up to 10 services monitored on your account between the March 1 and March 3 2016:

https://portal.plumbr.eu/api/v2/services?startDate=2016-03-01T00:00&endDate=2016-03-02T00:00&_rows=10

The response to the call above would look similar to the following JSON:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
  "items" : [ {
    "serviceName" : "BitcoinController.mining()",
    "serviceId" : null,
    "health" : 62.5,
    "transactionSummary" : {
      "successCount" : 100,
      "slowCount" : 50,
      "failedCount" : 50
    },
    "jvmInfo" : {
      "jvmId" : "someJvmId",
      "jvmName" : "JvmName",
      "networkName" : "Network",
      "jvmFullName" : "JvmName@Network"
    },
    "healthy" : false
  }, {
    "serviceName" : "BitcoinController.transact()",
    "serviceId" : null,
    "health" : 97.8,
    "transactionSummary" : {
      "successCount" : 110,
      "slowCount" : 5,
      "failedCount" : 0
    },
    "jvmInfo" : null,
    "healthy" : false
  } ],
  "hasMore" : false
}

As seen, the returned JSON contains two services monitored during the period specified in the input. The services also publish their health along with the number of total, slow & failed transactions detected during this period.

Apparently the BitcoinController.mining() service is performing rather badly, with 25% of the transactions being too slow and 25% failing altogether. The transactions with the bitcoins, as one might guess from the BitcoinController.transact() service are flowing quite nicely, out of the 110 transactions 105 have been succeeding and just 5 have been too slow for the end user to tolerate.

Hope the example was simple and straightforward enough for you to dig into the API itself and start integrating Plumbr to the data visualization and aggregation tools of your choice.