Setting you timeout values in a chain is a goldilocks problem. You will need to find just the right settings that work for your chain. I will try to go through the 3 situations that I can think of. The first 2 are not good and the third is the best solution.
The Chain For this explanation, I will be using the following chain of 4 APIs the last API calls a database and a consumer of the chain:
The Consumer calls API 1 , API 1 calls API 2 and after API 2 has answered API 1 will call API 3 and then API 3 will call API 4. After the API 3 gets its info from a database and answers to API 2 and API 2 answered to API 1, API 1 will answer the consumer of the chain. This in a normal working chain should, depending on what the APIs do, 500-700 milliseconds.
The consumer has said it wants ...
In two of my previous blogs I talked about what AIOPS can do for you. Now I would like to talk to you about what AIOPS tooling needs to have to be as useful as possible.
• Ingesting data from multiple sources. • Analytics on real time data on the moment of ingestion. • Historical analysis of stored data. • Provide access to the data. • Storing the acquired data. • Use machine learning to analyse the data. • Being able to take action on result of analysis. • Large set of integration options.
You will need to look at your data creating streams. Where is your data located and can the tool ingest this data from all those resources? Do not just think of logging ...
Controlling the incoming and outgoing messages from your application so that they do not cross over a predetermined limit.
Controlling the incoming and outgoing messages on bases of resource measurements. These can be CPU/Disk IO/Network IO. But also, Threads used or functional measurements.
Rate limiting & Throttling are used to protect you application from none agreed high loads. But you not only protect your application. You also protect your back ends because they get the load you send to them. The load to the back ends is not always a 1 to 1. The load can be a 1:N relation so for every call you ...
All Applications that you write should have good logging. But what is good logging? Let’s start with a few No Brainers. Your applications uptime is always more important than your logging. If the data that you want to write is more important than it should not be in a log but in a database of some sort. Logging is only transient data.
We can define 3 types of logging:
There is are a lot of new monitoring tools out there. The tools are becoming more sophisticated and there are more of them. How do you keep up with the new Application Monitoring tools when every time you want to try a new monitoring tool you have to update your applications? This slows down your speed of change. So why not decouple your applications from your monitoring tools.
It used to be that a lot of tooling is API based. This means you from your application send data to a API of your monitoring application. To do this your application has to talk the protocol that the Monitoring tool understands. And if you want to switch monitoring tools you will have to upgrade your application.