You want to monitor workstations, desktop PCs or laptops.
For the sake of simplicity, all the above will be called "endpoint" in this article.
To state the potentially obvious: We do not encourage using Checkmk for monitoring laptops, workstations or similar endpoints.
While it is technically possible to use Checkmk for endpoint monitoring, there are specialized solutions for that.
While it is technically possible to monitor your endpoints - as long as they run our agent - there are some things to consider.
Your endpoints are most likely not online for the bigger part of the day. Hence, you need to consider several aspects:
Checkmk polls all monitored hosts within the configured normal check interval (by default once a minute).
If the service then enters a not-OK-state, Checkmk uses the retry interval to re-check (again, once a minute by default).
If the endpoint is DOWN, Checkmk regularly tries to poll the agent, needs to wait for the timeout (10 seconds by default) before it aborts this try.
This binds a fetcher process for the mentioned amount of time and hence decreases your monitoring performance.
This problem multiplies with the number of endpoints monitored.
Related reading: Checkmk Performance
As mentioned before, your endpoints will be DOWN a good part of the day on average. Hence, you need to think about your monitoring operation.
Typically, your hosts are UP all day every day, and you want your monitoring to notify you, the moment this changes. And if you do some planned maintenance, you schedule a downtime.
For endpoints this will not work as easily: Downtimes to not solve the aforementioned performance issues, as monitoring continues through downtimes. And you will not be able to keep track of manually schedule them for your hosts.
Read below for possible approaches to solve this problem.
Following the downtimes, you need to consider notifications. Monitoring something typically means, that you want to be notified about problems. With endpoints this might be similar, but does not have to.
Depending on your specific use case, you need to make sure your notification configuration fits the use case and creates meaningful information if at all.
There is no "Solution" in the typical meaning of the word. But here are some ideas, to help you get going, if you really want to monitor your endpoints using Checkmk.
Use dedicated sites for endpoint monitoring. This makes both configuration and sizing easier, and the aforementioned issues do not interfere with your most critical infrastructure monitoring.
It is possible to have your endpoints run a script on shutdown, that creates a downtime for themselves through the Checkmk REST API. On boot another script could delete that downtime.
You can use check periods for your endpoints, which configure when a host or service will be checked. That way you can disable monitoring for static periods of time, like the night or weekends.
However, with users suspending their endpoints during breaks or similar, this can only be a partial solution.
After all, we believe in a best-of-best approach, which means "Use the best tool for the job".
While Checkmk is a perfect fit for your infrastructure monitoring needs, it might not excel as much with endpoints.