Are XaaS vendor APIs really useful for IT monitoring?

Definition of “API”: the magic word that every IT sales person has to trot out as soon as they’re asked whether their application can interface with another.

Correct answer! (most of the time).

Now imagine the IT team implementing the solution and now thinking: “so how are we going to connect this tool and that other one?”. There you go. It’s like receiving a piece of Swedish furniture in kit form: now it has to be assembled!

Are there any interoperability issues?

Statistical studies on the IT monitoring market are, after all, rare.

We have, however, unearthed a 2021-2023 barometer commissioned by vendor Centreon from Vanson Bourne, based on a panel of 600 IT professionals in Europe and North America (companies with over 500 employees). You can download it here.

The first surprising figure: only 61% of their information systems are monitored.

27% of those surveyed consider visibility of their IS performance to be excellent. So there’s still a lot of fuzziness out there!

Last but not least, 59% of respondents are not satisfied with their tools, with the number 1 reason being poor integration of tools and their inability to provide unified visibility of their IS.

Being optimistic and benevolent, we could say that Senhub is aimed at 59% of EU and US companies!

The truth is undoubtedly a little more nuanced. Nevertheless, it does show that interoperability between IS management tools is a real issue.

Understanding these issues

It is now mandatory for all vendors to offer APIs enabling data to be retrieved from or to their applications. Gone are the days of reverse engineering, when people hacked into databases to make minor modifications. APIs provide protection for data and data models. They are also the standard that enables secure exchanges across the Web. In short, the Internet and the Cloud, in particular, would be very different (if not non-existent) without them.

But is it enough for a vendor to offer its own APIs?

I think the answer has long been no. The proof: vendors offer SDKs in the main languages to make developers’ lives easier. If APIs evolve, the vendor updates its SDK, which developers can then effortlessly integrate into their applications.

When you’re a user of an IT monitoring solution, there’s a catch: you’re not the developer of the solution. So if you need to collect metrics from a Cloud provider or SaaS application, how do you go about it?

The world of resourcefulness

Not all users are created equal. Some are able to purchase very expensive monitoring solutions that cover their every need. Others can call on the services of companies capable of adapting a solution to their needs. At the other end of the scale, many have no major needs and are satisfied with a small, inexpensive or open source solution as is.

But what about the vast majority of IT teams between these 2 extremes, who are asked to be efficient and responsive, and for whom a centralized monitoring tool is a real challenge?

To be effective, IT Ops need to build a cockpit where all important information can be fed back into the system.
From there, they can define and implement a unified alert strategy in which the right person is notified of an incident within their expertise as quickly as possible, and ensure that they have the metrics they need to resolve the problem quickly. Let’s not forget, by the way, that an unavailable application costs money and/or impacts the company’s sales.

From this same cockpit, IT Ops will be able to extract all the information they require. Who doesn’t need to produce a dashboard of application health, or availability reports to ensure that SLAs are being met?

This majority category of users therefore needs to solve this interoperability problem.

Are XaaS vendor APIs really useful for IT monitoring?

By that I mean, if you’re not a cloud provider like Azure or Amazon, will your users make the effort to use your APIs?

Well, it depends.

We’re clearly talking about a cost/benefit ratio here. Users will make the effort if they have a particular issue with the application concerned, or if they can find a quick and cheap way of doing so. If not, they’ll take care of it when they have a trainee on hand, and it’ll be a “nice to have”.

Let’s talk a little technical. What does it mean to develop a connector?

It already implies that there are people on the team who know how to develop a script in Powershell, Python, Perl or any other language that can consume APIs.
They then need to understand the API documentation, identify the interesting information to be collected and write the script that will collect, aggregate and format it so that the monitoring tool can interpret it correctly when it runs the script.
And don’t forget that the connector must be maintained. Vendors are constantly upgrading their APIs, and sometimes in a rather brutal way.
All this multiplied by the number of IS-integrated solution vendors.

Not so simple, and above all, very time-consuming…

So, unless a vendor considers that its APIs are there to impress, it has every interest in facilitating their use by its users, especially if it considers this to be a competitive advantage.

This majority category of users therefore needs to solve this interoperability problem.

Conclusion: Senhub, what does it do and for whom?

Senhub solves all the problems outlined above. It provides off-the-shelf connectors, designed and maintained by IT monitoring experts.

The IT Ops team has no development or maintenance effort to make, since Senhub responds to its monitoring tool in its native format.

If the APIs or the monitoring tool evolve, Senhub adapts, thus guaranteeing the continuity of the metrics flow.

For a SaaS vendor, it’s the ultimate SDK for direct compatibility with PRTG, Zabbix, Prometheus, Nagios and its forks.

In conclusion, Senhub makes a significant contribution to improving the integration of our customers’ IS management tools, with the monitoring tool as the main focus. It makes interoperability possible for all budgets, enabling IT teams to concentrate on their core business and not waste time battling with SaaS vendor APIs.