Monitoring, Version 6.2
There are a few factors to consider when determining the location of your Tivoli Monitoring components. The primary factors are firewalls and slow network connections. Before discussing the locations of these components in the data center, you must understand these components, the roles that they play, and what affects the load on these components.
The Tivoli Monitoring components and data paths to the Tivoli® event management products are illustrated in Figure 2.
Tivoli Monitoring installation requires the following optional and mandatory components:
The Tivoli Enterprise Monitoring Server, referred to as the monitoring server, is the first component installed to begin building the IBM® Tivoli Monitoring Services foundation. The monitoring server is the key component on which all other architectural components directly depend. The monitoring server is the collection and control point for alerts received from agents. The monitoring server collects the performance and availability data of the agents.
The monitoring server is also responsible for processing heartbeats to track the online or offline status of monitoring agents. A monitoring agent sends a heartbeat every 10 minutes (this is configurable). If a heartbeat signal is not received from an agent within the heartbeat interval (plus a 3-minute grace period), the monitoring server considers the monitoring agent to be offline. The online or offline status of the monitoring agent is also called the managed system status.
In addition to the roles described in the previous paragraphs, the hub monitoring server also provides the following functions:
There are two types of monitoring servers: the hub monitoring server and the remote monitoring server. The hub monitoring server is the focal point for the entire Tivoli Monitoring environment. The hub monitoring server is under a significant load. Work on the hub includes connections from the remote monitoring server, authentication, situations, policies, and workflows.
The hub monitoring server stores, initiates, and tracks all situations and policies and is the central repository for storing all active conditions and short-term data on every Tivoli Enterprise Monitoring Agent (monitoring agent). The hub monitoring server is also responsible for initiating and tracking all generated Take Action commands.
The monitoring server storage repository is a proprietary database format, referred to as the Enterprise Information Base (EIB), that is grouped as a collection of files located on the monitoring server. These files start with a file name prefix qa1 and are located in the following directories:
On UNIX and Linux: <installation_dir>/tables/<tems_name>
On Windows: <installation_dir>/cms
Where <installation_dir> specifies the Tivoli Monitoring installation directory and <tems_name> specifies the Tivoli Enerprise Monitoring Server name.
Place the hub monitoring server inside the data center on a high-performance network (100 Megabits per second or higher). Connectivity between the Tivoli Enterprise Portal Server and hub monitoring server as well as between the hub monitoring server and most of the remote monitoring server must be fast and reliable. For large environments, use a multi-processor server. Some hardware configuration guidance is identified in Sizing your Tivoli Monitoring hardware.
The remote monitoring server is a collection point for the agents that are connected to that remote monitoring server. Certain types of situations run on the remote monitoring server. The load on the remote monitoring server is typically low. Load is driven higher if historical data is collected at the remote monitoring server instead of at the agents.
Placement of the remote monitoring server depends on a few factors. Plan your firewalls early to ensure that communications can be established between the Tivoli Monitoring components with only a modest number of holes in the firewall.
By locating the Warehouse Proxy agent on the same computer as the remote monitoring server, you can negotiate NAT environments with their historical data collection. For remote locations connected over a slow network, place the remote monitoring server at the remote location if there are significant numbers of computers. For remote locations with just a few computers, it doesn't make sense to place a remote monitoring server at the remote location.
The Tivoli Enterprise Portal Server, referred to as the portal server, is a repository for all graphical presentation of monitoring data. The portal server database consists of all user IDs and user access controls for the monitoring workspaces. The portal server provides the core presentation layer, which allows for retrieval, manipulation, analysis, and pre-formatting of data. The portal server manages data access through user workspace consoles.
The portal server keeps a persistent connection to the hub monitoring server, and can be considered a logical gateway between the hub monitoring server and the Tivoli Enterprise Portal client (portal client). Any disconnection between the two components immediately disables access to the monitoring data used by the portal client.
Locating the portal server in the same LAN segment as the hub monitoring server provides optimal performance when using the Tivoli Enterprise Portal graphical user interface (GUI). For users with multiple data centers, if the network connectivity is good, then one portal server is sufficient. If the network connection between data centers has significant latency, then additional portal servers can be placed at each data center.
Caution must be taken when using this approach because there can be only one read-write master portal server. Other portal servers must be used in a read-only manner. Read-only means that users must not create and edit objects like situations, workspaces, and policies. Customization must be replicated from the master portal server to the read-only portal server.
When you install the portal server, a proprietary integrated Web server is installed for use with the portal client in browser mode. Depending on the network topology and possible security implications, this can affect the construction of the solution. To avoid security issues, you may install an external Web server on the same computer where you installed the portal server. If there will be more than ten concurrent portal clients connected to the portal server, an external Web server can improve scalability of the portal server. For additional details, refer to IBM Tivoli Monitoring Installation and Setup Guide.
The Tivoli Enterprise Portal client, also known as the portal client, is a Java-based user interface that connects to the portal server to view all monitoring data collections. The portal client is the user interaction component of the presentation layer. The portal client brings all of these views together in a single window so you can see when any component is not working as expected. The client offers three modes of operation, that all work with Java:
See Table 3 for more information.
The browser client is automatically installed with the Tivoli Enterprise™ Portal Server (on the Web server that is integrated with the portal server). The desktop client is supported on Windows and Linux operating systems. You can install the desktop client from the IBM Tivoli Monitoring installation media or you can use IBM Web Start for Java to download the desktop client from the Tivoli Enterprise Portal Server. To find out what browsers are supported see the Platform support matrix.
Using browser mode or Web Start clients allow you to perform maintenance updates in a single location. If the desktop client is installed from installation media, maintenance must be installed on each computer. If Web Start for Java is used to download and run the desktop client, you gain the performance advantage of the desktop client along with the convenience of centralized administration from the server. Additional performance gains can be made by modifying the Java heap settings. (For more details on the heap settings see Locating and sizing the Portal client.) Unless you want a very secure environment where there are no downloads, use IBM Web Start for Java for obtaining the desktop client.
Many customers install the desktop client on Citrix for the following reasons. Citrix allows for better GUI performance for users at remote locations. In addition, some users do not allow the Tivoli Enterprise Portal client's prerequisite Java version to be installed on desktop computers. By using Citrix, users do not have to install Java on the user's desktop systems.
Monitoring agents are installed on the system or subsystem that requires data collection and monitoring. Monitoring agents are responsible for gathering data on various properties, or attributes, of a monitored system, subsystem, application, or database, the managed system, and for sending that data to the monitoring servers. Monitoring agents test for specified conditions, or situations, by periodically comparing attribute values against specified thresholds. When the tested values match or exceed the thresholds, monitoring agents notify the monitoring server, and alert are displayed in the portal client.
The following scenarios prompt the monitoring server to gather data samples from the agents:
When a Tivoli Enterprise Portal workspace is opened or refreshed, the portal server sends a sampling request to the hub monitoring server. The request is passed directly to the monitoring agent, if there is a direct connection, or indirectly through the remote monitoring server to which the monitoring agent connects. The monitoring agent takes a data sampling and returns the results through the monitoring server and portal server to the portal workspace.
A situation can have a sampling interval as frequent as once every 30 seconds or as seldom as once every three months. When the interval expires, data samples are requested from the agent in which the returned values are compared with the condition described in the situation. If the values meet the condition, an event is generated and corresponding alerts or automation are initiated.
The collection of historical data can be configured to send the data to the remote monitoring server at regular intervals or, transfer data collections from the agent to the Warehouse Proxy agent at hourly or daily intervals. If firewall restrictions are disabled or minimal, configure all of the agents to transfer directly to Warehouse Proxy agent. If firewall security is an issue, you can either use the firewall gateway or place the Warehouse Proxy agent on the remote monitoring server where a network connection is already established.
Typically, there are no unique considerations regarding the placement of monitoring agents. The main consideration is whether to store historical data on the agent or on the remote monitoring server. For environments with slow network connections between the agent and the remote monitoring server, storing the data on the monitoring server spreads out the network load of transmitting the historical data. Doing this places a higher demand on the remote monitoring server, and effectively lowers the number of agents that can be managed from the remote monitoring server.
For short-term historical requests of agent data less than 24 hours, the request does not have to cross the slow link, but this savings is offset by the remote monitoring server having to read a larger amount of data from disk (from all agents of that agent type connected to the remote monitoring server) to find the results for the desired agent. For environments with network events that cause agents to failover to a secondary monitoring server, this option may be a poor choice. When an agent fails over, it loses access to the short-term historical data because the data is located on the primary remote monitoring server and the agent is connected to the backup remote monitoring server.
By installing the operating system agent on the system first, the remaining agents can be deployed remotely using the Add agent capabilities.
The Warehouse Proxy agent is a unique agent that performs only one task: collecting and consolidating all historical data from the individual agents to store in the Tivoli Data Warehouse. If you are using the Tivoli Data Warehouse, at least one Warehouse Proxy agent is required for each Tivoli Monitoring installation.
The Warehouse Proxy agent uses ODBC (open database connectivity) on Windows and JDBC (Java Database Connectivity) on AIX® and Linux to write the historical data to a supported relational database. The Warehouse Proxy agent is typically placed on the same LAN segment as the warehouse database, which allows for the best throughput to the database. You can also place the Warehouse Proxy agent on the same server as the warehouse database.
For larger environments or deployments with multiple data centers, use multiple Warehouse Proxy agents. You can have as many as one Warehouse Proxy agent per monitoring server in your monitoring environment. Placing the Warehouse Proxy agent on the same server as the remote monitoring server reduces the number of servers running Tivoli Monitoring components. This placement also simplifies the configuration because the Warehouse Proxy agent can be configured to service agents connected to the local monitoring server. If the server running the remote monitoring server goes down and the agent fails over to a secondary monitoring server, the agent should be able to upload historical data through the Warehouse Proxy agent on the secondary monitoring server. This placement also has the advantage of limiting the number of agents that upload historical data through a single Warehouse Proxy agent.
NAT environments require specific considerations. The agents receive the IP address of the Warehouse Proxy agent from the monitoring server. In a NAT network, you must ensure that the agents receive the correct IP address of the Warehouse Proxy agent. To ensure that the agents can communicate with the Warehouse Proxy agent, place the Warehouse Proxy agent on the same servers as the remote monitoring server. This placement is required only for the agents that are connected to a NAT network.
For information on configuring the historical collection, see the IBM Tivoli Monitoring User's Guide.
The Summarization and Pruning agent is a unique agent that performs the aggregation and pruning functions for the historical detailed data on the Tivoli Data Warehouse. The Summarization and Pruning agent has advanced configuration options that enable customization of the historical data storage. One Summarization and Pruning agent manages the historical data in the Tivoli Data Warehouse.
The Summarization and Pruning agent can be placed on the Tivoli Data Warehouse database server to minimize network transmission delay during its processing. If the Summarization and Pruning agent is placed on a separate server, ensure that it connects to the database server with a high-speed network connection of 100 Megabits per second or higher. For large environments, the database server must have at least four processors and a large number of disks, with maintenance by a skilled database administrator.
Performance enhancements were added into the Summarization and Pruning agent for the Tivoli Monitoring V6.2 release. Some of the enhancements require a new database schema. The warehouse will function without the schema changes, but will not take advantage of some of the performance improvements. For the enhancements that do not require a new schema, there are minor database changes that are documented in the IBM Tivoli Monitoring Installation and Setup Guide. In a new Tivoli Monitoring environment, the warehouse database schema will be created using the new schema. If the Tivoli Monitoring V6.2 environment was updated, the database will continue to use the old schema and will not benefit from the improvements. If you want to take advantage of the performance improvements in an upgraded environment, you will need to create a new warehouse database with a new schema. If desired, you can migrate the data from your old warehouse database into your new warehouse database.
The Tivoli Data Warehouse is the storage database that contains all of the warehoused (long-term) historical data. A Warehouse Proxy agent must be installed to leverage the Tivoli Data Warehouse function within the environment. In large-scale deployments, a Tivoli Data Warehouse can be shared among monitoring installations.
Also called IBM Tivoli Monitoring 5.x Endpoint Agent, this integration agent enables the collection and visualization of IBM Tivoli Monitoring 5.x resource models in the Tivoli Enterprise Portal. The visualization is the direct replacement for the Web Health Console.
Additionally, the agent provides the roll-up function of IBM Tivoli Monitoring 5.x metrics into the Tivoli Data Warehouse.
Tivoli Enterprise Console® events can be forwarded from Tivoli Monitoring V6.2 to Tivoli Enterprise Console Version 3.9. The events are forwarded from the hub monitoring server to the Tivoli Enterprise Console server or Tivoli Enterprise Console gateway. Make sure that firewall ports are opened between the hub monitoring server and Tivoli Enterprise Console servers. By default, the Tivoli Enterprise Console uses port 5529.
The Tivoli Enterprise Console event synchronization component sends updates to situation events back to the monitoring server and are then forwarded to the portal server. Actions performed at the Tivoli Enterprise Console for Tivoli Monitoring situations are reflected in the Tivoli Enterprise Portal Server, this is an optional component that must be installed on your Tivoli Enterprise Console server.
If you are already using Netcool/OMNIbus to monitor events from other sources in your enterprise, you can also view and manage situation events from a Tivoli Enterprise Monitoring Server in the Netcool/OMNIbus console. Event integration requires Netcool/OMNIbus V7.x and Netcool/OMNIbus V7.x Probe for Tivoli EIF.
Situation events are sent to Netcool/OMNIbus Probe for Tivoli EIF using the Tivoli Event Integration Facility (EIF) interface. The Netcool/OMNIbus EIF Probe receives events, maps them to the Netcool/OMNIbus events format, and then inserts into Netcool/OMNIbus ObjectServer. When an Netcool/OMNIbus user acknowledges, closes, or reopens a situation event, Netcool/OMNIbus sends those changes to the originating monitoring server through the event synchronization component. For information on forwarding events to Netcool/OMNIbus and installing the event synchronization component, see the IBM Tivoli Monitoring Installation and Setup Guide.
By default, the EIF Probe listens on the default port (5529).
Using the firewall gateway, you can traverse even the most complex firewalls. Using the IP PIPE or IP SPIPE protocols, the Tivoli Monitoring software can traverse most firewall configurations. In most cases, the firewall gateway is not necessary.
For detailed information on installing and configuring the firewall gateway go to http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?topic=/com.ibm.itm.doc_6.1/itm_firewall.htm.
The Tivoli Universal Agent is a customizable agent that allows you to monitor many different types of hardware, operating systems, and applications. The Tivoli Universal Agent has several different data providers that collect metric data. Some of the data providers gather data from a source running locally on the server (Script, File) while others (ODBC, SNMP, Socket, API, Post) collect data either locally or remotely.
From a networking and connection perspective, there are two aspects to the placement of a Tivoli Universal Agent. The Tivoli Universal Agent connects into a monitoring server just like any monitoring agent. You can use any of the supported protocols such as IP.UDP and IP.PIPE. In addition, for the data providers with remote monitoring capabilities, you must consider the network connection between the Tivoli Universal Agent and the monitored system. Each data provider uses a different access method, so you must consider different ports and protocols.
For optimal performance, place the Tivoli Universal Agent in close LAN proximity to the computer that is gathering the data. Some Universal Agents are very lightweight and can be configured to remotely monitor over slower WAN links. Other Universal Agents gather large volumes of data and can be run only on a LAN environment. As you create your custom monitoring solution, calculate the expected network traffic by examining the metrics being collected and the data collection interval.
For more information about the Tivoli Universal Agent, refer to the IBM Tivoli Monitoring Universal Agent User's Guide.
The Agent Builder, introduced in Tivoli Monitoring V6.2, is a wizard that makes it easier to build custom monitoring solutions. Using mostly point and click capabilities, the Agent Builder allows you to create a monitoring agent using multiple data providers such as WMI, Perfmon, Log scraping, scripts, and process monitoring. Over time additional data providers will be added to the Agent Builder.
Monitoring agents created using the Agent Builder have two advantages over agents based on the Tivoli Universal Agent. First, the Agent Builder monitoring agents tend to run with lower CPU utilization than an equivalent Tivoli Universal Agent. Second, you do not need to worry about Tivoli Universal Agent versioning.
However, the Agent Builder is not a complete replacement for the Tivoli Universal Agent. The Tivoli Universal Agent has some key capabilities that Agent Builder monitoring agents do not have. For example, the Tivoli Universal Agent has an ODBC data provider; the Agent Builder does not. A single Tivoli Universal Agent can be configured to monitor multiple remote systems, using several types of data providers. The Agent Builder can be configured to monitor multiple remote systems, but you must create one agent instance for each remotely monitored server.
For more information about Agent Builder, refer to the IBM Tivoli Monitoring Agent Builder User's Guide.
[ Top of Page | Previous Page | Next Page | Contents | Index ]
