Hi Fred,
MySQL InnoDB cluster relies on Group Replication, which provides the mechanism to replicate data within InnoDB clusters with built-in failover, and not on the asynchronous replication (except for the distributed recovery that I'll briefly explain in this reply).
By default, when you create a cluster, it is running in single-primary mode. This means that an InnoDB cluster has a single read-write server instance - the primary. Multiple secondary server instances are replicas of the primary. If the primary fails, a secondary is automatically promoted to the role of primary. I believe that's why you thought that primary was a master and the two other instances slaves (as in the classic asynchronous replication).
As for the distributed recovery I mentioned above, it's the process that kicks-in whenever you join an instance to a cluster. This process uses the asynchronous master-slave replication until the instance finishes joining the group.
As stated on the manual: "Group Replication distributed recovery can be summarized as the process through which a server gets missing transactions from the group so that it can then join the group having processed the same set of transactions as the other group members."
So, you can assume that as soon as the distributed recovery process is complete asynchronous replication is no longer used. That's the reason why your query to check the slave status returns an empty row.
As for the monitoring capabilities you're looking for, use Shell's AdminAPI command to check the cluster status:
<Cluster.>status()
For further information about the command and its output, please check the InnoDB cluster userguide section about it:
https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-with-cluster.html#check-innodb-cluster-status
I'd also advise you to read through the userguide of InnoDB cluster for a full overview of it and how to use it.
Cheers,
Miguel