Overview
Users of Aurea Monitor may experience confusion regarding the categorization of IN and OUT values in their system. This confusion can extend to discrepancies in the fault counts between IN and OUT, as well as how these values are represented in the audit database. The system acts as a Web Service (WS) gateway, with various consumers sending requests to various backends via the system. Users may seek clarity on how errors should be categorized and displayed in this specific configuration. They may also want to understand how the four parts of the flow (outbound request, inbound request, inbound reply, outbound reply) are counted and how these are represented in the IN and OUT categories.
Solution
In the context of Aurea Monitor, the terms 'upstream' and 'downstream' are used to describe the flow of messages between services in a distributed system. Here's how these concepts map to the IN and OUT directions in Aurea Monitor Statistics (AMS) and how the four parts of the flow are counted:
- Outbound Request: This is a request message sent from a service to another service. In the context of AMS, this is considered as an OUT operation on the consumer (upstream) side because the consumer is sending out a request.
- Inbound Request: This is the same request message, but from the perspective of the service receiving it. In AMS, this is considered as an IN operation on the provider (downstream) side because the provider is receiving an incoming request.
- Inbound Reply: After processing the request, the provider sends a reply back to the consumer. This reply is considered as an IN operation on the consumer (upstream) side in AMS because the consumer is receiving an incoming reply.
- Outbound Reply: From the perspective of the provider, the reply being sent back to the consumer is considered as an OUT operation in AMS because the provider is sending out a reply.
The mapping of upstream/consumer and downstream/provider to IN and OUT in AMS is based on the direction of the message flow relative to the service:
-
Consumer (Upstream) Side:
- Outbound Request: Counted as OUT because the consumer is sending a request.
- Inbound Reply: Counted as IN because the consumer is receiving a reply.
-
Provider (Downstream) Side:
- Inbound Request: Counted as IN because the provider is receiving a request.
- Outbound Reply: Counted as OUT because the provider is sending a reply.
An error in the outbound request or inbound reply on the consumer side could be reflected differently than an error in the inbound request or outbound reply on the provider side. The classification of errors as IN or OUT would follow the same logic as above, based on where the error occurred in the message flow and relative to the service (consumer or provider).
Summary
In Aurea Monitor, the IN and OUT values represent the direction of the message flow relative to the service. The outbound request and inbound reply are counted as OUT and IN respectively on the consumer side, while the inbound request and outbound reply are counted as IN and OUT respectively on the provider side. Errors can occur at any stage of the message flow and are classified as IN or OUT based on where they occurred in the message flow and relative to the service. To resolve discrepancies in the fault counts, it's necessary to review the specific configurations and implementations within the Aurea Monitor setup and the database statistics.
FAQ
-
What does IN and OUT represent in Aurea Monitor Statistics?
IN and OUT represent the direction of the message flow relative to the service. OUT refers to messages sent from the service, while IN refers to messages received by the service. -
How are errors classified as IN or OUT in Aurea Monitor?
Errors are classified as IN or OUT based on where they occurred in the message flow and relative to the service. An error in the outbound request or inbound reply on the consumer side is classified as OUT or IN respectively, while an error in the inbound request or outbound reply on the provider side is classified as IN or OUT respectively.