How to configure the Robotmk Scheduler
| [0:00:00] | Welcome back to the Checkmk Synthetic Monitoring series. So far, we have built our first Robot Framework tests to check if the complaint portal works from the user's perspective. And in this video, we are going to take the next step to help our hero, Bob. |
| [0:00:17] | We will learn about the architecture of Robotmk, configure Checkmk for Robotmk, and install the Checkmk agent on the test machine. |
| [0:00:40] | In this diagram, I would like to explain the components that are now all working together. On the left, we have our Checkmk server; on the right, the test client, where both the Checkmk agent and the Robotmk scheduler will run. And with the help of RCC, the scheduler will automatically create the Python environment to execute our Robot Framework tests. |
| [0:01:09] | The results are stored in the file system and collected by the Robotmk agent plugin. The Checkmk server receives the raw execution results from Robot Framework, and discovers and monitors the test cases. |
| [0:01:27] | Now we need to prepare the client. You can use a dedicated test host for this. In my case, I'm keeping it simple and using the same machine I created the tests on. |
| [0:01:39] | It's already monitored by Checkmk. When the Robotmk scheduler runs later on this machine, it needs to know where the robot suites are located. |
| [0:01:51] | I like to use “/var/robots,” but you can also use a different path. |
| [0:02:06] | That's it. Now it's time to configure the Robotmk scheduler to actually run our tests. |
| [0:02:13] | In the Setup menu, search for the word “robot,” and we use the bakery rule and choose Robotmk scheduler (Linux). Add rule. |
| [0:02:25] | This rule creates the configuration file for the scheduler. The first thing we configure is the base directory. This is where Robotmk will search for the test projects. In my case, I have chosen “/var/robots.” |
| [0:02:40] | What comes next might look complex, but it's actually very flexible and logical. Let's break it down from the inside out. |
| [0:02:50] | A plan describes how Robotmk should execute a particular test suite. Plans are grouped into sequences, which define when and how often the tests run. You can add multiple plans to a sequence. |
| [0:03:07] | They are then executed one after another sequentially. You can also create multiple sequences, which then run in parallel with individual intervals. You just have to make sure that your client has enough CPU and RAM to handle it. |
| [0:03:25] | Now let's create our first plan in the first sequence. The sequence should run every two minutes. The application name — this can be anything — I will call it “ComplaintPortal.” |
| [0:03:38] | Relative path to test suite means the path to your robot file relative to the base directory. I usually copy here the full path from the explorer and then just remove the base directory portion. |
| [0:03:52] | And then finally limit per attempt: one minute is plenty of time to run this test, of course. If your application is unstable and you want to retry failed tests automatically, you can configure re-executions here; but we won't need that right now. |
| [0:04:10] | Next we configure the environment build. Relative path to robot.yaml — this tells RCC how to build the Python environment for the suite. And the timeout for the environment build — let's set it to ten minutes, that's more than enough. |
| [0:04:28] | And finally we limit this rule to apply only to our test host. All the other settings can remain as they are at the beginning. |
| [0:04:38] | Then save the rule and go to the Agent Bakery where we can bake now the new agent package. |
| [0:04:54] | When downloading, just make sure you get the right one because there are already other packages available like here. The column on the right side always shows the hostname for which the respective agent package was baked. |
| [0:05:18] | To install the package, we become the root user with sudo and use the command “dpkg -i” to install the Debian/Ubuntu package. |
| [0:05:35] | And again, be careful to install the correct one. |
| [0:05:40] | On Linux, the Robot scheduler then starts as a systemd unit, and with "sysctl status", you can check whether the system service is running correctly. |
| [0:05:52] | And that's it. In this video, you learned how to configure the Robotmk scheduler in Checkmk and create a new installation package using the Agent Bakery. The new agent is now installed, which means that our suite is now running at its defined interval of two minutes. |
| [0:06:12] | Now try it out yourself and let me know in the comments below if it is working on your side. In the next episode, we will discover the test services in Checkmk. See you there! |
Interested in learning more? Register for a dedicated Synthetic Monitoring training course.
