Discovering Synthetic Monitoring test cases in Checkmk
| [0:00:01] | Welcome back to Part 6 of the Checkmk Synthetic Monitoring series, where we build an automated test for a supermarket complaint portal. In the last video, we configured the Robotmk scheduler and installed the Checkmk agent. The tests are now running reliably in the background. And in this episode, we will discover the test cases in Checkmk. Let's go. |
| [0:00:34] | Here is our Ubuntu machine in Checkmk, and the Discovery service on this host already shows us that there are four new Robotmk services that can be discovered. |
| [0:00:47] | Why four, you ask? I will get to that in a moment. Let's start the discovery on the host. There they are. But oops, they are not working. We will have to take a look at that right away. By clicking “Accept all”, we accept all four newly detected services. Now we save the configuration. |
| [0:01:13] | And now let's take a closer look at the host's service list. The newly detected services are still pending, and with an active rescheduling of the Checkmk service, we retrieve the fresh data from the Checkmk agent. |
| [0:01:31] | And here we now have our two failed test services. I open now the Robot Framework log file. You know this already from VS Code, which will surely contain the reason for the failure. And... here we have it. The reason is clear. Remember that we have started the browser with “headless=False”? |
| [0:01:55] | We wanted to have a UI, but if the web tests are supposed to run in the background, this is not possible, of course, because without an X server, the browser cannot display a UI. |
| [0:02:06] | The solution here is very simple. We just have to open a terminal as root and open the tests.robot file. And there we replace “False” with “True” — “headless=True.” |
| [0:02:21] | Now the browser can start headless. On the next execution, the browser should run after two minutes at the latest. Now we reschedule the check service. And yes, now the checks are green. Let's move on to the services. |
| [0:02:38] | First, there is the RMK — which means Robotmk — Scheduler Status. This service monitors the core health of the Robotmk scheduler. It gives answers to questions like: Is the scheduler running properly? Can it build environments? Can it execute the plans and like that. |
| [0:03:00] | And then we have the RMK Plan service. This service tells us whether the scheduler was able to run a certain plan in general — regardless of what the test cases themselves returned. |
| [0:03:12] | Both the RMK Scheduler and Plan services are mostly interesting for Checkmk or Robotmk administrators, or anyone maintaining the Robotmk infrastructure. |
| [0:03:24] | The other two services should look very familiar. They are representing the two test cases we have written in our Robot file, which are submitting the complaint and verifying the message in the mailbox. |
| [0:03:38] | These are your actual monitoring services, and each one reflects the real result of the corresponding Robot Framework test. The blue icon in each service opens the Robot Framework log file. And this is very handy when debugging or proving what happened. |
| [0:04:00] | If you have followed along until here — great job. And now it's your turn. You should be able to discover the same services on your Checkmk system too. Again, if you have any questions or additions, just write them down in the comments. |
| [0:04:15] | And in the next video, we will take this one step further. You will then learn how to apply thresholds and how to get alerts when test durations exceed the normal limits. |
| [0:04:28] | See you in the next video. Bye! |
Interested in learning more? Register for a dedicated Synthetic Monitoring training course.
