[ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899241#comment-16899241 ]
ASF subversion and git services commented on GEODE-7001: -------------------------------------------------------- Commit 81f8f9c1ca1ec9a591287905e559051284117057 in geode's branch refs/heads/develop from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=81f8f9c ] GEODE-7001: Rename LocalRegionTest to LocalRegionPartialMockTest Co-authored-by: Aaron Lindsey <alind...@pivotal.io> Co-authored-by: Kirk Lund <kl...@apache.org> > Add a gauge to track region entry count > --------------------------------------- > > Key: GEODE-7001 > URL: https://issues.apache.org/jira/browse/GEODE-7001 > Project: Geode > Issue Type: New Feature > Components: statistics > Reporter: Dale Emery > Priority: Major > Labels: observability > Time Spent: 8h 20m > Remaining Estimate: 0h > > 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 -- This message was sent by Atlassian JIRA (v7.6.14#76016)