Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
Description
Add a gauge to RegionPerfStats to track the entry count.
As part of understanding system state and health, knowing what regions exist with how much data in them is an often asked question of a data store. The underlying metric is the CachePerfStats.entries value. This is only a piece of the information that customers need as it does not expose the region or region type to the users which is critical to understanding how things are setup.
Scenario: REPLICATE region
Given a cluster with the following servers:
- server1
- server2
And the cluster has a "REPLICATE" region named X
And the user has put 10 entries with distinct keys into region X
Then server1's meter registry has the following meter - meter name: member.region.entries
- tag: region_name = X
- tag: <all the common tags>
- tag: data_policy = REPLICATE
- value: 10
Then server2's meter registry has the following meter - name: member.region.entries
- tag: region_name = X
- tag: <all the common tags>
- tag: data_policy = REPLICATE
- value: 10
Scenario: PARTITION region with no redundancy
Given a cluster with the following servers:
- server1
- server2
And the cluster has a "PARTITION" region named X
And the user has put 10 entries with distinct keys into region X
Then server1's meter registry has the following meter - meter name: member.region.entries
- tag: region_name = X
- tag: <all the common tags>
- tag: data_policy = PARTITION
- value: between 0 and 10
Then server2's meter registry has the following meter - name: member.region.entries
- tag: region_name = X
- tag: <all the common tags>
- tag: data_policy = PARTITION
- value: between 0 and 10
And the values of those meters add up to 10
Scenario: PARTITIONED REDUNDANT
Given a cluster with the following servers:
- server1
- server2
- server3
And the cluster has a "PARTITION_REDUNDANT" region named X
And the redundancy level is set to 1 copy (2 total copies of each key should exist)
And the user has put 10 entries with distinct keys into region X
Then server1's meter registry has the following meter - meter name: member.region.entries
- tag: region_name = X
- tag: <all the common tags>
- tag: data_policy = PARTITION
- value: between 0 and 10
Then server2's meter registry has the following meter - name: member.region.entries
- tag: region_name = X
- tag: <all the common tags>
- tag: data_policy = PARTITION
- value: between 0 and 10
Then server3's meter registry has the following meter - name: member.region.entries
- tag: region_name = X
- tag: <all the common tags>
- tag: data_policy = PARTITION
- value: between 0 and 10
And the values of those meters add up to 20
