[
https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897307#comment-16897307
]
ASF subversion and git services commented on GEODE-7001:
--------------------------------------------------------
Commit 279fa0eb007adb789e1fa1a90e310299bc19e0a7 in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=279fa0e ]
GEODE-7001: Add region entry count gauge (#3850)
* GEODE-7001: Add region entry count gauge
Add 'member.region.entries' gauge in RegionPerfStats
- Add region.name and data.policy tags
- Add an AtomicLong to track the entry count
- Configure the member.region.entries gauge to fetch from new
getLocalSize() method (see below).
- Configure the 'entryCount' stat to be supplied by new getLocalSize()
method.
Add getLocalSize() method to InternalRegion, and implement it in
LocalRegion and PartitionedRegion
- In LocalRegion, the method returns the region map size minus the
number of tombstones.
- In PartitionedRegion, the method sums the local sizes of all local
bucket regions.
Also refactored the following:
- Reorganize CachePerfStats/RegionPerfStats constructors
- Remove CachePerfStats.getEntries()
- Remove use of CachePerfStats.getEntries() from
PartitionedRegionStatus.
- Add @Override to ValidatingStatisticsType methods in StatisticsTypeImpl
- Extracted invokeSuppliers() to new SuppliableStatistics interface and
rename as updateSuppliedValues()
- Move responsibility to prepend 'RegionStats-' onto region statistics
textID into the classes that create RegionPerfStats and
CachePerfStats.
Co-authored-by: Michael Oleske <mole...@pivotal.io>
Co-authored-by: Kirk Lund <kl...@apache.org>
Co-Authored-By: Mark Hanson <mhan...@pivotal.io>
Co-Authored-By: Aaron Lindsey <alind...@pivotal.io>
* empty commit to trigger precheckin
* Remove leftover atMost
* Spotless found unused import
> 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
> Time Spent: 7h 50m
> 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)
