When Kudu scans are assigned to remote impalads (e.g. the kudu tabletservers do not exist), Impala should indicate that there will be remote reads as we do for HDFS. The information should already be available in the planner and scheduler, the KuduScanNode can put information in the profile. These are "expected" remote reads.
The other case to consider is "unexpected" remote reads where Impala schedules the scan node where there should be a tserver (according to the metadata gathered during planning), but it isn't there (e.g. tablet moved). For this we'd need support from the Kudu client which doesn't exist. I suspect it's a somewhat uncommon case but worth adding when it's possible: https://issues.apache.org/jira/browse/KUDU-1598