Re-Index Method not re-indexing

[VousDeux]

Greetings:

I'm not certain if this problem is specifically related to this script, or if it is more of a generel help question, but this seemed to me like the logical place to start.

I am running Cacti v0.8.7b, at the current patch level, on Windows XP Pro SP2 with RRDTool v1.2.27, PHP v5.2.3, Apache v2.2.4, and MySQL v5.0.15. I am also using the cmd.php for polling on a 5-minute interval.

I have a process called autotask.exe that is running on Windows 2000 Pro SP4. The machine is used almost exclusively for this task. Microsoft's SNMP is being used, and hrSWRunName and the name of the executable are configured as specified.

Once-per-day, this process is scheduled to stop, and then restart about 3-minutes later. Autotask.exe is responsible for the shutdown schedule, but the AT command is used to launch it again.

What I have discovered is that the graph will usually, but not always, stop accumulating data when either the process is restarted or the machine is rebooted.

When I first configured the script, the re-index method was set to 'Index Count Changed.' After observing the undesirable behavior, I tried resetting the method to 'Verify All Fields.' This change did not seem to solve the problem.

I have found that the only way I can get the graph to start working again is to click the green circle next to the associated data query.

I have attached a couple of images for reference. The 'Supplemental Graph Template Data' shows that the poller was unsuccessful at re-indexing after the process was restarted before 5:00 a.m. I manually clicked the green circle when I arrived at 8:00 a.m. A reboot can also be seen before noon. I waited for 15-minutes after the reboot before manually clicking the green circle again.

Thank you for your consideration. I am looking forward to resolving this issue.

[VousDeux]

Oops.

I intended to post this under Win32 - Monitoring running processes. I'm not sure exactly where I went wrong, but could someone please move it?

Thanks

[gandalf]

Moved on user request

[BSOD2600]

Hmm the verify all fields should've done the reindexing automatically. Change your cacti logging level to debug for a cycle and pay attention/post what Cacti does for that device when it runs the win32 running processes script (maybe be easier to just look for the data source number aka DS[xx]).

[VousDeux]

Hi, and thanks for the response.

I'm not exactly sure I know how to do what you are asking. In the Cacti settings, I found that I could set the poller logging level to debug, so that is what I did. I did not see anything that just said cacti logging level.

I searched 10,000 tail lines of the resulting cacti log file for DS[2937], after the polling cycle, and found only the following two entries:

06/12/2008 09:24:58 AM - CMDPHP: Poller[0] Host[76] DS[2937] SNMP: v2: 10.41.207.85, dsname: proc_mem, oid: .1.3.6.1.2.1.25.5.1.1.2.572, output: 117712
06/12/2008 09:24:58 AM - CMDPHP: Poller[0] Host[76] DS[2937] SNMP: v2: 10.41.207.85, dsname: proc_cpu, oid: .1.3.6.1.2.1.25.5.1.1.1.572, output: 819323

Please forgive my ignorance if this is not what you were asking for. I appreciate your time and attention to this matter.

Thanks again!

[VousDeux]

I decided to also keep an eye on the log while the autotask.exe was going through the restart process in question. When the autotask.exe shutdown at 09:53 a.m. I found the following log entries for the next polling cycle:

06/12/2008 09:54:55 AM - CMDPHP: Poller[0] Host[76] DS[2937] WARNING: Result from SNMP not valid. Partial Result:
06/12/2008 09:54:55 AM - CMDPHP: Poller[0] Host[76] DS[2937] WARNING: Result from SNMP not valid. Partial Result:

At the next polling cycle, the autotask.exe had been restarted. Here are the log entries:

06/12/2008 09:59:58 AM - CMDPHP: Poller[0] Host[76] DS[2937] SNMP: v2: 10.41.207.85, dsname: proc_cpu, oid: .1.3.6.1.2.1.25.5.1.1.1.2316, output: 607
06/12/2008 09:59:58 AM - CMDPHP: Poller[0] Host[76] DS[2937] SNMP: v2: 10.41.207.85, dsname: proc_mem, oid: .1.3.6.1.2.1.25.5.1.1.2.2316, output: 29260

I have observed that the graph is updating this time around without the need for manual intervention (it figures, I wanted it to mess up this time).

I have also had two occasions, when I clicked the green circle to reload the data query, that it left a nasty spike in the cpu data, so I would rather not have to do that.

Thanks for your help!

[BSOD2600]

I have observed that the graph is updating this time around without the need for manual intervention (it figures, I wanted it to mess up this time).

Indeed, tis typical when troubleshooting something

I have also had two occasions, when I clicked the green circle to reload the data query, that it left a nasty spike in the cpu data, so I would rather not have to do that.

Hmm, thought I set the max for the data source correctly, but apparently not. Go to data templates -> SNMP - Running Process Info. For the proc_cpu change the max to 100, which I think should fix it for future devices. Then you'll need to use the "rrdtool tune" function to resize the proc_cpu DS in your existing rrd files which use this template. Alternatively, you can delete the rrd file(s) so cacti will re-create them with the update DS sizes.

Also, notice the end of the OID, .1.3.6.1.2.1.25.5.1.1.2.2316 is the PID of the process being monitored. Thats a quick way you can verify if cacti is going to/polled the correct PID for its info. Can also look in the cacti poller cache...

[VousDeux]

I had already set the data source item maximum value to 100. Thank you for confirming that I am at least on the right track

Since I messed up while trying to figure out how to remove the spike, I ended up deleting the rrd file anyway, so the new one should be good to go.

I am a little unsure, however, about the value that I should have set while trying to execute the tune function. I finally arrived at 'proc_cpu:102400,' but I guess I'm still not sure because the log entry I posted earler had an output of 819323 for the proc_cpu.

Thanks again!

[BSOD2600]

I am a little unsure, however, about the value that I should have set while trying to execute the tune function. I finally arrived at 'proc_cpu:102400,' but I guess I'm still not sure because the log entry I posted earler had an output of 819323 for the proc_cpu.

I think it would be something like

Code: Select all

rrdtool tune --maximum proc_cpu:100 <rrd file>