In general you will be fine with reading from secondaries, but here are a few things to consider :
All members of a replica set will service the read requests at roughly same speed. This is because when you write to primary server, the data is also written to the secondaries. So, you need to check the actual performance benefits you get here.
Are you fine with stale data (as replication occurs asynchronously)? As this is a dashboard, it's probably fine to have slightly out-of-date data.
Are these replica sets geographically distributed? If yes, it may be a good idea to set read preference to nearest so that you will read from low latency servers.
MongoDB documentation says that in general you shouldn't use secondary read preferences to add extra read capacity. On the other hand, sharding is often treated as the preferred way to add extra Read/Write capacity as it distributes your reads/writes across different groups of machines.
However, if you choose to read from a secondary machine, it may be a good idea to have the Dashboard as a separate app with read preference set to secondary. This way you won't mix up the dashboard code with the other parts of the main app.
Hope this helps. Please let me know if you have any questions. :)