Hi Ruben, Yes, I definitely agree :-) Thinking at it, it should be good idea to include timezone information there. Noting this one down.
Cheers, Paolo On Wed, Apr 11, 2012 at 01:01:50PM +0200, Ruben Laban wrote: > It's actually much simpler. Each file already contains the required info > (though its presence does depend on your config). For example: > > --START (1334141100+300)-- > > Start + interval = all the (timestamp related) info I need > > No need to check file ctimes and/or parse configs. I'm guessing relying > on this piece of information is as good as any other solution, if not > better. > > Regards, > Ruben > > > On 29/Mar/2012 23:02, Paolo Lucente wrote: >> Hi Ruben, >> >> The risk of #2 is that if anybody accidentally does anything with >> the file, you might be screwed. It's also true you insert data in >> RRD shortly after the file is created so the probability is slim. >> But in this sense you can perhaps consider relying on file ctime >> rather than mtime. >> >> Relying on the file name is IHMO the way to go. Depending on how >> you are inserting data in a RRD file, your option #1 looks OK to >> me (granted that you define somewhere the config in use and parse >> it accordingly - or more simply you define the step explicitely). >> >> Cheers, >> Paolo >> >> On Thu, Mar 29, 2012 at 12:42:05PM +0200, Ruben Laban wrote: >>> >>> Hi Paolo, >>> >>> Thanks for the clarification. >>> >>> Now to think of a nice way to deal with this "issue". >>> >>> * Manually add the interval to the file's timestamp, or >>> * Rely on the file's mtime, or >>> * Ignore the problem and insert "inaccurate" data into the RRDs >>> >>> None of those are really idea, tho I guess the 2nd one will turn out to >>> the most reliable. >>> >>> Regards, >>> Ruben Laban >>> >>> On 29/Mar/2012 09:01, Paolo Lucente wrote: >>>> Hi Ruben, >>>> >>>> That is intended. What is encoded in the filename is the basetime of a >>>> timeslot, what in a SQL table would be the stamp_inserted field. The OS >>>> timestamp of the file, ie. when the file was last touched, encodes what >>>> in a SQL table would be the stamp_updated field instead. >>>> >>>> Cheers, >>>> Paolo >>>> >>>> On Wed, Mar 28, 2012 at 11:14:48AM +0200, Ruben Laban wrote: >>>>> Hi Paolo, list, >>>>> >>>>> Just now I noticed another unexpected behavior: >>>>> >>>>> -rw------- 1 root root 402 2012-03-28 10:50 >>>>> pmacct_up0_in_total_20120328-1045 >>>>> -rw------- 1 root root 402 2012-03-28 10:55 >>>>> pmacct_up0_in_total_20120328-1050 >>>>> -rw------- 1 root root 402 2012-03-28 11:00 >>>>> pmacct_up0_in_total_20120328-1055 >>>>> >>>>> The documentation states: >>>>> >>>>> KEY: [ sql_table | print_output_file ] >>>>> DESC: ... Dynamic names are supported through the use of >>>>> variables, which are computed at the moment when data is purged to the >>>>> backend. ... >>>>> >>>>> So I'd expect the file written at 10:50 to called -1050, not -1045. >>>>> >>>>> Am I interpreting the documentation wrong, did I stumble upon a bug, or >>>>> something completely different? >>>>> >>>>> Regards, >>>>> Ruben Laban >>>>> >>>>> _______________________________________________ >>>>> pmacct-discussion mailing list >>>>> http://www.pmacct.net/#mailinglists >>>> >>>> _______________________________________________ >>>> pmacct-discussion mailing list >>>> http://www.pmacct.net/#mailinglists >>> >> >> _______________________________________________ >> pmacct-discussion mailing list >> http://www.pmacct.net/#mailinglists > _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
