Nagios Support Forum

Hello @mrjsokol

Thanks for following up, send over the System Profile. We don't see to many issues popping out at us, did see some performance graphics data with some error messages. Let's optimize the perfdata as well.
I want to reset the nagios system user account to make sure that it is not expired.

In some situations the nagios user account can expire causing issues like this to occur. Run this command to see if the nagios user is expired:

Code: Select all

chage -l nagios

If it is, run this command to enable the expired nagios user:

Code: Select all

chage -I -1 -m 0 -M 99999 -E -1 nagios

Please let us know which event that is not sending data so we can do further checking.

Thanks,
Perry

Good afternoon,

password is set to never expire or be inactive. Its only the icon images of any events that have the ? in front of the event referenced. Also Is there a way to set the retention of event to only retain maybe 1 million since we seem to have a lot of events since our check in periods are pretty frequent. If its not the amount of data we are retaining, is there a way to optimize the data so that this page will load faster as this page take some time to load data.

Thank you and have a great week,
Joseph

Hello @mrjsokol

Thanks for following up, I will check to see if there are any config settings to scale down the 'Nagios Event logs', and also wanted to provide the support document to Optimizing The PHP Settings File

Want to take a look at the Apache and Nagios 'eventlog.php' triggered events
Please send over the '/tmp/resultseventlog.tar.gz'.

Thanks,
Perry

Good morning Perry,

Sent over the requested file. In addition, I did note that when deleting and re-adding some hosts to my xi envirn I was getting errors when trying to save changes to my configuration. I know in the past we have done many db repairs. I had to delete the written files to the DB and write the files back via xi admin page to resolve the conflict. Would these DB issues be in any relation to the issue at hand?

Hello @mrjsokol

Thanks for following up, we see that the last time there was an issue with the database was logged 11.11.2021, and appears repaired. We don't see anything reported since. The Core Configuration pre-flight check details shows no errors:
From the Apache logs we see 'eventlog.php' {REQUEST_STATUS} > 200". Do you get the same results when you request from incognito/private mode from your browser?

It pulls the data from '/usr/local/nagios/var/nagios.log' and want to know what you see from the Core CGI backend:
Please let us know how the pre-flight check looks like, private/incognito mode, and the core/cgi-bin/showlog looks like.

Thanks,
Perry

Good morning Perry,

I have pm'ed you the logs and to confirm Pre flight is showing okay. The logs are also showing 200's as well but we ran into another instance of trying to delete out a config to re-add the device and getting an error during the saving of the config to the database. I have attached screenshots of the instance in case I'm not explaining the situation well. In addition, with everything coming up green for event logs, is the only way to improve the performance of the event logs page, to reduce the length of time it records the event logs for or are there other DB optimizations that can be performed?

Thank you and have a great day,
Joseph

Hello @mrjsokol

Thanks for providing the details, want to work on passing the pre-flight by working on 'US - CAFE-73-75-01's TCPOS FrontEnd config. Appears to be correctly config'ed. Head over to Core Configuration Manager (CCM) > Bring up the Service for 'US - CAFE-73-75-01's TCPOS FrontEnd' > hit up all input fields and then [Save]

• Apply Configuration

Then check the Pre-flight:
Run through [Delete] ==> [Write] ==> [Apply Configuration] if pre-flight fails. Let me know how things are looking.

Thanks,
Perry

Good morning Perry,

We had used the delete, write and check files method to get around this issue for a while now. We are seeing the issue along with the icon cache of event logs still prevalent on our installation. Is there a reasoning why this is more frequent after the upgrade to the latest server version?

Good morning Perry,

We had used the delete, write and check files method to get around this issue for a while now. We are seeing the issue along with the icon cache of event logs still prevalent on our installation. Is there a reasoning why this is more frequent after the upgrade to the latest server version?

Hello @mrjsokol

Hello

Thanks for following up with the inquiry on the config issue you saw during the Nagios xi upgrade.

In review, the database relationship hashes with the Core Configurations. In other words, the database is the brain and writes to the Core, and the 'applyconf' imports updated changes to the database. We have checks and balances to verify that the database and configs match. We also keep a hash in the database and compare object configs so that changed objects are updated.

During our upgrade, some factors can cause the outcome. Several things come to mind; one could be a ghost host/service unaware is sticking around. Or there was a config hanging out in the temp directory unexpectedly imported over. Among other things, we realize that a lot is going on during the Nagios upgrade; when writing the configs to the Core from the database, a config possibly introduced, causing an error condition that you received.

Deleting and rewriting from the database does not harm and often restores unanticipated 'cfg' issues that one is not aware of. The relationship between the two is why we have checks in place, but we can rewrite them to make repairs.

Thanks,
Perry