Not a customer? Click the 'Start a free trial' link to begin a 30-day SaaS trial of our product and to join our community.
Existing Cisco AppDynamics customers should click the 'Sign In' button to authenticate to access the community
12-08-2022 11:34 AM
What are the benefits around creating health rules in baseline and browser metrics?
Solved! Go to Solution.
12-12-2022 12:10 PM
@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...
12-12-2022 12:18 PM - edited 12-12-2022 12:20 PM
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…
02-06-2023 09:51 AM
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?
Thank you
02-07-2023 09:22 AM
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.
Thanks,
Ryan, Cisco AppDynamics Community Manager
Found something helpful? Click the Accept as Solution button to help others find answers faster.
Liked something? Click the Thumbs Up button.
Check out Observabiity in Action
new deep dive videos weekly in the Knowledge Base.
Thank you! Your submission has been received!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form