The Conundrum of Monitoring
So you put up your website in the cloud, and your hosting company, cloud providers, and all sorts of people offer you to monitor your website.
Launching A Platform
Now that I am approaching the launch of my platform for auction events for creators, I am putting it up in the cloud. So I need to create a server where the platform will run. Having done that, I encountered so many options to monitor it.
Despite having twenty-five years of industrial experience, I still found my head swirling from all these offers. In all the IT companies I worked for, we had a DevOps or infrastructure team to monitor whatever we needed.
So I had to make some order in my thoughts. For this purpose, I created the drawing you see at the top of this article.
The Web Application and the Scheduler
We have a web application, a website with screens, and a database. For any platform, there are some jobs that we need to do every day, every week, or every month. Such jobs include sending monthly invoices. Thus, we need a scheduler to run these jobs at the required frequency.
What Should We Monitor
Uptime
We want to know that the website is up and running. This is called uptime. The uptime monitor has to run outside the server and the platform. Because otherwise, you would not know that your server is down.
Resources
Websites and servers can get overloaded, either temporarily or permanently. Temporary spikes can be due to particular days of the year, like the holiday shopping season. Permanent overload points to the need to increase the resources available.
Resource monitors require some agent to be attached to your website to report the CPU, memory, or disk load. The resource monitor can reside inside or outside the server. In many cases, you will use both. An internal monitor is cheaper but can be clogged down in overload.
Periodic Jobs
Did the jobs run on time? Were they successfully executed?
You can record somewhere on the server whether the job is finished. But you must monitor outside the server to see if a job was successfully executed. The reason is that if the job did not run, no one inside could tell you that. Maybe the scheduler is dead.
So each regular job has to report to an outside monitor on its execution. And the monitor that has a list of jobs and frequencies can compare these reports to what happened and alert you for any malfunction.
An External Scheduler
Due to all the complications of scheduling and monitoring, numerous companies offer to schedule jobs for you by calling some endpoint (function) in your platform. Such offers are often named cron something - reminiscent of the Linux cron scheduler.
Conclusion
I hope that now you can better sort all the different options for monitoring and make a cost-effective choice.
Top comments (0)