[STORM-2780] MetricsConsumer record unnecessary timestamp

[BigOneLiu]

https://issues.apache.org/jira/browse/STORM-2780

@revans2 Could you please review my pr? thx

[revans2]

@BigOneLiu When the task info is created

storm/storm-client/src/jvm/org/apache/storm/executor/Executor.java

Lines 291 to 293 in 124acb9

	IMetricsConsumer.TaskInfo taskInfo = new IMetricsConsumer.TaskInfo(
	hostname, workerTopologyContext.getThisWorkerPort(),
	componentId, taskId, Time.currentTimeSecs(), interval);

The time that is set there is when the metric was sent (in seconds). In most cases it should not take much if any time for it to make its way to the metrics consumer, but if it does the times could be off from one another.

I personally am +1 for this change, because I don't really use this time when I am looking at logged metrics, but if others want it they should speak up.

[BigOneLiu]

@vesense
Could you please review my pr?
If it could be an improvement?

[vesense]

I prefer to Ieave it as it is, since the log time and the taskInfo.timestamp is not same. Perhaps someone uses it, I'm not sure.

[BigOneLiu]

@revans2 @vesense
Actually you can easily get the taskInfo.timestamp(1508207360) from thr date (2017-10-17 10:29:20) ,and Log4j framework has provided more accurate date(2017-10-17 10:29:20,906 126908).
If users who don't know MetricsConsumer read this log file, they may be confused.
So I think it's better to delete it.

[revans2]

@BigOneLiu actually like I sad they are not coming from the same location. 99.9% of the time they are probably going to be the same underlying value, but if for some reason the metrics tuple is delayed by 1 second they are 100% guaranteed to be different.

@vesense if you are concerned about this that is probably a good enough reason to not do it. Users are going to have enough on their hands going to 2.x where we may even be moving to an entirely new metrics system.

[BigOneLiu]

@revans2 like you said 99.9% of the time they are the same,and if the tuple is delayed by 1 second,it's a big problem for storm.maybe you don't need this data then.
vesense's consideration is good enough but I don't mean to delete the attribute in taskInfo.I just delete it from log file in case user get confused.
users can call taskInfo.timestamp whenever they want to use it in new metrics system.
I just concern about this,if you think it's not a good step I would no longer insist.