DGARM Nagios Core - Deployment Process Summary

Source video: DGARM-Infosys-Nagios-Core-deployment-Process.mp4 (3h 59min)

Summary

The main hands-on device onboarding session — with all four components (Nagios Core, NagiosQL, PNP4Nagios, Thruk) working, the team starts actually adding hosts and services, using Nagios XI kept open side-by-side as the reference/comparison system. This is the most process-heavy of the six recordings and maps directly to a repeatable onboarding runbook.

Established host groups (NagiosQL)

Seen configured: linux-servers, windows-servers, network-printers, switches — plus a linux-server host template already built and reused across hosts (dcnpelkkib01, dcnpdlphyez01, etc.), IPs in the 10.150.20.x range.

Step-by-step onboarding process demonstrated (NagiosQL GUI)

Add a host (Supervision → Host): hostname, IP address/description, assign to a host group (e.g. linux-servers), attach the linux-server template, mark Active/Registered, save.
Faster path for repeat hosts — clone instead of rebuild: use the host list's clone/copy icon (second icon from the right in the host list) rather than creating from scratch each time. Edit the cloned copy's hostname/IP/description, keep Active/Registered checked, save. This was explicitly called out as much faster than manual re-entry once one host of a given type is fully working.
Add services per host (Supervision → Services): naming convention observed — SvcT_NCPA_CPU_usage (service template) / description "CPU usage" — choose the NCPA check command, supply the plugin argument (copied from a known-working example rather than retyped), assign host group, save.

- Important distinction called out explicitly: cloning a host is a safe shortcut, but cloning a service is not just a duplicate — each service's underlying check command/arguments must still be correct for that specific host, or it silently won't work. "Service edition is not duplication... we have made a separate service, we have made a command here."
- Additional services added the same way: disk usage, memory usage (copy an existing similar service, change the check command argument, e.g. disk path, save).

Force an immediate check rather than waiting for the schedule, to validate a newly added service right away (Nagios Core "submit passive check" / re-schedule next check via the CGI).
Verify in Thruk: newly onboarded hosts/services show up in Thruk's status views once Nagios has picked up the config and completed at least one check cycle — this is also where the team spot-checked real results, e.g. a switch (linksys-srw224p) showing PING CRITICAL / Port Bandwidth UNKNOWN with check_mrtgtraf: Unable to open MRTG log ... — i.e. MRTG-based port/bandwidth checks need an MRTG log file present before they'll report cleanly, a real gap to fix during network-switch onboarding (see the Network Switch video).
Grouping: host groups can be created/duplicated the same clone-then-edit way in NagiosQL (Supervision → Host groups) rather than built from scratch.

Access/network issues hit during onboarding

Firewall blocking NCPA port on some target hosts — same class of issue as in earlier sessions: had to open the NCPA port (5693) via firewalld (firewall-cmd --add-port=5693/tcp ... then reload) before the host became reachable.
NCPA token/secret mismatches — the NCPA agent requires a matching token ("community string"-like secret) between the agent config and the check command's argument; typos here caused failed/blank checks until corrected.
Confirmed NCPA agent footprint is minimal ("it will fetch the data only") when a team member asked whether it's heavy on CPU/memory — worth reassuring client teams who ask this during rollout.

Process/organizational notes

Windows onboarding got stuck: the team could not find any host in the existing Nagios XI instance already tagged as a Windows server to use as a onboarding reference/plugin source, and the person who'd know (Bimlish) was unavailable — this got parked and rescheduled for the next morning rather than guessed at. Action item: confirm with network/Windows team which IP(s) are already NCPA-monitored Windows hosts in XI, so plugins/config can be copied forward instead of built from zero.
Network devices use SNMP walk (polling), not SNMP trap in this deployment — an explicit design choice confirmed mid-session ("we don't use trap... we do SNMP walk") — relevant for anyone assuming trap-based alerting will work here.
General pacing note from the vendor lead: once one Linux host and one network device are fully onboarded and validated, the rest of each category should replicate quickly since the templates/services/commands are now proven — the slow part is always the *first* of each device type.

Additions to the runbook's fix/issue log

Symptom	Root cause	Fix
New NCPA host unreachable from Nagios Core server	Host-level firewall blocking the NCPA port	`firewall-cmd --add-port=5693/tcp --permanent && firewall-cmd --reload` on the target host
NCPA check returns no/blank data	Token/secret mismatch between NCPA agent config and the Nagios command's argument	Re-verify the exact secret string on both sides (case-sensitive)
Switch port/bandwidth check shows UNKNOWN: `check_mrtgtraf: Unable to open MRTG log`	MRTG-based check expects a pre-existing MRTG log file for that interface, which didn't exist yet	Set up/point MRTG logging for the switch's ports before relying on `check_mrtgtraf` (see Network Switch video for the full fix)
Cloned service silently doesn't work even though the host is fine	Cloning a service only duplicates config — it doesn't guarantee the check command/arguments are valid for the new context	Always verify/edit the check command + $ARGx$ values per service, don't assume clone = ready to use