Monitoring the SAP TREX Server
The eG Enterprise embeds a specialized monitoring model for the SAP TREX server (see Figure 1), using which the performance of the critical services and components of the server can be tracked, issues affecting server-performance captured at the earliest, and the root-cause of the issues promptly traced and treated before it adversely impacts the business in the overall SAP environment.
Every layer depicted by Figure 1 is associated with a series of tests, each of which seeks to answer the following questions related to the performance of the SAP TREX server:
- Is the server accessible when a HTTP request is simulated?;
- What is the current configuration status of the RFC server?;
- How many threads were configured for the RFC server?;
- What is the current status of the RFC server?;
- What is the current CPU and disk usage of the SAP TREX server?;
- How well the search requests, indexing requests and merging requests were processed by the SAP TREX server?;
- How many indices were available in a location other than the default directory?;
- How many indices were valid?;
- How many indexes were valid in the Fast Search infrastructure module?;
- What is the maximum size allocated to the global dictionary and what is the current size of the global dictionary?;
- What is the current status of each index?;
- How effective was each index in search and query operations?;
- What is the current state of the queues within each queue group?;
- What is the current state of documents in the queues that are within each queue group?;
- How many threads are allocated to each service of the SAP TREX server?;
- How many threads are currently running, idle, suspended etc for each service?;
- How many messages of the configured patterns were added to the logs?
Since the Operating System, TCP and Network layers of Figure 1 have already been discussed in detail in the Monitoring Unix and Windows Servers document, let us now focus on the remaining layers in the forthcoming sections.