AppDynamics Overview
 | Important Note: AppDynamics is no longer part of Openbravo offer. It can be used at your own discretion (as any other monitoring product) but there is no "native" support for it in the Openbravo product. |
Contents |
Concepts
In this section some basic AppDynamic concepts are explained. For more information, refer to AppDynamics documentation.
Business Transactions
AppDynamics collects information about requests and background processes. Different requests can be grouped into a single Business Transaction based on some configuration rules. Business transactions allow to have aggregated information for the performance of all the requests contained in it. Being possible to analyze for an specific Business Transaction, its load, average response time, number and percentage of errors, slow requests, etc.
Transaction Snapshots
Agents continuously retrieve summarized information about all requests, this allows to understand load and response time trends over time. In addition to this aggregated information, snapshots are captured. Snapshots include a much more detailed information about a single request which includes, stack traces, errors, executed sql queries, additional parameter information (needs to be configured), etc…
Snapshots can be triggered because of three reasons:
- Slow, stalled or error transaction identified. When a transaction is considered to be in one of these situations can be configured globally or per transaction type.
- Periodic collection. By default every 10 minutes, AppDynamics captures one snapshot of each transaction type. This period can also be configured.
- Diagnostic session. Diagnostics sessions can be automatically triggered when the transaction violates some health rules or manually started.
Configuration
Default Settings
If ob-appdynamics-config.xml is imported when a new application is created, it provides a series of default configurations that make easier to analyze Openbravo performance.
Business Transactions and Data Collectors
Here is the list of the default Business Transactions and which date is collected (defined by Request Data Collectors) when snapshots of each type are obtained.
In all the cases, snapshots for transactions implemented as Servlets, URL and session ID is included.
- ScheduledBackground. Detects background processes, it creates a new Business Transaction for each different process.
- DataSource. Groups all requests to datasources. DataSource requests are used to populate data in grid and forms views of Standard Openbravo Windows. It collects information about the criteria used in the request, pagination, selected properties, operation (fetch, update, insert or delete), sorting and the Tab it was invoked from.
- DataSourceFK. Contains requests perform in grid view to populate drop down list used when filtering by a foreing key. The information collected in snapshots is the same as in Datasource adding which is the foreign key entity.
- DataSource-QueryWidget. DataSource used in query list widgets. Contains same information as standard DataSource and widget id.
- FIC. Requests to FormInitializationComponent. This component is in charge of managing settings in form view. Snapshots for this transaction include mode, tab id, row id, parent id (in case of subtabs)
- ActionHandler. Groups all the requests performed from the UI to perform actions different than getting data for DataSources. The action is retrieved.
- KernelServlet. Groups requests to KernelServlet which is in charge of generating JavaScript for infrastructures such as standard windows, static javascript, static CSS, etc.
- XML-WS and JSON-WS. Requests to default DAL REST WebServices XML and JSON. Transaction for these types are split by request method (GET, POST, PUT and DELETE). Snapshots contain information about pagination, where clause, sorting and selected properties.
- WindowButton. Includes all 2.50 style servlets, most of them implementing buttons in windows. It is retrieved the record id the button was executed from as well as the command sent to the backend.
The following transactions are used when WebPOS is in use, none of them include additional information
- WebPOS-Master Data. Requests to get master data (products, prices, business partners, etc).
- WebPOS-Order Loader. Invoked whenever tickets are sent from WebPOS to backend.
- WebPOS-Cash Up. Cash Up process implementation
- WebPOS-JSONRest. Rest of processes invoked from WebPOS are grouped in this transaction.
- WebPOS-Session Ping. Ping sent from WebPOS to backed to check connectivity.
- WebPOS. Groups any other requests coming from WebPOS that are not matching any of the ones described above.
 | HTTP Data collectors are associated with Business Transactions. It is only possible to do this association with already discovered ones. So by default, all collectors in the application are set to be applied to “New Transactions”, once they are discovered this flag can be removed and associate them only with the ones making sense. |
