Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.
When I made that change my numbers started working.
This is the same as editing the "to" field in the tree view, right?
Well I tried some values (300, 3600, 600, 200) but the result is always the same: nothing!
Then I edited the field in the tree view by changing the end time, but still nothing is displayed.
I don't know exactly but I guess the timeserver was offline the first time cacti ran, so the time was actually
time()+3600
, then I started ntpd and the time was corrected. Could this be the error??
Another thing: I have the feeling that some of our virtual machines do have issues with their time, some servers are running faster, some slower. The cacti server seems to run normal, but maybe vmware is the reason for these cacti errors??
TheGrudge wrote:I don't know exactly but I guess the timeserver was offline the first time cacti ran, so the time was actually
time()+3600
, then I started ntpd and the time was corrected. Could this be the error??
This could be a problem. If it was +3600 (or 1 hour) out then this could cause some issues with the data in the RRA's. But that should work itself out after that hour has elapsed. If there was a value written to the RRA and then the time was set back 1 hour your RRA's would just not accept anymore data being written to them until the time is back to where that previous value was written. At least that's my understanding of it. Once a value is written to an RRA any previous values are locked and cannot be modified (well except maybe for a full export and re-import of the RRA).
TheGrudge wrote:Another thing: I have the feeling that some of our virtual machines do have issues with their time, some servers are running faster, some slower. The cacti server seems to run normal, but maybe vmware is the reason for these cacti errors??
I has a similar problem with some VM's I was playing with on MS's Vitrual Server. The time would always float away on me. Even the time daemon for Virtual Server, which is suppose to help keep the time in check, didn't work. I ultimately had to abandon any Virtual Server stuff because of all the time issues I was having. I couldn't virtualize my NTP server either because of this issue. It would drift and then be reset, and then drift again, and then be reset. It got to the point where the strata was too high and all other NTP clients wouldn't sync off it anymore. So in my experience, virtualization and acurate time are mutually exclusive right now. So it may be the root cause of some of your problems. Though I run some GSX server stuff at home and don't have near the problems I had with the MS Virtual Server.
warnesj wrote:If there was a value written to the RRA and then the time was set back 1 hour your RRA's would just not accept anymore data being written to them until the time is back to where that previous value was written.
But there are values written to the RRA because my statistics grow as normal, the only thing that isn't possible anymore is zooming and the initial tree view is broken, so I have to unset the from and to fields.
warnesj wrote:I has a similar problem with some VM's I was playing with on MS's Vitrual Server. The time would always float away on me. Even the time daemon for Virtual Server, which is suppose to help keep the time in check, didn't work. I ultimately had to abandon any Virtual Server stuff because of all the time issues I was having. I couldn't virtualize my NTP server either because of this issue. It would drift and then be reset, and then drift again, and then be reset. It got to the point where the strata was too high and all other NTP clients wouldn't sync off it anymore. So in my experience, virtualization and acurate time are mutually exclusive right now. So it may be the root cause of some of your problems. Though I run some GSX server stuff at home and don't have near the problems I had with the MS Virtual Server.
So do you thing I can't run cacti on a virtual machine? Or is it possible to repair the RRA in some kind of way??
Any ideas??
We NEED to run it on VMware so there is no way of running cacti on a normal server again.
It is so frustrating because I am responsible for cacti and everyday people are asking me when it will work again... and I don't even know if it will ever work again correctly...
I had this same problem due to a migration to a new host. The solution to my problem was to change the rrdtool version in the configuration. Since I had copied my original cacti directory to the new server it obviously had all the original settings, but the new server had rrdtool 1.2.x not 1.0.x as the old one did. Here is a FAQ about it: http://cacti.net/downloads/docs/html/faq.html#AEN1956
Oh my god its working!!! Thanks!!! I had Cacti running on SUSE 9.2 but when I moved the machine to VMWARE I updated my Linux installation. So rrdtool was upgraded, too.
So again: thank you! thank you! thank you!
warnesj wrote:You ran into what I ran into when I moved between servers. For each data source the location of the RRA files is in the poller_item table in a field called rrd_path. You need to modify that rrd_path field for each item in the poller_item table. The way I did it for my install was export the Cacti database (using mysqldump) and then using VI I did a search for all instances of my old path and replaced it with my new path. Then I imported the new data and wholla! Everything started working again. But don't modify your original dump file!! Use a copy (just in case everything goes to crap).