Monitoring with AppDynamics
Contents |
Finding Performance Issues
The purpose of AppDynamics is to check application health in terms of performance and help to pinpoint the causes of possible problems.
There are two main techniques to find this kind of problems: proactively and reactively, both of them explained in the following sections.
Continuous Monitoring
Even before user notices slowness or big issues arise, it is possible to analyze which are the slowest parts in the application, being those candidates to be optimized.
Slow transactions
Slowest transactions can be detected from Application Dashboard > Top Business Transactions Tab. From this view you can have an idea of which are the most used transactions, which are the ones consuming more time and which of them have a bigger rate of slow, stalls and errors. These are the candidates to review, in order to try to optimize them. From this view you can navigate to transaction snapshots for each of them to gather more information about the most expensive spots of each of them.
Another interesting view is Slowest Database Calls tab, here top 10 slowest queries are listed, if snapshots are taken you can also see which Business Transactions executed these queries.
Baseline Comparison
You can compare performance (Load and Response Time) during a time range with a base line. This comparison can be done globally or per Business Transaction and allows to understand the behavior compared with the average.
Errors
In addition to performance issues, AppDynamics can also help to detect and pinpoint errors in code.
When a request throws and exception or logs an message with a level of error or greater, the transaction associated to that request is marked as erroneous and a snapshot is taken.
From the Business Transactions list window, you can see the percentage of errors per different business transaction. Once you have detected the Business Transaction you want to check the errors for, open it by double clicking in its line and go to Errors tab. Here you will see a graph of when the errors occurred and a list of snapshots obtained for erroneous transacations. Opening these snapshots and drilling down allows to see the Error Details section of the snapshot, where the error stack trace is shown.
False positives
Because of what is considered as error, there might be some false positives that do not require of any action. For example, when a processed invoice is tried to be modified, Openbravo throws an error at DB level which is logged, detecting this transaction as erroneous. In this case the it is an error because the user tried to do something not allowed, but the code itself is OK.
It is possible to fine tune the messages and exceptions considered as error in order to minimize the number of false positives. This can be done from Configure > Instrumentation > Error Detection tab.
Fine Tuning BTs
AppDynamics for Openbravo delivers some predefined generic BTs which make sense for general Openbravo monitoring.
It is possible that for a single BT some of the request to correctly perform and some other to be slow. This can be due the fact BTs group several different requests, for example DataSource BT groups all the requests executed to populate the grids in any tab, but some tabs could perform fine whereas some others can be slow. In order to better understand the problem these BTs can be split in several, ie. one for the tab known to be slow and another for the rest. This allows to better track the issue, and compare times before and after a fix is applied.
Similarly, HTTP Data Collectors can be customized based on concrete needs.
 | AppDynamics limits to 50 the number of different Business Transactions per Application Agent in order to minimize performance impact in server. If new transactions are defined, check this limit is not reached, if so some other transactions should be removed. |
Proactive Monitoring
AppdDynamics is able to proactively monitor Openbravo instance, creating automatic notifications as soon as something starts going wrong.
Health Rules
AppDynamics allows to set up Health Rules, when these rules are violated:
- A visual hint is shown in the controller to easily understand which business transactions violated which rules
- It is possible to configure actions, such as send an email, when some health rules are violated, this allows to react as soon as the problem is detected.
- additional snapshots for those transactions are automatically obtained, they can help to understand the root causes of the problem.
Reactive Monitoring
When the system is known to poorly perform during a period of time, reactive monitoring helps to determine where the problems are.
The actions taken to look for the problems are the same as the defined for the Continuous Monitoring but narrowing time range down to the period the problem was noticeable.
Addressing Performance Issues
When performance problems are found, first step is to detect where the issue comes from. Performance degradation can mainly be caused by:
- Configuration. For example: heavy background process executed during activity peaks, solution would be to schedule to be executed during more quiet periods; slow datasources produced by full scans to big tables, solution would be to add correct indexes or to prevent UI sorting or filtering by those properties (see Grid Configuration); etc.
- Extension modules. Installed modules can cause performance issues. In this case the problems should be reported to the module owner.
- Openbravo core. When the error is coming from Openbravo code the issue should be reported.
Reporting Performance Issues
When a performance problem is found in Openbravo core code. The way to report is:
- Grant Openbravo support team access to your AppDynamics controller
- Narrow down the time range the problem happened
- Identify the business transactions causing problems
- If snapshots are present, send them by exporting as PDF
Benchmarking
AppDynamics computes baselines with statistical information of load and response time for each Business Transactions as well as for the whole Application.
These base lines can act as a benchmark to compare with, being possible to know how the application, or a business transaction, behaves in comparison with the average. This comparison can be seen in Application and Business Transactions Dashboards.
After a performance issue is fixed, the expected result is response time for the involved transactions to start being smaller than the base line.
Compare Releases
After a performance bug fix is deployed or after updating to a new version of Openbravo or of a module, it is possible to compare the performance for the whole application or a concrete Business Transaction.
This window is accessed from main menu > Analyze > Compare Releases.
Here graphs for two different time ranges can be compared. Select in the first one a time range previous to the fix and in the second one a time after it is applied.
