I appreciate the feedback. There is so much churn in the developer mailing list I found myself unable to track new additions or changes like I used to do.
The touch point with is AppDynamics is JMX, which I see is supported in the dropwizard metrics. For the issue I had, I am fortunate to have a talented intern and she was able to get everything working for our last Sprint. Going forward, I will be floating this functionality around and see if we can't start leveraging it soon. Thanks -Jason -----Original Message----- From: Björn Weide [mailto:bjoern.we...@netcentric.biz] Sent: Tuesday, February 07, 2017 4:12 AM To: users@sling.apache.org Cc: georg.henz...@netcentric.biz Subject: Re: Sling Health Checks Just my 2cents on that one - for me it sounds like it would be a good fit to use Sling Metrics here to record your metrics (like # of submissions in your case). You could then use a custom reporter to expose the data to AppDynamics (not sure about the integration points there). In case you want to use a HC for that metrics you could implement some kind of delta reporter that simply reports the deltas of selected metrics to an internal store and then implement a HC checking these deltas against your thresholds (we are using this setup in one of our projects). Best regards, Bjoern On Tue, Jan 31, 2017 at 4:59 PM, Jason Bailey <jason.bai...@sas.com> wrote: > So I'm part of a team that I will characterize as being "highly > resource optimized" We have an AppDynamics instance that we use to > monitor the state of our instances as much as possible. One of the > OOTB features is the ability to tie into JMX and present graphs and > historical information on specific items. > > We have a variety of business processes and functions in Sling that > would be beneficial to us to monitor, and in particular graph, so that > we can do intelligent alarming. Where we are having problems is that > collection of state that would allow us to do intelligent monitoring. > > Example being submission processing. If the number of submissions each > instance is handling falls below a certain threshold or increases > beyond a certain number, it's an issue of concern, a warning. But > certain days and a particular time, it's a situation where need > someone looking at it immediately. > > Additionally having a value being returned would also allow us to > track trends or unusual events in a historical manner so that we can > hopefully identify issues before they happen. > > -Jason > > -----Original Message----- > From: Georg Henzler [mailto:slin...@ghenzler.de] > Sent: Tuesday, January 31, 2017 3:24 AM > To: users@sling.apache.org > Subject: Re: Sling Health Checks > > Hi Jason, > > no it is not possible at the moment - but nobody stops you to make the > HC component also provide an additional, custom MBean that shares some > additional result properties of the HC execution to other services. > > In theory the HC result could be extended to allow for custom > properties (that are then in turn exposed via JMX), but the idea > behind the HCs is that due to the clearly defined result type (with a > clear semantic for each > status) consumers can easily decide whether an instance is healthy or > not, additional properties might be confusing. Could you describe your > use case in a bit more detail? > > Regards > Georg > > On 2017-01-30 18:56, Jason Bailey wrote: > > Anyone know if it's possible to use the Sling Health Checks to > > expose a value via the MBean other than the ones explicitly defined > > in the Result Object? > > > > Thanks > > -Jason >
