Press enter to see results or esc to cancel.

Monitor Web Api Responses with Nodinite

API’s have become such an important part in our integration eco-systems and for us at Nodinite API’s are not just providers of data, they also help us to make sure we deliver the highest possible quality.

For instance, you can look at our documentation. Nodinite is documented using Markdown which we after a change compile to HTML. The documentation is version controlled using GIT in Bitbucket and compiled using an Azure Logic App to HTML. The compiled HTML is then saved in an Azure Table, this for two reasons:

  1. While visiting the documentation page we want to provide you the documentation with the best performance
  2. Azure Search; We are using Azure Search to make our documentation searchable and Azure Search needs storage such as an Azure Table to index it in the right way.
Nodinite Documentation High Level Architecture

In this blog post you will learn how to monitor a web service with Nodinite v4.x.

If you want to follow the steps described here please make sure you have the following:

  1. A running Nodinite instance.
  2. Nodinite Web Service Monitor Agent installed on one of your machines

The Problem

While Markdown is awesome, it is important to know your way around and to notice that things can go wrong.

For instance, while writing your documentation and putting hyperlinks into it, you need to double check syntax and your spelling, otherwise it will not work – you can follow this link to learn more about hyperlinks in Markdown:

At Nodinite we chose to use hyperlinks in the following way (see Gist below).

The code snippet above compiles [Nodinite][] to a hyperlink linking to that is defined in the bottom of the markdown file. This allows us to have all external links stored at the bottom of the page and it is easy for us to make changes to the URL’s if needed.

What we realized was, that you have to treat Markdown with caution, because otherwise you will have links in your documentation that are not compiled correctly, like we had.

We identified the issue while reading our documentation and saw the following characters as part of the compiled documentation “][]” and after investigating the issue, we realized, we were not cautious enough while writing hyperlinks. Of course, this is not good, so we had to figure out a way to detect this issue automatically and get notified whenever there are hyperlinks that are not compiled correctly.

The Solution

Nodinite is a platform to centralize monitoring, logging and documentation of your system integrations/workflows and that’s were we thought, why not use Nodinite to monitor a web service which we can ask to see if the following characters are part of the compiled documentation: ][]. Below you will find the steps we were taking to monitor if there are any markdown syntax hyperlink errors.

What we need:

What we want to achieve:

  1. Set up Nodinite’s Web Service Agent to continuously call our API
  2. Set up a monitor view in Nodinite that monitors the status of the API call
    1. The monitor view is OK if no errors were found
    2. The monitor view is ERROR if errors were found

The steps needed in Nodinite:

  1. Open Nodinite’s web client in your browser
  2. Go to “Administration”
  3. Go to “Sources”
  4. Choose your Nodinite Web Service Monitor Agent
  5. And click on “Remote Configuration”; This will open a modal in which you can configure what to monitor with the monitor agent. The monitor agent allows you to monitor as many web-services as you want; REST, WCF or any web service you want.
  6. In the “Web Services” Tab, press “+ Add”.

  7. As the name for the web service call, we chose “Nodinite Documentation – Documents containing ][]”

  8. As for the request, response and evaluation of Response body tabs, we need to do the following
    1. Request

      The URI is self-explanatory, this is the request URI to the API that will return the list of files in our documentation of which the content contain ][].
      The polling interval shown in the picture above is for demo purposes only. In our scenario we have set it up to check every 4th hour.

    2. Response

      The response status is expected to be 200, since our API is designed that, as long as no exception has been thrown, the status is 200. Otherwise a 4xx or 5xx status is used to tell the consumer that something went wrong.

    3. And now to the important part: Evaluation on Response Body

      The API we have designed returns a list of strings and we expect the list to be empty. Also, the API returns its body in JSON and that means, if the list is empty, there will still be a response body, an empty list: [].

      To make sure the response body contains an empty list we will use a regular expression – \[\], which will match on [].

After following the steps above you will have to add the web service call to a monitor view, either a new or existing one. When you have done this, Nodinite will automatically notice you whenever the list is not empty!

Nodinite Monitor View showing that our RegEx did not match – we now know there are files in our documentation containing ][].
Et voilà! You are now monitoring the response of your web api!

This is a simple use case that shows the power of Nodinite. Many of both legacy and modern integrations are built based on APIs and these are important to monitor. Nodinite provides fully extensible API monitoring in which you can not only monitor the response body, but also the response status. There are no limitations on how many API’s you can monitor.

Let us know what you think and also, click here to see a full list of monitor & logging capabilities with Nodinite



Leave a Comment