In Paragon automation, we may see difference in aggregated and non aggregated data where we have less entries.

This could be noticed only for some specific nodes or its noticed on random occasions.

hb-default:controller:VMX102

   controller.telemetry/ctrl-label-switched-path : 288

   controller.telemetry/ctrl-label-switched-path-aggregation : 288

   controller.telemetry/ctrl-label-switched-path/lsp-stats-collection : 287

hb-default:controller:VMX101

   controller.telemetry/ctrl-label-switched-path : 286 <<<< non aggregated data

   controller.telemetry/ctrl-label-switched-path-aggregation : 244 <<<< aggregated data

   controller.telemetry/ctrl-label-switched-path/lsp-stats-collection : 286 

We need to dump the aggregated and non-aggregated data from the influx DB and then compare the data.. 

#kubectl exec -it -n healthbot <tsdb-podname> -c tsdb-shim -- influx -database 'hb-default:controller:VMX101' -execute 'select * from "controller.telemetry/ctrl-label-switched-path" where time >now() - 1d group by * limit 1' – format csv > non-aggregation-data.csv

#kubectl exec -it -n healthbot <tsdb-podname> -c tsdb-shim -- influx -database 'hb-default:controller:VMX101' -execute 'select * from "controller.telemetry/ctrl-label-switched-path-aggregation" where time >now() - 1d group by * limit 1' – format csv > aggregation-data-influx.csv

Once the data is captured we can compare both the file, see example:

Non aggregated data:

We could see an entry at “2/11/25 8:32:53.722” and next entry came at “2/11/25 8:37:53.664”, we could see that entry is received within 5min interval. Its lesser by milliseconds. 

Aggregated Data:

We could see the entry of “2/11/25 8:37:53.664” which is combination of “2/11/25 8:32:53.722” & “2/11/25 8:37:53.664”, with elapsed time of 600. With average of the lsp-stats-bps.

From the data snippet shown above, we could see the non-aggregated data has been received data with in the 5min interval[Negative Jitter] “2/11/25 8:37:53.664”.

So the data for “2/11/25 8:32:53.722” & “2/11/25 8:37:53.664” will be combined as a single entry for the aggregated calculation and will be update at “2/11/25 8:37:53.664”  with elapsed time 600[10min] and data will be average of the two entries.  

This doesn’t indicate we missed the entry at “2/11/25 8:32:53.722”. it’s just that because of negative jitter, that entry has been considered for next cycle “2/11/25 8:37:53.664” rather than at “2/11/25 8:32:53.722” under the aggregated table. This is expected behaviour.