Database Monitoring
AppDynamics Pro Documentation
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 Monitoring
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.
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 offering to a more tightly-integrated
standalone AppDynamics for Databases server
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.
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.
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.
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:
Start the Controller Events Service
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
For information on additional hardware requirements for the AppDynamics Controller to support Database Monitoring, see AppDynamics Pro, Controller System Requirements.
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".
Start the Controller Events Service
The Database Agent requires the Controller Events Service, which must be started before starting the agent.
1.
2.
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).
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.
Using SQL Server Management Studio, create a new login for the AppDynamics SQL Server Database Collector.
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 in the SQL Server documentation.
2.
3.
From the User Mapping tab, map the new user to the master and msdb databases.
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.
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 >
Viewing Object Information
To view object information on the Database > Objects Browser, map the monitoring user to the databases of interest.
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.
for sys.sysaltfiles and then give select permissions on the object to the Public role.
Properties
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
"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).
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
schema user. You can create this plan table with the following command from sqlplus Monitoring
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
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 There are three ways to authenticate the Database Collector to access the system information.
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.
1. 2. 3. 4. 5. 1.
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 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.
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."
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
. Click .
Control 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
, the following are also required when the Database Agent is hosted on AIX, Linux or
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
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.
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 , you must use a command similar to following to start the Database Agent; database instance
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
1. 2.
3.
4.
configure the named Windows account as follows:
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 , and then click for both Access Permissions and Launch and
> COM Security Edit Limits
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 , give Remote Launch and Remote Activation privileges to
Management Instrumentation
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
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.
1. 2. 3. 4. a. b. c. 5.
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.>
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 .>
Enter the following on the command line:
Linux:
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.
Configure how the agent connects to the Controller, using the Controller Host and Con
properties.
troller Port
Optional. Configure agent to use SSL, using the Controller SSL Enabled property. (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
5.
6. 7.
8.
9.
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.
Launch the Database Agent using the required system properties.
: The following assumes that all the necessary
For one Database Agent per Controller
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 -jar <agent_home>/db-agent.jar
.uniqueHostId=<unique_host_ID>
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.
Linux
From the command line, enter:
java -Dappdynamics.agent.uniqueHostId=<unique_host_ID> -jar <agent_home>/db-agent.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.
: If the agent you're installing is not the sole
For multiple Database Agents per Controller
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,
Start the Controller Events Service
Before you start the Database Agent, you must start the Controller Events Service.
Linux: <controller_home>/bin/controller.sh start-events-service Windows: <controller_home>\bin\controller.bat start-events-service
Windows Users - Don't close the command shell window
When you close the command shell window the agent shuts down. See Installing the
to run the agent in the background.
9.
1.
2.
3.
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
-Ddbagent.name="Scarborough Network Database Agent\auth\x64"
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
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
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.
3. 1. 2. 3. 4. 5. 6.
(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
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:
Agent properties related to naming agents or designating them as backup
New in 4.0.4
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
: Uniquely identifies the machine running the Database Agent.
Description
The value of this property must be different for every Database Agent in your environment. -Dappdynamics.agent.uniqueHostId=<unique_host_ID>
System Property:
ASCII string, including spaces. agent_name
Type: If < > contains spaces, you must enclose the
N/A
Default:
: Required.
Required
: -Dappdynamics.agent.uniqueHostId="Scarborough Server Agent One"
Example
Path to the Java Library
: Provides the absolute path to sqlijdbc_auth.dll.
Description
-D
System Property: java.library.path
Value:
For 64-bit systems: <agent_home>\auth\x64 For 32-bit systems: <agent_home>\auth\x64 ASCII string, including spaces. agent_name
Type: If < > contains spaces, you must enclose the
entire name in double quotes (" ").
: Recommended for Unix and . Required for SQL Server Windows Authentication on
Required
Windows 64-bit systems.
: -Djava.library.path="D:\AppDynamics\Database
Example Agent\auth\x64"
Path to the Agent jar File
: Provides the absolute path to sqlijdbc_auth.dll.
Description
-jar
System Property:
Value: <agent_home>db-agent-jar
ASCII string, including spaces. agent_name
Type: If < > contains spaces, you must enclose the
entire name in double quotes (" "). : Yes
Required
: -jar="D:\AppDynamics\Database
Example Agent\db-agent.jar"
Agent-Controller Communication Properties Controller Host Property
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
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
The following properties are useful or necessary when you are configuring your
New in 4.0.4
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
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
Specifies the name of the Database Agent you want the agent to backup. You can
Description:
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
system property.
Property
- .backup.for=<agent_name>
System Property: Ddbagent.is
ASCII string, including spaces.
Type: If <agent_name> contains spaces, you must enclose the entire name in double quotes (" ").
N/A
Default:
: Only if you want the agent to backup another agent.
Required
:
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
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.
1. 2.
3.
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
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
. The tool creates a Windows service that
Resource Kit for Windows 2003 Server SRVANY.EXE
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/
. The required utilities are included in this resource kit
download/details.aspx?id=17657
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
3. i. a. b. c. 4.
name in all three files.
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.
in the sample attached.
AppDynamics Database Agent Service
Application is the path to the JDK you use for Database Agent.
<agent_home> in the sample attached.
\\jre7\\bin\\java.exe
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
java -Djava.library.path="<agent_home>\auth\x64"
-Dappdynamics.agent.uniqueHostId=<unique_host_ID> -Xms32m -jar "<agent_home>\db-agent.jar"
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: in the sample
sc create "AppDynamics Database Agent Service"
attached.
Specify binPath as the path to the SRVANY.EXE Windows Resource d:\AppDynamics\DatabaseAgent\srvany.exe in the sample above
Customize UninstallDBService.cmd
For 64-bit systems, allocating 32 MB of initial heap size
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.
a.
@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
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.
1.
2.
3.
4.
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
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
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 "db-" with the name of your file or symbolic link:
agent
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:
4. 1. 2. 3. 4. 5. 6. 7. 8. 9.
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
Create a batch file containing the following line:
java -Djava.library.path="<agent_home>\auth\x64"
-Dappdynamics.agent.uniqueHostId=<unique_host_ID> -Xms32m -jar <agent_home>\db-agent.jar
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:
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
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.
: From the list, select the database type the Collector will monitor. Database Type
: From the list, select the Database Agent that manages the collector. If you only Database Agent
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.
:
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 field as described above.
base
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.
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
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.
View Overall Database and Server Performance
On this page:
Database Monitoring Window Databases Window
Database Dashboard Database Live View Related pages:
Access Database Monitoring
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.