Error Detection
Whenever an uncaught exception is raised or a message with error or higher severity is written in log4j. The whole transaction is marked as error and snapshot is collected.
It is possible to set some exceptions or log4j error message not to be detected as error.
Call Graph Settings
From this tab you can configure which are the classes/packages that are detailed within snapshots.
| | By default AppDynamics, excludes from graphs all packages starting by org.*. Default Openbravo application includes org.openbravo.*. If you have any module which package starts with org.*, you should add it to "Shown Packages" section.
|
It also enables to change how SQL are captured, being possible to capture parameter values (Capture Raw SQL) or to filter them out (Filter Parameter Values). By default application is configured to include these values, in this way it makes easier to replicate the queries once captured, but it also displays more information, which in some cases could be sensitive.
Change Settings
All these default settings can be modified for the requests detected after the change.
| | 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. |
| | After changing configuration, it might be required to reset agent to prevent existent business transactions to be cached in memory. This is done through: Servers > App Servers > openbravo > tomcat > App Server Agent clicking in the Reset button. |
Discovering AppDynamics
This section briefly explains the main windows used from AppDynamics controller UI.
Global Time Range
AppDynamics agents are constantly gathering information which is stored in the controller server for up to one year.
In the top right side of all screens Global Time Range menu is shown, all information seen in the UI is always restricted to the range set at this level.
All Applications Dashboard
From the main page in AppDynamics controller site,All Applications Dashboard is opened by clicking on View All Applications. It displays aggregated information of all available applications (Openbravo instances).
It allows in a single view to have an overall impression of each application performance.
Application Dashboard
From All Applications Dashboard, clicking an application name Application Dashboard window is opened.
Here information about all Business Transactions performance during the global time range is presented.
This window has 3 tabs: Dashboard, Top Business Transactions and Transaction Analysis
Dashboard Tab
Displays an Application Flow Map which depicts communications between different nodes and backends.
In the right side, global information about Business Transactions Health and Server Health where are counted all the Health Rule violations during the time range. Transaction Scorecard counts number of Normal, Slow, Very Slow, Stall and Error transactions and Exceptions counts number of Exceptions captured during this time.
In the bottom area graphs about Load (requests per minute), Response Time (average time to complete each requests) and Errors are visualized.
Top Business Transactions Tab
This tab lists 10 top business transactions grouped by:
- Load. It represents the total number of calls and call per minute by transaction.
- Response Time. How much time each transaction took to be completed in average.
- Errors. Number of transactions detected as erroneous.
- Slow Transactions. Slow and very slow transactions. Note when a transaction is detected as slow or very slow can be configured. By default it is defined as greater tab some (3 for slow and 4 very slow) deviations from the average during the last 2 hours. Because of this, if a transaction always takes a long time to response, it will be listed in reponse time but not as slow.
- Stall. A transaction is considered as stalled when it takes more time to complete than a configurable threshold (default is 40 seconds).
- Health Rule Violations. Health rules can be configured per business transaction.
Transaction Snapshots Tab
A transaction snapshot contains information about a concrete request. Including stack trace, sql queries, additional information obtained by data collectors, etc.
Snapshots are useful to pinpoint the root cause of performance issues. They are collected when transactions are slow or have errors, as well periodic collection occurs (by default every 10 minutes) for all transactions.
Drill down
Transaction Snapshots can be opened to show a dashboard with information about execution time, timestamp the snapshot was taken at, business transaction associated to the request and time splits between different tiers. From here Drill Down button can be clicked, from this view the following information can be seen:
- Summary. A summary for the snapshot which includes time taken to complete, timestamp when the snapshot was taken, reason to take the snapshot (scheduled, slow or error transaction), Business Transaction, URL, etc.
- Call Graph. Includes information about the stack trace with the time each method took. Next to each method, executed SQL queries can be checked.
- SQL Calls. Information about the SQL queries including the time each took.
- HTTP Params. If HTTP Data Collectors are defined for this Business Transaction (see Default Settings section), some request parameters are included in this view. They are useful to understand how the request was produced.
- Error Details. In case errors occurrence during execution, here you can see a list of them, with stack trace for each one.
- Hardware/Mem. This view contains graphs of machine and JVM usage at the moment the snapshot was captured.
Business Transactions
Accessible from main menu > Business Transactions.
This window lists all the business transactions with numeric information about load of performance of each of them.
From here it is possible to navigate to a single transaction, where a dashboard window, similar to the Application Dashboard is presented. This dashboard contains information just for the selected transaction, being possible in this way to understand how this transaction behaves over time.
Databases
Accessible from main menu > Servers > Databases.
It lists all detected databases.
By selecting one of them, a dashboard where graphs for load and response time is opened.
There is also available a Slowest Database Calls tab, here the top 10 slowest database queries are listed. In case snapshots containing these calls are available, it is possible to navigate to them to drill down for more information.
JVM Monitoring
Open from main menu > Serves > App Servers > openbravo > tomcat > Memory tab.
In this tab information about heap consumption, time spent in garbage collections, major collections, etc. is shown.
| | When the time range is bigger than 4 hours, graph resolution decreases from 1 minute to 10. In this case, Heap grap shows 3 lines for Current Usage, these lines represent maximum, average and minimum usage for these 10 minutes. |
Hardware Monitoring
Open from main menu > Servers > App Servers > openbravo > tomcat > Hardware tab.
It depicts information about CPU, Memory, Disk I/O and Network I/O.
Note this information to be displayed Machine Agent needs to be in execution.
