Boost excessively logging updates

[SergejLT]

updated from cacti v1.1.29 to -> cacti v1.1.33 spine v1.1.33 boost disabled "direct population of poller_output_boost table" disabled; "poller_output_boost" table empty only local poller working

cacti.log each poller cycle keeps increasing by these notes ->

2018/01/23 14:08:30 - BOOST NOTE: Updating Local Data ID:'34861', Total of '0' Updates to Process 2018/01/23 14:08:30 - BOOST NOTE: Updating Local Data ID:'98375', Total of '0' Updates to Process 2018/01/23 14:08:30 - BOOST NOTE: Updating Local Data ID:'98391', Total of '0' Updates to Process 2018/01/23 14:15:00 - BOOST NOTE: Updating Local Data ID:'123217', Total of '0' Updates to Process 2018/01/23 14:15:00 - BOOST NOTE: Updating Local Data ID:'123216', Total of '0' Updates to Process 2018/01/23 14:15:00 - BOOST NOTE: Updating Local Data ID:'123212', Total of '0' Updates to Process 2018/01/23 14:15:00 - BOOST NOTE: Updating Local Data ID:'123213', Total of '0' Updates to Process

what is causing this? can these notes be disabled? they are filling log significantly

[netniV]

Try the following SQL statement and let me know the results:

SELECT name,value FROM settings WHERE name in ('boost_rrd_update_enable', 'boost_rrd_update_system_enable');

[SergejLT]

result

+--------------------------------+-------+ | name | value | +--------------------------------+-------+ | boost_rrd_update_enable | | | boost_rrd_update_system_enable | on | +--------------------------------+-------+ 2 rows in set (0.00 sec)

[netniV]

Yeah, it's that second option that's causing it :)

'boost_rrd_update_system_enable' => array(
        'friendly_name' => __('System Level RRD Updater'),
        'description' => __('Before RRD On-demand Update Can be Cleared, a poller run must always pass'),
        'method' => 'hidden',
        'default' => ''
        ),

So far I can't find any code that actually disables that setting. Therefore, I would use the following SQL statement:

UPDATE settings SET value = '' WHERE name = 'boost_rrd_update_system_enable';

If you are sure you are not using Boost, then you should be OK with that. Let me know if there are any more issues though.

[SergejLT]

Yeap that did the trick. Thanks

[pautiina]

@SergejLT read please this https://github.com/Cacti/spine/issues/42 and this issue https://github.com/Cacti/cacti/issues/1127 and update you spine

[SergejLT]

this problem started when i updated cacti and spine to latest v1.1.33

[netniV]

The current version of the Cacti code checks both values I mentioned above. If EITHER is set, it's considered to be on. If boost_rrd_update_enable is on, but boost_rrd_update_system_enable is not, it actually forces boost_rrd_update_system_enable on.

As far as I can see, nothing ever turns that back off. Thus, once boost has been enabled, or you save the settings with that flag in them, your stuck with it being on.

Spine only checks the boost_rrd_update_enable

[g1augusto]

Hi Everyone,

I noticed that I also have these logs and i have BOOST enabled

6/Jan/2018 11:25:21 - BOOST NOTE: Updating Local Data ID:'28592', Total of '6' Updates to Process 26/Jan/2018 11:25:21 - BOOST NOTE: Updating Local Data ID:'28591', Total of '6' Updates to Process 26/Jan/2018 11:25:07 - BOOST NOTE: Updating Local Data ID:'9', Total of '5' Updates to Process 26/Jan/2018 11:25:07 - BOOST NOTE: Updating Local Data ID:'8', Total of '5' Updates to Process 26/Jan/2018 11:25:02 - BOOST NOTE: Updating Local Data ID:'16', Total of '4' Updates to Process 26/Jan/2018 11:25:02 - BOOST NOTE: Updating Local Data ID:'15', Total of '4' Updates to Process 26/Jan/2018 11:24:58 - BOOST NOTE: Updating Local Data ID:'121', Total of '4' Updates to Process 26/Jan/2018 11:24:58 - BOOST NOTE: Updating Local Data ID:'120', Total of '4' Updates to Process 26/Jan/2018 11:24:50 - BOOST NOTE: Updating Local Data ID:'392', Total of '4' Updates to Process 26/Jan/2018 11:24:50 - BOOST NOTE: Updating Local Data ID:'391', Total of '4' Updates to Process 26/Jan/2018 11:24:47 - BOOST NOTE: Updating Local Data ID:'393', Total of '4' Updates to Process

For a very big amount at every BOOST copy interval, is there a way to eliminate them ?

[netniV]

I'll see if there is a POLLER_VERBOSITY assigned to the logging level of these, if not that may be a fix though @cigamit may say there is a reason to always log these.

[netniV]

From what I can see, the logging option is wrong in lib/boost.php. It's actually reading what the system level of logging is, and then using that on it's function calls. What it should be doing is the opposite, setting the logging level to DEBUG and then raising it to LOW when it is in debug mode.

So this:

$log_verbosity = read_config_option('log_verbosity');

if ($debug) {
        $log_verbosity = POLLER_VERBOSITY_DEBUG;
}

The above basically means it will ALWAYS log it. It should be

$log_verbosity = POLLER_VERBOSITY_DEBUG;

if ($debug) {
        $log_verbosity = POLLER_VERBOSITY_LOW;
}

[cigamit]

I looked at this merge, and I'm scratching my head, saying what is wrong with it. I'll take a second look today.

[netniV]

This is a bit like the logging error on with the cacti_log function were it was slightly out. On this, rather than saying that boost should be logged at a certain level, it was reading the configuration level and using that meaning it never matters what logging level you had, it was also logged. If that was supposed to happen, it shouldn't even bother reading the log setting, and shouldn't pass the POLLER_VERBOSITY flag at all.

Config	Boost	Logged
LOW	LOW	Yes
MEDIIUM	MEDIUM	Yes
HIGH	HIGH	Yes

What should happen is

Config	Boost	Logged
LOW	HIGH	No
MEDIIUM	HIGH	No
HIGH	HIGH	Yes

[cigamit]

Right, I understand that.

[netniV]

@jhonnyx82 this should be in the latest develop code, can you confirm this now works for you?

[g1augusto]

Sorry, I did not have a chance to try that yet.

Can you point me to the files related to this ? I would not commit the whole develop to my production instance but I can add the files related

[anarkia1976]

@netniV @cigamit I'm on the latest release and it seem fixed for me. Always a great work guys. The last update is soo stable. thanks a lot.

[cigamit]

Thanks. Closing. Releasing soon as Rony get's back from Cisco Live.