Realtime Web Services Monitoring Deployment Options

By: Thomas Bayer
Date: 09/07/2009

To monitor Web Services in realtime data about invocations has to be recorded. The open source monitoring tool Membrane Router makes it possible to realize several of different topologies to collect the necessary data from a service oriented architecture. This article introduces a centralized approach and two decentral ones.

Figure 1: Sample Service Landscape

The services are provided by the hosts server1 and server2. They are accessed by two workstations. Deployed at workstation1 is a Customer Relationship Management application client that uses a ServiceA of the CRM application. The CRM application delivers events back asynchronously to the CRMGUI using a callback service. The CRM application is also used by the OrderGUI at worstation2. The Order application on host server2 is using a service of a finance application running on the same host server2.

1. Centralized Monitoring

All Web Services traffic can be routed through one central hub. In order to track each call every client has to route this messages through the central router. In figure 2 client 6 accesses ServiceD over the membrane router even they are deployed on the same host.

Figure 2: Centralized Monitoring

The centralized monitoring is easy to install and gives the administrator one place to monitor and control the service network. The centralized approach is simple and powerful. The disadvantages are a slightly decreased performance and the single point of failure.

1.1 Pros and Cons

+ Simple management and deployment

+ Services can be moved between servers easily

+ A Membrane Registry instance is not needed to gather performance and availability statistics

- Single point of failure

- Increased latency

1.2 Rules

Table 1 lists the routing rules for a centralized monitoring. You can use the Membrane Monitor GUI to create these rules.
The first three rules forward messages of the proper service. The last one is a forwarding rule for the callback service of the CRMGUI client.

Port	Path	Method	Target Host	Target Port
80	/CRM/.*	*	server1	80
80	/Order/.*	*	server2	80
80	/Finance/.*	*	server2	80
80	/CRMGUI/.*	*	workstation1	80

Table 1: Rules for a centralized Monitoring

Because each service is accessed over the host the router is running on the URL´s of the services endpoints change. The URLs of the services in our example are therefore:

http://router.predic8.com/CRM/Service
http://router.predic8.com/CRM/ServiceB
http://router.predic8.com/Order/ServiceC
http://router.predic8.com/Finance/ServiceD
http://router.predic8.com/CRMGUI/CallbackService

2. Decentralized Monitoring using Agents

There are different possibilities for a decentralized Web Services monitoring. In the following sections we discuss the following options:

Monitoring of Servers
Monitoring of Servers and Clients

The decision for one option is dependent on the requirements and the motivation for the monitoring.

2.1. Monitoring of Servers

To prove that the services are working as guaranteed by a service level agreement a realtime monitoring of the servers can be an option. An instance of the router is deployed on every computer hosting services. See figure 3:

Figure 3: Monitoring Agents at server side

Because there are as many Membrane Router installations as servers the data about the service invocations is scattered on different computers. A central Web Services registry can accumulate all that data and compute performance and availability statistics.

2.1.1. Pros and Cons

+ High Performance

+ No single point of failure

+ Easy to deploy if there are few servers and many clients

- More deployment effort

- Client failure is not monitored

- Only half of the network failures are monitored

- Does not answer the questions if the client or the network failed

2.1.2. Rules

Every instance of the Membrane Router needs its own routing configuration. Table1 2 list the rules for the agent deployed on server1.

Port	Path	Method	Target Host	Target Port
80	/CRM/.*	*	localhost	8080
80	/CRMGUI/.*	*	workstation1	80

Table 2: Rules for Server1

The first rule sends service requests to the CRM application. The router cannot run on the same port as the application server hosting the CRM application. Therefore the port for the CRM application was changed from 80 to 8080 as shown in figure 4.

Figure 4: TCP Ports for the Router and Application Server

The second rule forwards callbacks to the client program on workstation1. Now let´s have a look at the configuration for the agent running on server2.

Port	Path	Method	Target Host	Target Port
80	/ORDER/.*	*	localhost	8080
80	/Finance/.*	*	localhost	8080

Table 3: SOAP routing rules for server2

The two rules resemble the one for the CRM application on the server1. Messages are accepted on port 80 and forwarded to port 8080. If the ports of the Finance application changed as in the example the endpoint address of Client 6 doesn´t need any modifications. Because now the router is running at port 80 and forwarding requests from Client 6 to the finance application.
The clients on workstation1 and workstation2 do not need any modifications because the endpoint URLs of the services have not changed. This deployment options is advisable if there are few servers and many clients. The requirements specified in a SLA can be monitored and it can be documented that the service levels where met from the servers. But if something goes wrong at the network it is not monitored. To monitor even network failures agents can be installed at the clients too.

2.2. Monitoring of Servers and Clients

In critical environments it can be important to know exactly what went wrong and who is responsible for the failure. In our last deployment every node hosting clients or services is monitored by an instance of a Membrane Router.

Figure 5: Decentralized Monitoring of Clients and Servers

This is a complicated setup but it captures most of the failures and it is clear who is responsible for a service outage.

2.2.1. Rules

The rules for server1 and server2 are the same as in the previous setup but this time we need additional rules for the agent routers deployed on the workstations. Let´s have a look at the rules for workstation1:

Port	Path	Method	Target Host	Target Port
80	/CRM/.*	*	server1	80
80	/CRMGUI/.*	*	localhost	8080

Table 4: Rules for workstation1

The first rule forwards requests to the CRM application. But to direct traffic through the agent the endpoint URL of ServiceA has to be changed in the CRMGUI client from

http://server1/CRM/ServiceA

To

http://localhost/CRM/ServiceA

The second rule is for the CallbackService.

2.2.2. Pros and Cons

+ The monitor captures almost all failures

+ The monitoring delivers a culprit for outage

- The setup is complicated

3. Summary

What the proper monitoring topology is depends on the requirements and the environment. Using Membrane Monitor you can realize central and decentral settings. Download the monitor and test it.