{"id":265,"date":"2009-07-13T15:55:03","date_gmt":"2009-07-13T15:55:03","guid":{"rendered":"https:\/\/fir3netwp.gmsrrpobkbd.com\/2009\/07\/13\/nsm-delayed-logs\/"},"modified":"2021-07-24T19:03:05","modified_gmt":"2021-07-24T19:03:05","slug":"nsm-delayed-logs","status":"publish","type":"post","link":"https:\/\/www.fir3net.com\/Firewalls\/Juniper\/nsm-delayed-logs.html","title":{"rendered":"NSM – Delayed Logs"},"content":{"rendered":"
Issue<\/strong><\/span><\/p>\n Logs received on the NSM are delayed by 6 minutes. The log viewer hangs for close to 6 minutes and then displays all the logs within a group. Also today`s log directory does not get created within \/DevSvr\/logs. <\/span><\/p>\n Solution<\/strong><\/span><\/p>\n The NSM device server does a log tuple repair for each log received from the firewall device. To disable the tuple repair change the following flag in the devSvr.cfg to,<\/span><\/p>\n devSvrManager.bypass_policylookup_enabled 1 <\/span><\/p>\n Notes<\/strong><\/span><\/p>\n Changing the above might though have a side affect of causing crashes in how the NSM Gui log window is displayed. Issue Logs received on the NSM are delayed by 6 minutes. The log viewer hangs for close to 6 minutes and then displays all the logs within a group. Also today`s log directory does not get created within \/DevSvr\/logs. Solution The NSM device server does a log tuple repair for each log received from the … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[],"yoast_head":"\n
These tables are maintained in device server (DevSvr). However if these devices are not in sync, then the
tables go out of sync with the logs. Which means that each log that is received needs to query the database in the gui server (guiSvr).
If the logging rates is high then there is a good chance that the thread doing the database query might get stuck or
overloaded.
The NSM tuple repair is not designed to be able to handle such a high amount of queries to the DB.
It is advised that if you require tuple repair of logs then the devices should be in sync with the NSM.
If devices are not keep in sync its better to disable tuple repair. As the tuple repair failing to complete will add an extra load to the NSM servers. <\/p>\n
The full fix for this issue is found within NSM revisions 2008.2r2e10 and 2009.1.
<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"