-
Type:
Bug
-
Resolution: Duplicate
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Integration
-
ALL
-
None
-
None
-
None
-
None
-
None
-
None
-
None
I started the server like this:
/mongod --setParameter internalQueryConfigureTelemetrySamplingRate=1000000
Then I ran the following sequence of commands:
MongoDB Enterprise > db.c.find({a: {$gt: 3}})
MongoDB Enterprise > db.c.find({a: {$gt: 3}, b: {$lt: 0}})
MongoDB Enterprise > db.c.find({a: {$gt: 3}, c: {$elemMatch: {d: 1}}})
MongoDB Enterprise > db.getSiblingDB("admin").aggregate([{$telemetry: {}}]).pretty()
{
"key" : {
"find" : {
"find" : "###",
"filter" : {
"###" : {
"###" : "###"
}
}
},
"namespace" : "test.c",
"applicationName" : "MongoDB Shell"
},
"metrics" : {
....
},
"asOf" : Timestamp(1668637488, 0)
}
{
"key" : {
"find" : {
"find" : "###",
"filter" : {
"###" : {
"###" : "###"
}
}
},
"namespace" : "test.c",
"applicationName" : "MongoDB Shell"
},
"metrics" : {
...
},
"asOf" : Timestamp(1668637488, 0)
}
{
"key" : {
"find" : {
"find" : "###",
"filter" : {
"###" : {
"###" : "###"
}
}
},
"namespace" : "test.c",
"applicationName" : "MongoDB Shell"
},
"metrics" : {
...
},
"asOf" : Timestamp(1668637488, 0)
}
My expectation was that the key field would be unique and would give some indication of what the three queries I ran against the system were. Instead, the key is always the same, and does not appear to be related to what the original query was.
I haven't looked into the root cause deeply, but this looks to me like it is a bug in how the redaction is implemented. Therefore, we might want to deal with this problem together with SERVER-71426, which is another redaction-related bug.
- duplicates
-
SERVER-73494 Integrate serialized query shape for find command into telemetry read and write path
-
- Closed
-
- is related to
-
-
- Closed
-