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)

1. 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.
2. 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.
3. 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).

1. 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).
2. 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).
3. 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

Source recording