Monitoring workstations desktops or laptops

Owned by Robin Gierse
Last updated: Dec 12, 2024 by Matthew Hierholzer

This article details the nuances in monitoring both desktops and laptops using Checkmk.

APPLICABLE TO ALL CHECKMK VERSIONS

Table of Contents

Problem

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.

Background

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:

Monitoring Performance

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: How-to adjust Checkmk performance

Downtimes

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 do 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.

Notifications

Following the downtimes, you need to consider notifications. Monitoring something typically means that you want to be notified about issues. 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.

Host Management

Of course, you need to manage your endpoints in the first place. That means you have to consider how to add, remove and update them, as the fluctuation is probably way higher than with infrastructure.

Solution

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.

Dedicated sites

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.

Automatic downtimes

It is possible to have your endpoints run a script on shutdown that creates downtime for themselves through the Checkmk REST API. On boot, another script could delete that downtime.

Check periods

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.

Wired Network Interfaces

There might be other services one needs to consider, but especially wired network interfaces are rather prominent. Checkmk stores the state and the speed of the network interface in the discovery phase. If a network interface changes state or speed - depending on your configuration - it will raise a non-OK state. There is a good solution, however: Configure a rule "Network interfaces and switch ports" to ignore the speed and state of those particular interfaces. This way you still have metrics and monitoring for e.g., error rates, while not being annoyed by unnecessary notifications.

Specialized solutions

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.