Health Rules Benefits

[Joel_Francois]

What are the benefits around creating health rules in baseline and browser metrics?

[iamryan · Accepted solution]

Hi @Joel.Francois,

Thanks for getting this question started on the community. Community posts are generally for peer-to-peer support.  I think the level of detail of questions you have would be better suited for a Support ticket or a chat with your AppD rep.

How do I submit a Support ticket? An FAQ - To talk to your AppD Rep, you will probably have to talk to your AppD Admin to get that conversation started. 

[Aaron_Schifman]

@Joel.Francois I would say that Health Rules are a way to customize your anomaly detection engine. We have a number of built-in HRs that you can use as-is or customize, depending on the type of entity you are looking to configure, on top of creating your own. 

If a value for say, the response time between services, or hardware resource such as CPU goes beyond a threshold you configure, you can configure warnings and/or critical notifications and automated responses. 

While baselines are automatically detected with the AppDynamics cognition engine, Health Rules are configured by the end user. Baselines will alert on deviations the system sees as anomalies, where as HRs will rely on the values being defined by you, or AppD if we are talking out-of-the-box health rules. 

So the main points here are that you have control over which values are determined to mean an issue, or potential one, and having the ability to automate responses to those alerts...email, Jira ticket, PagerDuty notification, etc...

[Joel_Francois]

Thank you for all of this information Aaron. I'm asking to learn more about moving from the traditional thresh hold over to using baselines and browser metrics instead.

In AppDynamics my team and I currently are getting the health rules

Using thresholds – error rate, call per min, response time.

One of our biggest challenges are: when we are trying to identify what the number exactly should be. It’s hard for us to say this one should be at this number exactly.

When two of our products- Account & summary have higher total request compared to another and another product has a much higher call rate than others.

How do we scale those into have the same threshold between each of these when the transaction number amounts are different. The avg transaction per sec is much higher in one place than the other. Maybe we can use a baseline or metric browsers?

1. What are the advantages of using baselines and browser metrics compared to the using the traditional threshold? Baseline monitoring auto ticketing within health rules.
2.  Also what are the pros and cons of using baselines and the metric browser?
3. How to create auto ticketing based on the baseline when there is an change in error rate, call per min, response time?
4. How do we scale those into have the same threshold between each of these when the transaction number amounts are different?
5. Using baseline and metric browser is that a better way to capture the health rules than what we have been using with just threshold?

Thank you

[Aaron_Schifman]

I also want to add some details here that I put together for a presentation some time ago...

AppDynamics provides a method to account for variations in the normal operation of the overall application, various user experience areas such as browser or mobile applications as well as API monitoring…additionally, databases, servers, and analytics make up the scope of Health Rules.

Baselines derived from AppDynamics Cognition Engine, feed into health rules…

The types of health rules that can be configured are around:

•Transaction performance metrics related to the load, i.e. response time, slow calls, stalls, errors, etc.,

•Node health such as the hardware, JVM, JMX, disk I/O…

•User experience areas such as how they relate to pages, i.e. the DOM build time, digest cycles, load and execution time, AJAX requests, mobile app status changes, HTTP errors, and many other relevant performance metrics.

•Additionally, types relating to hardware resources for servers, databases, service endpoints, and just a slew of others…