CPU and memory graphs are comforting, but the business stops when one specific service stops — the database, the licence server, the application on its odd port. Monitor that thing directly.
Every network has a service whose death matters more than any server’s CPU: the Tally or ERP data service, the SQL instance behind the billing software, the licence server that CAD starts by phoning, the in-house application listening on a port nobody documented. OpManager’s default monitors will happily report the host healthy — CPU fine, disk fine — while that service lies dead. The fix is a custom monitor aimed at the service itself: a port-level check that the application answers, or a custom SNMP monitor reading the one counter that tells the truth. OpManager supports service/port monitors, custom SNMP monitors built on your own OID, and script-based checks for awkward cases. This page builds the common one — a critical service on a known port — and tests it like a sceptic.
Host health and service health are different questions. Custom monitors ask the second one.
Vague targets make useless monitors, so write the facts down first: the server’s name or IP, the port the application listens on (the vendor’s documentation or the server itself will tell you — on the server, netstat -ano lists listening ports against process IDs), and what a healthy answer looks like. A TCP port monitor proves something accepted a connection; some services deserve a stricter test, where the monitor expects a banner or response string. Decide which level your service needs before opening OpManager — a port that accepts connections while the application behind it is hung is the classic false-green.
OpManager lets you add monitors beyond the defaults in three flavours: service monitors for known services and TCP ports, custom SNMP monitors where you supply the OID of the counter you care about, and script monitors for checks only a command can express. For a port check, create the service monitor with the port and a sensible polling interval — critical services deserve a short interval, but remember every second of interval is load and log; one to five minutes is the honest range for most offices. Set the threshold as binary and unforgiving: the service answers, or the alarm is critical. This is not a utilisation graph to be tuned; it is a heartbeat.
Attach the monitor to the server’s device profile so it appears on the snapshot page alongside CPU and disk, and give it a display name the night-shift brain understands — Billing Service – Port 9001, not “Custom Monitor 7”. Then wire the notification profile: a dead business service is critical-tier from birth, so it goes to email plus the escalation path, not to the dashboard-only tier where warnings live. If the service has a known daily restart (some licence services bounce at midnight), note it now and consider a narrow downtime window rather than teaching everyone to ignore a nightly critical.
Now the step everyone skips: stop the service in a quiet moment (or point the monitor at a closed test port) and watch. The monitor should fail, the alarm should raise with the service’s name, and the notification should arrive. Restart the service and confirm the alarm clears cleanly. This five-minute rehearsal catches the real-world killers — a monitor associated with the wrong device, a notification profile attached to nothing, a port number typed from memory. A custom monitor that has never been seen failing is a decoration, not a control.
Once one custom monitor earns its keep, the pattern repeats across the office: a custom SNMP monitor reading a UPS’s battery charge or a printer’s toner OID, a script monitor confirming the backup share actually received last night’s file, a port monitor on the CCTV recorder. Keep a small register of what each custom monitor checks and why — future admins inherit these, and an unexplained monitor alarming at 3 a.m. helps nobody. Retire monitors when the service dies for real; a monitor of a decommissioned application is tomorrow’s alarm storm.
Monitors are associated from the device pages shown throughout the OpManager setup video — see the console layout there, then add yours.
▶️ Watch Full VideoCheck the vendor’s documentation first. On the server itself, netstat -ano shows listening ports with their process IDs, and Task Manager or services.msc connects the ID to the application. Confirm from a second machine that the port accepts connections before building the monitor.
Yes — that is what custom SNMP monitors are for. If the device exposes the value over SNMP, supply its OID, set the unit and thresholds, and test it against the live device. Device vendors publish their MIBs; the OID for printer toner and UPS battery values are common examples.
As few as cover the services whose failure stops work — usually a handful. Each one must have an owner, an alarm route and a reason. A wall of fifty custom checks nobody remembers creating becomes the noise this series keeps warning about.