When autoprobe determines back-ends, what is the different between metrics for a "System" and "Web Service"?
I have a backend system that shows up twice in metric browser (same address and same port) once labeled as a "System" and another time labeled as a "Web Service". The metrics recorded/graphed are not the same.
If a metric appears under "Web Service" the call is made using a SOAP or http library that we track. Therefore we can give it a meaningful name containing e.g. the WS namespace and operation or the http path. If the call appears as "System" we don't recognize the framework that is making the call and only register it at the Socket level.
Since an answer was provided to the question and no responses were given to the questions posed, marking as closed,
To answer your questions:
1) We are using v10.2.0.22
2) I don't have traces, so how would I go about getting a trace?
The app is running in WebSphere and the backend appears like these:
System webgate.someplace.com on port 443
WebService at https_//webgate.someplace.com_443.
Looking at the responses per interval graphs, they are pretty similar but the WebService graph has more data points than the System graph when I hover over a point. But the average response time graphs are not similar at all (one difference is the response time graph for System has some high spikes that the graph for WebService doesn't).
Guenter is unavailable this week. Please open a case to pursue for a quicker response
To add to Guenter's response, and hopefully not to contradict, shall we think about how this works on a technical level.
You have your Web Services calls and System (Socket) calls for the same transaction, both metrics actually relate to the same communication just on different levels.
You won't see the same amount of responses per interval, average response times because sockets will not be opened and closed as many times as web service calls will be made.
I don't write these applications, but I would assume it would be best practice for a socket to be opened, then as many web service calls to be made as possible (really that depends on who is using the application) but perhaps you reach a socket timeout as there haven't been any web service calls for a while, so the socket gets closed.
Then when more web service calls need to be made, the socket will first be opened.
I assume it is not a good practice for a socket to be opened and closed each time a web service call needs to be made.
I hope this explains why there is not a 1:1 correlation between the metrics (Responses per Interval etc) for the two metrics.
You would see a similar relationship between JDBC calls and Socket calls to databases, and it is possible to see just the System calls as outbound socket calls to another system, but no other related metrics.