2020-12-31 09:53:43 -05:00
|
|
|
proc cmdstat {cmd} {
|
|
|
|
|
return [cmdrstat $cmd r]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
proc errorstat {cmd} {
|
|
|
|
|
return [errorrstat $cmd r]
|
|
|
|
|
}
|
|
|
|
|
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 07:01:05 -05:00
|
|
|
proc latency_percentiles_usec {cmd} {
|
|
|
|
|
return [latencyrstat_percentiles $cmd r]
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-09 08:13:24 -04:00
|
|
|
start_server {tags {"info" "external:skip"}} {
|
2020-12-31 09:53:43 -05:00
|
|
|
start_server {} {
|
|
|
|
|
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 07:01:05 -05:00
|
|
|
test {latencystats: disable/enable} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
r CONFIG SET latency-tracking no
|
|
|
|
|
r set a b
|
|
|
|
|
assert_match {} [latency_percentiles_usec set]
|
|
|
|
|
r CONFIG SET latency-tracking yes
|
|
|
|
|
r set a b
|
2022-01-09 20:04:18 -05:00
|
|
|
assert_match {*p50=*,p99=*,p99.9=*} [latency_percentiles_usec set]
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 07:01:05 -05:00
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [latency_percentiles_usec set]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {latencystats: configure percentiles} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [latency_percentiles_usec set]
|
|
|
|
|
r CONFIG SET latency-tracking yes
|
|
|
|
|
r SET a b
|
|
|
|
|
r GET a
|
2022-01-09 20:04:18 -05:00
|
|
|
assert_match {*p50=*,p99=*,p99.9=*} [latency_percentiles_usec set]
|
|
|
|
|
assert_match {*p50=*,p99=*,p99.9=*} [latency_percentiles_usec get]
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 07:01:05 -05:00
|
|
|
r CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"
|
2022-01-09 20:04:18 -05:00
|
|
|
assert_match [r config get latency-tracking-info-percentiles] {latency-tracking-info-percentiles {0 50 100}}
|
|
|
|
|
assert_match {*p0=*,p50=*,p100=*} [latency_percentiles_usec set]
|
|
|
|
|
assert_match {*p0=*,p50=*,p100=*} [latency_percentiles_usec get]
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 07:01:05 -05:00
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [latency_percentiles_usec set]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {latencystats: bad configure percentiles} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
set configlatencyline [r config get latency-tracking-info-percentiles]
|
|
|
|
|
catch {r CONFIG SET latency-tracking-info-percentiles "10.0 50.0 a"} e
|
|
|
|
|
assert_match {ERR CONFIG SET failed*} $e
|
|
|
|
|
assert_equal [s total_error_replies] 1
|
|
|
|
|
assert_match [r config get latency-tracking-info-percentiles] $configlatencyline
|
|
|
|
|
catch {r CONFIG SET latency-tracking-info-percentiles "10.0 50.0 101.0"} e
|
|
|
|
|
assert_match {ERR CONFIG SET failed*} $e
|
|
|
|
|
assert_equal [s total_error_replies] 2
|
|
|
|
|
assert_match [r config get latency-tracking-info-percentiles] $configlatencyline
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {latencystats: blocking commands} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
r CONFIG SET latency-tracking yes
|
|
|
|
|
r CONFIG SET latency-tracking-info-percentiles "50.0 99.0 99.9"
|
|
|
|
|
set rd [redis_deferring_client]
|
|
|
|
|
r del list1{t}
|
|
|
|
|
|
|
|
|
|
$rd blpop list1{t} 0
|
|
|
|
|
wait_for_blocked_client
|
|
|
|
|
r lpush list1{t} a
|
|
|
|
|
assert_equal [$rd read] {list1{t} a}
|
|
|
|
|
$rd blpop list1{t} 0
|
|
|
|
|
wait_for_blocked_client
|
|
|
|
|
r lpush list1{t} b
|
|
|
|
|
assert_equal [$rd read] {list1{t} b}
|
2022-01-09 20:04:18 -05:00
|
|
|
assert_match {*p50=*,p99=*,p99.9=*} [latency_percentiles_usec blpop]
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 07:01:05 -05:00
|
|
|
$rd close
|
|
|
|
|
}
|
|
|
|
|
|
2022-01-17 05:32:32 -05:00
|
|
|
test {latencystats: subcommands} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
r CONFIG SET latency-tracking yes
|
|
|
|
|
r CONFIG SET latency-tracking-info-percentiles "50.0 99.0 99.9"
|
|
|
|
|
r client id
|
|
|
|
|
|
|
|
|
|
assert_match {*p50=*,p99=*,p99.9=*} [latency_percentiles_usec client\\|id]
|
|
|
|
|
assert_match {*p50=*,p99=*,p99.9=*} [latency_percentiles_usec config\\|set]
|
|
|
|
|
}
|
|
|
|
|
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 07:01:05 -05:00
|
|
|
test {latencystats: measure latency} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
r CONFIG SET latency-tracking yes
|
|
|
|
|
r CONFIG SET latency-tracking-info-percentiles "50.0"
|
|
|
|
|
r DEBUG sleep 0.05
|
|
|
|
|
r SET k v
|
|
|
|
|
set latencystatline_debug [latency_percentiles_usec debug]
|
|
|
|
|
set latencystatline_set [latency_percentiles_usec set]
|
2022-01-09 20:04:18 -05:00
|
|
|
regexp "p50=(.+\..+)" $latencystatline_debug -> p50_debug
|
|
|
|
|
regexp "p50=(.+\..+)" $latencystatline_set -> p50_set
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 07:01:05 -05:00
|
|
|
assert {$p50_debug >= 50000}
|
|
|
|
|
assert {$p50_set >= 0}
|
|
|
|
|
assert {$p50_debug >= $p50_set}
|
|
|
|
|
} {} {needs:debug}
|
|
|
|
|
|
2020-12-31 09:53:43 -05:00
|
|
|
test {errorstats: failed call authentication error} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
assert_equal [s total_error_replies] 0
|
|
|
|
|
catch {r auth k} e
|
|
|
|
|
assert_match {ERR AUTH*} $e
|
|
|
|
|
assert_match {*count=1*} [errorstat ERR]
|
|
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=1} [cmdstat auth]
|
|
|
|
|
assert_equal [s total_error_replies] 1
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {errorstats: failed call within MULTI/EXEC} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
assert_equal [s total_error_replies] 0
|
|
|
|
|
r multi
|
|
|
|
|
r set a b
|
|
|
|
|
r auth a
|
|
|
|
|
catch {r exec} e
|
|
|
|
|
assert_match {ERR AUTH*} $e
|
|
|
|
|
assert_match {*count=1*} [errorstat ERR]
|
|
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=0} [cmdstat set]
|
|
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=1} [cmdstat auth]
|
|
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=0} [cmdstat exec]
|
|
|
|
|
assert_equal [s total_error_replies] 1
|
|
|
|
|
|
|
|
|
|
# MULTI/EXEC command errors should still be pinpointed to him
|
|
|
|
|
catch {r exec} e
|
|
|
|
|
assert_match {ERR EXEC without MULTI} $e
|
|
|
|
|
assert_match {*calls=2,*,rejected_calls=0,failed_calls=1} [cmdstat exec]
|
|
|
|
|
assert_match {*count=2*} [errorstat ERR]
|
|
|
|
|
assert_equal [s total_error_replies] 2
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {errorstats: failed call within LUA} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
assert_equal [s total_error_replies] 0
|
|
|
|
|
catch {r eval {redis.pcall('XGROUP', 'CREATECONSUMER', 's1', 'mygroup', 'consumer') return } 0} e
|
|
|
|
|
assert_match {*count=1*} [errorstat ERR]
|
Treat subcommands as commands (#9504)
## Intro
The purpose is to allow having different flags/ACL categories for
subcommands (Example: CONFIG GET is ok-loading but CONFIG SET isn't)
We create a small command table for every command that has subcommands
and each subcommand has its own flags, etc. (same as a "regular" command)
This commit also unites the Redis and the Sentinel command tables
## Affected commands
CONFIG
Used to have "admin ok-loading ok-stale no-script"
Changes:
1. Dropped "ok-loading" in all except GET (this doesn't change behavior since
there were checks in the code doing that)
XINFO
Used to have "read-only random"
Changes:
1. Dropped "random" in all except CONSUMERS
XGROUP
Used to have "write use-memory"
Changes:
1. Dropped "use-memory" in all except CREATE and CREATECONSUMER
COMMAND
No changes.
MEMORY
Used to have "random read-only"
Changes:
1. Dropped "random" in PURGE and USAGE
ACL
Used to have "admin no-script ok-loading ok-stale"
Changes:
1. Dropped "admin" in WHOAMI, GENPASS, and CAT
LATENCY
No changes.
MODULE
No changes.
SLOWLOG
Used to have "admin random ok-loading ok-stale"
Changes:
1. Dropped "random" in RESET
OBJECT
Used to have "read-only random"
Changes:
1. Dropped "random" in ENCODING and REFCOUNT
SCRIPT
Used to have "may-replicate no-script"
Changes:
1. Dropped "may-replicate" in all except FLUSH and LOAD
CLIENT
Used to have "admin no-script random ok-loading ok-stale"
Changes:
1. Dropped "random" in all except INFO and LIST
2. Dropped "admin" in ID, TRACKING, CACHING, GETREDIR, INFO, SETNAME, GETNAME, and REPLY
STRALGO
No changes.
PUBSUB
No changes.
CLUSTER
Changes:
1. Dropped "admin in countkeysinslots, getkeysinslot, info, nodes, keyslot, myid, and slots
SENTINEL
No changes.
(note that DEBUG also fits, but we decided not to convert it since it's for
debugging and anyway undocumented)
## New sub-command
This commit adds another element to the per-command output of COMMAND,
describing the list of subcommands, if any (in the same structure as "regular" commands)
Also, it adds a new subcommand:
```
COMMAND LIST [FILTERBY (MODULE <module-name>|ACLCAT <cat>|PATTERN <pattern>)]
```
which returns a set of all commands (unless filters), but excluding subcommands.
## Module API
A new module API, RM_CreateSubcommand, was added, in order to allow
module writer to define subcommands
## ACL changes:
1. Now, that each subcommand is actually a command, each has its own ACL id.
2. The old mechanism of allowed_subcommands is redundant
(blocking/allowing a subcommand is the same as blocking/allowing a regular command),
but we had to keep it, to support the widespread usage of allowed_subcommands
to block commands with certain args, that aren't subcommands (e.g. "-select +select|0").
3. I have renamed allowed_subcommands to allowed_firstargs to emphasize the difference.
4. Because subcommands are commands in ACL too, you can now use "-" to block subcommands
(e.g. "+client -client|kill"), which wasn't possible in the past.
5. It is also possible to use the allowed_firstargs mechanism with subcommand.
For example: `+config -config|set +config|set|loglevel` will block all CONFIG SET except
for setting the log level.
6. All of the ACL changes above required some amount of refactoring.
## Misc
1. There are two approaches: Either each subcommand has its own function or all
subcommands use the same function, determining what to do according to argv[0].
For now, I took the former approaches only with CONFIG and COMMAND,
while other commands use the latter approach (for smaller blamelog diff).
2. Deleted memoryGetKeys: It is no longer needed because MEMORY USAGE now uses the "range" key spec.
4. Bugfix: GETNAME was missing from CLIENT's help message.
5. Sentinel and Redis now use the same table, with the same function pointer.
Some commands have a different implementation in Sentinel, so we redirect
them (these are ROLE, PUBLISH, and INFO).
6. Command stats now show the stats per subcommand (e.g. instead of stats just
for "config" you will have stats for "config|set", "config|get", etc.)
7. It is now possible to use COMMAND directly on subcommands:
COMMAND INFO CONFIG|GET (The pipeline syntax was inspired from ACL, and
can be used in functions lookupCommandBySds and lookupCommandByCString)
8. STRALGO is now a container command (has "help")
## Breaking changes:
1. Command stats now show the stats per subcommand (see (5) above)
2021-10-20 04:52:57 -04:00
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=1} [cmdstat xgroup\\|createconsumer]
|
2020-12-31 09:53:43 -05:00
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=0} [cmdstat eval]
|
|
|
|
|
|
|
|
|
|
# EVAL command errors should still be pinpointed to him
|
|
|
|
|
catch {r eval a} e
|
|
|
|
|
assert_match {ERR wrong*} $e
|
|
|
|
|
assert_match {*calls=1,*,rejected_calls=1,failed_calls=0} [cmdstat eval]
|
|
|
|
|
assert_match {*count=2*} [errorstat ERR]
|
|
|
|
|
assert_equal [s total_error_replies] 2
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-24 11:45:13 -05:00
|
|
|
test {errorstats: failed call NOSCRIPT error} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_equal [s total_error_replies] 0
|
|
|
|
|
assert_match {} [errorstat NOSCRIPT]
|
|
|
|
|
catch {r evalsha NotValidShaSUM 0} e
|
|
|
|
|
assert_match {NOSCRIPT*} $e
|
|
|
|
|
assert_match {*count=1*} [errorstat NOSCRIPT]
|
|
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=1} [cmdstat evalsha]
|
|
|
|
|
assert_equal [s total_error_replies] 1
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat NOSCRIPT]
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-31 09:53:43 -05:00
|
|
|
test {errorstats: failed call NOGROUP error} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat NOGROUP]
|
|
|
|
|
r del mystream
|
|
|
|
|
r XADD mystream * f v
|
|
|
|
|
catch {r XGROUP CREATECONSUMER mystream mygroup consumer} e
|
|
|
|
|
assert_match {NOGROUP*} $e
|
|
|
|
|
assert_match {*count=1*} [errorstat NOGROUP]
|
Treat subcommands as commands (#9504)
## Intro
The purpose is to allow having different flags/ACL categories for
subcommands (Example: CONFIG GET is ok-loading but CONFIG SET isn't)
We create a small command table for every command that has subcommands
and each subcommand has its own flags, etc. (same as a "regular" command)
This commit also unites the Redis and the Sentinel command tables
## Affected commands
CONFIG
Used to have "admin ok-loading ok-stale no-script"
Changes:
1. Dropped "ok-loading" in all except GET (this doesn't change behavior since
there were checks in the code doing that)
XINFO
Used to have "read-only random"
Changes:
1. Dropped "random" in all except CONSUMERS
XGROUP
Used to have "write use-memory"
Changes:
1. Dropped "use-memory" in all except CREATE and CREATECONSUMER
COMMAND
No changes.
MEMORY
Used to have "random read-only"
Changes:
1. Dropped "random" in PURGE and USAGE
ACL
Used to have "admin no-script ok-loading ok-stale"
Changes:
1. Dropped "admin" in WHOAMI, GENPASS, and CAT
LATENCY
No changes.
MODULE
No changes.
SLOWLOG
Used to have "admin random ok-loading ok-stale"
Changes:
1. Dropped "random" in RESET
OBJECT
Used to have "read-only random"
Changes:
1. Dropped "random" in ENCODING and REFCOUNT
SCRIPT
Used to have "may-replicate no-script"
Changes:
1. Dropped "may-replicate" in all except FLUSH and LOAD
CLIENT
Used to have "admin no-script random ok-loading ok-stale"
Changes:
1. Dropped "random" in all except INFO and LIST
2. Dropped "admin" in ID, TRACKING, CACHING, GETREDIR, INFO, SETNAME, GETNAME, and REPLY
STRALGO
No changes.
PUBSUB
No changes.
CLUSTER
Changes:
1. Dropped "admin in countkeysinslots, getkeysinslot, info, nodes, keyslot, myid, and slots
SENTINEL
No changes.
(note that DEBUG also fits, but we decided not to convert it since it's for
debugging and anyway undocumented)
## New sub-command
This commit adds another element to the per-command output of COMMAND,
describing the list of subcommands, if any (in the same structure as "regular" commands)
Also, it adds a new subcommand:
```
COMMAND LIST [FILTERBY (MODULE <module-name>|ACLCAT <cat>|PATTERN <pattern>)]
```
which returns a set of all commands (unless filters), but excluding subcommands.
## Module API
A new module API, RM_CreateSubcommand, was added, in order to allow
module writer to define subcommands
## ACL changes:
1. Now, that each subcommand is actually a command, each has its own ACL id.
2. The old mechanism of allowed_subcommands is redundant
(blocking/allowing a subcommand is the same as blocking/allowing a regular command),
but we had to keep it, to support the widespread usage of allowed_subcommands
to block commands with certain args, that aren't subcommands (e.g. "-select +select|0").
3. I have renamed allowed_subcommands to allowed_firstargs to emphasize the difference.
4. Because subcommands are commands in ACL too, you can now use "-" to block subcommands
(e.g. "+client -client|kill"), which wasn't possible in the past.
5. It is also possible to use the allowed_firstargs mechanism with subcommand.
For example: `+config -config|set +config|set|loglevel` will block all CONFIG SET except
for setting the log level.
6. All of the ACL changes above required some amount of refactoring.
## Misc
1. There are two approaches: Either each subcommand has its own function or all
subcommands use the same function, determining what to do according to argv[0].
For now, I took the former approaches only with CONFIG and COMMAND,
while other commands use the latter approach (for smaller blamelog diff).
2. Deleted memoryGetKeys: It is no longer needed because MEMORY USAGE now uses the "range" key spec.
4. Bugfix: GETNAME was missing from CLIENT's help message.
5. Sentinel and Redis now use the same table, with the same function pointer.
Some commands have a different implementation in Sentinel, so we redirect
them (these are ROLE, PUBLISH, and INFO).
6. Command stats now show the stats per subcommand (e.g. instead of stats just
for "config" you will have stats for "config|set", "config|get", etc.)
7. It is now possible to use COMMAND directly on subcommands:
COMMAND INFO CONFIG|GET (The pipeline syntax was inspired from ACL, and
can be used in functions lookupCommandBySds and lookupCommandByCString)
8. STRALGO is now a container command (has "help")
## Breaking changes:
1. Command stats now show the stats per subcommand (see (5) above)
2021-10-20 04:52:57 -04:00
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=1} [cmdstat xgroup\\|createconsumer]
|
2020-12-31 09:53:43 -05:00
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat NOGROUP]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {errorstats: rejected call unknown command} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_equal [s total_error_replies] 0
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
catch {r asdf} e
|
|
|
|
|
assert_match {ERR unknown*} $e
|
|
|
|
|
assert_match {*count=1*} [errorstat ERR]
|
|
|
|
|
assert_equal [s total_error_replies] 1
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {errorstats: rejected call within MULTI/EXEC} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_equal [s total_error_replies] 0
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
r multi
|
|
|
|
|
catch {r set} e
|
2022-01-23 03:05:06 -05:00
|
|
|
assert_match {ERR wrong number of arguments for 'set' command} $e
|
2020-12-31 09:53:43 -05:00
|
|
|
catch {r exec} e
|
|
|
|
|
assert_match {EXECABORT*} $e
|
|
|
|
|
assert_match {*count=1*} [errorstat ERR]
|
2021-08-06 22:27:24 -04:00
|
|
|
assert_match {*count=1*} [errorstat EXECABORT]
|
|
|
|
|
assert_equal [s total_error_replies] 2
|
2020-12-31 09:53:43 -05:00
|
|
|
assert_match {*calls=0,*,rejected_calls=1,failed_calls=0} [cmdstat set]
|
|
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=0} [cmdstat multi]
|
2021-08-06 22:27:24 -04:00
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=1} [cmdstat exec]
|
|
|
|
|
assert_equal [s total_error_replies] 2
|
2020-12-31 09:53:43 -05:00
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {errorstats: rejected call due to wrong arity} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_equal [s total_error_replies] 0
|
|
|
|
|
assert_match {} [errorstat ERR]
|
|
|
|
|
catch {r set k} e
|
2022-01-23 03:05:06 -05:00
|
|
|
assert_match {ERR wrong number of arguments for 'set' command} $e
|
2020-12-31 09:53:43 -05:00
|
|
|
assert_match {*count=1*} [errorstat ERR]
|
|
|
|
|
assert_match {*calls=0,*,rejected_calls=1,failed_calls=0} [cmdstat set]
|
|
|
|
|
# ensure that after a rejected command, valid ones are counted properly
|
|
|
|
|
r set k1 v1
|
|
|
|
|
r set k2 v2
|
|
|
|
|
assert_match {calls=2,*,rejected_calls=1,failed_calls=0} [cmdstat set]
|
|
|
|
|
assert_equal [s total_error_replies] 1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {errorstats: rejected call by OOM error} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_equal [s total_error_replies] 0
|
|
|
|
|
assert_match {} [errorstat OOM]
|
|
|
|
|
r config set maxmemory 1
|
|
|
|
|
catch {r set a b} e
|
|
|
|
|
assert_match {OOM*} $e
|
|
|
|
|
assert_match {*count=1*} [errorstat OOM]
|
|
|
|
|
assert_match {*calls=0,*,rejected_calls=1,failed_calls=0} [cmdstat set]
|
|
|
|
|
assert_equal [s total_error_replies] 1
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat OOM]
|
2022-02-21 04:20:41 -05:00
|
|
|
r config set maxmemory 0
|
2020-12-31 09:53:43 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test {errorstats: rejected call by authorization error} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_equal [s total_error_replies] 0
|
|
|
|
|
assert_match {} [errorstat NOPERM]
|
|
|
|
|
r ACL SETUSER alice on >p1pp0 ~cached:* +get +info +config
|
|
|
|
|
r auth alice p1pp0
|
|
|
|
|
catch {r set a b} e
|
|
|
|
|
assert_match {NOPERM*} $e
|
|
|
|
|
assert_match {*count=1*} [errorstat NOPERM]
|
|
|
|
|
assert_match {*calls=0,*,rejected_calls=1,failed_calls=0} [cmdstat set]
|
|
|
|
|
assert_equal [s total_error_replies] 1
|
|
|
|
|
r config resetstat
|
|
|
|
|
assert_match {} [errorstat NOPERM]
|
2022-02-21 04:20:41 -05:00
|
|
|
r auth default ""
|
2020-12-31 09:53:43 -05:00
|
|
|
}
|
2022-02-21 04:20:41 -05:00
|
|
|
|
|
|
|
|
test {errorstats: blocking commands} {
|
|
|
|
|
r config resetstat
|
|
|
|
|
set rd [redis_deferring_client]
|
|
|
|
|
$rd client id
|
|
|
|
|
set rd_id [$rd read]
|
|
|
|
|
r del list1{t}
|
|
|
|
|
|
|
|
|
|
$rd blpop list1{t} 0
|
|
|
|
|
wait_for_blocked_client
|
|
|
|
|
r client unblock $rd_id error
|
|
|
|
|
assert_error {UNBLOCKED*} {$rd read}
|
|
|
|
|
assert_match {*count=1*} [errorstat UNBLOCKED]
|
|
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=1} [cmdstat blpop]
|
|
|
|
|
assert_equal [s total_error_replies] 1
|
|
|
|
|
$rd close
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-31 09:53:43 -05:00
|
|
|
}
|
|
|
|
|
}
|
