Lessons learned from support cases - common things to look for.
Does DNS function properly?
If not any daemon that's doing name resolution will be very slow. Verify the system has an FQDN and resolves to itself. Also check if it can resolve other hosts.
### Check the local systems fqdn screen [root@demo: ~]# hostname -f demo.opmantek.com ### can the local system resolve it's own hostname? screen [root@demo: ~]# dig +short demo.opmantek.com 192.168.88.44 ### Can the system resolve other hosts? screen [root@demo: ~]# dig +short freebsd.org 8.8.178.110
Does the system have the correct time? Is it synced with a time server?
[nmis@demo var]$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +cachens2.onqnet 13.64.159.31 3 u 426 1024 377 4.845 -0.126 0.458 +ec2-13-54-31-22 54.252.165.245 3 u 352 1024 377 18.036 1.540 1.008 -node01.au.verbn 192.12.19.20 2 u 514 1024 377 18.966 -16.530 1.176 *ntp3.syrahost.c 218.100.43.70 2 u 422 1024 377 63.642 -1.172 0.852 [nmis@demo var]$ date -u 2017. 02. 16. (?) 22:33:31 UTC
Compare the system UTC time with actual UTC time. A site such as https://time.is/UTC will show current UTC time.
If the system time is not correct it will result in a lot of problems.
- Time stamps not correct on events
- Graph data not correct
- Transactions with other systems fail (e.g. cookies could already be expired at the time of issue.)
NMIS
Email alerts
Contacts.nmis must have the correct DutyTime format.
External Authentication
conf/Config.nmis must have the proper auth_method order as well as that method being provisioned.
opCharts Troubleshooting
TopN
Use the following utility to troubleshoot why charts are being populated into TopN
/usr/local/omk/bin/nmis_topn_export.exe debug=true timing=1 force=1 > topnDebug.txt