The collection IS fault tolerant. If for some reason one server has issues, or even entire network segments cease to exist, some collector server somewhere else will accept the data because the collectors are clustered behind a redundant load balancer as well.
And if for some reason a collector is unable to transmit to a processor, it just hangs onto the data (1 minute batches) until one of the redundant processing systems comes back online. This is where a potential backlog could occur...if for some reason the link between the two independent clusters is not there and then it comes back, there would be a large inflow of batches that have been gathering on the collectors. Or, if there are not enough processors to keep up with the inflow of batches, the queue could begin to stack up. Any of these reasons are why I'd like to be able to execute the update with the "collected" time value and not some time that is after the "last update". Of course, I can ensure that the values are updated in the correct order. However, there may be hours of lag between updates. The target where the data was collected did not have any lag, it is just a lag before it finally makes it to the active batch being processed. I've tried to do the updates using the "collected" time value, but it complains that the time value occurs prior to the last update...hence the reason for this thread. -- View this message in context: http://rrd-mailinglists.937164.n2.nabble.com/Disabling-Last-Update-tp7580590p7580597.html Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com. _______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
