{section}
{column}

h1. Introduction

The Petals BC Soap is composed of several internal components. Each one can be monitored and provides several metrics:
* consumer side:
** incoming requests
*** incoming information request counter,
*** incoming web-service request counter,
*** incoming web-service request response times,
*** incoming unknown request counter,
** thread pool processing web-service requests,
* provider side:
** outgoing web-service request counter,
** outgoing web-service request response times,
** web-service client pool.

Moreover, as the Petals BC Soap is based on the Petals CDK, all common metrics are also provided, see [Monitoring Petals CDK-based components].

{column}
{column:width=35%}
{panel:title=Table of contents}{toc:outline=true}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list|showAnonymous=true|showCount=true|showLastTime=true}{panel}
{column}
{section}

h1. Monitoring the consumer side

h2. Monitoring the thread pool processing incoming requests

!petals-bc-soap-http-thread-pool.png|align=center!

See [Creating a graph using a simple data|How to create a graph with Cacti#Creating a graph using a simple data] to graph the stats of the thread pool processing incoming requests:
* Script/Command of the data input method: {{petals-cli.sh \-h <petals_host> \-n <petals_jmx_port> \-u <petals_jmx_user> \-p <petals_jmx_password> \-c \-- monitoring \-o petals-bc-soap \-f http-thread-pool \-- \-n <petals-bc-soap-id>}}
{tip}If you have only one Petals BC SOAP installed on your Petals node, the input field {{petals-bc-soap-id}} can be replaced by its value{tip}
* Output fields of the script/command:
|| Name || Description || Type ||
| {{AllocatedThreadsMax}} | The maximum number of allocated threads | GAUGE |
| {{AllocatedThreadsCurrent}} | The current number of allocated threads | GAUGE |
| {{IdleThreadsMax}} | The maximum number of idle threads | GAUGE |
| {{IdleThreadsCurrent}} | The current number of idle threads | GAUGE |
| {{MaxSize}} | The maximum size of the thread pool | GAUGE |
| {{MinSize}} | The minimum size of the thread pool | GAUGE |
| {{EnqueuedRequestsMax}} | The maximum number of requests that are enqueued waiting a thread to be processed | GAUGE |
| {{EnqueuedRequestsCurrent}} | The current number of requests that are enqueued waiting a thread to be processed | GAUGE |

h2. Monitoring the incoming requests

!petals-local-transporter-delivered-messages.png|align=center!

See [Creating a graph using a simple data|How to create a graph with Cacti#Creating a graph using a simple data] to graph the incoming requests:
* Script/Command of the data input method: {{petals-cli.sh \-h <petals_host> \-n <petals_jmx_port> \-u <petals_jmx_user> \-p <petals_jmx_password> \-c \-- monitoring \-o petals-bc-soap \-f incoming-http-requests-count \-- \-n <petals-bc-soap-id> \-r}}
{tip}If you have only one Petals BC SOAP installed on your Petals node, the input field {{petals-bc-soap-id}} can be replaced by its value{tip}
* Output fields of the script/command:
|| Name || Description || Type ||
| {{Information}} | Number of information request received | COUNTER |
| {{Unknown}} | Number of unknown request received | COUNTER |
| {{WS}} | Number of web-service request received | COUNTER |

h2. Monitoring the incoming web-service requests per operation and execution status

!incoming-ws-requests-count.png|align=center!

See [Creating a graph using a data query|How to create a graph with Cacti#Creating a graph using a data query] to graph the stats about incoming web-service requests per operation:
* the data query definition to put in a file:
{code}
<interface>
<name>Get web-service request number of the BC Soap per operation</name>
<script_path>petals-cli.sh</script_path>
<arg_prepend>-h localhost -n 7700 -u petals -p petals -c -- monitoring -o petals-bc-soap -f incoming-ws-requests-count</arg_prepend>
<arg_index>-- -n petals-bc-soap --list-operations</arg_index>
<arg_query>-- -n petals-bc-soap --query-operations</arg_query>
<arg_get>-- -n petals-bc-soap --query-operations</arg_get>
<output_delimeter>!</output_delimeter>
<index_order>filterName</index_order>
<index_order_type>alphanumeric</index_order_type>
<!--index_title_format>|chosen_order_field|</index_title_format-->

<fields>
<filterName>
<name>Operation name</name>
<direction>input</direction>
<query_name>NAME</query_name>
</filterName>
<succeeded>
<name>Succeeded invokation counter</name>
<direction>output</direction>
<query_name>SUCCEEDED</query_name>
</succeeded>
<error>
<name>Failed invokation counter</name>
<direction>output</direction>
<query_name>ERROR</query_name>
</error>
<fault>
<name>Faulty invokation counter</name>
<direction>output</direction>
<query_name>FAULT</query_name>
</fault>
<pending>
<name>Pending invokation counter</name>
<direction>output</direction>
<query_name>PENDING</query_name>
</pending>
</fields>
</interface>
{code}
* Output fields of the script/command:
|| Name || Description || Type ||
| {{succeeded}} | The succeeded invokation counter | COUNTER |
| {{error}} | The failed invokation counter | COUNTER |
| {{fault}} | The faulty invokation counter | COUNTER |
| {{pending}} | The pending invokation counter | GAUGE |

h2. Monitoring the response times of incoming web-service requests per operation and execution status

!incoming-ws-requests-response-times.png|align=center!

See [Creating a graph using a data query|How to create a graph with Cacti#Creating a graph using a data query] to graph the stats about response times of incoming web-service requests per operation:
* the data query definition to put in a file:
{code}
<interface>
<name>Get web-service response times of the BC Soap per operation</name>
<script_path>petals-cli.sh</script_path>
<arg_prepend>-h localhost -n 7700 -u petals -p petals -c -- monitoring -o petals-bc-soap -f incoming-ws-requests-response-times</arg_prepend>
<arg_index>-- -n petals-bc-soap --list-operations</arg_index>
<arg_query>-- -n petals-bc-soap --query-operations</arg_query>
<arg_get>-- -n petals-bc-soap --query-operations</arg_get>
<output_delimeter>!</output_delimeter>
<index_order>filterName</index_order>
<index_order_type>alphanumeric</index_order_type>
<!--index_title_format>|chosen_order_field|</index_title_format-->

<fields>
<filterName>
<name>Operation name</name>
<direction>input</direction>
<query_name>NAME</query_name>
</filterName>
<succeededMin>
<name>Succeeded invokation: Min response time</name>
<direction>output</direction>
<query_name>SUCCEEDED_MIN</query_name>
</succeededMin>
<succeededAvg>
<name>Succeeded invokation: Avg response time</name>
<direction>output</direction>
<query_name>SUCCEEDED_AVG</query_name>
</succeededAvg>
<succeededMax>
<name>Succeeded invokation: Max response time</name>
<direction>output</direction>
<query_name>SUCCEEDED_MAX</query_name>
</succeededMax>
<succeeded10p>
<name>Succeeded invokation: 10-percentil response time</name>
<direction>output</direction>
<query_name>SUCCEEDED_10P</query_name>
</succeeded10p>
<succeeded50p>
<name>Succeeded invokation: 50-percentil response time</name>
<direction>output</direction>
<query_name>SUCCEEDED_50P</query_name>
</succeeded50p>
<succeeded90p>
<name>Succeeded invokation: 90-percentil response time</name>
<direction>output</direction>
<query_name>SUCCEEDED_90P</query_name>
</succeeded90p>
<pendingMin>
<name>Pending invokation: Min response time</name>
<direction>output</direction>
<query_name>PENDING_MIN</query_name>
</pendingMin>
...
<errorMin>
<name>Failed invokation: Min response time</name>
<direction>output</direction>
<query_name>ERROR_MIN</query_name>
</errorMin>
...
<faultMin>
<name>Faulty invokation: Min response time</name>
<direction>output</direction>
<query_name>FAULT_MIN</query_name>
</faultMin>
</fields>
</interface>
{code}
* Output fields of the script/command:
|| Name || Description || Type ||
| {{succeededMin}} | The min response time of succeeded invokations | GAUGE |
| {{succeededAvg}} | The average response time of succeeded invokations | GAUGE |
| {{succeededMax}} | The max response time of succeeded invokations | GAUGE |
| {{succeeded10p}} | The 10-percentil response time of succeeded invokations | GAUGE |
| {{succeeded50p}} | The 50-percentil response time of succeeded invokations | GAUGE |
| {{succeeded90p}} | The 90-percentil response time of succeeded invokations | GAUGE |
| {{pendingMin}} | The min response time of pending invokations | GAUGE |
| {{pendingAvg}} | The average response time of pending invokations | GAUGE |
| {{pendingMax}} | The max response time of pending invokations | GAUGE |
| {{pending10p}} | The 10-percentil response time of pending invokations | GAUGE |
| {{pending50p}} | The 50-percentil response time of pending invokations | GAUGE |
| {{pending90p}} | The 90-percentil response time of pending invokations | GAUGE |
| {{errorMin}} | The min response time of failed invokations | GAUGE |
| {{errorAvg}} | The average response time of failed invokations | GAUGE |
| {{errorMax}} | The max response time of failed invokations | GAUGE |
| {{error10p}} | The 10-percentil response time of failed invokations | GAUGE |
| {{error50p}} | The 50-percentil response time of failed invokations | GAUGE |
| {{error90p}} | The 90-percentil response time of failed invokations | GAUGE |
| {{faultMin}} | The min response time of faulty invokations | GAUGE |
| {{faultAvg}} | The average response time of faulty invokations | GAUGE |
| {{faultMax}} | The max response time of faulty invokations | GAUGE |
| {{fault10p}} | The 10-percentil response time of faulty invokations | GAUGE |
| {{fault50p}} | The 50-percentil response time of faulty invokations | GAUGE |
| {{fault90p}} | The 90-percentil response time of faulty invokations | GAUGE |