Database Monitoring AppDynamics Pro Documentation Version 4.0.x Page 1
Database Monitoring...................................................... 3 Database Monitoring Requirements and Supported Environments................. 5 Required Database Permissions........................................ 7 Authentication for Host Monitoring....................................... 12 Configure WMI Permissions and Security................................. 13 AppDynamics Database Monitoring Architecture.............................. 17 Install or Upgrade the Database Agent...................................... 18 Database Agent Configuration Properties................................. 22 Installing the Database Agent as a Windows Service........................ 28 Start the Database Agent Automatically on Linux........................... 31 Start the Database Agent Automatically on Windows........................ 32 Configure Database Collectors............................................ 32 Monitor Databases and Database Servers................................... 36 Access Database Monitoring........................................... 36 View Overall Database and Server Performance............................ 37 Discover Normal Database and Server Activity............................. 41 Configure Problem Detection Notifications................................. 42 Monitor Database Performance......................................... 43 Database Dashboard............................................... 43 Database Live View................................................ 45 Database Queries................................................. 47 Database Clients.................................................. 49 Database Sessions................................................ 50 Database Object Browser........................................... 51 Database Reports................................................. 53 Monitor Database Server Hardware...................................... 54 Administer AppDynamics Database Monitoring............................... 56 Adding Database Instance Licenses..................................... 56 Database Agent Events Reference...................................... 57 Database Agent FAQ................................................. 58 Page 2
Database Monitoring AppDynamics Pro Database Monitoring versions AppDynamics for Databases new in 4.0 AppDynamics Pro Database Monitoring is our first step in the transition from our standalone AppDynamics for Databases server offering to a more tightly-integrated solution in which AppDynamics Pro, along with the new Database Agent, monitors and reports your database activity. Many, but not all of the platforms and metrics supported by AppDynamics for Databases are monitored and reported in AppDynamics Pro Database Monitoring. Feature parity between these two offerings is expected in the near future. On this page: How AppDynamics Monitors Databases Related pages: AppDynamics Database Monitoring Architecture Monitor Databases and Database Servers Configure Roles Watch the video: Getting Started - Database Agent AppDynamics Pro Database Monitoring gives you end-to-end visibility into the performance of your applications, helping you dramatically reduce the time it takes to find and fix database performance issues. Use AppDynamics Database Monitoring to monitor your databases and database servers for situations you need to be aware of, whether it be load that is too high, response time is too slow, number of executions of a SQL queries are too high, or disk capacity is too low. Using the power of AppDynamics Pro, AppDynamics Database Monitoring monitors your databases 24/7 automatically and can alert you when unusual or critical situations arise. AppDynamics Database Monitoring provides an intuitive interface on a single pane of glass that visualizes database and server activity so you can see at a glance where problem areas are. Copyright AppDynamics 2012-2015 Page 3
How AppDynamics Monitors Databases AppDynamics Database Monitoring takes a time-based approach to monitoring, providing you with visibility of the database performance over time. You can see the current performance of connected sessions, drill down into SQL Explain plans and view database statistical information. You can see what is happening now as well as what occurred over the last day, the last week or the last month. The product answers important questions such as What happened to the online application yesterday to make it slow down? and Why is the overnight batch job still running this morning at 8:55? AppDynamics Database Monitoring sorts database activity by efficiency, showing you the worst performing activities. You can immediately see potential problems, such as which SQL statement or stored procedure is consuming system resources, which machine is experiencing lags, and which programs are causing the bottlenecks. For example, AppDynamics for Databases shows how much time is spent fetching, sorting or waiting on a lock. Copyright AppDynamics 2012-2015 Page 4
AppDynamics Database Monitoring polls for running queries and statistics to build a complete picture of what is happening on the database instance. This information tells you exactly what is active within the instance and most importantly what SQL statements are executing. The depth of data collected from AppDynamics Database Monitoring is comprehensive and allows detailed drill down. An expert DBA can view the resource consumption profile of an instance, drill into a performance spike, and then find the underlying root cause within seconds. When your SQL code is running well, AppDynamics Database Monitoring shows this without requiring you to analyze configuration parameters and metrics. Start the Controller Events Service Before you start the Database Agent, you must start the Controller Events Service. Database Monitoring Requirements and Supported Environments For large scale deployments, or where monitored systems are extremely busy, please contact AppDynamics Support for installation recommendations and assistance. On this page: Systems that AppDynamics Database Monitoring Supports AppDynamics Pro Controller Requirements Software Requirements Network Requirements Related pages: Required Database Permissions Database Monitoring Systems that AppDynamics Database Monitoring Supports Once Database Monitoring is available, you can create collectors that run on the AppDynamics Controller to monitor any of the following systems: Copyright AppDynamics 2012-2015 Page 5
System Category System Type Supported via Amazon RDS Version Databases MySQL yes all versions including Percona and MariaDB Microsoft SQL Server yes 2000, 2005, 2008, 2012, and 2014 Oracle yes 8i, 9i, 10g, 11g, and 12c PostgreSQL 8.x, 9.x IBM DB2 LUW 9.x, 10.x Sybase 15+, Sybase ASE Sybase IQ Hardware Monitoring Windows 32-bit (will also work on 64-bit systems) Linux 32-bit and 64-bit Solaris all versions AIX Database Monitoring is accomplished by two components, the Database Agent and the AppDynamics Pro Controller. The agent collects the data from the database server and passes it to the AppDynamics Controller for interpretation and display in the Controller UI. One Database Agent can collect metrics from up to 200 databases. The Database Agent does not need to be installed on the same system hosting the database server. Agent Hardware Requirements The machine running the Database Agent needs: 1-10 collectors: 2 GB RAM, Single CPU 10-20 collectors: 4 GB RAM, 2 CPUs More than 20 collectors: 8 GB RAM, 4 CPUs A maximum heap size of 50 MB per collector AppDynamics Pro Controller Requirements Copyright AppDynamics 2012-2015 Page 6
For information on additional hardware requirements for the AppDynamics Controller to support Database Monitoring, see AppDynamics Pro, Controller System Requirements. Start the Controller Events Service The Database Agent requires the Controller Events Service, which must be started before starting the agent. Software Requirements The Database Agent runs on a Java Virtual Machine. JVMs versions 1.7 and 1.8 are supported. Network Requirements The machine on which the database is running or the machine you want to monitor must be accessible from the machine where the Database Agent is installed and running. This machine must have a network connection, internet or intranet. If your databases are behind a firewall, you must configure the firewall to permit the machine running the Database Agent program access to the databases. The database listener port (and optionally the SSH or WMI port) must be open. Required Database Permissions On this page: IBM DB2 (LUW) Database Permissions Microsoft SQL Server Database Permissions MySQL Server Database Permissions Oracle Database Permissions PostgreSQL Database Permissions Sybase ASE Database Permissions Permissions Required for Explain Plans Each monitored database requires permissions for the AppDynamics Database Monitoring user so that it can gather important monitoring data. The database user is specified when you are adding a Collector. Before adding the Collector, ensure a user for the Collector is available with the required permissions as stated below. The monitor user must be able to connect to the database remotely from the machine running the Database Agent. The permissions required are database dependent. IBM DB2 (LUW) Database Permissions For complete AppDynamics for Databases functionality the following monitoring switches of the DB2 server need to be enabled: "BUFFERPOOL", "LOCK", "SORT", "STATEMENT", "TABLE", "TIMESTAMP", and "UOW". Copyright AppDynamics 2012-2015 Page 7
You can enable these monitoring switches by the following commands: update dbm cfg using dft_mon_uow on; update dbm cfg using dft_mon_stmt on; update dbm cfg using dft_mon_timestamp on; update dbm cfg using dft_mon_lock on; update dbm cfg using dft_mon_bufpool on; update dbm cfg using dft_mon_table on; update dbm cfg using dft_mon_sort on; The monitoring user needs SYSMON authority and connect privileges to monitor. In general, this user must be a part of the sysmon_group. Additional Permissions for DB2 LUW 9.7 and later grant execute on function SYSPROC.MON_GET_PKG_CACHE_STMT to user appddbmon Additional Permissions for DB2 LUW 10.1 and later Create new user account called appddbmon. Ensure that it has SYSMON authority. grant select on SYSIBMADM.mon_current_sql to user appddbmon grant select on SYSIBMADM.SNAPSTMT to user appddbmon grant select on SYSIBMADM.SNAPAPPL_INFO to user appddbmon grant execute on function SYSPROC.MON_GET_PKG_CACHE_STMT to user appddbmon Microsoft SQL Server Database Permissions The user account used for monitoring can be a Windows authenticated account (if the Database Agent is running on Windows) or SQL Server authenticated (if AppDynamics for Databases is running on Windows or Linux). Required Permissions to see Execution Plans The SQL Server user, specified in the Create Collector > Connection Details section must be a SQL Server Authenticated user that is a member of the sysadmin server role or a Windows Authenticated Account with SHOWPLAN access on each database. For more information, see Showplan Security and SHOWPLAN Permission and Transact-SQL Batches in the SQL Server documentation. Minimum Permissions Required for SQL Server Logon You can use the procedure below to create a SQL Server user with the minimum permissions required. Use the following to create a SQL Server logon user that provides the minimal level of permissions required in order to gain full AppDynamics Database Monitoring/SQL Server functionality. 1. Using SQL Server Management Studio, create a new login for the AppDynamics SQL Server Database Collector. 2. Copyright AppDynamics 2012-2015 Page 8
2. From the User Mapping tab, map the new user to the master and msdb databases. 3. Viewing Object Information To view object information on the Database > Objects Browser, map the monitoring user to the databases of interest. Once you have created the login, give the following privileges to the user, substituting <username> with the name you specified on the Login - New window: Note: You can execute the following as a batch from a query window in Management Studio. The example shows grants to appdynamics_user, remember to change this if you have set up a different login. use master GRANT VIEW ANY DATABASE TO <appdynamics_user>; GRANT VIEW ANY definition to <appdynamics_user>; GRANT VIEW server state to <appdynamics_user>; GRANT SELECT ON [sys].[sysaltfiles] TO <appdynamics_user> GRANT execute on sp_helplogins to <appdynamics_user> GRANT execute on sp_readerrorlog to <appdynamics_user> use msdb GRANT SELECT on dbo.sysjobsteps TO <appdynamics_user> GRANT SELECT on dbo.sysjobs TO <appdynamics_user> GRANT SELECT on dbo.sysjobhistory TO <appdynamics_user> where <appdynamics_user> is the name of the SQL Server user account specified in Create New Collector, Connection Details, Username field. Also, the agent must be started with the path to its authentication library. For more information see, Windows Authentication for Microsoft SQL Server. SQL Server Authentication If you are running AppDynamics Database Monitoring on Linux then you must use SQL Server authentication. If your SQL Server database allows mixed-mode authentication, then the SQL Server AppDynamics Database Monitoring uses to monitor the SQL Server database can use a SQL Server username/password authenticated account. If you would like to lock the role/permissions for the account down, then AppDynamics Database Monitoring requires: View any database View any definition View server state One additional requirement for I/O monitoring is to give permissions on a System view called sys.sysaltfiles. To do this you need to select the master database > Views > System Views > Copyright AppDynamics 2012-2015 Page 9
Properties for sys.sysaltfiles and then give select permissions on the object to the Public role. Windows Authentication If you would like to use a Windows authenticated account to connect to the SQL Server database, the following is required: When creating the collector from the Create New Collector dialog, do not specify Username and Password in the database Connection Details. Also, the agent must be started with the path to its authentication library. For more information see, Windows Authentication for Microsoft SQL Server. MySQL Server Database Permissions The MySQL user the Database Agent uses to monitor the MySQL database, must have "SELECT", "PROCESS", and "SHOW DATABASES" privileges on all databases. If you do not have a suitable existing user, you can use a command such as the following to create a new user; where host is the hostname or IP address of the machine running the AppDynamics Database Agent, and password is a suitably secure password: GRANT SELECT,PROCESS,SHOW DATABASES on *.* to 'appddbmon'@'host' identified by 'password'; FLUSH privileges; Oracle Database Permissions For versions of Oracle prior to 10g The permissions required for the Oracle user are: CONNECT SELECT ANY DICTIONARY To create a user with these permissions, you can run the following SQL. In this SQL, change "password" to a safe and secure password, and change the tablespace names, "users" and "temp" to those available in your Oracle instance. CREATE user appddbmon IDENTIFIED BY password default tablespace users temporary tablespace temp; GRANT CONNECT, SELECT ANY DICTIONARY, resource to appddbmon; For versions of Oracle 10g and later The permissions required for the Oracle user are : CREATE SESSION SELECT_CATALOG_ROLE To create a user with these permissions, you can run the following SQL. In this SQL, change Copyright AppDynamics 2012-2015 Page 10
"password" to a safe and secure password, and change the tablespace names, "users" and "temp" to those available in your Oracle instance. CREATE USER appddbmon IDENTIFIED BY password default tablespace users temporary tablespace temp; GRANT CREATE SESSION, SELECT_CATALOG_ROLE TO appddbmon; Required Permissions for Oracle Explain Plans The user you are using to monitor your Oracle database must have the privileges necessary to execute the SQL statement for which you are determining the execution plan. See Oracle Help Center, Explain Plan Privileges for more information. PostgreSQL Database Permissions The monitoring user must be superuser and must be able to connect remotely to the PostgreSQL instance from the machine where the AppDynamics Database Agent is installed. For information on how to allow users to authenticate from a remote client machine, see http://www.postgresql.org/ docs/8.3/static/auth-pg-hba-conf.html. For complete AppDynamics Database Monitoring functionality, the "track_activities" parameter must be enabled on the PostgreSQL server. Sybase ASE Database Permissions For complete AppDynamics Database Monitoring functionality, the monitoring user requires the sa_role and mon_role privilege. To create a new dedicated user for AppDynamics for Database, you can use following sample user creation script. Before running the script, change "password" to a more secure value. exec sp_addlogin 'appddbmon', 'password', @defdb='master', @deflanguage='us_english', @fullname='appddbmon monitoring account', @auth_mech = 'ANY' go exec sp_locklogin 'appddbmon', 'unlock' go exec sp_role 'grant', 'sa_role', 'appddbmon' go exec sp_role 'grant', 'mon_role', 'appddbmon' go Also, the following configuration parameters must be set to 1 (true) in order to monitor the Sybase ASE database with AppDynamics for Databases: "enable monitoring", "wait event timing", "SQL batch capture", and "object lockwait timing". You should also set "max SQL text monitored" to at least 8192 (8kB). Here is an example of the commands required to configure these settings: Copyright AppDynamics 2012-2015 Page 11
sp_configure "enable monitoring", 1 go sp_configure "wait event timing", 1 go sp_configure "SQL batch capture", 1 go sp_configure "object lockwait timing", 1 go sp_configure "max SQL text monitored", 8192 go If the value for "max SQL text monitored" was previously less than 4096, then increasing this setting will require that you restart the Sybase ASE instance. Permissions Required for Explain Plans AppDynamics for Databases can generate explain plans within its SQL drilldown window. To enable this functionality, you must have a plan table accessible to the AppDynamics Database Monitoring schema user. You can create this plan table with the following command from sqlplus when logged on as the AppDynamics Database Monitoring user: Windows: @?\rdbms\admin\utlxplan.sql Linux: @?/rdbms/admin/utlxplan.sql Authentication for Host Monitoring On this page: Authentication Methods Related pages: Configure an SSH Key for Controller Access Authentication Methods Database Agent User Permissions Database Monitoring collects the stats from common commands like vmstat/iostat or gathering metrics from the file system such as /proc and as such the user that runs the Database Agent requires no special permissions, just the ability to run those common commands and write to files Copyright AppDynamics 2012-2015 Page 12
in the Database Agent directory. Database Agent Collector Authentication When monitoring the database host, Database Monitoring must log in to the host system to gather system information. There are three ways to authenticate the Database Collector to access the monitored host: Specify a username and password in the Collector configuration dialog Place a PEM file or an id_rsa file in the <agent home>/keys directory If the Database Agent is running on LINUX, Solaris or AIX, place SSH keys in the <home>.ssh directory of the user running the agent. You can create an SSH key using the same procedure as described for the Controller, Configure an SSH Key for Controller Access. Configure WMI Permissions and Security On this page: Requirements to Monitor Windows 7 and Higher Systems (agent running on Unix-like platform) Ensure User Account Meets Minimum Security Requirements When Using WMI Enable Remote Registry Access Grant Access to WBEM Scripting Locator Configure the Firewall Additional Requirements to Monitor Windows 2012 and Higher Systems (agent running on Unix-like platform) Grant Full Control Permissions to Select Registry Keys General Considerations for all Platforms Use Windows Authentication for Microsoft SQL Server Prevent Unauthorized Remote Access to WMI Related pages: WMI and the Database Agent on the AppDynamics Community To monitor Windows-based machine hardware with AppDynamics Database Monitoring, AppDynamics uses Windows Management Instrumentation (WMI) to remotely gather the metrics. WMI is often complicated to troubleshoot when the Database Agent is running on a Linux or Unix-like machine. This topic identifies requirements for the target machine configuration that can help you avoid some problems and pitfalls. It also provide some additional considerations regarding using WMI to monitor a SQL Server database agent and preventing unauthorized remote access to WMI. Copyright AppDynamics 2012-2015 Page 13
The following are required when the Database Agent is hosted on AIX, Linux or Solaris platforms t o monitor Windows 7 and higher systems. 1. 2. 3. 4. 5. Named Windows Account: The user specified in the collector configuration that the AppDynamics Database Agent uses to connect to the target machine is referred to as "named Windows account." Ensure that the named Windows account is a member of the local Administrators group. Ensure that the named Windows account meets the minimum WMI security requirements Enable Remote Registry Access Grant access to WBEM scripting locator The following are required when the Database Agent is hosted on AIX, Linux or Solaris platforms t o monitor Windows 2012 and higher systems. Grant full control permissions to select registry keys Requirements to Monitor Windows 7 and Higher Systems (agent running on Unix-like platform) The following are required when the Database Agent is hosted on AIX, Linux or Solaris platforms t o monitor Windows 7 and higher systems. Ensure User Account Meets Minimum Security Requirements When Using WMI Enable Security Options for Windows Systems that are part of a Domain Ensure the named Windows account has the correct permissions for WMI Control. Run the wmimgmt.msc program. Right click the WMI Control icon on the left and click Properties. Click the Security tab. Click the root node of the tree, and click Properties. Ensure that the named user account running the Database Agent has the relevant permissions. The minimum permissions that your remote Windows account needs for the Database Agent are: Execute Methods Enable Account Remote Enable If the named Windows account does not have all of these permissions, you might see an access denied error or the following error: Error=800706BA The RPC server is unavailable. SWbemLocator or Error=80070005 Access is denied SWbemLocator Enable Classic Security Options for Local (non-domain) Windows Systems Applies to Windows computers that are not part of a domain. 1. Copyright AppDynamics 2012-2015 Page 14
1. 2. 3. 1. 2. 3. 4. 5. 6. 7. Open the Control panel, and go to Administrative Tools > Local Security Policy. The Local Security Settings window appears. Go to Local Policies > Security Options. Change the value of "Network access: Sharing and security model for local accounts." to Cl assic. Enable Remote Registry Access The Remote Registry service must be running on the target machine. If the Remote register service is off, you will see the following error: Message not found for errorcode: 0xC0000034 or Access is denied By default Windows 7 and above systems will still deny remote access to the registry, even if the Remote Registry service is started. To test this, try to connect to the slave registry via regedit on another machine. If you get a error similar to Access is denied, run powershell as an administrator on the slave, and execute Enable-PSRemoting. Restart the machine and try launching the slave again. Grant Access to WBEM Scripting Locator The Database Agent requires full access to the WBEM Scripting Locator. On the target system allow full access to the WBEM Scripting Locator as follows: As an Administrator on the target machine, launch regedit. Locate the registry key: 76A64158-CB41-11D1-8B02-00600806D9B6 in HKEY_CLASSES_ROOT\CLSID Right click the key and click Permissions. Click Advanced, and then on the Owner tab change the owner to the Administrators group. Click Apply. On the Permissions tab change the permissions for the Administrators group to Full Control. Click Apply. Close regedit. Restart the Remote Registry Service, using Administrative Tools > Services. Configure the Firewall WMI uses RPC which listens on port 135 but then allocates a dynamic port for subsequent communication. Configure your Firewall to always allow the TCP port 135 exception and follow the dynamic RPC ports. If there is a problem with the firewall, port 135 then you will probably see this error: ERROR: Message not found for errorcode: 0xC0000001 Additional Requirements to Monitor Windows 2012 and Higher Systems (agent running on Unix-like platform) In addition to the requirements described in Requirements to Monitor Windows 7 and Higher Systems, the following are also required when the Database Agent is hosted on AIX, Linux or Copyright AppDynamics 2012-2015 Page 15
Solaris platforms to monitor Windows 2012 and higher systems. Grant Full Control Permissions to Select Registry Keys For the Database Agent running on AIX, Linux or Solaris to monitor Windows 2012 (64-bit) and above systems, complete the following changes on the target system. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. As an Administrator on the target machine, launch regedit. Change the permissions for both of the following registry keys to Full Control: 72C24DD5-D70A-438B-8A42-98424B88AFB8 in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID 76A64158-CB41-11D1-8B02-00600806D9B6 in HKEY_CLASSES_ROOT\CLSID Find the following registry key: 72C24DD5-D70A-438B-8A42-98424B88AFB8 in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID Right click and click Permissions. Change the owner to the Administrators group. Change the permissions for the Administrators group to Full Control. Change owner back to TrustedInstaller. User is "NT Service\Trusted Installer" on local machine. Repeat steps 4 to 6 above for the following registry key: 76A64158-CB41-11D1-8B02-00600806D9B6 in HKEY_CLASSES_ROOT\CLSID. Close regedit. Restart the Remote Registry service, using Administrative Tools > Services. General Considerations for all Platforms These topics apply to the Database Agent running on any supported platform; Windows, Linux, and Unix-like systems. Use Windows Authentication for Microsoft SQL Server To use Windows Authentication for the Database Agent to connect to a Microsoft SQL Server database instance, you must use a command similar to following to start the Database Agent; specifying the path to the Database Agent authentication library. Windows 64-bit java -Djava.library.path="C:\dbagent404\auth\x64" -jar db-agent.jar Windows 32-bit java -Djava.library.path="C:\dbagent404\auth\x64" -jar db-agent.jar Also, the Windows account used to start the Database Agent must be a Windows user who can authenticate with the database server. Prevent Unauthorized Remote Access to WMI For Windows 2003 R2 SP2 You may want to setup extra security in the Windows Distributed Component Object Model (DCOM) to prevent unauthorized users from accessing WMI remotely. The following prevents users other than those configured as follows from remotely accessing the WMI. You can Copyright AppDynamics 2012-2015 Page 16
configure the named Windows account as follows: 1. 2. 3. 4. On the target machine, add the named Windows account to the Performance Monitor Users group In Services and Applications, bring up the properties dialog of WMI Control. On the Security tab, highlight Root/CIMV2, click Security > Add Performance Monitor Users and enable the options: Enable Account and Remote Enable. Run dcomcnfg. Click Component Services > Computers > My Computer > Properties > COM Security, and then click Edit Limits for both Access Permissions and Launch and Activation Permissions. Add Performance Monitor Users and allow remote access, remote launch, and remote activation permissions. In Component Services > Computers > My Computer > DCOM Config > Windows Management Instrumentation, give Remote Launch and Remote Activation privileges to the Performance Users Group. AppDynamics Database Monitoring Architecture The AppDynamics Database Agent is a standalone Java program that collects performance statistics about your database instances and database servers. One Database Agent can monitor 100-200 database instances. The Database Agent can be deployed on any machine running Java 1.7 or higher that has network access to the database instance to be monitored and the AppDynamics Pro Controller. The Database Monitoring windows in the Controller UI provide a common GUI to all your database instance and database server performance metrics. New in 4.0.4 The AppDynamics Controller and Database Agent now support multiple Database Agents reporting to the same Controller. You can run additional backup Database Agents that take over for your primary Database Agents in case the primary ones go offline, ensuring your database instances are continually monitored despite agent failure or during planned machine downtime. The additional Database Agents can run on the same machines as the primary Database Agents or on different machines. You can have an agent in each distinct network of your environment. Since the agent requires network access to the database instance, you may need multiple agents to monitor all the database instances in your environment. You can have multiple Database Agents running under different user accounts on the same machine, which is particularly useful if you want to monitor SQL Server via Windows Authentication as various users. Copyright AppDynamics 2012-2015 Page 17
Install or Upgrade the Database Agent On this page: AppDynamics Pro Controller Requirements Install Database Agent Increase the JVM Memory Verify that the Agent is Running Upgrade the Database Agent Troubleshooting Related pages: Database Monitoring Database Agent Configuration Properties Required Database Permissions Database Agent FAQ Start the Database Agent Automatically on Linux Start the Database Agent Automatically on Windows Watch the video: Getting Started - Database Agent New in 4.0.4 The AppDynamics Controller and Database Agent now support multiple Database Agents reporting to the same Controller. New Multi-Database-Agent Properties support this functionality. Copyright AppDynamics 2012-2015 Page 18
You can run additional backup Database Agents that take over for your primary Database Agents in case the primary ones go offline, ensuring your database instances are continually monitored despite agent failure or during planned machine downtime. The additional Database Agents can run on the same machine as the primary Database Agents or on different machines. You can have an agent in each distinct network of your environment. Since the agent requires network access to the database instance, you may need multiple agents to monitor all the database instances in your environment. You can have multiple Database Agents running under different user accounts on the same machine, which is particularly useful if you want to monitor SQL Server via Windows Authentication as various users. AppDynamics Pro Controller Requirements AppDynamics Database Monitoring requires the Controller Events Service, which is not started by default. Before you start the Database Agent you must start the Events Service. Install Database Agent In the steps that follow, <agent_home > is the agent installation directory. 1. 2. 3. Ensure you have Java 1.7 or later installed on the machine. The agent must have network access to the databases you want to monitor. Download the Database Agent installation zip file. Log on as an administrator to the machine where you'll be installing the Database Agent and extract the zip file to <agent_home >. Do not use spaces in the destination directory path. Windows: If necessary, you can unblock the zip file before you extract it as follows: Right-click on the zip file, select Properties, and choose unblock. Double-click the dbagent-x.x.x.zip file and extract the files to <agent_home >. 4. 5. Linux: Enter the following on the command line: unzip dbagent-x.x.x.zip -d /opt/appdynamics/<agent_home> You can have multiple Database Agents concurrently running the agent jar located in the <agent_home> directory. Configure the agent/controller communications using either the < agent_home>/conf/controll er-info.xml file or by adding system properties to the JVM startup command or script file. a. Configure how the agent connects to the Controller, using the Controller Host and Con troller Port properties. b. Optional. Configure agent to use SSL, using the Controller SSL Enabled property. c. (For Multi-tenant mode or SaaS installations only.) Configure the agent account information, using the Account Name and Account Access Key properties. (For on-premise installations only) Obtain a license.lic file with Database Monitoring licensing from your sales or support representative and put the license file in the same Copyright AppDynamics 2012-2015 Page 19
5. 6. 7. directory as where you installed the Controller. After placing the license in the directory, the Controller may take a minute or two to detect the new license. Restarting the Controller forces it to detect new licenses. (Optional) Configure the agent to run automatically when the machine starts on Linux or Win dows. (Optional) Configure the logging level of the Database Agent running on this JVM. Start the Controller Events Service Before you start the Database Agent, you must start the Controller Events Service. 8. Start the Controller Events Service. Linux: <controller_home>/bin/controller.sh start-events-service Windows: <controller_home>\bin\controller.bat start-events-service 9. Launch the Database Agent using the required system properties. For one Database Agent per Controller: The following assumes that all the necessary parameters have been specified in the controller-info.xml. Windows Open a command shell and enter: java -Djava.library.path=" <agent_home> \auth\x64" -Dappdynamics.agent.uniqueHostId=<unique_host_ID> -jar <agent_home>/db-agent.jar where <agent_home> is the absolute path to the location where the Database Agent is installed and <unique_host_id> is a name for the machine running the Database Agent that is unique to the Controller you're connecting to. You must specify all of these options. Windows Users - Don't close the command shell window When you close the command shell window the agent shuts down. See Installing the Database Agent as a Windows Service to run the agent in the background. Linux From the command line, enter: java -Dappdynamics.agent.uniqueHostId=<unique_host_ID> <agent_home>/db-agent.jar & -jar where <unique_host_id> is a name for the machine running the Database Agent that is unique to the Controller you're connecting to. You must specify all of these options. The agent process runs in the background. For multiple Database Agents per Controller: If the agent you're installing is not the sole Database Agent in your environment, use the launch commands as above along with the Mu lti-database-agent Properties, on the command line or in your startup script. For example, Copyright AppDynamics 2012-2015 Page 20
your launch command to startup one agent might be similar to the following examples. In your JVM startup script, specify one line for each Database Agent that you want to startup on that machine. Agent properties used for multi-agent installations include, Note that if the agent configuration property values contain spaces, you must enclose the entire name in double quotes (" ") for Windows and single quotes (' ') for Linux and Unix-like systems. For example, Linux java -Ddbagent.name='Scarborough Network Database Agent' -Dappdynamics.agent.uniqueHostId='Scarborough Network Database Agent Host' -Ddbagent.is.backup.for='Pickering Network Database Agent' -jar <agent_home>/db-agent.jar Windows java -Djava.library.path="C:\AppDynamics\Database Agent\auth\x64" -Ddbagent.name="Scarborough Network Database Agent" -Dappdynamics.agent.uniqueHostId="Scarborough Network Database Agent Host" -Ddbagent.is.backup.for="Pickering Network Database Agent" -jar "C:\AppDynamics\Database Agent\db -agent.jar" Increase the JVM Memory To monitor 100 or more databases, you may need to increase the JVM memory allocation size. For example, on Linux use this command to start the agent, and to initially allocate 256 MB to the agent instead of the default of 64 MB. java -Xms256m -jar <agent_home>/db-agent.jar Verify that the Agent is Running 1. Verify the agent installation. Open the <agent_home>/logs/agent.log file. If successful, this file should contain the following message: Started AppDynamics Database Agent Successfully 2. 3. This message is also printed on the STDOUT of the process. Verify that the agent is reporting using an Administrator account, go to the Controller in Settings > AppDynamics Agents > Database Agents. On the Database Agents section, the name of the Database Agent appears along with its version number. If this is the only Database Agent you've installed, its name will be Default Database Agent, otherwise the name will the the name you specified either on the JVM startup command line. (For initial database agent installation only) Next Steps, configure the database collector. Copyright AppDynamics 2012-2015 Page 21
3. (The configuration parameters depend on the specific database to be monitored.) The database collector configurations are stored in the Controller database and are not deleted by uninstalling and reinstalling the Database Agent, only by deleting the Collector. Upgrade the Database Agent 1. 2. 3. 4. 5. 6. Shut down the Database Agent process before you install. Make a copy of the Database Agent home directory. Delete the original Database Agent home directory. Install the Database Agent as described above in steps 2-7 above. Don't start the agent yet. Copy the <copy of agent_home>/conf/controller-info.xml file to the new <agent_home>/conf/ directory. Start the agent and verify the installation as described in Verify that the Agent is Running. Troubleshooting Look in the Database Monitoring Events window. Look at the Database Agent log file: <agent_home>/logs/agent.log. Database Agent Configuration Properties On this page: Where to Configure Database Agent Properties Example Database Agent controller-info.xml File Example Startup Configuration Using System Properties Database Agent Properties Required System Properties Agent-Controller Communication Properties Multi-Database-Agent Properties Multi-Tenant Mode Properties Proxy Properties for the Controller Other Properties Related pages: Installing the Database Agent Where to Configure Database Agent Properties You can configure agent/ properties: in the controller-info.xml file located in the <db_agent_home> /conf directory in the system properties (-D options) section in the JVM start-up script: java -D<agent_system_properties> -jar <db_agent_home>/db-agent.jar Copyright AppDynamics 2012-2015 Page 22
New in 4.0.4 Agent properties related to naming agents or designating them as backup partners can only be configured on the command line or in the JVM start-up script. However, you can specify the Controller/Agent connection details in the controller-info.xml file. The system properties override the settings in the controller-info.xml file. System properties are case-sensitive. Example Database Agent controller-info.xml File <?xml version="1.0" encoding="utf-8"?> <controller-info> <controller-host>192.10.10.10</controller-host> <controller-port>8090</controller-port> <!-- The following attribute enables or disables SSL communications between the agent and the Controller.--> <controller-ssl-enabled>false</controller-ssl-enabled> <!-- The following account-related parameters are necessary only for SaaS installations--> <!--account-name></account-name--> <!--account-access-key></account-access-key--> </controller-info> Example Startup Configuration Using System Properties A bash example. Note that the system properties are case-sensitive. -Dappdynamics.controller.hostName=192.168.1.20 -Dappdynamics.controller.port=8090 Database Agent Properties This section describes the Database Agent configuration properties, including their controller-info-xml elements and their system property options. Required System Properties Unique Host ID Property Description: Uniquely identifies the machine running the Database Agent. The value of this property must be different for every Database Agent in your environment. System Property: -Dappdynamics.agent.uniqueHostId=<unique_host_ID> Type: ASCII string, including spaces. If < agent_name> contains spaces, you must enclose the entire name in double quotes (" "). Copyright AppDynamics 2012-2015 Page 23
Default: N/A Required: Required. Example: -Dappdynamics.agent.uniqueHostId="Scarborough Server Agent One" Path to the Java Library Description : Provides the absolute path to sqlijdbc_auth.dll. System Property: -Djava.library.path Value: For 64-bit systems: <agent_home>\auth\x64 For 32-bit systems: <agent_home>\auth\x64 Type: ASCII string, including spaces. If < agent_name> contains spaces, you must enclose the entire name in double quotes (" "). Required: Recommended for Unix and. Required for SQL Server Windows Authentication on Windows 64-bit systems. Example: -Djava.library.path="D:\AppDynamics\Database Agent\auth\x64" Path to the Agent jar File Description : Provides the absolute path to sqlijdbc_auth.dll. System Property: -jar Value: <agent_home>db-agent-jar Type: ASCII string, including spaces. If < agent_name> contains spaces, you must enclose the entire name in double quotes (" "). Required : Yes Example: -jar="d:\appdynamics\database Agent-Controller Communication Properties Controller Host Property Agent\db-agent.jar" Description: This is the host name or the IP address of the AppDynamics Controller, e.g. 192.168.1.22 or myhost or myhost.abc.com. This is the same host that you use to access the AppDynamics Controller UI. Element in controller-info.xml: <controller-host> System Property: -Dappdynamics.controller.hostName Type: String Default: None Required: Yes Copyright AppDynamics 2012-2015 Page 24
Controller Port Property Description: This is the HTTP(S) port of the AppDynamics Controller. This is the same port that you use to access the AppDynamics browser-based user interface. If the Controller SSL Enabled property is set to true, specify the HTTPS port of the Controller; otherwise specify the HTTP port. See Controller SSL Enabled Property. Element in controller-info.xml: <controller-port> System Property: -Dappdynamics.controller.port Type: Positive Integer Default: For On-premise installations, port 8090 for HTTP and port 8181 for HTTPS are the default ports the Controller listens to. For the SaaS Controller Service, port 80 for HTTP and port 443 for HTTPS are the default ports the Controller listens to. Required: Yes Multi-Database-Agent Properties New in 4.0.4 The following properties are useful or necessary when you are configuring your system to include more than one Database Agent. Database Agent Name Property Description: This property uniquely identifies the Database Agent to the Controller. If you already have a (pre-4.0.4) Database Agent in your environment, it can report data to a 4.0.4 and higher controller, and will automatically receive the default name, Default Database Agent. You do not need to supply a name for this agent. System Property: -Ddbagent.name=<agent_name> Type: ASCII string, including spaces. If < agent_name> contains spaces, you must enclose the entire name in double quotes (" "). Default: The default name of the Database Agent is Default Database Agent Required: Required when you have more than one Database Agent reporting to the Controller (w hether there are more than one Database Agents running on the same machine or you have multiple Database Agents running on different machines. In addition, if you specify this property (Agent Name Property), you must also specify the Unique Host ID Property. Specify the Database Agent name under the following conditions: To enable more than one AppDynamics Database Agent to report data to the Controller, specify a unique name for this Database Agent. Any Database Agent you do not explicitly name automatically receives the name "Default Database Agent". Therefore, to prevent double-reporting of data, you must explicitly name either all the Database Agents in your environment or all but one of the Database Agents (namely, the default Database Agent) in your environment. To support multiple Database Agents when you have databases spread across multiple networks, and one machine cannot access all the databases on all the networks. In this Copyright AppDynamics 2012-2015 Page 25
case you can have a uniquely named Database Agent in each network that monitors the databases only visible on that network. If you have multiple Database Agents running on the same machine under different user accounts to monitor SQL Server via Windows Authentication as various users. Naming the Database Agent is optional under the following conditions If you have only one Database Agent, you do not need to specify the name of the Database Agent. To fortify your environment, add Database Agents to be a backup partner for other Database Agents. If you do not specify a name for the backup partner, a name will be generated for it. Example: -Ddbagent.name="Scarborough Network Database Agent" Agent Is Backup Property Description: Specifies the name of the Database Agent you want the agent to backup. You can run additional backup Database Agents that take over for your primary Database Agents, ensuring your databases are continually monitored despite agent failure or during planned machine downtime. The additional Database Agents can run on the same machines as the primary Database Agents or different ones. If you specify this property (Agent Is Backup Property), you must also specify the Unique Host ID Property system property. System Property: - Ddbagent.is.backup.for=<agent_name> Type: ASCII string, including spaces. If <agent_name> contains spaces, you must enclose the entire name in double quotes (" "). Default: N/A Required: Only if you want the agent to backup another agent. Example: -Ddbagent.is.backup.for="Scarborough Network Database Agent" Multi-Tenant Mode Properties If the AppDynamics Controller is running in multi-tenant mode or if you are using the AppDynamics SaaS Controller, specify the account name and account access key for this agent to authenticate with the Controller. If the Controller is running in single-tenant mode (the default) there is no need to configure these values. Account Name Property Description: This is the account name used to authenticate with the Controller. If you are using the AppDynamics SaaS Controller, the Account Name is in the Welcome email AppDynamics sent to you. Element in controller-info.xml: <account-name> System Property: -Dappdynamics.agent.accountName Type: String Copyright AppDynamics 2012-2015 Page 26
Default: None Required: Yes for AppDynamics SaaS Controller and other multi-tenant users; no for single-tenant users. Account Access Key Property Description: This is the account access key used to authenticate with the Controller. Element in controller-info.xml: <account-access-key> System Property: -Dappdynamics.agent.accountAccessKey Type: String Default: None Required: Yes for AppDynamics SaaS Controller and other multi-tenant users; no for single-tenant users. Proxy Properties for the Controller These properties route data to the Controller through a proxy. Proxy Host Property Description: This is the proxy host name or IP address. Element in controller-info.xml: Not applicable System Property: -Dappdynamics.http.proxyHost Type: String Default: None Required No Proxy Port Property Description: This is the proxy HTTP(S) port. Element in controller-info.xml: Not applicable System Property: -Dappdynamics.http.proxyPort Type: Positive Integer Default: None Required: No Other Properties Controller SSL Enabled Property Description: This property specifies whether the agent should use SSL (HTTPS) to connect to the Controller. If SSL Enabled is true, set the Controller Port property to the HTTPS port of the Controller. See Controller Port Property. Copyright AppDynamics 2012-2015 Page 27
Element in controller-info.xml: <controller-ssl-enabled> System Property: -Dappdynamics.controller.ssl.enabled Type: Boolean Default: False Required: No Installing the Database Agent as a Windows Service 1. 2. 3. On this page: Install the Database Agent as a Windows Service - Pre Windows 2008 Install the Database Agent as a Windows Service - Windows 2008 and 2012 Uninstall the Database Agent as a Service Known Issues Related pages: Install or Upgrade the Database Agent Database Agent Configuration Properties Database Monitoring Most Windows server software runs as a service when the machine boots up. To secure your environment and ensure Database Agent availability, you can install the Database Agent as a Windows service using the SRVANY.EXE and SC.EXE utilities that are part of the Microsoft Resource Kit for Windows 2003 Server. The SRVANY.EXE tool creates a Windows service that launches the JVM processes for the agent in non-gui mode using parameters specified in the registry of the service. The SC.EXE command is used to install and uninstall the agent service. Install the Database Agent as a Windows Service - Pre Windows 2008 The following procedure involves editing the registry. Before proceeding, know how to backup and restore the registry as described in the WIndows Registry Editor online help. Install the agent as usual, described in Install or Upgrade the Database Agent. Obtain the INSTSRV.EXE and SC.EXE utilities. Download the Windows Server 2003 Resource Kit Tools, at http://www.microsoft.com/en-us/ download/details.aspx?id=17657. The required utilities are included in this resource kit Prepare registry and batch command files. To simplify service creation and deregistration, we have attached two batch command files, InstallService.cmd and UninstallService.cmd to this page. InstallService.cmd requires the information in the DatabaseAgent.reg file to set the registry key for the service. DatabaseAgent.reg to set the registry key values for the service InstallDBService.cmd to install the service UninstallDBService.cmd to uninstall the service Download these files and edit them as indicated below. Specify the same service Copyright AppDynamics 2012-2015 Page 28
name in all three files. i. Customize DatabaseAgent.reg. Edit the service name, Application, AppParameters, and AppDirectory values of this file for your environment. Specify the service name is specified on the first line of this file. AppDynamics Database Agent Service in the sample attached. Application is the path to the JDK you use for Database Agent. <agent_home> \\jre7\\bin\\java.exe in the sample attached. The Database Agent is compatible with JRE 1.7 and 1.8 AppParameters is everything you want to pass to the JVM as arguments. For a 32-bit system, set java.library.path="<agent_home>\auth\x32", the absolute path For a 64-bit system, set java.library.path="<agent_home>\auth\x64", the absolute path If your agent will be monitoring more than 100 databases, increase the size of the initial memory allocation specified in the code example below as follows: change -Xms32m to -Xms256m For 64-bit systems, allocating 32 MB of initial heap size java -Djava.library.path="<agent_home>\auth\x64" -Dappdynamics.agent.uniqueHostId=<unique_host_ID> -Xms32m -jar "<agent_home>\db-agent.jar" a. b. c. AppDirectory points to the agent working directory, the location where you installed the Database Agent. <agent_home>. Customize InstallDBService.cmd. Edit the create and binpath values in this file for your environment. Specify the service name in quotes in the sc command create option as follows: sc create "AppDynamics Database Agent Service" in the sample attached. Specify binpath as the path to the SRVANY.EXE Windows Resource d:\appdynamics\databaseagent\srvany.exe in the sample above The service installed runs with the permissions of the user logged in when service is created. To change the user running the installed process, modify InstallService.cmd by inserting the following anywhere before "pause" at the end of the file. sc config <service> obj= <username> password= <password> Note: There is a required space between obj= and <username>. 4. Customize UninstallDBService.cmd Copyright AppDynamics 2012-2015 Page 29
4. UninstallDBService.cmd - Uninstalls the Database Agent Service @echo off rem UnInstall AppDynamics Database Agent Service echo "Stopping AppDynamics Database Agent Service - may be running" sc stop "AppDynamics Database Agent Service" echo "Uninstalling AppDynamics Database Agent Service from the Service Manager" sc delete "AppDynamics Database Agent Service" echo "done." pause a. Specify the name of the service in quotes after the sc stop or delete options. "AppDynamics Database Agent Service" in the sample file attached. From the Windows Explorer, right-click InstallDBService.cmd and click Run as Administrator. Install the Database Agent as a Windows Service - Windows 2008 and 2012 Download NSSM - the Non-Sucking Service Manager. Create a start.bat file containing your agent startup script, such as: -Djava.library.path="<agent_home>\auth\x64" -jar <agent_home>db-agent.jar java -jar db-agent.jar where <agent_home> is where you installed the Database Agent. Add the path to nssm.exe to your Path environment variable. Start a command shell and enter the following: nssm.exe install <service name> where <service name> is the name of the agent service. In the NSSM service installer dialog, enter the full path to the agent startup script in the Path field of the Application tab. Enter any other details appropriate for your environment. For information on the various options, see the NSSM documentation. Click Install service. A service is created named <service name>, that starts up automatically when the machine is started and that is also restarted if the process stops for any reason. Uninstall the Database Agent as a Service If you used INSTSRV.EXE and SC.EXE utilities: From the Windows Explorer, right-click UninstallService.cmd and click Run as Administrator. Thi s stops and removes the service from Windows. If you used NSSM: From a command shell, enter nssm.exe remove <service name> where <service name> is the name of the agent service. Copyright AppDynamics 2012-2015 Page 30
Known Issues In Windows Server 2003 you must install and start or stop the service from the console window. If you do a normal RDP connection to the 2003s Terminal Services the service will be stopped when you log-out. Therefore issue the command "mstsc /console <machinename>" to connect to the console session of Windows Server 2003. Start the Database Agent Automatically on Linux Related pages: Install the Database Agent Database Agent Configuration Properties 1. 2. Create an initialization script that starts the agent, as in the sample initialization script that is an attachment to this page. In your script, set the JAVA and AGENT_HOME values to the paths for your system. Also configure agent options, as needed. Enable execution permissions for the script. For example, given an initialization script named db-agent, enter: sudo chmod 775 db-agent 3. 4. Place the script in the initialization directory on your system, typically /etc/init.d. Alternatively, create a symbolic link to the script from the init.d directory to the script if you want to keep it in another location. Add the script as a service as follows: On Red Hat and most Linux Operating Systems, run these commands, replacing "dbagent" with the name of your file or symbolic link: chkconfig --add db-agent chkconfig --level 2345 db-agent on On Ubuntu and Debian Operating Systems, run this command, replacing "appdcontroller" with the name of your file or symbolic link: update-rc.d -f db-agent start 99 2 3 4 5. In the command: start is the argument given to the script (start, stop). Copyright AppDynamics 2012-2015 Page 31
99 is the start order of the script (1 = first one, 99 = last one) 2 3 4 5 are the runlevels to start Be sure to include the dot (.) at the end of the command. The Database Agent now starts automatically upon machine startup. Start the Database Agent Automatically on Windows Related pages: Install or Upgrade the Database Agent Database Agent Configuration Properties 1. Create a batch file containing the following line: For 64-bit systems, allocating 32 MB of initial heap size java -Djava.library.path="<agent_home>\auth\x64" -Dappdynamics.agent.uniqueHostId=<unique_host_ID> -Xms32m -jar <agent_home>\db-agent.jar 2. For a 32-bit system, the set java.library.path="<agent_home>\auth\x32" If your agent will be monitoring more than 100 databases, you may need to increase the size of the initial memory allocation specified in the code above as follows: 3. 4. 5. 6. 7. 8. 9. change -Xms32m to -Xms256m Click Control panel > Scheduled Tasks. Select the batch file to execute. This is the file created in step 2. Create a new task. Select When my computer starts. Enter the administrator's credentials to run the Database Agent as that user. Click Finish. To start the Database Agent for the first time, right-click on the scheduled task, and click Ru n. Configure Database Collectors On this page: Add a Database Collector Verify Collector Setup Edit a Database Collector Delete a Database Collector Troubleshooting Collector Problems Related pages: Adding Database Instance Licenses Database Monitoring Copyright AppDynamics 2012-2015 Page 32
Configure Roles Watch the video: Creating Database Collectors The Database Agent Collector is a process that runs within the Database Agent to communicate with databases, servers, and infrastructure to collect metrics. Configure one Collector for each database instance that you want to monitor. You can also configure the Collector to monitor the machine hosting the database instance the Collector is monitoring. Each active Collector consumes one license. The Database Agent can support up to 200 Collectors. To monitor 100 + database instances, increase the initially allocated heap size for the Database Agent JVM. Add a Database Collector For required roles and permissions required to add, edit, and create collectors, see Configure Roles. Complete each field of the Configure > Collector > Create New Collector dialog and then click OK. Your database administrator can provide you with the necessary details. The Configure > Collectors window lists all collectors. Monitored database instances appear on the Database Monitoring and Databases windows, and on the AppDynamics Pro Controller Home page. You can link a database on the application flow maps to a database instance monitored by Database Monitoring. Descriptions of the fields in the Create New Collector dialog follow. Complete the Connection Details Section Use the following to help you complete the fields of the Add New Collector and Edit Collector windows. The fields that display depend on the type of Database Collector you selected. Database Type: From the list, select the database type the Collector will monitor. Database Agent: From the list, select the Database Agent that manages the collector. If you only have one Database Agent, then its name will be Default Database Agent unless you changed the name on the Database Agent startup command using the Database Agent Name configuration property. Database: (SQL Server) Specify "master". Name: (for all databases) Enter the name of the database. This is the name that will appear in the Database Monitoring windows. Hostname or IP Address: (for all databases) Specify the hostname or IP address of the machine serving the database. The hostname or IP address appears in the Hostname column of the Collector Administration window. EnterpriseDB: Click if your PostrgreSQL database installation is an EnterpriseDB distribution. Copyright AppDynamics 2012-2015 Page 33
Failover Partner : (for Microsoft SQL Server) If you use Database Mirroring, enter the hostname of the IP address of the Failover Partner here. If you specify this field you must also specify the Data base field as described above. Listener Port: (for all databases) Specify the TCP/IP address of the port the database uses for communicating with the AppDynamics Database Monitoring agent. The database list port appears in the Listener Port column of the Collector Administration window. Custom JDBC Connection String: (for all databases) Normally, the Database Agent generates a JDBC connection string based on the information provided in the collector configuration dialog. You also have the option to specify a custom connection string, which can be useful for setting custom authentication options. For example, you can use LDAP to authenticate with an Oracle database, by using a connection string such as: jdbc:oracle:thin:@ldaps://ldap.acme.com:7777/sal es,cn=oraclecontext,dc=com. SID or SERVICE_NAME: (for Oracle) Specify the services name or SID of the database to monitor. Click either SID or SERVICE_NAME to indicate which database identifier you are using. Connect as a sysdba: (for Oracle) Click if you want to connect as user sys and enable password files. Running the collector using a sysdba account allows the Collector to monitor an Oracle instance in standby mode, an instance that is used for failover which is being replicated from the main active instance. Username: (for all databases) Specify the name of the user the Database Agent uses to connect to the database. This user must have the Required Database Permissions. The user account used for monitoring a SQL Server database can be a Windows authenticated account (if the Database Agent is running on Windows) or SQL Server authenticated (if the Database Agent is running on Windows or Linux). Password: (for all databases) Specify the password of the user the Database Agent uses to connect to the database. Logging Enabled: Click to enable verbose mode logging, which logs all communications between the Controller and the Collector. Enable only during troubleshooting because logging can consume a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located in the <db_agent_home>\agent directory and have the format <CollectorName>_out.log and <CollectorName>_err.log. Complete the Hardware Monitoring Section Monitor Operating System: Click if you want CPU consumption metrics collected from the monitored host. Operating System: Specify the operating system of the monitored host: Windows, Linux, Solaris, AIX, and NetApp. Domain: For Windows only, specify the the name of the domain in which the hardware resides. SSH Port: For Linux, Unix and NetApp only, specify the Secure Shell (SSH) port number the Controller should use for encrypted communications with the monitored host. The default port number of 22 will be used if you do not specify a different port number here. Use certificate: For Linux, AIX, and Solaris, AppDynamics also supports certificate-based Copyright AppDynamics 2012-2015 Page 34
authentication via Privacy Enhanced Mail (PEM). To implement certificate-based authentication, enable the Use certificate option and copy the PEM file to the <db_agent_home>\keys directory. Note, if the $HOME/.ssh directory exists, the agent will use the certificate found there. This option appears only if the agent is running on a machine running Linux, AIX or Solaris. Username: Specify the name of the user the Database Agent uses to log on to the monitored host. To collect OS metrics from a Windows host, the configured user (or Collector Service user if using Windows Authentication) must be able to establish a WMI connection to the target host and collect Windows Performance Counters. Password: Specify the password of the user the Database Agent uses to log on to the monitored host. The number of echo characters shown in the password text field should not be interpreted to imply the number of characters stored for the (encrypted) user password. Verify Collector Setup Once the Collector is up and running, in just a short time you can start viewing the historical activity data. The Collector configuration window now has a collector icon you can click to edit the details of the collector if required. The Collector will also appear in the list of Databases shown in the left navigation menu. It might take a few minutes before the Collector and its metrics are reported. From the left navigation menu, click Databases to see a high-level view of the activity of all the configured Collectors. Click the name of the database to see more details of the metrics AppDynamics Database Monitoring has captured. For information on using and interpreting the Collector windows, see Monitor Databases and Database Servers. Edit a Database Collector From the Collectors window, you can edit any of the details of the collector except the type of database platform to monitor. Delete a Database Collector From the Collectors window, you can delete a database Collector. Troubleshooting Collector Problems Collectors that have not been configured correctly, or that cannot connect to the database for any reason, will show an error on the Infrastructure, Databases, and individual database dashboards. Hovering over the error icon displays the potential reason for the error. If your Collector isn't reporting any metrics after a few minutes, and you know the database is up and running with activity, check the Events window. Agent Diagnostic Events can appear if the password is incorrect or communication errors have occurred. The message summaries on the Copyright AppDynamics 2012-2015 Page 35
Events window can help you diagnose and troubleshoot Collector problems. Check the collector configuration to ensure all the values you entered are correct. Ensure that your Database Agent has network connection to the databases you want to monitor. Monitor Databases and Database Servers Related pages: AppDynamics for Databases Architecture Database Monitoring Configure Roles Watch the video: Quick Overview: Database Monitoring Dashboards and Metrics The topics in this section show you how to use the features of AppDynamics to monitor and troubleshoot your database environments. Access Database Monitoring View Overall Database and Server Performance Discover Normal Database and Server Activity Configure Problem Detection Notifications Monitor Database Performance Monitor Database Server Hardware For roles and permissions required to view Database Monitoring windows, see Configure Roles. Access Database Monitoring Related pages: Monitor Database Performance You can access Database Monitoring either from the AppDynamics Home page or when associated with an application database, you can link to the Database Monitoring database instance Dashboard by right-clicking the database on the Application Flow Map, Tier Flow Map or Node Flow Map. Copyright AppDynamics 2012-2015 Page 36
The AppDynamics Database Monitoring section in the Application Database Dashboard displays which database collector is associated with the database. To change this association, click Configure mapping and choose another database collector. View Overall Database and Server Performance On this page: Database Monitoring Window Databases Window Database Dashboard Database Live View Related pages: Access Database Monitoring Copyright AppDynamics 2012-2015 Page 37
Database Monitoring provides several overall views of your databases that show key performance indicators. On these database views, the server health or status indicates whether critieria has been met for normal, warning or critical health rules. The green check mark indicates that the database is operating within normal conditions, the red exclamation mark indicates that at least one critical health rule has been violated. Database Monitoring Window From a glance at the main Database Monitoring window, you can see the overall performance of your databases and if there are any critical issues with them. The Datababases indicator shows if criteria have been met for normal, warning, or critical health rules for any of the databases. The Load graph provides insight into the total number of calls monitored over all your database collectors. Databases Window The Databases view shows all your collectors and key performance indicators. Errors display prominently so you can focus on troublesome areas. Two views are provided for your convenience that can be sorted by Name, Load or Time in database. Databases Card View Server health appears next to the database name. Errors display prominently so you can focus on troublesome areas. The Databases Card view show database queries, time in database, and if you have hardware monitoring enabled it also shows the percentage of CPU capacity consumed by the database. Copyright AppDynamics 2012-2015 Page 38
Databases List View If you are monitoring many databases, the list view can get you to the databases you want to see quickly. Database Dashboard Individual database dashboards provide more performance indicators and subtabs that allow you to dive deeper into database performance metrics. Copyright AppDynamics 2012-2015 Page 39
Database Live View The database Live View shows you current activity on your database, including SQL wait states and a list of sessions. If you have Hardware Monitoring enabled for the database server, you will also see CPU Usage and Memory Usage graphs. Copyright AppDynamics 2012-2015 Page 40
Discover Normal Database and Server Activity On this page: View Performance Metrics on the Metrics Browser Related pages: Detect Anomalies Using Dynamic Baselines Configure Baselines Health Rules AppDynamics Database Monitoring automatically learns to detect performance anomalies using baselines that are specific to your database and database server environments. AppDynamics creates baselines by collecting metrics from your monitored databases and servers over defined periods of time. This establishes what is normal for your environment. You can also create your own baselines. View Performance Metrics on the Metrics Browser On the Metric Browser for Database Monitoring, you can visualize performance metrics and see how they deviate from expected behaviors established by the baseline. Copyright AppDynamics 2012-2015 Page 41
Configure Problem Detection Notifications Related pages: Alert and Respond Policies Health Rules Actions Email Digests Getting Started Wizard for Alerts You can configure AppDynamics Database Monitoring to alert you when certain conditions are met or exceeded for monitored databases, operating systems, and server hardware. The Getting Started Wizard can help you through the process if you're new to using AppDynamics Pro. Alternatively you can create alerting policies manually if you are already familiar with the process. You configure Health Rules, Actions, Policies, and Email Digests for monitoring databases almost exactly the same as you would configure these for monitored applications. The Database Health Rule is applied to a specific database instance being monitored and is based on metrics you select. The Health Rule is violated when specified critical or warning conditions are met for that database. Database Policy Actions are limited to email or SMS message notifications and custom actions that have been uploaded to the Controller. Once you have defined Health Rules and Actions you can create a Policy based on a Health Rule to send you an email or an SMS message when a Health rule is violated. Copyright AppDynamics 2012-2015 Page 42
Monitor Database Performance Related pages: Access Database Monitoring Monitor Databases and Database Servers The subtabs for each database provides the most detailed information about your database. This section provides descriptions of the various windows for the database instance and how to interpret the information that displays. From most of these subtabs you can drill down to the Queries view. Database Dashboard Database Live View Database Queries Database Clients Database Sessions Database Object Browser Database Reports Database Dashboard Related pages: Access Database Monitoring View Overall Database and Server Performance Discover Normal Database and Server Activity Configure Problem Detection Notifications Monitor Database Performance The dashboard for each individual database provides the most detailed information about your database. Copyright AppDynamics 2012-2015 Page 43
Server Health: Server Health at the top of this window indicates the extent to which health rules are being violated: Green - Healthy server Yellow/orange - server with warning-level violations Red - server with critical-level violations Load: At a glance you can see the total number of calls during the specified time period and the number of calls for any point in time. The number of calls to the database directly correlates with database performance; the more calls there are, the longer it takes to respond to each call. SQL wait states: Activities that contribute to the time it takes the database to service the request. The wait states consuming the most time may point to performance bottlenecks. For example, a db file sequential read wait state may be caused by segment header contention on indexes or by disk contention. Copyright AppDynamics 2012-2015 Page 44
Number of connections: This graph shows the number of database client connections at any point in time. If you see a "Too many connections" error when your application tries to access the database it means that all available connections are in use by database clients. The maximum number of connections is a variable set in the database. For example, for the MySQL database, th e number of connections allowed is controlled by the max_connections system variable. Its default value is 100. The number of connections shown here may indicate that you need to support more connections and you should set a larger value for this variable. Time spent in Database: The total time spent executing SQL statements during the specified time period. CPU: For the specified time period, the chart shows the percentage of available CPU resources consumed by users and the system, and the percentage of time the CPU was idle. High CPU may indicate the more CPU resources are required or that your system is running at its maximum level and for example, may need to be upgraded with a more powerful processor. Memory: Shows memory usage. If memory usage is too high then you may need to add more memory to your system. For example, if you see high memory usage and wait states because sorts have been performed on disk because there isn't enough memory, then the lack of memory is likely degrading application performance and needs to be addressed. Disk I/O: Measures disk performance and compares performance with the specified default baseline. High disk I/O may mean that you need faster disks or that sorts are being performed on disk because your system doesn't have enough memory. Monitoring Disk I/O can tell you if you have an I/O bottleneck and if your disks are adversely affecting application performance. When you see a disk I/O bottleneck you may need to tune the application that is using the most I/O and cache more of its data in memory instead. You may also improve disk I/O by adding an index. Examining disk I/O before and after you make changes to your applications can help you determine whether the changes have been effective in resolving any database I/O bottlenecks you are experiencing. Network I/O: Measure network performance and compares performance with the specified default baseline. High network I/O indicates that some database tasks may be waiting for network resources to be free until other database tasks are finished using them. You may want to reduce your network load by scheduling large data transfers to off-peak time or rewrite your application to reduce the number of times it accesses the remote host for one request. If Network I/O is always high but you don't see any performance problems in your application and utilization of other system resources such as CPU and memory are normal, then this value shouldn't concern you. Accessing Metric Brower To see more information about a specific metric, double click any point on the graph and the Metric Browser opens displaying that metric. You can then hover over a point on the graph in the Metric Browser for more information about the metric. This feature is available for all the graphs except the SQL wait states graph. Database Live View Related pages: Access Database Monitoring Database Monitoring Copyright AppDynamics 2012-2015 Page 45
Monitor Databases and Database Servers Monitor Database Performance The live view displays current activity for the database server. The live view shows key performance metrics for the last time period, which can be refreshed in a specified time interval between 10 seconds and 5 minutes. CPU Usage: If you have enabled Hardware Monitoring for the server the chart shows the percentage of available CPU resources consumed by users and the system and a break down of how the CPU is being used. IO: Disk input and output. System: Database operating system activities. User: User interaction with the database. SQL wait states: As described for the database instance dashboard. Session List: A table describing database usage instances and their properties. The database session is the application interaction with the database, a new session is started for each request. The columns displayed are database dependent. Memory Usage: Displays how much memory is in use and how much is available. : SQL wait states Activities that contribute to the time it takes the database to service the request. The wait states consuming the most time may point to performance bottlenecks. For example, db file sequential reads may be caused by segment header contention on indexes or by disk contention. Copyright AppDynamics 2012-2015 Page 46
Database Queries Related pages: Access Database Monitoring Required Database Permissions Database Monitoring Monitor Databases and Database Servers Monitor Database Performance The Database instance Queries window displays the top 10 SQL statements. These are the statements that consume the most CPU time in the database. Comparing the query weights to other metrics such as SQL wait times may point you to SQL that requires tuning. Once you have identified the statements that are consuming the most resources, you can dig down deeper for details that can help you tune the SQL statement. For indepth query details, click a SQL statement and then click View Query Details. Copyright AppDynamics 2012-2015 Page 47
To see how the SQL was executed internally within the database, click the Execution Plan tab. T he statement execution plan is the sequence of operations the database performs to run the statement. Oracle Explain Plan Limitations For Oracle, AppDynamics Database Monitoring displays execution plans for only SELECT, UPDATE, INSERT, and DELETE statements because Database Monitoring relies on the O racle EXPLAIN PLAN statement to obtain the execution plans and the Oracle EXPLAIN PLAN statement only provides the Oracle optimizer's execution plans for SELECT, UPDATE, INSERT, and DELETE statements. See also, Required Oracle Database Permissions. Copyright AppDynamics 2012-2015 Page 48
If you have a poorly performing piece of SQL that you are trying to tune, the obvious place to start it to look at the most costly step of the execution plan. Tuning SQL is of course a vast topic, but a couple of things to look out for include: Index or table scans: May indicate a need for better or additional indexes. Bookmark Lookups: Consider changing the current clustered index, using a covering index and limiting the number of columns in the SELECT statement. Filter: Remove any functions in the WHERE clause, don't include views in your Transact-SQL code, may need additional indexes. Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? Database Clients Related pages: Access Database Monitoring Database Queries Copyright AppDynamics 2012-2015 Page 49
Database Monitoring Monitor Databases and Database Servers Monitor Database Performance The database Clients window shows you the IP addresses of the Top N clients using the database. A database client is any application that accesses the database. To see the Top N SQL run by the client, click a Client IP address and then click View Top Queries. From the Client top queries page, to see more details about a query you can double-click a query to open the Query Details window Database Sessions Related pages: Access Database Monitoring Database Monitoring Monitor Databases and Database Servers Monitor Database Performance The database Sessions window shows you the Session ID of the Top N sessions using the database. A database session is an instance of database usage. When a client connects to the database, a session is created. When the query completes, the session ends. To see the Top N Copyright AppDynamics 2012-2015 Page 50
SQL run in the session, click a Session ID and then click View Top Queries. From the Client top queries page, to see more details about a query, double-click a query to open the Query Details wi ndow and from there see the Execution Plan of the query. Database Object Browser Related pages: Access Database Monitoring Database Monitoring Monitor Databases and Database Servers Monitor Database Performance When you detect a problem with database performance, you may be able to correct the problem by adding an index, refusing access to certain users, or creating a new index on a table. You can browse through the database objects to find ways to tune the database, including the indexes that are currently available on the various tables. The contents of the Database Object Browser are updated when you access them or click Refresh. Note: The objects available for browsing are database dependent. The following are some examples of browsable content. Copyright AppDynamics 2012-2015 Page 51
Database uptime and version for all platforms Users: who has access to the database for all platforms Supported for Oracle, MySQL Parameters: database initialization parameters Supported for Oracle Variables: system variables indicating how the database was configured. Current Statistics: the current value of statistics collected. The various statistics available are database dependent and are a superset of those shown in the Database Monitoring - Metric Browser page. System Waits: SQL waits experience by the database Copyright AppDynamics 2012-2015 Page 52
Database Objects: search for specific objects, and browse through database schemas, tables, columns and indices. Search Database Reports On this page: I/O Report Time Series Comparison Report Top Activity Report Top SQL Report Wait State Report Related pages: Access Database Monitoring Database Monitoring Monitor Databases and Database Servers Monitor Database Performance The following describes the reports available in Database Monitoring at Databases > database_n ame > Reports. The reports available depend on the database platform being monitored. The reports are listed in alphabetical order and indicate which database platforms support them. I/O Report Description: This report gives information on physical I/O performed by the database instance. Relevance: Your physical disk I/O may be affecting database performance. Poor response times may mean that you're doing too much physical I/O or that you're for example scanning tables or indexes when you should be doing seeks. Poor response times may also indicate that your SQL may need to be tuned or that the database tables are missing indexes. It may also mean that you need to adjust your I/O capacity. Platform: Microsoft SQL Server, Oracle Time Series Comparison Report Description: This report allows compares the performance of two databases during the same time period based on a specific statistic type. Relevance: You may want to compare the performance of your development and production databases before and after you tune the SQL queries or add an index or join. This report can help you determine the effectiveness of any performance tuning procedures you have implemented. Copyright AppDynamics 2012-2015 Page 53
Platform: IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Sybase IQ Top Activity Report Description: Display the top time in database SQL statements in a time-series view. This report also displays data in a table and highlights the time spent in the database for each of 10 top SQL statements. Relevance: Use this report to see which SQL statements are using the most database time. This helps to determine the impact of specific SQL statements on overall system performance allowing you to focus your tuning efforts on the statements that have the most impact on database performance. Platform: IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Sybase IQ Top SQL Report Description: This report displays the top 10 SQL statements for the specified statistic in a time-series view. Relevance: Use this report to see which SQL statements are using the most database resources. This helps to determine the impact of specific SQL statements on overall system performance allowing you to focus your tuning efforts on the statements that have the most impact on database performance. Platform: IBM DB2, Microsoft SQL Server, Oracle Wait State Report Description: This report displays time-series data on Wait Events (states) within the database. Ea ch distinct wait is color-coded, and the Y-axis displays time in seconds. This report also displays data in a table and highlights the time spent in each wait state for each SQL statement. Relevance: The wait states consuming the most time may point to performance bottlenecks. For example, db file sequential reads may be caused by segment header contention on indexes or by disk contention. Platform: IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Sybase IQ Monitor Database Server Hardware On this page: Hardware Metrics Comparing Server and Database Metrics Related pages: Metric Browser Watch the video: Copyright AppDynamics 2012-2015 Page 54
Hardware Metrics When a Database Collector has also been configured to monitor the database hardware, AppDynamics gathers information about the operating system and machine hosting the database. The following metrics are collected: CPU: This trend displays CPU usage percentage over time. Memory: This graph displays memory used over time. Disk I/O: This graph displays disk input and output for data in kb over time. Network I/O: This graph displays network input and output in kb/sec over time. You can click anywhere on the graphs to get details about activity at that point in time. Metrics are collected by the agent and reported once a minute. Double-clicking on KPI points in the graph displays the Metric Browser showing the selected metric. Comparing Server and Database Metrics You can view and compare hardware and database metrics in the Metric Browser. This can help you visualize the effect of server performance on database performance. Copyright AppDynamics 2012-2015 Page 55
Administer AppDynamics Database Monitoring Related pages: Database Monitoring Database Monitoring Requirements and Supported Environments Install or Upgrade the Database Agent Controller Settings for Machine and Database Agents The following topics describe procedures and provide reference material relevant to a DBA or AppDynamics Pro Administrator. Adding Database Instance Licenses Database Agent Events Reference Database Agent FAQ Adding Database Instance Licenses On this page: Add New Licenses Transfer a License between Database Instances Related pages: Configure Database Collectors License Information Copyright AppDynamics 2012-2015 Page 56
The Controller requires a license for the total number of database instances to monitor concurrently. The AppDynamics Controller supports one Database Agent only and can monitor 100 + database instances. Add New Licenses 1. 2. Obtain a license.lic file with your existing AppDynamics licenses plus the new licenses from AppDynamics support. Put the license file in the Controller home directory. The Controller may take a few minutes to detect the new license. Restart the Controller to force immediate license detection. Settings -> License displays license information. Scroll to the bottom of the license window to see the number of concurrent database instance licenses. The APM, Database, and Server Monitoring sections show the number of database licenses currently consumed. Transfer a License between Database Instances To transfer a license to another database instance, remove the collector for one database instance and then add a new collector. Database Agent Events Reference On this page: Agent Diagnostic Events JDBC Driver-related Agent Diagnostic Events Related pages: Monitor Events Events Reference You can see Database Agent events on the Database Monitoring > Events window and in the <agent_home>/logs/db-agent#.log files. Database Agent events are of type Agent Diagnostic Event, with case-specific messages attached. Agent Diagnostic Events Initialize/re-initialize the DB collector Summary: Initialize/re-initialize the DB collector Copyright AppDynamics 2012-2015 Page 57
Description: Sent when database collector has successfully started. This happens when you configure a new collector, start/restart the agent process (in which case you'll see this event once for each collector), or when the collector recovers from a failure to communicate with the monitored database (for example, when the database goes down for a while, then comes back). Severity: Info Initialize/re-intialize the hardware metric collector Summary: Initialize/re-intialize the hardware metric collector Description: Same as the above, but refers to a hardware collector, not a database collector. This is sent when hardware collector has successfully started. This happens when you configure a new collector, start/restart the agent process (in which case you'll see this event once for each collector), or when the collector recovers from a failure to communicate with the monitored hardware (for example, when the system goes down for a while, then comes back). Severity: Info Server parameter [?] has been changed from [?] to [?] Summary: Server parameter [?] has been changed from [?] to [?] Description: The Database Agent constantly monitors database configuration parameters. When a parameter changes, which generally means a database administrator made a deliberate change, the agent sends this event. AppDynamics Database Monitoring users can use these events to track configuration changes in their databases. Severity: Info JDBC Driver-related Agent Diagnostic Events Summary: The text of the message is the error from the vendor's JDBC driver. Description: When the agent fails to collect data from a monitored database, it sends this event, and goes into sleep mode for one minute. It will then retry contacting the database every minute, until it succeeds. Once it succeeds, it will send an Agent Event "initialize/re-initialize" message, as described above. This happens when the database goes down, or when you add a collector with a wrong password, or wrong hostname, etc. When the Collector is in sleep mode because of an error, you'll see a indicator next to the database on the Infrastructure and Infrastructure > Databases, on Configure > Collectors window. You will also see the full text of the error in the Infrastructure > Events window. Severity: Error Database Agent FAQ On this page: Shut Down the Database Agent Identify the Database Agent Process Reset a Database Agent Copyright AppDynamics 2012-2015 Page 58
Metric Values for Disk and Network are Zero Server Health Indicator and the Database Agent Resolve Metric Reporter Type Mismatch Problem Shut Down the Database Agent If the Database Agent process is running in the background, you can stop it by simply entering the kill command with the process ID as the argument. If it is running in the foreground in a console, you can press Ctrl+C to shut down the agent. Note that the Database Agent implements a shutdown hook, so issuing the kill command (or Ctrl+C) from the operating system causes the the agent to perform a graceful shut down. Identify the Database Agent Process For Linux Use the following command to identify which process is running the Database Agent. ps -ef grep db-agent For Windows Process Explorer is a free application from Microsoft that can help you identify the Database Agent process. When there are multiple java processes running, hover over a java process in Process Explorer to identify the process that was started using the db-agent.jar file. Reset a Database Agent 1. 2. Using an Administrator account, login to the Controller UI, click Settings > Agents > Databases tab and select a Database Agent. Click Reset Selected Database Agent. The reset operation purges all existing data for an agent and starts gathering them again. It stops the agent and starts it again. Metric Values for Disk and Network are Zero This situation may occur when a 32-bit JRE is used with 64-bit operating system. To solve this problem, use a 64-bit JRE with the 64-bit operating system. Server Health Indicator and the Database Agent Metrics monitored by the agent are included in the infrastructure health indicator in the dashboards. The health indicator is driven by health rule violations in the given time period and health rule violations are configured on hardware metrics collected by the Database Agent. Health rules for all possible metrics are not pre configured out-of-the-box. To configure additional health rules, see Co nfigure Health Rules. Copyright AppDynamics 2012-2015 Page 59
Resolve Metric Reporter Type Mismatch Problem Switch from the Java Hardware Monitor to the Hardware Monitor if you see messages similar to the following in the logs: [Worker-7] 12 Sep 2014 07:27:49,449 WARN MonitorOutputHandler - Metric Reporter type mismatch for metric [Hardware Resources Network Incoming packets/sec] com.singularity.ee.agent.commonservices.metricgeneration.metrics.metricreportert ypemismatchexception: Aggregator of OBSERVATION already exists for metric Metric Identifier[Hardware Resources Network Incoming packets/sec] ID[0] Copyright AppDynamics 2012-2015 Page 60