Important
Deprecated in version 7.1: Use the 7.1版本中已弃用:请改用auditConfig cluster parameter instead.auditConfig集群参数。
Definition定义
getAuditConfigNew in version 5.0.在版本5.0中新增。getAuditConfigis an administrative command that retrieves audit configurations from是一个管理命令,用于从mongodandmongosserver instances.mongod和mongos服务器实例检索审计配置。
Compatibility兼容性
This command is available in deployments hosted in the following environments:此命令在以下环境中托管的部署中可用:
- MongoDB Enterprise
: The subscription-based, self-managed version of MongoDB:MongoDB的基于订阅的自我管理版本 - MongoDB Community
: The source-available, free-to-use, and self-managed version of MongoDB:MongoDB的源代码可用、免费使用和自我管理版本
Important
This command is not supported in MongoDB Atlas clusters. MongoDB Atlas集群不支持此命令。For information on Atlas support for all commands, see Unsupported Commands.有关Atlas支持所有命令的信息,请参阅不支持的命令。
Syntax语法
The command has the following syntax:该命令具有以下语法:
db.adminCommand(
{
getAuditConfig: 1
}
)Behavior行为
Auditing must be enabled to use 必须启用审核才能使用getAuditConfig.getAuditConfig。
Nodes that are not participating in a runtime audit configuration return their current configuration file settings for 未参与运行时审核配置的节点返回其当前的auditLog.filter and setParameter.auditAuthorizationSuccess.auditLog.filter和setParameter.auditAuthorizationSuccess配置文件设置。
Nodes that are participating in the runtime audit synthesize their current configuration from memory. 参与运行时审计的节点从内存中合成其当前配置。Configuration updates are distributed via the oplog mechanism which means updates on 配置更新是通过oplog机制分发的,这意味着mongod nodes are distributed to secondary nodes very quickly. mongod节点上的更新会很快分发到辅助节点。However, the distribution mechanism is different on 然而,mongos nodes. mongos节点上的分布机制不同。mongos nodes have to poll the primary server at regular intervals for configuration updates. mongos节点必须定期poll(轮询)primary服务器以获取配置更新。You may see stale data due to polling delay if you run 如果在分片轮询主服务器以获取更新的配置详细信息之前,在primary服务器上运行setAuditConfig on the primary server and getAuditConfig on a shard before the shard has polled the primary server for updated configuration details.setAuditConfig并在分片上运行getAuditConfig,则可能会由于轮询延迟而看到过时的数据。
Note
If you are writing automated audit scripts, note that the quoting style and the types used to represent the cluster signature differ between 如果您正在编写自动审计脚本,请注意,mongosh and the legacy mongo shell. In mongosh the types are Binary and Long. The corresponding types in the legacy shell are BinData and NumberLong.mongosh和遗留mongoshell之间用于表示集群签名的引用样式和类型不同。在mongosh中,类型是Binary和Long。遗留shell中的相应类型是BinData和NumberLong。
// mongosh
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: Long("0")
}
// mongo
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : Long(0)
}Examples示例
Run 在getAuditConfig on the admin database .admin数据库上运行getAuditConfig。
db.adminCommand({getAuditConfig: 1})
The example server is configured to audit read and write operations. It has a filter which captures the desired operations and the 示例服务器被配置为审核读写操作。它有一个筛选器,可以捕获所需的操作,并且auditAuthorizationSuccess value has been set to true.auditAuthorizationSuccess值已设置为true。
{
generation: ObjectId("60e73e74680a655705f16525"),
filter: {
atype: 'authCheck',
'param.command': {
'$in': [ 'find', 'insert', 'delete', 'update', 'findandmodify' ]
}
},
auditAuthorizationSuccess: true,
ok: 1,
'$clusterTime': {
clusterTime: Timestamp(1, 1625767540),
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: Long("0")
}
},
operationTime: Timestamp(1, 1625767540)
}