In the context of API monitoring, your API management system might generate logs to help you learn about the behavior of your APIs. For instance, you might get an alert if a HTTP error is seen. That might tell you there are problems with the API, but only problems of certain kinds. If won’t tell you if there is a problem with what is being returned to the user.
This can be a big issue. Some systems will always return a HTTP 200 response code, even if there is a server error. (SOAP API are especially notorious for always returning 200s.) In this situation, a HTTP 500 response code (Internal Server Error) should return. But if you don’t configure the system properly, tit won’t happen. And in some instances, what seems like an error to the end user might not seem like an error on the server side.
(It can be tempting to wrap code in layers of exception handling, which might prevent a process crashing. But if you catch all the exceptions thrown, it might look as though as the server returned successfully because it has. It just hasn’t done what the user wanted it to.)
DevOps logs also won’t tell you the overall latency your end users are experiencing. If you want to understand what is happening to your end users – and your business – you have to measure what is actually happening to your end users. Otherwise you’re just guessing.
There are a couple of issues here. The first is that a business is a cybernetic organization. It takes in inputs from its environment, processes them in various ways, and produces outputs.
A cybernetic organization constantly changes as it responds to change in its environment and internal state. It evolves to realize its goals more effectively and efficiently. Of course, one of the things that can change about a business is its goals. It can even change how it changes its goals!
A business needs to know as much it can about its internal state and external environment. Or, rather, as much as it needs to know. Measuring things can be expensive and you don’t want to spend a lot of energy, effort and resources to measure things and process the collected information if it doesn’t tell you anything useful in improving the business.
If your APIs aren’t working properly, it’ll cost you in the long run if not the short. Now, DevOps might say the APIs are working fine from their perspective. Why even bother measuring something if it is only to show up problems we can’t fix?
But the silo approach really won’t do. People defending their own patches by measuring and managing against soft metrics is ultimately only going to end in tears. All cybernetic organizations – whether microbes, whirlpools, people, companies or galaxies – are involved in the Darwinistic struggle for life. It’s the job of the brain of the firm to see through the self-interest of the occupants of the silos.
Monitoring the performance and quality of your APIs is neither difficult nor expensive. As APImetrics has shown, it’s false economy not to understand your APIs and to rely on measuring what you can measure just because you can measure it. It’s vital to always think those steps further out.
Because if you don’t, your rivals are going to.