Here at Canela, we love using our own products to create internal tools. If our products are good for our own usage, they’ll be good for our clients too. Recently, I have been working on a tool to monitor our various servers and web services. Our cloud is robust and we have lots of failsafes in place but it still good to run a little tool to monitor that everything is alright. Most companies will outsource this to popular server monitoring services, but we decided to build our own.
Our little tool basically goes through all our server regions worldwide and check each server individually. It is a simple loop going from region to region and then verifying the nodes to see how healthy they are. If any node has a problem, our tool will take the necessary action to bring it back up to a good state.
We can simply keep an iPad running the software and we can see at a glance the status of our server and see the software taking action if needed — that is so rare that to implement the feature, I had to force an error on a server so that our software could actually find a bad node and then take action — it is a simple internal tool but one built with our own technology and under our control.
There is a lot of value in building your own tools. Not everything you build needs to be something for the market or a client. Optimizing your workflow by building tools that work the way you want them too makes your work better and reduce your reliance on technologies outside your control.
Those of you familiar with Appli’s control structures might be wondering how I implemented an infinite loop though. There is no repeat forever action. You could in theory use a repeat … times and use a really large number of iterations to mimic a forever loop, but that is not really repeating forever. How to fix that? How to make a software that runs automatically and then keep running (something that is super common in automation scenarios such as a server monitor service).
Well, you leverage screens. Yes, screens. Our tool checks all servers and then it sleeps for a while before checking them again. To implement this, I used two screens:
- A dashboard screen that checks all servers.
- A waiting screen that waits for a while.
The way it works is that once the dashboard screen finishes checking all the servers, it uses the go screen action to go to the waiting screen. The openScreen event of the waiting screen is triggered, that event waits the necessary amount of time before going back to the dashboard screen. That triggers the openScreen event of the dashboard screen which runs the tests. The tool keep going back and forth between these two screens as it bounces forever checking our servers. No repeat loop necessary.
There is a third screen which is an action screen. The openScreen event of that screen will figure out which action it needs to take to fix the badly behaving node and do it. Once it is done, it will go back to the dashboard screen and the dance between that screen and the waiting screen will resume.
A simple and easy to understand tool with a simple workflow just navigating between screens. Sometimes, building apps with Appli is just too easy.
