You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Dinesh Akhand <di...@amdocs.com> on 2017/08/21 11:12:22 UTC
[Discuss] FunctionStats over the JMX [GEODE-3462]
Hi Team,
We are looking for implementing the function stats over JMX.
Currently Function Stats are not part of JMX. We can't see them on JMX server.
Can you please assist what is the correct way to implementing it.
We have many function which are instanceOf FunctionAdapter.
We want to monitor their stats on JMX server . can you please assist.
But we having lots of user created function . for monitoring the few critical functions, we want then as per configuration based.
GEODE-3462. https://github.com/apache/geode/pull/720
Thanks,
Dinesh Akhand
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>
Re: [Discuss] FunctionStats over the JMX [GEODE-3462]
Posted by Kirk Lund <kl...@apache.org>.
I just ran across a test in Geode which manipulates similar APIs for Client
stats on the CacheServerMXBean:
String[] clientIds = cacheServerMXBean.getClientIds();
ClientHealthStatus clientStatus1 =
cacheServerMXBean.showClientStats(clientIds[0]);
ClientHealthStatus clientStatus2 =
cacheServerMXBean.showClientStats(clientIds[1]);
ClientHealthStatus[] clientStatuses =
cacheServerMXBean.showAllClientStats();
The above code can be used to view the stats per client or for all clients
connected to that CacheServer.
We could do something similar for Functions.
On Tue, Aug 22, 2017 at 10:06 AM, Kirk Lund <kl...@apache.org> wrote:
> Hi Dinesh,
>
> Check out this project by Charlie Black: https://github.com/
> charliemblack/geode-exposing-metrics-via-JMX
>
> We currently have no plans to introduce out-of-the box Geode MXBeans for
> every Function or for all stats. When you combine this with federating of
> MBeans to the JMX Manager(s), it puts too much overhead on the cluster and
> severely impacts performance. It can also result in StatSampler pauses and
> GC problems. This was a big part of the problem with the old
> pre-GemFire-7.0 JMX (com.gemstone.gemfire.admin) that lead us to
> deprecating and replacing it with the current Geode MXBeans
> (org.apache.geode.management).
>
> Users of Geode already have the ability to craft their own MBeans which
> can be federated using the ManagementService API. See
> org.apache.geode.management.ManagementService. Unfortunately, we don't
> yet have an example for this -- it's a bit more involved than Charlie's
> project and would probably involve using the (currently internal-only)
> Statistics Monitoring API.
>
> We do plan to move or mirror part of the Statistics Monitoring API
> from org.apache.geode.internal.statistics to a User API
> (org.apache.geode.statistics) which would make it easier to use the stat
> sampler for updating custom MBeans with stat values. In addition, we plan
> to provide statistic categories (basic, expert, advanced) and make more
> improvements to allow definition of monitors for statistics types before
> statistics instances are actually created. There is an important trade-off
> between monitoring and performance that needs to be carefully considered
> with any usage of the Statistics Monitoring API.
>
> The statistics that are currently exposed on Geode MXBeans fall into two
> categories: the most important stats which we believe are vital in all use
> cases of monitoring Geode are exposed as JMX *attributes* on corresponding
> MXBeans such as RegionMXBean, DiskStoreMXBean. Additional stats which are
> very important but maybe not as important are grouped together as *Metrics
> open data types and accessible by a JMX *operation* such as
> MemberMXBean#showJVMMetrics, MemberMXBean#showOSMetrics,
> DistributedSystemMXBean#showDiskMetrics. This allows us to expose a
> larger number of stats but only by active request (invoking the operation).
> If we actually exposed all of these stats as attributes instead of grouped
> together as the result of an operation then again, the impact on
> performance is too great.
>
> Geode also has aggregate MXBeans which represent the entire cluster such
> as DistributedSystemMXBean and DistributedRegionMXBean. These provide
> cluster-wide aggregate attributes and operations. There are show*Metrics
> operations exposed at this level as well which aggregate stat values across
> the entire cluster.
>
> I do think it would be reasonable to add a new FunctionMetrics open data
> type and a corresponding showFunctionMetrics operation to one of the
> MXBeans (probably the MemberMXBean). That would give the user a view of
> Function stats for that one member. It might also make sense to add
> showFunctionMetrics operation to DistributedSystemMXBean to provide an
> aggregate view of the function stats for the entire cluster.
>
> If you need to expose the function stats as attributes which are
> constantly updated instead of using a showFunctionMetrics operation then I
> think your best approach may be to use custom MBeans such as described in
> Charlie Black's project or try out using the ManagementService APIs for
> registering MBeans.
>
> On Mon, Aug 21, 2017 at 4:12 AM, Dinesh Akhand <di...@amdocs.com>
> wrote:
>
>> Hi Team,
>>
>> We are looking for implementing the function stats over JMX.
>> Currently Function Stats are not part of JMX. We can't see them on JMX
>> server.
>> Can you please assist what is the correct way to implementing it.
>>
>> We have many function which are instanceOf FunctionAdapter.
>> We want to monitor their stats on JMX server . can you please assist.
>>
>> But we having lots of user created function . for monitoring the few
>> critical functions, we want then as per configuration based.
>>
>>
>> GEODE-3462. https://github.com/apache/geode/pull/720
>>
>> Thanks,
>> Dinesh Akhand
>>
>> This message and the information contained herein is proprietary and
>> confidential and subject to the Amdocs policy statement,
>>
>> you may review at https://www.amdocs.com/about/email-disclaimer <
>> https://www.amdocs.com/about/email-disclaimer>
>>
>
>
Re: [Discuss] FunctionStats over the JMX [GEODE-3462]
Posted by Kirk Lund <kl...@apache.org>.
Hi Dinesh,
Check out this project by Charlie Black:
https://github.com/charliemblack/geode-exposing-metrics-via-JMX
We currently have no plans to introduce out-of-the box Geode MXBeans for
every Function or for all stats. When you combine this with federating of
MBeans to the JMX Manager(s), it puts too much overhead on the cluster and
severely impacts performance. It can also result in StatSampler pauses and
GC problems. This was a big part of the problem with the old
pre-GemFire-7.0 JMX (com.gemstone.gemfire.admin) that lead us to
deprecating and replacing it with the current Geode MXBeans
(org.apache.geode.management).
Users of Geode already have the ability to craft their own MBeans which can
be federated using the ManagementService API. See
org.apache.geode.management.ManagementService. Unfortunately, we don't yet
have an example for this -- it's a bit more involved than Charlie's project
and would probably involve using the (currently internal-only) Statistics
Monitoring API.
We do plan to move or mirror part of the Statistics Monitoring API
from org.apache.geode.internal.statistics to a User API
(org.apache.geode.statistics) which would make it easier to use the stat
sampler for updating custom MBeans with stat values. In addition, we plan
to provide statistic categories (basic, expert, advanced) and make more
improvements to allow definition of monitors for statistics types before
statistics instances are actually created. There is an important trade-off
between monitoring and performance that needs to be carefully considered
with any usage of the Statistics Monitoring API.
The statistics that are currently exposed on Geode MXBeans fall into two
categories: the most important stats which we believe are vital in all use
cases of monitoring Geode are exposed as JMX *attributes* on corresponding
MXBeans such as RegionMXBean, DiskStoreMXBean. Additional stats which are
very important but maybe not as important are grouped together as *Metrics
open data types and accessible by a JMX *operation* such as
MemberMXBean#showJVMMetrics, MemberMXBean#showOSMetrics,
DistributedSystemMXBean#showDiskMetrics. This allows us to expose a larger
number of stats but only by active request (invoking the operation). If we
actually exposed all of these stats as attributes instead of grouped
together as the result of an operation then again, the impact on
performance is too great.
Geode also has aggregate MXBeans which represent the entire cluster such
as DistributedSystemMXBean and DistributedRegionMXBean. These provide
cluster-wide aggregate attributes and operations. There are show*Metrics
operations exposed at this level as well which aggregate stat values across
the entire cluster.
I do think it would be reasonable to add a new FunctionMetrics open data
type and a corresponding showFunctionMetrics operation to one of the
MXBeans (probably the MemberMXBean). That would give the user a view of
Function stats for that one member. It might also make sense to add
showFunctionMetrics operation to DistributedSystemMXBean to provide an
aggregate view of the function stats for the entire cluster.
If you need to expose the function stats as attributes which are constantly
updated instead of using a showFunctionMetrics operation then I think your
best approach may be to use custom MBeans such as described in Charlie
Black's project or try out using the ManagementService APIs for registering
MBeans.
On Mon, Aug 21, 2017 at 4:12 AM, Dinesh Akhand <di...@amdocs.com> wrote:
> Hi Team,
>
> We are looking for implementing the function stats over JMX.
> Currently Function Stats are not part of JMX. We can't see them on JMX
> server.
> Can you please assist what is the correct way to implementing it.
>
> We have many function which are instanceOf FunctionAdapter.
> We want to monitor their stats on JMX server . can you please assist.
>
> But we having lots of user created function . for monitoring the few
> critical functions, we want then as per configuration based.
>
>
> GEODE-3462. https://github.com/apache/geode/pull/720
>
> Thanks,
> Dinesh Akhand
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>