Hi @Anoshpananda, sorry my bad and thanks for the clarification. I cannot think of any “automatic” solutions, and the only solutions I can think of are ultimately variations on what @gonhaddock has said as I don’t think there is going to be any automatic mechanism for this.
Whatever you do will almost certainly involve inserting additional nodes or components into your workflow at the points you wish to monitor.
I have decided to try approaching this from the point of view of creating a component to do some of the work for us. I’ve called it “Record Component Time”, and the idea is that it could be linked into the workflow using the flow variable ports.
So if we had the following workflow, containing two components and a bunch of other nodes:
We could “monitor” the times of those components by stitching in a “Record Component Time” component on either side. This would be configured with a “label/component” name and an indicator of whether it is recording start or stop…
Of course this isn’t just restricted to monitoring components. These could be placed around anything for which you wanted to record start and end times.
Provided they are connected in with the flow variable ports, at the end of this, the final “Record Component Time” component can have its data port read to retrieve the timing information.
The flow data ports are purely for orchestration. The component doesn’t use them for passing the timing data… So just how this data makes its way to the final data port is “using magic” 
(Oh and it might also uses an in-memory H2 database)
Joining up flow ports isn’t ideal, but I cannot think of any simpler way of achieving this. I guess it depends on just how many components you have as to whether this is practical!
Monitoring Start and End.knwf (139.6 KB)
I’ve disconnected the components in this workflow from the hub, so that you don’t get “update?” messages. But you can find it on the hub if need be, here
(Because the “timing” information is stored in H2, the information isn cleared if the workflow gets reset. It also means that it can remain between invocations, so you might find that running a part of the workflow multiple times results in timing data remaining from previous invocations. Reset the whole workflow to clear it down!)