Printed Documentation
Table Of Contents
Welcome to AdventNet Micro Agent for MySQL™ 2
Quick Tour 3
About Micro Agent for MySQL 4
Architecture of Micro Agent for MySQL 6
Contacting AdventNet 7
Other AdventNet Products 9
Installation Guide 11
System Requirements 12
Service Pack Process 13
Release Features 17
Working with Micro Agent for MySQL 18
Deploying the Micro Agent 19
Testing the Micro Agent 23
Testing through HTTP 24
Testing through SNMP 26
MIB Browser Operations 27
SNMP Table Operations 30
SNMP Trap Viewer 32
SNMP V3 35
SNMP Configurations 38
Managing the MySQL Server 43
MySQL Details 44
Performance 45
Queries 47
Users 49
Configurations 51
Database and Table 54
Errors 56
Notification 57
Runtime Rules 58
Integrating with HP OpenView 61
Troubleshooting 63
Known Issues and Limitations 64
Welcome to AdventNet Micro Agent for MySQL™
AdventNet Micro Agent for MySQL offers an easily deployable agent to monitor and manage the MySQL database through HTTP and SNMP consoles. It leverages an in-depth MySQL performance monitoring by providing real-time statistics and availability of the MySQL server. It also helps in fine-tuning the MySQL database applications as well as monitoring the error logs and the usage of memory and CPU.
Micro Agent for MySQL supports various OSs, such as Windows, Linux, and Solaris. It also provides support for remote deployment of the agent.
The following are the various sections that are covered in the product documentation. Please choose the section, based on your requirement, to learn more.
|Quick Tour section gives an overview about AdventNet Micro Agent for MySQL, its architecture, and the technologies on which it is built.|
|Further, it provides the contact information and various other products of AdventNet. |
|Release Features lists the various features available with the current release of the product. |
|Installation Guide guides you on how to install the service packs of the product and also gives the system requirements. |
|Working with Micro Agent for MySQL elaborates the features of Micro Agent for MySQL and also explains the management features provided |
|with the agent. |
|Troubleshooting lists down the various troubleshooting tips for the problems encountered while using AdventNet Micro Agent for MySQL. |
|Known Issues and Limitations lists out all the known issues and limitations of AdventNet Micro Agent for MySQL. |
*MySQL is a trademark of MySQL AB
Quick Tour
About Micro Agent for MySQL lists the various features of the product, which make it the most comprehensive product to manage the MySQL server.
Micro Agent for MySQL Architecture explains the architecture of Micro Agent for MySQL with appropriate block diagrams.
Contacting AdventNet chapter contains contact information details about our sales and support teams.
Other AdventNet Products lists the comprehensive range of network management products and tools of AdventNet.
About Micro Agent for MySQL
[pic]
• Overview
• Need for MySQL Agent
• MySQL Management Using AdventNet Micro Agent for MySQL
• Value Proposition of AdventNet Micro Agent for MySQL
• Key Features
[pic]
Overview
AdventNet Micro Agent for MySQL helps the MySQL users to maximize their system availability and overall performance. AdventNet's primary goal is to bring enterprise-level availability and performance to the growing number of customers using MySQL database to run their mission-critical applications.
AdventNet's Micro Agent for MySQL supports various platforms, such as Windows, Linux, and Solaris. It exposes the MySQL server information through HTTP and SNMP, the two widely used protocols. Micro Agent for MySQL comes with a predefined MIB, called ADVENTNET-MYSQL-MIB to enable SNMP manageability for the various MySQL server parameters. A user-friendly Web console and an SNMP manager tool (MIB Browser) are also bundled with the product for testing the deployed agent, thus providing a complete off-the-shelf user experience.
Need for MySQL Agent
Keeping databases highly available is key for any modern organization, because minutes of downtime can be extremely costly in terms of revenue and productivity. It is also very essential for the MySQL users to monitor the health of the MySQL database. Agent for MySQL works to keep the users informed about critical MySQL server details, so that they can ensure business without interruption.
MySQL Management Using AdventNet Micro Agent for MySQL
AdventNet provides a proven solution for MySQL users to monitor and manage the MySQL server by providing Micro Agent which exposes the MySQL database through both HTTP and SNMP consoles. It comes with a command line tool that helps the users to easily deploy the agent in the MySQL server. Both remote and local deployment of the agent is possible using this tool.
Value Proposition of AdventNet Micro Agent for MySQL Users
The value proposition offered by AdventNet Micro Agent for MySQL users is as follows:
• Out-of-the-box agent for a comprehensive management of the MySQL server.
• Timely alerts on critical situations of the MySQL server.
• Easy integration with Standard SNMP consoles, such as HP OpenView, IBM Tivoli etc.
Key Features
The key features of AdventNet Micro Agent for MySQL are listed below:
• Comprehensive fault and performance management of MySQL 3.23.x and 4.0.x
• Exhaustive monitoring of the various MySQL parameters, such as Queries, Configurations, Log files, Users, and User details
• Preconfigured notifications and e-mails for fault management
• Runtime rule configuration to emit notifications and send e-mails on exceeding thresholds
• Command line utility for agent deployment in multi-platforms
• Facilitates management through HTTP and SNMP consoles
• User-friendly Web console for database monitoring
• SNMP Manager tool (MIB Browser) for testing the agent through SNMP
• SNMP v3 support
• Supports various platforms, such as Windows, Linux, and Solaris
Architecture of Micro Agent for MySQL
[pic]
• Overview
• The Micro Agent
• The AdventNet Shared Object/Dll
[pic]
Overview
AdventNet Micro Agent for MySQL facilitates an efficient management of the MySQL server through HTTP and SNMP consoles. The architecture of the agent is illustrated with the architecture image provided below.
[pic]
The Micro Agent
The above image clearly depicts how the MySQL agent bridges between the MySQL server and the remote managers. The agent gathers all the information of the MySQL server, such as MySQL Databases, Tables, Performance details, MySQL Queries, Users, Logs, etc. and exposes them through HTTP and various SNMP managers, such as HP OpenView, IBM Tivoli, etc. In addition to the above, it emits notifications to the managers when a critical situation is encountered in the server.
The AdventNet Shared Object/DLL
The AdventNet shared object (for Linux/Solaris) or DLL (for Windows) retrieves the log information and other minute details of the MySQL server. The agent uses the SO/DLL for in-depth monitoring of the MySQL server. Installing the SO/DLL is not mandatory. It is left to your option to deploy the SO/DLL. The following are the parameters exposed through the SO/DLL:
• CPU usage of the MySQL server.
• Memory usage of the MySQL server.
• Database details, such as the space occupied by the database.
• Operations on log information, such as updating the Slow Query table, the Update Query table, the General Query table, and the Error table.
Contacting AdventNet
[pic]
• Technical Support
• Feedback
• Sales
[pic]
AdventNet, the Internet Management Infrastructure Company is the market leader in providing open, scalable, extensible, and cross-platform management solutions for managing the Internet and e-commerce infrastructure. In addition to that it provides affordable software for management and provisioning of complex networks, systems, and IT applications. AdventNet's solutions range in scope from optical and core Internet working management systems, cable modem, DSL, storage, security management to E-commerce application management. In each of these fast-growing markets, AdventNet is the leading provider of technology. With a broad product portfolio and an active customer base ranging from enterprises, equipment vendors to service providers, AdventNet has emerged as a company that provides affordable and high-quality alternatives to the other expensive software that are common in this industry.
AdventNet is always eager to hear its customer's comments, feedbacks, and suggestions, which help improving the products and hence we give you the contact information of our sales and support teams. Our development experts provide the best support and specialize in resolving the most complex problems encountered by various organizations.
Technical Support
For support and bug report, please send e-mails to agent-support@. For those with support contracts, AdventNet provides priority support via e-mail with a reply usually provided within 24 hours.
Please provide the following information while sending support mails:
• Release version of the product
• Operating system and version
• Log messages (MYSQL_AGENT.log, agent.log under /data directory)
• Debug messages or hex dumps, if any
• JDK version, if applicable
• Stack traces, if any
• CLASSPATH environment variable, if applicable
• Name and version (with SP version) of the MySQL server
and any other information. This will help us provide faster responses to your queries.
During the evaluation phase, AdventNet provides the support free of cost. This support includes e-mail access to our product specialists for problem resolution, clarifications in documentation, and technical guidance. Feel free to send your queries to us. We promise to respond as quickly as possible to make your evaluation a success.
Feedback
We welcome your feedback that will help us improve the APIs and provide future enhancements.
Send your feedback to agent-support@
Sales
For sales and product licensing inquiries, please use the contact information available in the following URL or you can send e-mail to sales@:
You can also call the AdventNet headquarters at the following numbers:
Phone: +1-925-924-9500 and ask for sales
Fax: +1-925-924-9600
Other AdventNet Products
AdventNet, the Internet Management Solutions Company™ is the leading provider of open, scalable, extensible, and cross-platform management solutions for managing the Internet and e-commerce infrastructure. AdventNet's solutions range in scope from optical and core Internetworking Management Systems, Cable Modem, DSL, Storage, Security Management to E-Commerce application management. In each of these fast-growing markets, AdventNet is the leading provider of technology.
AdventNet Solutions For Enterprises
|Managing JBoss Application Server and User-Defined MBeans through SNMP |
|AdventNet SNMP Adaptor for JMX: provides an out-of-the-box SNMP Agent for monitoring the JBoss application server. It also caters to the|
|needs of the JMX developers who want standards-based management for their MBeans through SNMP. AdventNet SNMP Adaptor for JMX can |
|seamlessly integrate with enterprise consoles, such as HP OpenView, Tivoli, CA Unicenter, etc. thus providing quick integration of JMX |
|applications with existing management solutions. |
|Managing J2EE and EAI Middleware Application |
|AdventNet ManageEngine JMX Studio: It is a unique product, focused on the J2EE and EAI middleware application development community. |
|This empowers the developers to expose business and application specific management information through standard management |
|technologies, such as JMX and SNMP. |
|Managing J2EE Applications |
|AdventNet ManageEngine Applications Manager: It provides a best-of-breed solution to manage WebLogic and WebSphere application servers |
|efficiently in any real-time business environment. This product is primarily aimed at catering to the needs of managing WebLogic and |
|WebSphere servers across different deployment scenario. It has the flexibility to manage single or large deployment of |
|WebLogic/WebSphere-based applications. It uses a client-server architecture with superior fault and performance management capabilities |
|for managing the WebLogic and WebSphere Application server infrastructure and other associated software infrastructure, such as Web |
|servers, Databases, and so on. |
|Testing Java/J2EE Applications |
|AdventNet QEngine: It is a Web-based cross-platform, comprehensive, customizable, extensible, and uninterrupted automated testing |
|platform that enables testing of multi-tier management applications built on J2EE/J2SE technologies. It automates the functional testing|
|of your application where the valid, invalid, and inopportune behavior can be tested. As part of the support for performance testing, |
|AdventNet QEngine supports capability measurements, resident time and response time measurements, and resource usage monitoring. In |
|addition to the above, it also makes it possible to automate the stability, load, and regression testing of your multi-tier management |
|application. |
AdventNet Solutions for Telecom Industry
|Management APIs |
|AdventNet AgentToolkit (Java Edition): The AdventNet Agent Toolkit Java Edition is a rapid prototyping and development tool used for |
|building Java-based standalone SNMP and TL1 agents. It also supports building agents with multi-protocol access to common management |
|information through SNMP, RMI, HTTP, CORBA, and TL1. |
|AdventNet Agent Toolkit (C Edition): A rapid tool for making prototypes and a development tool for building SNMP, HTTP, and TL1 agents |
|in strict ANSI C language. The toolkit primarily focuses on system management and device management and hence the runtime agent is very |
|modular, portable, and customizable. The toolkit supports to provide multiple protocol (SNMP, HTTP, and TL1) access to common management|
|instrumentation, called MultiProtocol Agent. In addition to supporting MultiProtocol agent, it also supports Standalone SNMP and TL1 |
|agents |
|AdventNet SNMP API: It is the industry leading development environment for building cross-platform, Java and Web-based management |
|applications, applets and mediation frameworks. The product can be used to build system management, application management, and network |
|management applications and applets. It includes class libraries and Java Beans for Java SNMP development, as well as a complete MIB |
|Browser for interacting with SNMP-enabled devices. |
|AdventNet TL1 API: It comprises a set of Java libraries for developers seeking to leverage the power of Java TM and other Internet |
|technologies in quickly delivering Java and web-based solutions for managing TL1 devices. It provides a good base to build network |
|management products and solutions for TL1 device management. |
|AdventNet CLI API: It consists of Low level, High level, and Distributed APIs. The low level API consists of Java classes that implement|
|the core CLI functionality including the communication framework, which enables the user to access the CLI API. The high-level APIs make|
|it easier the development of network management applications using the CLI libraries, whereas the distributed functionality is carried |
|out by RMI API. |
|AdventNet Mediation Server: A multi-protocol mediation service for telecommunications network management applications. It is designed |
|for scalable multi-tier architectures, such as J2EE that form the basis for many OSSs and NMS products and solutions being built today. |
|It provides a common interface based on XML messaging to applications using the Mediation Server. |
|Simulating Networks and Systems |
|AdventNet Simulation Toolkit: It provides a comprehensive set of tools for creating a simulated environment consisting of networks, |
|systems, and applications. It not only supports setting up a simulated agent but also simulating an entire network on a Linux box. In |
|addition to it, it also provides a rich set of utilities which help in setting up a simulated network in a very short time. All the |
|real-time conditions can be simulated very easily using Simulation Toolkit. It provides an intuitive GUI for configuration and |
|comprehensive scripting capability in Java and JPython languages. |
|Other Utilities |
|AdventNet SNMP Utilities: Targeted toward the end users, it is a set of cross-platform applications and applets for SNMP and Web-based |
|network management. These utilities can be used for device, element, application, and system management. These tools can communicate and|
|interact with any SNMP enabled device. |
| |
|The following tools form a part of the product: |
|MibBrowser: Used to view and operate on data available through an SNMP agent in a managed device. |
|TrapBrowser: Used to parse and view the received traps. |
|V3 Agent Configuration tool: Tool for configuring USM user tables and VACM entries for SNMPV3 agent. |
|Proxy Forwarder: Used to translate SNMP V3 request for SNMP V1 and V2c agents. |
|WebServer and SAS Server: Facilitates in using SNMP management applets. |
|EMS, NMS, Provisioning, and OSS Systems |
|AdventNet Web NMS: It is an open, massively scalable, carrier-grade management infrastructure platform built for the Internet age. It |
|provides out-of-the-box application functions with tremendous flexibility to customize a variety of domain-specific needs. |
|AdventNet TMF, EMS and NMS: Based on Tele-Management Forum (TMF) standards, enable carriers to manage multi vendor/multi technology |
|devices through a common management system that integrates across a diverse set of devices. |
|AdventNet V5 Protocol Stack: It is a portable, ANSI C implementation of the ETSI and ITU-T switching and signaling protocol stack for V5|
|interfaces. |
|AdventNet V5 Monitor: It is a PC-based visual tool with a easy-to-use Java GUI for monitoring and analysing ITU-T/ETSI V5 interfaces |
|which is available for Linux and Windows OS. |
| AdventNet V5 LE Simulator: It is a PC-based tool which simulates a V5 Local Exchange to test any V5 AN implementation and is available |
|in both online and offline modes. |
Installation Guide
System Requirement explains the system and software requirements for installing and working with Micro Agent for MySQL.
Service Pack Process details the various procedure involved, such as installation and uninstallation of the service pack.
System Requirements
[pic]
• Hardware Requirements
• Software Requirements
[pic]
The following is the minimum hardware and software requirements for installing and using AdventNet Micro Agent for MySQL.
Hardware Requirements
The performance exhibited by AdventNet SNMP Adaptor for JMX will depend considerably on the CPU and memory of the installed system. The following is the suggested minimum configuration:
|Operating Platform |Processor Speed |Memory |Hard Drive Space |
|Windows |Minimum 266 MHz |Minimum 64 MB RAM |35 MB |
|Linux |Minimum 266 MHz |Minimum 64 MB RAM |35 MB |
|Solaris |Minimum 266 MHz |Minimum 64 MB RAM |35 MB |
Software Requirements
|Platforms |MySQL Version |Browsers |
|Windows NT4 |MySQL 3.23.x and MySQL 4.0.x series |Netscape 6.0 or later |
| | |Internet Explorer 5.0 or later |
| | |Mozilla 1.0 or later |
| | |Opera 7.1 or later |
|Windows 2000 | | |
|Windows XP | | |
|Linux 7.0 or later | | |
|Solaris 5.7 | | |
|Solaris 5.8 | | |
For Linux and Solaris systems, the MySQL client libraries must be installed to invoke the agent.
Service Pack Process
[pic]
• Overview
• Update Manager
• Installing Service Pack
• Uninstalling Service Pack
[pic]
Overview
A service pack is a collection of bug fixes and minor feature enhancements that can be applied in a single instance over the product. It is an efficient and easy process for maintaining and updating the product. Every service pack version is cumulative and contains the bug fixes of the previous version. During the installation of a service pack, the corresponding files are updated in the product installation directory. When a service pack is developed, all the customers are informed of the service pack and the fixes available in it.
Update Manager
Update Manager is a tool distributed with this application for installing the service pack. It can be accessed from the Launcher's Options menu. Update Manager provides a feature wherein the user can query the service pack file or a previous version. On doing this, the user can see the names of the files inside the service pack. It also gives the information of the current version of the service pack installed.
The main benefits of the Update Manager are
• To install AdventNet's service packs.
• To revert to previous versions.
• To view details of installed service packs.
• Uninstalling service pack.
Installing Service Pack
The steps involved in installing a service pack are given below:
1. Invoke UpdateManager.bat/sh from the /bin directory to launch AdventNet Update Manager.
2. Browse and select the service pack file in PPM format. Only compatible service pack files are allowed to be loaded. This step enables the Readme and "Install" buttons.
3. Click the Install button to install the service pack. The confirmation message informing that the service pack has been successfully installed is displayed.
[pic]
4. Close the screen. This will display the Update Manager main screen. The Uninstall and Details buttons will be enabled.
5. Click Exit to close the screen.
[pic]
Uninstalling Service Pack
The steps involved in uninstalling the service pack are detailed below:
1. Invoke UpdateManager.bat/sh to launch AdventNet Update Manager.
2. Select the service pack which you wish to uninstall and click Uninstall. This brings up the Uninstall screen.
3. Click Finish to complete the uninstallation process. After the successful uninstallation of the service pack, a message is displayed to indicate that.
4. Click Close.
[pic]
The product would be reverted to the selected version.
Release Features
The salient features of Micro Agent for MySQL are listed below:
• Out-of-the-box monitoring and management of the MySQL server
• Comprehensive monitoring of MySQL performance, queries, users, and the user details
• Ability to view the MySQL configuration details and the various log files, including error logs
• Management facilities through SNMP consoles, such as HP OpenView, IBM Tivoli, etc.
• User-friendly Web console for database monitoring
• Remote and local deployment support
• Preconfigured rules for fault and performance management
• Runtime rule configuration for emitting notifications
• Command line utility for agent deployment
• SNMP Manager tool (MIB Browser) for testing the agent through SNMP
• SNMP v3 support
• Support for various platforms, such as Windows, Linux, and Solaris
• Support for MySQL 3.23.x and 4.0.x series
Working with Micro Agent for MySQL
The following sections of this book guide you to deploy and test the MySQL agent and to know more about its comprehensive management features:
• Deploying the Micro Agent
• Testing the Micro Agent
• Managing the MySQL Server
• Performance
• Queries
• Users
• Configurations
• Table and Database
• Errors
• Notification
• Runtime Rules
• Integrating with HP OpenVIew
Deploying the Micro Agent
[pic]
• Overview
• Deploying in Linux/Solaris
• Deploying in Windows
• Manual Deployment
• Remote Agent Configurations
• Command Line Options
• Reinitializing the Agent
• Undeploying the Agent
[pic]
Overview
To manage the MySQL server using AdventNet Micro Agent for MySQL, you must first deploy the agent. The deployment of the agent can be done both locally and remotely. A command line utility is provided for deploying the agent. Remote deployment can be done with inter-operating systems also. The following are the combinations of operating systems supported to deploy the agent using the deployer. However manual deployment can be done for all the possible combinations of the OSs:
• Windows to Windows
• Windows to Linux
• Windows to Solaris
• Linux to Linux
• Linux to Solaris
Deployment can be classified into two categories, viz. deploying in Linux/Solaris and deploying in Windows. The categories mentioned above are discussed below.
Deploying in Linux/Solaris
Deploying in Unix involves deployment of the agent to the operating systems, such as Linux and Solaris. The following is the procedure to deploy the agent in a Linux or a Solaris machine:
1. Invoke the DeployUnixAgent.bat/sh file from /bin. This invokes the command line deployer.
2. Specify the host name of the machine to which the agent is to be deployed. Specify it as localhost for local deployment.
3. Specify the user name by which you want to log into the host machine (not applicable to local deployment).
4. Enter the password for the user name specified (not applicable to local deployment).
5. Enter the root password of the host machine if you want the AdventNet shared object to be loaded.
6. Specify the OS version of the host machine.
7. If you want to change the default port where the agent runs, you can edit the file DeployUnixAgent.bat/sh and change the port values, such as the agent port, Trap port number, Trap receiver port, etc. before invoking the file.
This deploys the agent in the host machine and starts the agent at the specified port successfully.
Deploying in Windows
To Deploy the agent in a Windows machine, follow the steps given below:
1. Invoke the DeployWindowsAgent.bat file from /bin. This invokes the command line deployer.
2. Specify the host name of the machine to which the agent is to be deployed. Specify it as localhost if it is local deployment.
3. Enter the user name (not applicable to local deployment).
4. Enter the password (not applicable to local deployment).
5. Specify the shared drive on the host machine. Specify the installation directory for local deployment.
6. If you want to change the default port where the agent runs, you can edit the file DeployWindowsAgent.bat (for local deployment) / winagent.bat under bin/scripts (for remote deployment) and modify the port values, such as the agent port, Trap port number, Trap receiver port, etc. before invoking the file.
This deploys the agent into the remote/local Windows machine and starts the agent at the specified port.
|[pic] |Note: |
| |Command line deployment in Windows is possible only from a Windows machine. |
| |Remote deployment in Windows is possible only if the machines are in the same domain |
Manual Deployment
You can also deploy the agent manually in addition to deploying it using the command line deployer. Given below are the steps to be followed to deploy the agent in Windows and Linux/Solaris machines:
For Windows
1. Copy the adventnetmma.dll file from /lib to the %WINDIR%\system directory of the host machine.
2. Execute the mysqlagent.exe file from the agent/bin directory.
This deploys the agent in the host machine and starts the agent at the default port.
For Linux/Solaris
1. Copy adventnetmma_linux.so (for Linux) / adventnetmma_solaris.so (for Solaris) under /lib to the /usr/lib directory of the respective host machine.
2. Copy adventnetmma_linux*_ext.so/adventnetmma_solaris*_ext.so under /lib to the /usr/lib directory of the respective host machine where " * " denotes the OS version of the host machine.
3. Rename the copied file adventnetmma_linux*_ext.so/adventnetmma_solaris*_ext.so as adventnetmma_linux_ext.so/adventnetmma_solaris_ext.so. This file is required for dynamic enabling/disabling of the log files. Do not copy this file for MySQL versions 4.0.x or later as it is not compatible.
4. Execute the file mysqlagent_linux/mysqlagent_solaris from agent/bin directory.
This deploys the agent in the host machine and starts the agent at the default port.
Remote Agent Configurations
AdventNet Micro Agent for MySQL also gives you a provision to manage the MySQL server on a machine with the agent deployed in a different machine. To do so, configure the agent by following the procedure given below:
1. Edit the adventnetmysqlagent.conf file present under the /agent/conf directory.
2. Specify the name of the remote host where the database server is running in the "databasehost" field. Do not provide this if the server is local.
3. Specify the user name in the "user" field to connect to the remote MySQL server. The user specified must have the privileges to connect to the remote database.
4. Enter the password to acknowledge the database connection in the "password" field.
5. Start the agent either manually or using the command line deployer (Discussed in the above paragraphs)
Command Line Options
You can also change the default values of the HTTP and SNMP ports, the Trap port number, the Trap receiver port number, etc. using our command line options. Given below are the command line usages:
Usage: [-u] [-d] [-v] [-t] [-si] [-sp] [-sr] [-hw]
• -u To display the help message.
• -d To specify the absolute path for the runtime agent.
• -v To specify the product version information.
• -si To view the agent IP address.
• -sp To change the SNMP port instead of default (8001).
• -st To change the trap port number instead of default (8002).
• -sr To change the trap receiver port number instead of default (8004).
• -hw To change the HTTP port number instead of default (8040).
Reinitializing the Agent
You can reinitialize the agent, if you do not want the previously stored data to persist in the agent database after restarting it. To do so, follow the steps below:
1. Run the ReinitializeAgent.bat/sh file from /bin. This invokes a command line tool.
2. Specify the name of the host machine where the agent is to be reinitialized.
3. Specify the port where the MySQL server is running.
4. Enter the MySQL user name on the host machine and the password for the same. This action reinitializes the agent and clears all the previously stored data in the agent database.
|[pic] |Note: You must not reinitialize the database when the agent is running. |
Undeploying the Agent
To undeploy the agent from the host machine, follow the procedure given below:
1. Stop the agent by clicking the Shutdown option on the top right corner of the HTTP browser.
2. Remove adventnetmma_linux.so and adventnetmma_linux_ext.so (for Linux) / adventnetmma_solaris.so and adventnetmma_solaris_ext.so (for Solaris) from the /usr/lib directory and adventnetmma.dll (for Windows) from the %WINDIR%\system directory of the respective host machines.
3. Remove the agent/bin directory from the host machine.
Testing the Micro Agent
Once the agent is deployed, the MySQL server can easily be monitored and managed both through HTTP and SNMP. This agent is compliant with any SNMP manager and hence you can easily integrate it with standard SNMP management consoles, such as HP OpenView, IBM Tivoli, etc. For testing the agent through SNMP, you can use MIB Browser, which is an SNMP manager bundled with Micro Agent. For testing and managing trough HTTP, a user-friendly Web console has been provided.
The following two sections of this book guide you to use the HTTP and SNMP managers for testing and managing the agent:
• Testing through HTTP
• Testing through SNMP
Testing through HTTP
[pic]
• Connecting to the Web Console
• HTTP Manager
• Notifications
• Runtime Rules
[pic]
To test the deployed agent via HTTP, AdventNet provides a user-friendly Web console for viewing and operating on the data available in the MySQL server through Micro Agent for MySQL.
Connecting to the Web Console
For viewing and monitoring the MySQL database through the Web console
1. Connect to the host machine where the agent is deployed at the port where HTTP listens. By default the console listens at the port 8040.
2. Enter the user name and the password in the login screen. The default user name and password are "root" and "public" respectively.
To add new user names and passwords
1. Invoke the ChangePassword.bat/sh file from /agent/bin.
2. Enter the new user name and the new password.
This appends the new user name and the password.
The following is the screen that opens up when you log into the Web console. This summary page displays the various parameters, such as server details, connection details, database details, and the recent alerts received from the agent.
[pic]
HTTP Manager
Using the HTTP manager, you can browse through the different tabs and menus to easily monitor the various MySQL parameters. The following are the tabs available in the Web console provided:
• Performance
• Queries
• Users
• Configurations
• Database and Table
• Errors
• Runtime Rules
• Notifications
Notifications
You can also view the notifications emitted for the preconfigured rules in the agent. When you choose the notification tab, a screen opens up and displays the latest notifications emitted at that moment. The notification displayed contains the message string and the value of the attribute that is monitored.
Runtime Rules
Rules are those which monitor parameters of an application or other managed objects and perform tasks, such as sending notifications. You can configure your own set of rules at runtime using the HTTP manager. To know how to configure rules at runtime, refer to the section "Runtime Rules" under "Managing the MySQL Server".
Testing through SNMP
The deployed agent can be tested via SNMP using AdventNet MIB Browser. MIB Browser is an SNMP Manager used for viewing and operating on the data available in the MySQL server through Micro Agent for MySQL. AdventNet also provides a predefined MIB, called ADVENTNET-MYSQL-MIB to enable easy SNMP manageability to the MySQL server parameters.
This book would take you through the various processes involved during the course of using MIB Browser:
• MIB Browser Operations
• SNMP Table Operations
• SNMP Trap Viewer
• SNMP V3
• SNMP Configurations
MIB Browser Operations
[pic]
• Invoking MIB Browser
• Connecting the Agent
• Loading MIBs
• Unloading MIBs
• Performing SNMP Operations
o GET
o GET-NEXT
o GET-BULK
o SET
[pic]
Invoking MIB Browser
Invoking the MIB Browser as an application would enable you to use it as a standalone application. Follow these steps to invoke the application:
• Locate the MibBrowser.sh/MibBrowser.bat file under the /bin folder.
• Run MibBrowser.bat when you are working on a Windows environment and MibBrowser.sh when you are working on a Unix/Linux environment. Running the file invokes MIB Browser.
Connecting the Agent
The MIB Browser needs to be connected to the agent to access and monitor it. Give the respective details in the following fields of the MIB Browser to connect to the agent:
• Host: Specify the host name of the agent in this field.
• Port: Give the port number where the agent runs. The default SNMP port is 8001.
• Community: Enter the community with which you want to access the agent. By default, the community is set as public in the MIB Browser.
Loading MIBs
Follow the steps given below to load the MIBs:
1. Click the "LOAD MIB" button or select File--> Load MIB menu item, or use a shortcut Ctrl + O. This invokes LoadDialog.
2. Browse and select the MIB to be loaded. By default, it opens the MIB list available in the mibs folder.
The ADVENTNET-MYSQL-MIB is loaded automatically when the MIB Browser application is invoked.
Unloading MIBs
The next basic MIB operation is unloading it. To unload the loaded MIB, select the node of the MIB tree and then
1. Click the UNLOAD MIB button , or
2. Select the File --> UnLoad MIB menu item, or
3. Use the shortcut key Delete.
Performing any of the above will prompt you for a confirmation. Opting Yes would unload the MIB module from the MIB tree. If no module is selected in the MIB tree, all the MIB modules loaded will be unloaded.
Performing SNMP Operations
The MIB Browser allows the user to do the typical SNMP operations. The operations are categorized as follows:
• Retrieving Data: GET, GET NEXT, and GET BULK
• Altering Variables: SET
• Receiving Unsolicited messages: Traps
To perform any basic operation as categorized above, it is essential to specify the Object ID, the instance, host name, and community string. Changes can also be made to the parameters in the MIB Browser Settings panel.
The following is a sample image of MIB Browser with GET and SET operations performed on a node:
[pic]
GET Operation
The GET operation is performed to get one or more values from the managed objects:
1. Load the MIB file.
2. Select the desired node in the MIB Tree.
3. Click the Get SNMP Variable icon [pic] on the toolbar (or) choose Operations-->Get from the menu bar or press Ctrl + G.
This operation gets all objects under the selected MIB object, or the specific object if the MIB node and instance are specified.
GET-NEXT Operation
This operation is similar to the SNMP GET operation, but retrieves the value of the next OID in the tree. This operation is used for traversing the MIB tree. To perform this operation, follow the steps 1 and 2 as in SNMP GET. Then proceed with the following step 3:
3. Click the Get Next SNMP Variable button or [pic] icon on the toolbar (or) choose Operations -->GetNext from the menu bar or press Ctrl + N.
This operation gets the object next to the specified object, or the specific object instance if a MIB node is specified. The instance may or may not be specified.
GET-BULK Operation
To retrieve voluminous data from large table, the GET BULK operation is performed. To perform this operation, follow the steps 1 and 2 as in SNMP GET and continue with the following steps:
3. Configure the MIB Browser to either SNMPv2c or SNMPv3 as desired.
4. On configuring, under the MIB Browser Settings panel, the Max-Repetitions field and the Non-Repeaters field are enabled.
5. Click the Get Bulk SNMP data button or [pic] icon on the toolbar or choose Operations-->GetBulk from the menu bar or press Ctrl + B.
SET Operation
To modify the data for one or more MIB variables, use the SNMP SET operation by following the steps given below:
1. Load the MIB file.
2. Select the desired node in the MIB tree to which a value has to be set. Note that the SET operation can be performed only on the node that has read-write access.
3. Set the value in the Set Value field in the MIB Browser.
4. Click the Set SNMP Variable icon [pic] on the toolbar or choose Operations-->Set from the menu bar or press Ctrl + W.
5. To do a SET for Octet String Type in hex format, enter the bytes in hex format with each bytes separated by a colon and the entire string within single quotes. For example, to give 0xff0a3212, enter 'ff:0a:32:12' in the SetValue field.
SNMP Table Operations
[pic]
• Viewing SNMP Table
• Adding a Row
• Deleting a Row
[pic]
Viewing SNMP Table
AdventNet MIB Browser enables you to view the SNMP Table data in a separate window called SNMP Table Panel apart from allowing a walk on the SNMP tables. The SNMP Table Panel has various options using which you can add or delete a row, view graphs, and also use index editor.
The following is an image of SNMP Table Panel showing an SNMP data table:
[pic]
The following is the procedure to perform operations on an SNMP Table panel:
1. Specify the proper agent host name or IP address in the host field of MIB Browser.
2. Load the MIB in MIB Browser.
3. Specify a valid Table OID or choose the OID from the MIB by traversing through the MIB tree.
4. Click the View SNMP data table button on the toolbar or choose View-->Snmp Table menu item from the menu bar or use a shortcut Alt+T. This would invoke the SNMP Table.
5. Click the Start button in the bottom of the table panel. On clicking this button, the retrieval of data begins. The columnar objects are got and displayed in the table.
6. Click StartPolling to start the polling of the table. The polling intervals are based on the polling interval value set in the settings option.
7. Click the StopPolling button to stop the polling.
8. Click the Refresh button at intervals to refresh the table when you do not use the polling option.
Adding a Row
To add a new row to an SNMP table from the manager, the table should be an SMIv1 table with entryStatus defined, or an SMIv2 table with RowStatus column. For other cases, it is not possible to add a row to the SNMP table directly from the manager.
For SMIv2 tables, adding a new row to the SNMP table can be done in three ways:
• CreateAndWait.
• CreateAndGo using Multiple-Variable Set.
• CreateAndGo using SNMP table UI.
Deleting a Row
To delete a row of an SNMP table from the manager, the table should be an SMIv1 table with entryStatus column or an SMIv2 table with RowStatus column. For other cases, it is not possible to delete a row of the SNMP table from the manager. Using the SNMP table user interface, we can delete a row from the table.
SNMP Trap Viewer
[pic]
• Traps Overview
• Trap Viewer Overview
• Using Trap Viewer
[pic]
Traps Overview
Traps are unsolicited messages sent from SNMP agents to one or more SNMP management applications. It is an asynchronous notification sent by the agent to the manager, conveying the occurrence of some event on the managed device.
Trap Viewer Overview
In order to receive and view incoming traps at the specified port, MIB Browser has Trap Viewer. Trap Viewer is a graphical tool to view the traps received from one or more SNMP agents. Trap Viewer can listen to one or more than one port at a time and the traps can be sent from any host. By default, the MySQL agent sends the traps to the localhost at the port 8003.
Using Trap Viewer
The steps to be followed to work on Trap Viewer are given below:
1. Click the Trap Viewer icon [pic] on the toolbar, or choose View -->Trap Viewer menu item from the menu bar, or use a shortcut Alt + P to open the Trap Viewer tool.
2. Enter the desired port on which the viewer listens in the port field, once the Trap Viewer tool is invoked.
3. Set the community of the incoming traps as desired. The default value in the Community text field is public.
4. Click the Add button to add the community and port at which Trap Viewer has to listen. The added community and port are displayed in the TrapList combo box.
5. Click the Del button to delete the port and community list.
6. Click the Load button to load a Trap Parse file. It invokes a dialog box from which you can load the parser file. This step is optional and is required only if you want to filter the traps and apply some severities.
7. Click the Start button to receive the traps now. On clicking this, Trap Viewer begins to receive traps at specified port and community.
The following is an image of Trap Viewer with traps received at the port 8003:
[pic]
The traps when received are displayed in a table in Trap Viewer when clicked on the "Show Details" button. By default, the trap table has the following five columns:
• Class defines the severity of the trap as defined in the trap parser file.
• Type states the version of the trap as specified in the trap parser file.
• Source depicts the IP address of the host from where the traps were emitted.
• Date indicates the date and time when the trap was received.
• Message displays the value of the MIB variable of the varbinds and the contents of the message field specified while forming the notification.
8. Click the Show Details button or right-click the trap in the trap table and opt for 'View Trap Details' to view the details of the traps.
|Trap Details |Description |
|TimeStamp |This field shows the value stored in the MIB-II sysUpTime variable converted into hours, minutes, and |
| |seconds. It is a 32-bit unsigned value indicating the number of centiseconds that have elapsed since the|
| |(re)start of the SNMP agent and the sending of the trap. |
|Enterprise |This field shows the OID of the management enterprise that defines the trap message. The value is |
| |represented as an OBJECT IDENTIFIER value and has a variable length. This field is applicable only to |
| |SNMP v1. |
|Generic Type |This field shows the value based on the type of trap. The value is categorized and numbered 0 to 6. They|
| |are 0-coldStart,1-warmStart, 2-linkDown, 3-linkUp, 4-authenticationFailure, and 5-egpNeighborLoss. The |
| |trap type value 6 is identified as an enterprise-specific value. This field is applicable only to SNMP |
| |v1. |
|Specific Type |This field can have values from 0 to 2147483647. The specific trap type indicates the specific trap as |
| |defined in an enterprise-specific MIB. If the Generic Type value is 6, this field shows a value greater |
| |than 0. If the Generic Type value is a value other than 6, then the field shows a value 0. This field is|
| |applicable only to SNMP v1. |
|Message |This is a text field. By default, this field always contains the Varbinds in the trap PDU. This can be |
| |replaced with the text. |
|Severity |This field shows the severity or the intensity of the trap. It could be 0-All, 1-Critical, 2-Major, |
| |3-Minor, 4-warning, 5-Clear, and 6-Info. |
|Entity |This field contains the source IP address from which the Trap was sent. This field is applicable only to|
| | SNMP v1. |
|RemotePort |This field reveals the port from which the trap was sent by the originator. |
|Community |This field contains the community string. |
|Node | Source |
|TimeReceived |This field contains the date and time when the trap was received. |
|HelpURL |The URL shown here gives more details of the received trap. By default, the URL is |
| |- .html |
9. Click the Stop button to stop listening.
10. Click the Delete Entry button or right-click on the trap in the trap table and opt 'Delete the Selected Rows', to delete the selected trap.
11. Yet another option in Trap Viewer is ParserEditor. Trap Viewer can filter incoming traps according to certain criteria called parser criteria.
SNMP V3
[pic]
• SNMP V3 Overview
• Security Levels in SNMP V3
• Testing a V3 Agent
• Supported Privacy package
• To use JCE Classes with MIB Browser
• To use Cryptix Classes with MIB Browser
• Export Restrictions
[pic]
SNMP V3 Overview
The version 3 of Simple Network Management Protocol addresses some of the long pending issues related to the large scale deployment of SNMP. Due to the lack of security in using SNMP, system and network administrators were using other means such as telnet, ascii, etc., for configuration, accounting, and fault management. The primary goal of SNMP version 3 (SNMPv3) is to define a secure version of the SNMP. SNMPv3 also facilitates remote configuration of the SNMP entities, which make remote administration of SNMP entities a much simpler task. AdventNet has implemented SNMPv3 as defined from RFC2570 to RFC2576.
Security Levels in SNMP V3
As explained earlier, SNMP version 3 (SNMPv3) is used to provide a secured environment in managing the systems and networks. The SNMPv3 Agent provides support for three level of users. The supported security levels as defined in the USM MIB (RFC 2574) are
• noAuthNoPriv: Communication without authentication and privacy. The following table gives the default entries for noAuth users:
|Context Name |Security Level |User Name |Auth Protocol | Priv Protocol |Auth Password |Priv Password |
• authNoPriv: Communication with authentication and without privacy. The protocols used for authentication are MD5 and SHA (Secure Hash Algorithm). The default entries for authUsers are given in the table below:
|Context Name |Security Level |User Name |Auth Protocol | Priv Protocol |Auth Password |Priv Password |
• authPriv: Communication with authentication and privacy. The protocols used for authentication are MD5 and SHA. The DES (Data Encryption Standard) protocol is used for privacy. The default entries for privUsers are shown in the following table:
|Context Name |Security Level |User Name |Auth Protocol | Priv Protocol |Auth Password |Priv Password |
Testing a V3 Agent
The following are the steps to test the V3 agent with the default user entries:
1. Click Edit-->Settings to open the MIB Browser Settings dialog.
2. Select the SNMP version as V3.
3. Click the Add button in the General panel. The SnmpParameterPanel pops up.
4. Fill in the following details:
1. Target Host
2. Target Port
3. User Name
4. Security Level
5. Auth Protocol
6. Auth Password
7. Priv Protocol
8. Priv Password
9. Context Name
1. Load the MIB of your V3 agent.
1. Test the V3 agent by performing the operations as applicable for any agent.
Supported Privacy Packages
For privacy support, the Encryption packages that can be used are:
• JCE
• Cryptix
To use JCE classes with MIB Browser
1. Download JCE classes 1.2 or 1.2.1 from the following URL:
2. In case JCE 1.2 classes are downloaded, you get the following jar : jce12-rc1-dom.jar
3. In case JCE 1.2.1 classes are downloaded, you get the following four jars : jce1_2_1.jar, local_policy.jar, sunjce_provider.jar, and US_export_policy.jar
4. Make sure the jars are placed under the directory.
5. Also make sure the jars are included in the CLASSPATH of the setallEnv.bat/sh file (available in the /bin directory) in the beginning.
6. Add the code snippet provided in the table after the following line in the java.security file present in the jre/lib/security folder under the JDK installed in your machine:
security.provider.1=sun.security.provider.Sun
|security.provider.2=com.sun.crypto.provider.SunJCE |
7. Save the java.security file.
8. The USMUtils.class required for encrypting v3 requests and responses is available in AdventNetSnmp.jar under /jars.
Now, the v3Agent is ready for supporting Privacy.
|[pic] |Note: If JDK 1.4 is used, then JCE privacy jars are not required to be in the class path. |
To use Cryptix Classes with MIB Browser
1. Download Cryptix classes 3.1 or 3.2 from the following URL:
2. Make sure the jars are included in the CLASSPATH of the setallEnv.bat/sh file (available in the /bin directory) in the beginning. Please note that the jars are required to be in the CLASSPATH settings of the mysqlagent.exe file that is used for running the agent.
3. The USMUtils.class required for encrypting v3 requests and responses is available in AdventNetSnmp.jar (/jars directory) for 3.1 cryptix package.
4. Add the code snippet provided in the table, after the following line in the java.security file present in the jre/lib/security folder under the JDK installed in your machine:
security.provider.1=sun.security.provider.Sun
|security.provider.3=cryptix.provider.Cryptix |
Now, the v3Agent is ready for supporting Privacy
Export Restrictions
Encryption packages are bound by Export restrictions.
o If JCE 1.2 or its implementations are used in developing application and applets; they cannot be used outside US and Canada.
o JCE 1.2.1 does not have any export restrictions and it can be used in applications, which can be distributed throughout the world.
o The latest JDK version ( JDK 1.4 beta ) comes integrated with the JCE 1.2.1.
o Cryptix package does not have any such export restrictions.
SNMP Configurations
[pic]
• ACL Table
• Trap Forwarding Table
• Proxy Table
• Trap Receiver Table
• VACM Tables
• VACM Context Table
• VACM Security To Group Table
• VACM Access Table
• VACM View Tree Family Table
[pic]
The various SNMP configurations that can be done using Micro Agent for MySQL are listed below:
• ACL Table
• Trap Forwarding Table
• Proxy Table
• Trap Receiver Table
• VACM Tables
The steps to configure the above-mentioned tables are discussed in the following paragraphs.
ACL Table
An agent authenticates a request based on the community. Hence, it is required to store the community details and the details of the manager with the given access for that particular community in the agent side. To store these details, there is a table called Access Control Table (aclTable) present in the AGENT-SNMP-CONFIG-MIB.
This table maintains a set of authentication parameters given below:
• aclCommunity: The community used by the manager to communicate with the agent.
• aclAccess: The allowed access for the community. It could be No Access (0), Read_Only (1), Write_Only (2), or Read_Write(3).
• aclManager: IP address of the managers who are allowed specified access for the specified community. The default value is '0:0:0:0' which states access is provided to all managers for the corresponding community.
• aclStatus: The Row Status column.
To add communities dynamically during runtime to aclTable from the manager
1. Load the AGENT-SNMP-CONFIG-MIB in MIB Browser.
2. Select aclTable from the v1/v2AuthenticationTables module of agentConfiguration group.
3. Click the SNMP Table icon in MIB Browser to open up a wizard wherein entries can be added to aclTable.
Trap Forwarding Table
For sending traps and notifications to multiple managers, the agent maintains a table called Trap Forwarding Table or Manager Table. This table stores the information of all the managers and is defined in the AGENT-SNMP-CONFIG-MIB under the /mibs directory.
V3 Trap Forwarding Table holding the OID value .1.3.6.1.4.1.2162.10.2.1.2.2.2 in the AGENT-SNMP-CONFIG-MIB contains the following columns. This table is multi-lingual by nature, i.e., it can forward any version of traps to the Managers registered in the table. The columns, such as userName, secModel, and contextName are used in case of SNMP v3. The remaining columns are common to all the versions.
• v3ManagerHost (Index Column): The IP address of the manager.
• v3ManagerPort (Index Column): The port number of the manager.
• v3ManagerVersion: SNMP Version of the manager.
• v3ManagerCommunity: Community of the manager.
• v3ManagerUserName: The name of the user.
• v3ManagerUserSecModel: The security model used.
• v3ManagerUserContextName: The context name of the user.
• v3ManagerTimeOut: Timeout Value.
• v3ManagerRetries: Number of retries that can be made.
• v3ManagerStatus: Row Status of the entry.
• v3UserSecLevel: The security level of the user.
For adding entries to Trap Forwarding Table dynamically, follow the steps given below:
1. Load AGENT-SNMP-CONFIG-MIB from the MIB browser.
2. Select the v3TrapForwardingTable from the trapTables module of agentConfiguration group.
3. Click the SNMP Table icon in MIB Browser to open up a wizard wherein entries can be added to v3TrapForwardingTable.
Proxy Table
It is easier to manage a large number of agents when they have a hierarchical structure of master agents and sub-agents. Managers communicate with the master agents alone and access the sub-agents transparently, as if the information actually resides in the master agent.
AdventNet Micro Agent for MySQL also supports the proxy function using SNMP. Here, requests for an OID sub-tree of an existing SNMP agent can be exposed through the MySQL agent. This in turn would process the request by fetching the values from the SNMP agent which would act as its sub-agent.
Requests for OID sub-tree of a sub-agent can be processed by the master agent using the SNMP proxy feature. This feature can be used by enabling the SNMP proxy option which is discussed below. Follow the steps given below to do so:
1. Load AGENT-SNMP-CONFIG-MIB in MIB Browser.
2. Select proxyTable from the subAgentTables module of agentConfiguration group.
3. Click the SNMP Table icon (View SNMP Table Data) in MIB Browser to open up a wizard wherein entries can be added to the proxyTable.
4. Click Add in that SNMP Table wizard. The corresponding columns in the table are listed below.
5. Include the sub-agent entries.
The various entries in a Proxy table are as follows:
• OID: The OID of the node of the sub-agent which responds to the proxy requests.
• Host: The name of the host where the sub-agent is running.
• Port Number: The port number at which the sub-agent can be contacted.
• Version: Version of the SNMP interface available in the sub-agent.
• Community: Community of the sub-agent.
• Timeout: The duration for which a proxy request is valid.
• Retries: The number of attempts a master agent can make to proxy a request.
• Row Status: The proxy request is processed only if value of the row status is 'Active'.
Trap Receiver Table
This table maintains each sub-agent information like sub-agent's IP address, port number, community, etc. if it is allowed to send traps to the master agent. This table is used only if proxy is enabled. To configure this table, follow the steps given below:
1. Load AGENT-SNMP-CONFIG-MIB in MIB Browser.
2. Select trapReceiverTable from the subAgentTables module of agentConfiguration group.
3. Click the SNMP Table icon (View SNMP Table Data) in MIB Browser to open up a wizard wherein entries can be added to the proxyTable.
4. Click Add in that SNMP Table wizard. The corresponding columns in the table are listed below.
5. Include the sub-agent entries.
Each entry of this table discussed below corresponds to a sub-agent who is allowed to send traps to the master agent:
• agentHost (Index Column):Sub-agent's IP address.
• agentTrapPortNumber (Index Column): Sub-agent's port number.
• agentCommunity: The community string used by the sub-agent to send traps to the master agent.
• agentStatus: The status of this conceptual row.
VACM Tables
For security reasons, it is valuable to restrict the access rights of some groups to only a subset of the Management information in the Management domain. To provide this capability, access to a community is via a "MIB view" which details a specific set of managed object types within that community.
For example, for a given community, there will be one MIB view which provides access to all management information in that community, and often there will be other MIB views each of which contains some subset of the information.
So, the access allowed for a group can be restricted in the desired manner by specifying its rights, in terms of the particular (subset) MIB view it can access. By implementing the View-based access feature, this requirement can be achieved. The RFC 2575 MIB is implemented for this purpose.
|[pic] |Note: View-based Access Control for v1/v2c agents is given based on the community specified in aclTable. User-based |
| |Security Model (USM) and View-based Access Control (VACM) Tables are implemented by default when the agent is started in |
| |SNMP Version 3. |
It is possible to prevent a particular group in accessing an OID in the MIB using VACM. SNMPv2 Agent has implemented the VACM MIB as a default access control model.
To configure an entry from the Manager during runtime,
1. Start the MIB Browser application.
2. Load SNMP-VIEW-BASED-ACM-MIB from the /mibs directory.
3. This MIB contains the four tables in which the View-based Authorization has to be configured. The four tables are
1. vacmContextTable
2. vacmSecurityToGroupTable
3. vacmAccessTable
4. vacmViewTreeFamilyTable
1. Selecting the respective table and clicking SNMP Table icon in MIB Browser opens up a wizard wherein entries can be added to the required Tables by sending SET requests.
1. Please note that vacm context table is not configurable.
VACM Context Table
This table has a set of valid context names supported by the SNMPv3 Agent. The context name received will be checked with this table in the access validation phase. It is not configurable through SNMP.
This table has the following entry:
▪ VacmContextName: Refers to the context names supported by the snmpv3 agent.
VACM Security To Group Table
This table has a set of security to group mappings. If the received context name is valid, then the group name is obtained from this table by giving user (security) name and security model as an input. It is configurable through SNMP.
The entries of this table are
▪ vacmSecuirtyModel: Refers to the Security Model supported by the snmpv3 agent.
▪ vacmSecurityName: Refers to the name of the user.
▪ vacmGroupName: Refers to the group name to which the user belongs.
▪ VacmSecurityToGroupStorageType: Denotes the storage type "NON_VOLATILE".
▪ vacmSecurityToGroupStatus: Denotes the Row Status "Active".
VACM Access Table
This table has a set of access supported by the Agent. By giving group name, context name, security model, and security level, you can get a view name based on the received request type. It is configurable through SNMP.
The following are the entries of this table:
▪ vacmGroupName: Refers to the group to which the user belongs.
▪ snmpVacmAccessContextPrefix: Refers to the context name of the user.
▪ snmpVacmAccessSecurityModel: Refers to the Security Model supported by the snmpv3 agent - USM.
▪ snmpVacmAccessSecurityLevel: Refers to the Security level of the user.
▪ snmpVacmAccessContextMatch: Refers to the Context Match "Exact".
▪ snmpVacmAccessReadViewName: Refers to the read view name provided for the v3 user.
▪ snmpVacmAccessWriteViewName: Refers to the write view name provided for the v3 user.
▪ snmpVacmAccessNotifyViewName: Refers to the notify view name provided for the v3 user.
▪ snmpVacmAccessStorageType: Denotes the storage type "NON_VOLATILE".
▪ snmpVacmAccessStatus: Denotes the Row Status "Active".
VACM View Tree Family Table
This table has a set of views supported by the Agent. By giving view name and received OID, you can specify whether the received request has valid view or not. It is configurable through SNMP.
The entries of this table are as follows:
▪ VacmViewTreeFamilyViewName: The Read/Write/Notify view name provided for the v3 user.
▪ VacmViewTreeFamilySubtree: The Sub Tree OID for which read/write/notify access is provided. To change the default MIB view provided, i.e., the default Sub Tree OID, you must edit the snmpvacmviewtreefamilytable.txt file from the /agent/conf/snmp/acl directory and specify the desired OID for which the access is to be provided.
▪ VacmViewTreeFamilyMask: The mask for the OID.
▪ VacmViewTreeFamilyMaskLen: The length of the mask.
▪ VacmViewTreeFamilyType: "INCLUDED".
▪ VacmViewTreeFamilyStorageType: Denotes the storage type "NON_VOLATILE".
▪ VacmViewTreeFamilyStatus: Denotes the Row Status "Active".
Managing the MySQL Server
AdventNet Micro Agent for MySQL exposes the complete management information of MySQL server and hence makes the server available online all the time. The following sections of this book show you the various parameters exposed via this agent:
• MySQL Details
• Performance
• Queries
• Users
• Configurations
• Table and Database
• Errors
• Notification
• Runtime Rules
MySQL Details
AdventNet Micro Agent for MySQL helps you monitor the various MySQL details through HTTP consoles or SNMP managers, such as HP OpenView, IBM Tivoli, etc. The MySQL details that can be monitored are listed below:
• Server Availability: Shows "1" if the server is available and "2" if the server is not available.
• Uptime: The time for which the server has been active.
• Restarts: The number of times the server has been restarted.
• CPU Usage: The CPU used by the MySQL server in percentage.
• Memory Usage: The memory used by the MySQL server in KB.
• Total Memory: Total Physical Memory of the system in KB.
• Open Streams: Number of streams that are open (used mainly for logging).
• Open Files: Number of files that are open.
• Host Machine: The host machine where the MySQL database is installed.
• PID: The process ID of the current MySQL database instance.
• Port: The MySQL port. The default MySQL port is 3306.
• Protocol Version: The protocol version used by the MySQL server.
• Table Type: The default Table type.
• Time Zone: The time zone for the server.
|[pic] |Note: By default, the agent refers to the MySQL's error log to give the "Restarts" value. So if you choose a different file|
| |in a different location as your error log file, you must specify that in the conf directory of the agent. Otherwise a wrong|
| |value might be shown |
Performance
[pic]
• Overview
• Key Read Efficiency
• Key Write Efficiency
• Configurations
• Network Traffic
• Threads
• Connection Status
[pic]
Overview
Micro Agent for MySQL provides a user-friendly Web console and an SNMP manager (MIB Browser) through which the various performance parameters of the MySQL server can easily be monitored. The various performance parameters that are exposed through this agent are discussed below:
The performance parameters are grouped into different categories as follows:
• Key Read Efficiency
• Key Write Efficiency
• Configurations
• Network Traffic
• Threads
• Connection Status
Key Read Efficiency
The information related to Key Read are exposed as follows:
• Key Reads: The number of physical reads of a key block from disk.
• Key Read Request: The number of requests to read a key block from the cache.
• Key Read Efficiency: The ratio of the number of physical reads of a key block from the cache to the number of requests to read a key block from the cache in percentage. The MySQL performance is good if the value of Key Read Efficiency is 90 percent and above. Increasing the size of the cache improves the value of Key Read Efficiency and hence an improved the performance.
Key Write Efficiency
The Key Write parameters can be viewed as listed below:
• Key Writes: The number of physical writes of a key block to disk.
• Key Write Request: The number of requests to write a key block to the cache.
• Key Write Efficiency: The ratio of the number of physical writes of a key block to the cache to the number of requests to write a key block to the cache in percentage. For a good performance of the MySQL server, the value of Key Write Efficiency must be 90 percent and above. If it is found less, then you can increase the size of the cache to improve the performance.
Configurations
The performance-related configuration details exposed through this agent are as follows:
• Table Cache: It is the number of open tables for all the threads.
• Key Buffer: It is the size of the buffer used for index blocks. It is recommended to allocate 20 to 50 percent of your RAM for MySQL's key buffer. This helps to maintain the performance of MySQL server.
• Record Buffer: It is the size of the buffer allocated by a thread for each table it scans sequentially.
• Sort Buffer: It is the size of the buffer allocated by a thread to do a sort.
• Performance: Lists down the general performance details of MySQL server such as network traffic, key read efficiency, and key write efficiency information.
• Buffer and cache: Lists down the MySQL server's performance-related configuration details.
• Threads: Lists down the information related to threads and connection status of the MySQL server.
Network Traffic
The following are the Network Traffic details you can view using this Micro Agent:
• Bytes Sent: Number of bytes sent to all the clients.
• Bytes Received: Number of bytes received from all the clients.
• Avg Queries: Average number of queries executed per millisecond.
Threads
Thread related information exposed through the agent is shown below:
• Threads Created: Number of threads created to handle connections.
• Threads Connected: Number of connections that are currently open.
• Threads Cached: Number of threads in the thread cache.
• Threads Running: Number of threads that are not sleeping.
• Thread Cache Hit Ratio: The ratio of the number of threads created to the number of connection attempts to the MySQL server. This should be as low as possible (usually less than one).
Connection Status
The Connection Status parameters exposed are listed below:
• Connection Attempts: Number of connection attempts to the MySQL server.
• Aborted Connects: Number of tries to connect to the MySQL server that failed.
Queries
[pic]
• Overview
• General
• Slow Query Table
• Update Query Table
• General Query Table
• Query Usage
[pic]
Overview
Monitoring the queries executed in a database becomes very vital when it comes to managing the MySQL server. To improve the performance and the overall efficiency of the MySQL server, the queries executed in the server need to be optimized. It is very essential for an administrator to track the type and number of queries executed so that he can trace and optimize the un-optimized queries. AdventNet's Micro Agent for MySQL makes all the query-related information available online and facilitates easy monitoring through HTTP and SNMP managers.
The agent exposes all the query details under the following categories:
• General
• Slow Query Table
• Update Query Table
• General Query Table
• Query Usage
The various query details that can be monitored under each of the above categories are discussed in the subsequent paragraphs.
General
The general query details exposed are as follows:
• Total Queries: Total number of queries executed from server startup.
• Most Used Query: The most used SQL statement out of SELECT, INSERT, UPDATE , DELETE, etc.
• Slow Query Count: Number of slow queries captured.
Slow Query Table
Slow Query Table contains all the details of those queries whose process time exceeded the Long Query Time value. This table can be viewed only if Slow Query logging is enabled. The parameters exposed through the Slow Query table are as follows:
• Slow Query Index: The index value of the Slow Query table which is auto-incremented.
• Slow Query Timestamp: The date and time when the slow query is captured.
• Slow Query User Name: The user who executed the slow query.
• Slow Query Host Machine: The name of the host from which the output query is requested.
• Slow Query Time: The total process time of the query in seconds.
• Slow Query Lock Time: The time taken in seconds to secure the query's lock.
• Slow Query Rows Sent: The number of rows sent while executing the query.
• Slow Query Rows Examined: The number of rows examined while executing the query.
• Slow Query Database: The database in which the query is executed.
• Slow Query String: The query that is identified as slow.
Update Query Table
Update Query Table stores all statements that change data. This table must be enabled to view the various parameters in it. The various details shown in the Update Query table are as follows:
• Update Query Index: A unique value for each row of the table which is auto-incremented.
• Update Query Database: Name of the database being updated.
• Update Query String: The update query executed on the database.
General Query Table
General Query Table has all the information on the connections established and the queries executed. The following are the data exposed through the General Query table:
• General Query Index: The index value for the General Query table. This is auto-incremented.
• General Query Timestamp: The date and time when the information is logged.
• General Query Command ID: A unique value to identify a command.
• General Query Command Type: The type of the command that is executed. It may be "Connection" or "Query".
• General Query Command: The command that is executed.
Query Usage
In addition to the above details, the number of times the various types of queries executed are shown which are as follows:
• Select Query Count: The number of times the SELECT query is executed.
• Insert Query Count: The number of times the INSERT query is executed.
• Update Query Count: The number of times the UPDATE query is executed.
• Delete Query Count: The number of times the DELETE query is executed.
• Truncate Query Count: The number of times the TRUNCATE query is executed.
• Drop Index Query Count: The number of DROP INDEX statements executed.
• Create Index Query Count: The number of CREATE INDEX statements executed.
Users
[pic]
• Overview
• Active Users Table
• User Details table
[pic]
Overview
One of the major features of AdventNet Micro Agent for MySQL is the extensive monitoring of all the users of MySQL server and the user details. The agent explicitly shows the administrator, all the active users of the database and their respective process details through the HTTP and SNMP consoles and thus aiding an easy management of the users for the administrators.
Micro Agent for MySQL exposes all these user information under the following two different tables:
• Active Users Table: Gives the information of all the users connected to the server at the moment in a tabular form.
• User Details Table: Lists all the user details in the form of a table.
Active Users Table
The following are the information of the active users exposed via this table:
• ActiveUsersIndex: Provides a unique value for each row of the Active Users table.
• ActiveUsersName: Name of the user connected to the database.
• ActiveUsersHost: Host name of the connected user.
• ActiveUsersDatabase: The database on which the user is currently working on.
• ActiveUsersCommand: The type of command the user executed, such as connection, query, etc.
• ActiveUsersActivityTime: The time taken by the user to execute the command in milliseconds.
• ActiveUsersState: The current state of the user process.
• ActiveUsersCommandInfo: Information on the command executed.
User Details Table
The various user details exposed through the agent are listed below:
• User: The name of the user. It is used as the index value of the table.
• Host: Host name of the user. This is also used as the index value of the table.
• UserHashPassword: The password of the user. It is the hash value computed from the original password.
• UserSelectPriv: Shows whether the user has got SELECT privilege.
• UserInsertPriv: Shows whether the user has got INSERT privilege
• UserUpdatePriv: Shows whether the user has got UPDATE privilege.
• UserDeletePriv: Shows whether the user has got DELETE privilege.
• UserCreatePriv: Shows whether the user has got CREATE privilege.
• UserDropPriv: Shows whether the user has got DROP privilege
• UserReloadPriv: Shows whether the user has got RELOAD privilege.
• UserShutdownPriv: Shows whether the user has got SHUTDOWN privilege.
• UserProcessPriv: Shows whether the user has got PROCESS privilege.
• UserFilePriv: Shows whether the user has got FILE privilege.
• UserGrantPriv: Shows whether the user has got GRANT privilege.
• UserReferencesPriv: Shows whether the user has got REFERENCES privilege.
• UserIndexPriv: Shows whether the user has got INDEX privilege.
• UserAlterPriv: Shows whether the user has got ALTER privilege.
Configurations
[pic]
• Overview
• General
• Directories
• Logs
• Connection
• Metrics
• Agent Configurations
[pic]
Overview
The various server configuration details of MySQL are exposed through AdventNet MySQL Micro Agent. This agent allows you to view these details through both HTTP console and SNMP manager under the following categories:
• General
• Directories
• Logs
• Connection
• Metrics
• Agent Configurations
The following paragraphs describe all the above categories with all the details that are exposed through the MySQL agent.
General
The general configuration details exposed are listed below:
• Flush: This is ON if you have started MySQL with the flush option.
• Host Machine: The name of the host machine.
• Locked In Memory: This is ON if the memory is locked.
• Long Query Time: If the process time of any query exceeds this time, it becomes a slow query and hence the value of Slow Query Count gets incremented. This value can be altered by the user.
• Net Buffer Length: The communication buffer is reset to this size between queries. The buffer is automatically enlarged to the maximum allowed packet bytes during the query time.
• Net Read Timeout: The time required in seconds to wait for more data from a connection before aborting the read.
• Net Write Timeout: The time required in seconds to wait for a block to be written to a connection before aborting the write.
• Raid: This is "YES" if MySQL supports the RAID option
• Safe Show Database: If this is enabled i.e., if it is ON then the database for which the user does not have any privilege will not be shown.
Directories
The directory configurations of the MySQL server are as follows:
• Base Directory: The directory under which MySQL is installed.
• Data Directory: The directory under which the MySQL database files are kept.
• Socket Directory: The location of the Unix socket used by the server.
• TMP Directory: The directory used for storing the temporary files and the temporary tables.
Logs
The various log file configurations of the MySQL server are listed below:
• General Log: Contains all the SQL statements executed by the server. Shows "1" if it is enabled. Else shows "2".
• Log Bin: Contains all the updated queries executed by the server. Binary Log file is the advanced version of the Update Log file. Shows "1" if enabled. Else shows "2".
• Slow Query Log: Contains all the queries that took more than the Long Query Time value. Shows "1" if enabled. Otherwise shows "2".
• Update Log: Contains all the update queries executed by the server, such as UPDATE, DELETE, TRUNCATE, DROP, etc. Shows the status as "1" if available and "2" if not available.
• Dynamic Log File Control: You can dynamically enable or disable the following three log files. Specify "1" to enable and "2" to disable:
o Slow Query Logging: Enabling this logging populates the Slow Query table. The agent automatically enables the Slow Query logging if it is disabled before the agent's startup. It also creates the mysqlagent_slow.log file under /data from which it fetches the data to populate the Slow Query table. If the Slow Query logging is already enabled, then you must edit the adventnetmysqlagent.conf file present under agent/conf directory and specify the name and the path of the file from which the Slow Query table data are fetched.
o Update Query Logging: The Update Query table gets populated by enabling this. Similar to the Slow Query logging, the agent enables the Update Query logging also automatically and creates the mysqlagent_update.log file under /data from which it fetches the data to populate the Update Query table. If it is already enabled, then edit the adventnetmysqlagent.conf file present under agent/conf directory and specify the name and the path of the file from which the Update Query table data are fetched.
o General Query Logging: Enabling this populates the General Query table. By default, this is disabled. This log, when enabled, may cause performance degradation. Enabling this also creates a log file named mysqlagent.log under /data from which the data to populate the General Query table are fetched. If it is already enabled, then edit the adventnetmysqlagent.conf file present under agent/conf directory and specify the name and the path of the file from which the General Query table data are fetched.
|[pic] |Note: |
| |The dynamic enabling/disabling of the log files is possible only if the MySQL server is dynamically linked. |
| |Dynamic enabling/disabling is not supported for Windows and Solaris 5.8 machines. |
| |However, the agent can retrieve the log information, if the log files are specified in the adventnetmysqlagent.conf file |
| |under the agent/conf directory before starting the agent. |
• Polling Period: In addition to the above configurations, you can also define the period for which these log tables must get updated. The steps to do so are as follows:
• Edit the adventnetmysqlagent.conf file present under the agent/conf directory.
• Specify the polling period in seconds in the "pollingSeconds" field.
Connection
The following are the configuration details related to the connections of MySQL server:
• Backlog: The number of outstanding connection requests MySQL can have.
• Connect Timeout: The time in seconds for which the MySQL server waits for a connect packet before responding with a bad handshake.
• Interactive Timeout: The time in seconds for which the MySQL server waits for an activity on an interactive connection before closing it.
• Max Connections: The maximum number of connections allowed for the server at a time.
• Max Connect Errors: The maximum number of interrupted connections allowed from a host. The host exceeding this value will be blocked from further connections.
• Max User Connections: The maximum number of active connections for a single user. If it is zero, you can have any number of connections.
• Wait Timeout: The number of seconds the server waits for an activity on a non-interactive connection before closing it.
Metrics
The configurations on the various metrics of the MySQL server are shown below:
• Max Join Size: The maximum number of records that can be read by the JOINS.
• Thread Cache Size: The maximum number of threads that the cache can hold at a time.
• Open Files Limit: The maximum number of files the system allows the MySQL database to open. This is zero on systems where MySQL cannot change the number of open files.
• Query Buffer Size: The memory allocated to store results from old queries. This is zero, when the query cache is disabled.
• Record Rnd Buffer Size: It is the size of the buffer through which the rows are read to avoid disk seeks.
• Tmp Table Size: The size of an in-memory Temporary table. The temporary table exceeding this size is automatically converted into an on-disk MyISAM table by MySQL.
Agent Configurations
You can set the value of maximum number of rows to be exposed at a time for the various log tables through the agent. When the number of rows exceeds the specified value, the oldest entries are deleted and only the last "n" entries are shown, "n" being the maximum number of rows set for that table. By default, 100 rows can be exposed for each table.
The following are the various configurations for the log tables:
• Slow Query Table Max Rows: Specify the value of maximum number of rows to be shown in the Slow Query table.
• Update Query Table Max Rows: Specify the maximum number of rows to be displayed for the Update Query table.
• General Query Table Max Rows: Specify the maximum number of rows to be viewed for the General Query table.
• Error Table Max Rows: Specify the maximum number of rows to be exposed for the Error table.
Database and Table
[pic]
• Overview
• Database
• Tables
• Table Details
[pic]
Overview
Micro Agent for MySQL helps you effectively monitor the MySQL database and the tables by providing all the information in the respective tables. The various tables relevant to the databases and the tables that can be viewed through HTTP and SNMP consoles using the agent are discussed in the subsequent paragraphs.
The general details that are exposed are
• Total Database Created: The total number of times the "CREATE DATABASE" command is executed. This value is set to zero when the server is restarted.
• Total Database Dropped: The total number of times the "DROP DATABASE" command is executed. This value is set to zero when the server is restarted.
• Most Used DB: Name of the database that is used the most. To make this data available, Update Logging must be enabled.
Database
The total space occupied by the database and the number of tables in the database are exposed through a table. The various entries of the table are as follows:
• Database Name: Index value of the table. Shows a unique name for the database.
• Database Space Occupied: The total space occupied by the database.
• Database Number of Tables: Total number of tables in the database.
• Database Timestamp: The date and time when the information is fetched from the database.
Tables
The table related information in the database is exposed as follows:
• Total Tables Created : Number of times the "CREATE TABLE" command is executed in the MySQL server. This value gets reset to zero when the server is restarted.
• Total Tables Dropped: Number of times the "DROP TABLE" command is executed in the MySQL server. This value gets reset to zero when the server is restarted.
• Tables Open: Number of tables that are currently open.
• Total Tables Opened: Total number of tables that were opened. This includes the tables that were opened once and then closed.
• Table Lock Immediate: Number of times a table lock is acquired immediately. This is applicable only to the MySQL versions above 3.23.33.
• Table Lock Waited: Number of times a table lock could not be acquired immediately and a wait was needed.
• Pct Table Locks Blocked: The ratio of the number of table locks waited to the number of table locks immediate in percentage.
Table Details
The various tables and the table details like table name, database, data length, rows etc. are shown in the Table Details table. They are as follows:
• Database Name: Index value of the table; it shows a unique database name for each table.
• Table Name: Name of the table which is another index value of the table.
• Table Type: Table type supported by MySQL 1 ( ISAM 2, HEAP 3, MyISAM 4, InnoDB 5, and BDB).
• Table Row Format: The row storage format (Fixed, Dynamic, or Compressed).
• Table Rows: Total number of rows in the table.
• Table Avg Row Length: Average length of a row in the table.
• Table Data Length: Length of the datafile.
• Table Max Data Length: Maximum length of the datafile. For fixed row formats, this is the maximum number of rows in the table. For dynamic row formats, this is the total number of data bytes that can be stored in the table, if the data pointer size used is given.
• Table Index Length: Length of the index file.
• Table Data Free: Number of allocated but not used bytes.
• Table Auto Increment: Next auto-increment value of the table.
• Table Create Time: The time of creation of the table.
• Table Update Time: The time when the datafile was last updated.
• Table Check Time: The time when the table was last checked.
• Table Create Options: Extra options used with CREATE TABLE.
• Table Comment: The comment used when creating the table (or some information why MySQL could not access the table).
Errors
AdventNet Micro Agent for MySQL exposes the various errors occurring in the MySQL server through a table named Error Table. The data exposed in this table are fetched from the error log of MySQL server which is usually found inside the data directory under as mysql.err/hostname.err. If the name or the location of this file is changed, then you must specify that in the adventnetmysqlagent.conf file present under agent/conf. By default, Micro Agent looks for the file name specified under the data directory.
Error Table lists down all the error messages and the warnings with the date and time of occurrence which are shown below:
• Error Index: An auto-incremented unique value for each row of the table serving as the index for that table.
• Error Timestamp: The date and time of occurrence of the error.
• Error Message: The actual error message occurred at that instant.
Notification
In addition to retrieving data from the Managed resource and sending response to them, AdventNet Micro Agent for MySQL has the ability to send unsolicited messages to the managers when it detects some significant event. An unsolicited message of this sort is called trap (in SNMPv1) or Notification (in SNMPv2 and SNMPv3). The agent has been pre-configured to notify the managers of a few changes especially when a threshold is reached on some important parameters of the MySQL server. This helps the manager to easily monitor the faults occurring inside the server and take the corrective measures at the right time.
The following are the notifications that are pre-configured in the agent:
• Slow Query Notification: Produces notification when a slow query is captured.
• User Add Delete Notification: Produces notification when a new user is created or deleted.
• Read Efficiency Notification: Produces notification when the read efficiency falls below the threshold, i.e., below 90.
• Write Efficiency Notification: Produces notification when the write efficiency falls below the threshold, i.e., below 90.
• CPU Usage Notification: Produces notification when the CPU usage of the server exceeds a particular value set by the user. The default value is 5%.
• Memory Usage Notification: Produces notification when the memory usage of MySQL server exceeds a threshold. The default value is 10 MB.
• Server Down Notification: Produces notification when the server is down.
• New Error Notification: Produces notification when a new error is detected.
You can also edit these pre-configured rules and modify the values of threshold, polling interval, etc. It is also possible for you to configure rules at runtime using the agent to send e-mails and to emit notifications which can be viewed through HTTP managers. The same can be viewed as traps through SNMP managers. To learn how to configure rules at runtime, refer to the "Runtime Rules" section.
Runtime Rules
[pic]
• Overview
• Configuring Rules through HTTP
• Configuring Rules through SNMP
• Rule Table
• Configuring E-mails
• Configuring SNMP Manager Table through HTTP
[pic]
Overview
AdventNet Micro Agent for MySQL allows the users to configure their own rules in addition to providing pre-configured rules for emitting notifications to the managers. This can be done both through HTTP and SNMP managers. Rules monitor parameters of an application or other managed objects and perform tasks. They are made of data sources/attributes, conditions/criteria, and actions (sending notifications and e-mails).
Configuring Rules through HTTP
To configure rules through HTTP follow the steps given below:
1. Choose the Runtime Rules tab of the HTTP console.
2. Click Add New Rule to add a rule.
3. Enter the required values in the Rule table that comes up. The various fields that need to be filled are discussed under "Rule Table".
4. Click Create Rule to create a rule.
5. Create as many rules as you want, similarly.
Configuring Rules through SNMP
The steps to configure the rules through SNMP are as follows:
1. Load AGENT-SNMP-CONFIG-MIB from the mibs directory present under .
2. Choose the node ruleTable under this MIB.
3. Define the rules by setting the values for the various rows of the Rule table. The various fields of the Rule table are discussed below:
Rule Table
The various rows of the Rule table that need to be configured for defining a rule are as follows:
• Rule ID: An entry to index the table (not applicable to HTTP manager).
• Rule OID: The OID to be monitored. For table attributes, the OID of the table must be specified.
• Rule Type: The type of the rule. This can be "greaterThan(1)", "range(2)", "stringEquals(3)", "stringContains(4)", "isChanged(5)", or "tableRowAdded(6)". The rule type "isChanged" is not applicable to table attributes.
• Rule Integer Value: The integer threshold value for the rule.
• Rule Integer Lower Value: The lower integer value if the rule type is "Range".
• Rule String Value: The String value to be checked if the rule type is other than range or absolute.
• Rule Message String: The user message that has to appear along with the trap. The value of the attribute that is monitored is automatically appended to this message in the trap/notification.
• Rule Polling Period: The polling period for the rule in seconds.
• Mail Status: The status of the e-mail notification. If this is enabled then an e-mail is sent to notify the configured recipients. Otherwise, only the alerts are sent to the managers.
• Rule Row Status: The row status of the table. This can be "active(1)", "notInService(2)", "notReady(3)" "createAndGo(4)", "createAndWait(5)", or "destroy(6)" (not applicable to HTTP manager).
|[pic] |Note: |
| |For configuring rules of the type "tableRowAdded", the tables must have integer index values. |
| |While configuring rules for table attributes through SNMP, specify the ruleOID before specifying the ruleType. |
Configuring E-mails
To configure e-mail notification, follow the procedure given below:
1. Connect to the Web console.
2. Choose the "Runtime Rules" tab.
3. Click the "Configure E-Mail" option on the top right corner of the window.
4. Specify the IP address or the host name of the SMTP server in the "SMTP Host IP" field.
5. Specify the sender's e-mail address in the "From" field.
6. Specify the recipients' e-mail addresses with a comma separator in the "To" field. Maximum of 25 recipients can be specified in this field.
7. Click the "Update" button to finish configuring.
Alternatively, you can also follow the steps given below to configure e-mail notification:
1. Edit the email.prop file under the agent/conf directory.
2. Specify the IP address or the host name of the SMTP server in the SMTP_ADDRESS field.
3. Specify the sender's e-mail address in the FROM_ADDRESS field.
4. Specify the recipients' e-mail addresses with a comma separator in the TO_ADDRESS field. Maximum of 25 recipients can be specified in this field.
The e-mail notifications are sent with the Rule Message string as the subject of the mail and the corresponding alert details as the body of the mail.
|[pic] |Note: |
| | |
| |The e-mail notification can be sent only if the Mail Status is enabled. |
Configuring SNMP Manager Table through HTTP
Apart from configuring the rule table and the e-mails, you can configure the SNMP Manager list (Trap Forwarding table) for receiving SNMP traps (v1 and v2c) from the Web console itself. The procedure to configure the Trap Forwarding table is as follows:
1. Connect to the Web console.
2. Choose the "Runtime Rules" tab.
3. Select the "Manager List" option from the drop down menu.
4. Click "Add New Entry" to add an SNMP manager to whom the SNMP traps must be sent in addition to the default manager listed.
5. Specify the manager host IP address in the "Manager Host" field.
6. Specify the port where the manager host listens for SNMP traps in the "Manager Trap Port" field.
7. Specify the manager community in the "Manager Community" field.
8. Choose the SNMP version (v1 or v2c) from the combo box in the "version" field.
9. Click "Add Entry" to add the specified manager to the list of managers for whom the SNMP traps are sent.
Similarly, you can add as many managers as desired to the Manager list. You can also delete the managers added.
Integrating with HP OpenView
[pic]
• Overview
• Configuring HP OpenView
• Loading the MIB
• Querying the MIB
• Viewing SNMP Traps
[pic]
Overview
AdventNet Micro Agent for MySQL can easily be integrated with standard NSM consoles, such as HP OpenView, IBM Tivoli, CA Unicenter, etc. thus providing quick integration of the agent with existing management solutions. The following paragraph provides the guidelines to integrate the MySQL agent with HP OpenView.
For managing the MySQL server through HP OpenView, you must first configure it to the host and port where the agent runs and load the ADVENTNET-MYSQL-MIB from the /mibs directory provided by AdventNet. You can then make queries on the MIB, configure, and view SNMP traps through HP OpenView. All the above mentioned tasks are discussed in the subsequent sections of this topic.
Configuring HP OpenView
To configure HP OpenView, follow the steps given below:
1. Execute the xnmsnmpconf.exe file from the /bin directory.
2. Specify the required details in the appropriate fields of the dialog box that opens up. The following are the fields listed in this dialog box:
o Community
o Set Community
o Time Out
o Retries
o Remote Port
o Status Polling (in minutes/hours)
Loading the MIB
To load the ADVENTNET-MYSQL-MIB in HP OpenView
1. Execute the xnmloadmib.exe file from the /bin directory.
2. Browse and load the ADVENTNET-MYSQL-MIB through the load dialog box that pops up.
Querying the MIB
1. Execute the xnmbrowser.exe file from the /bin directory. This opens a dialog box.
2. Specify the appropriate details in the respective fields (listed below) of the dialog box:
1. Name or Address (the hostname or the ip address where the agent runs)
2. Community Name
1. Select the OID to be queried and click the Start Query button.
1. Enter a value in the "SNMP Set value" field and click the SET button if you want to set any value for an object.
The following image shows a sample query through HP OpenView:
[pic]
Viewing SNMP Traps
1. Configure the events using the Events Configuration wizard that gets invoked on executing the xnmtrap.exe file from the /bin directory.
2. View the various events emitted by invoking the xnmevents.exe file from the /bin directory.
The following image shows a sample trap received through HP OpenView:
[pic]
Troubleshooting
Some of the problems that you might encounter during the course of deploying the MySQL agent and managing the MySQL server are listed below. The cause of the snag and the key to its resolution are offered to prevent you from facing a deadlock.
1. Problem: Unable to start the agent in Unix systems. The following error occurs when trying to start the agent in Unix systems:
Error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory
Cause: This happens when the MySQL client libraries are not present under /usr/lib or the path specified by LD_LIBRARY_PATH.
Solution: Install the libmysqlclient.so under /usr/lib or the path specified by LD_LIBRARY_PATH.
2. Problem: The tables , such as Slow Query table, Update Query table, General Query table, and Error table are empty.
Cause: When the AdventNet SO/DLL is not deployed in the MySQL server, all the mentioned tables will not be exposed.
Solution: Deploy the AdventNet SO/DLL in the machine where MySQL server is running at the location specified below:
For Windows: Deploy the adventnetmma.dll file present under /lib into the %WINDIR%\system directory of Windows.
For Linux/Solaris: deploy the adventnetmma_linux.so/adventnetmma_solaris.so file present under /lib into the /usr/lib directory of Linux/Solaris.
3. Problem: Inconsistent restarts with MySQL 3.23.52 in Linux machines.
Cause: When the agent connects to the MySQL server, there are some problems in resolving the host name.
Solution: Use the --skip-name-resolve option while starting the MySQL server.
Known Issues and Limitations
[pic]
• Known Issues
• Limitations
[pic]
We, at AdventNet take all efforts to ensure that our customers do not waste their time and resources unnecessarily. This section lists out the known issues available with the product at the time of the release. The limitations have also been mentioned.
Known Issues
1. The following error message is thrown in Unix systems when the MySQL memory is low. Due to the lack of memory, the agent cannot load the MySQL shared libraries in the host machine which affects some of the functions of the agent.
|Out of memory; Check if mysqld or some other process uses all available memory. If not you may have to use 'ulimit' to |
|allow mysqld to use more memory or you can add more swap space |
One of the possible solutions to this is removing the option -Sg from the safe_mysqld script (usually found under the /usr/bin directory)
2. When the agent is started for the first time after reinitializing it, the MySQL server 4.0.15 gets restarted. Due to the restart of the server, you must restart the agent for a proper functionality. This does not happen if the MySQL server is dynamically linked.
Limitations
1. The MySQL user specified in the conf file must have all the following privileges to start the MySQL agent:
1. Insert
2. Update
3. Delete
4. Select
5. Create
6. Drop
7. Process
1. The MySQL agent cannot be run as a v1/v2 agent as it is by default, a v3 agent. However, it can process the v1/v2 requests.
1. The database administration activities such as querying or modifying the databases are not supported by Micro Agent for MySQL.
2. Dynamic enabling or disabling of the log files is not possible with Windows and Solaris 5.8. This is also applicable to Unix systems with MySQL 4.0.x versions.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
Related searches
- diy printed tea towels
- custom printed tea towels
- printed tea towels recipes
- wholesale printed tea towels
- custom printed dish towels
- printed kitchen towels wholesale
- recipes printed on dish towels
- recipes printed on tea towels
- printed flour sack towels
- printed tea towels
- tea towels with recipes printed on them
- custom printed kitchen towels