Overlooked API monitoring problems
To understand how API monitoring problems get overlooked, there’s an old story that goes something like this: You come across a person standing under a street light looking around. You ask if you can help.
“I’ve lost my car keys,” they say without looking up.
So you start to look around to help them. After a few minutes you ask, “where did you last see them?”
They stop, look up, and point at the woods to the side of the road. “I dropped them over there,” they say.
“So why are we looking here?”
They look confused for a moment and point upwards.
“But the light is over here!”
What does that all mean for APIs?
We often get asked, “Why should I monitor my APIs separately to all the other stuff I monitor?”
The answer is much like the moral of the story – monitoring what you know already works misses the point of monitoring.
You shouldn’t be monitoring because you’ve been told to. Or only monitoring the stuff you know won’t show errors. Or what’s easy to monitor because you’ve already got the tools.
You should be monitoring what you SAY you do, not what you THINK you do.
We all do it
I’m doing it now with this post. I can guarantee I’m going to read it a dozen times and think, wow, David, you can write can’t you? And I’d put it up on our Blog and LinkedIn and open a cool drink and congratulate myself without noticing a dozen spelling mistakes and a couple of sections that are meaningless nonsense.
So I’m not going to do that. I’m going to have Christine look at it. She’s an editor and a second set of eyes. She’s objective. She’ll fix the spelling mistakes and ask me what the hell I was thinking adding a bunch of meaningless drivel.
Your APIs are like that – and here’s where I’m going with this.
When you set up your monitoring scenarios, you need to do it based on what you’ve documented your API does. And you need to have somebody who has never seen your API before do the rest of the work.
Pay a contractor. Have us do it as part of your on-boarding. Hey, we love to welcome new clients! But get somebody who doesn’t instinctively know that that parameter isn’t actually optional, and that the scope in the OAuth flow always needs to have client:owner in it. A second set of eyes is the key here.
Top Tips for API Monitoring Problem Elimination
What I’m trying to say is, don’t stand under street lamps looking for your keys. Here’s how to flourish in dark places – and our top five tips for eliminating API monitoring problems.
- Regularly have somebody try and onboard your APIs without any prior knowledge, using only your documentation.
- Create your monitoring scenarios from the documentation – not from your (assumed) working test cases.
- Monitor the stuff that isn’t used frequently.
- Embrace the odd! If something is reported that you think is weird, have somebody dig into it. If you can’t see it in your logs, make sure you have better external coverage.
- Don’t rely on the output of any part of the delivery chain as proof that everything is working. That’s our industry street light right there. Just because your API Gateway is working doesn’t mean that your API is. You may be ignoring 4XX errors for good reason, or the database that’s failed is literally nothing to do with your API stack – still, it will be down as far as the rest of the world is concerned.
Independent, external verification of your APIs is absolutely essential. Don’t skimp!
Image thanks to Wikimedia Commons.
