Bug 310 #326
Bug 310 #326
Conversation
| @@ -426,10 +427,20 @@ def _process_naarad_config(self, config, analysis): | |||
| naarad.utils.parse_basic_metric_options(config, section) | |||
| sar_metrics = naarad.utils.get_all_sar_objects(metrics, infile, hostname, output_directory, label, ts_start, | |||
| ts_end, None) | |||
| if sar_metric.ts_start is None and (sar_metric.ts_end is None or sar_metric.ts_end > ts_start): | |||
| sar_metric.ts_start = ts_start | |||
| if sar_metric.ts_end is None and (sar_metric.ts_start is None or ts_end > sar_metric.ts_start): | |||
There was a problem hiding this comment.
Minor but looks like extra space (2 spaces) between > sar_metric.ts_start
There was a problem hiding this comment.
Good catch. Thanks.
On Fri, Mar 27, 2015 at 10:39 AM, Richard Hsu [email protected]
wrote:
In src/naarad/init.py
#326 (comment):@@ -426,10 +427,20 @@ def _process_naarad_config(self, config, analysis):
naarad.utils.parse_basic_metric_options(config, section)
sar_metrics = naarad.utils.get_all_sar_objects(metrics, infile, hostname, output_directory, label, ts_start,
ts_end, None)
if sar_metric.ts_start is None and (sar_metric.ts_end is None or sar_metric.ts_end > ts_start):sar_metric.ts_start = ts_startif sar_metric.ts_end is None and (sar_metric.ts_start is None or ts_end > sar_metric.ts_start):Minor but looks like extra space (2 spaces) between > sar_metric.ts_start
—
Reply to this email directly or view it on GitHub
https://github.com/linkedin/naarad/pull/326/files#r27315032.
| @@ -675,6 +675,7 @@ def get_standardized_timestamp(timestamp, ts_format): | |||
| else: | |||
| dt_obj = datetime.datetime.strptime(timestamp, ts_format) | |||
| ts = calendar.timegm(dt_obj.utctimetuple())*1000 + dt_obj.microsecond/1000 | |||
| ts = timestamp.replace(' ','_') | |||
There was a problem hiding this comment.
This doesn't seem to play well with dygraphs (the report.html file when graphing with Javascript). The Matplotlib files look correct though!
There was a problem hiding this comment.
Actually this is not what we want. This bypasses the conversion of a string timestamp to epoch milliseconds. We need the epoch milliseconds for comparison purposes otherwise we are comparing timestamp strings which won't be the correct comparison for comparing against ts_start and ts_end configurations.
|
I did try tackling this at one point, and it's not the complete solution that I wanted. As an overview all metric parsers will write to CSV files at the end and write The only issue, I had was that it converts it to a datetime string format such as |
Fix for bug #310 . The fix is more like a hack. So please review if it is ok.