应授予用户admin数据库的clusterMonitor角色，该角色包含replSetGetStatus权限且仅限集群只读监控，需在admin库执行db.grantRolesToUser("myuser",[{role:"clusterMonitor",db:"admin"}])。
普通用户执行 rs.status() 报错 “not authorized” 怎么办
因为 rs.status() 是一个内部诊断命令，底层调用的是 replSetGetStatus 管理命令，它不属于数据库级操作，而是集群级状态读取。MongoDB 默认不给任何数据库角色（比如 read、dbOwner）授予该权限，必须显式分配具备集群监控能力的角色。
为什么 clusterMonitor 角色能解决这个问题
这个内置角色专门用于授予对集群运行状态的只读访问权限，包含以下关键权限：
-
replSetGetStatus—— 直接支撑rs.status() -
serverStatus、top、getCmdLineOpts等配套诊断命令 - 不包含写权限、不涉及用户/角色管理、也不允许修改副本集配置
它比 root 或 clusterAdmin 更轻量、更安全，是面向运维只读场景的标准选择。
如何给用户添加 clusterMonitor 角色
必须在 admin 数据库上授予权限（这是 MongoDB 的硬性要求，其他数据库上下文无效）：
use admin
db.grantRolesToUser("myuser", [{ role: "clusterMonitor", db: "admin" }])
注意几个关键点：
- 用户必须已存在，且是在
admin库中创建的（或至少在admin库有角色绑定） -
db: "admin"不能省略或写成其他库名，否则权限不会生效 - 如果用户之前只有某业务库的
read角色，这次授权是追加，不是覆盖 - 权限变更立即生效，无需重启 mongod
容易被忽略的兼容性细节
在分片集群中，rs.status() 只反映当前连接节点所属副本集的状态；如果连的是 mongos，该命令根本不可用（会报 command replSetGetStatus requires authentication 或直接失败）。此时应改用 sh.status()，对应需要的是 clusterManager 或 clusterAdmin 角色。
另外，4.2+ 版本开始，clusterMonitor 不再隐式包含 hostInfo 权限，如需查看硬件/OS 信息，得额外加 hostManager 角色 —— 这个细节常被漏掉，导致 db.runCommand({ hostInfo: 1 }) 也报错。
