IMPORTANT: This documentation has been discontinued. Read the updated Monitor: Pipeline Metrics documentation on our new documentation portal.
The page Monitor: Pipeline Metrics generates detailed performance reports of pipelines, allowing a deeper and critical analysis of its main statistics.
Environment selector
At the top left of the screen, you can select the desired environment at any time on the page. When selecting the environment, the entire page is refreshed.
Period selector
On the right side, there is the selection of the desired period for the report, from 15 minutes to 7 days. You can also select a specific period of time.
Pipelines search bar
The page will refresh by selecting a pipeline. In this search form, type the name of the pipeline in which you want to view the reports.
Aggregation
The data reported in the graphs are aggregated as follows:
Averages or summations (depending on the metric) for all replicas of the pipeline chosen. In the list, we always provide a pipeline, in its Major version and to a given multi-instance (when applicable).
Only CPU and Memory graphics will present individual lines for each replica of the pipeline.
Deployments that use multiple replicas will display the number of executions per second, considering all replicas.
The name of the replica is displayed with the following label: pe-<realm>-<pipeline>-v-<versionMajor>-<hash>.This name is internal and should only be used for differentiation between replicas or for opening a call in the Digibee support.
When presenting the chart, the platform makes an account to know the best interval of minutes that will be consolidated at each point. The graph always will show a total of 30 points. Thus, for example, if the user selects a period of 15 minutes of data, the consolidated interval will be 30 seconds, for 1 hour, it will be every 2 minutes, and so on according to the table below:
Selected period | Consolidated period at one point |
15 minutos | 30 seconds |
1 hour | 2 minutes |
6 hours | 12 minutes |
1 day | 48 minutes |
7 days | 336 minutes |
Reports
Below it's presented how to analyze the reports presented on the page
Pipelines execution per second (eps)
The report shows the average number of executions per second consolidated in the selected period.
You can hover the mouse over the graph to view the completed runs in the selected range;
Pipeline message size (bytes)
The report shows the average size of the messages received and returned by the pipeline. The graph will always display two lines, one for the received message sizes and one for the message sizes returned by the pipeline. The line that defines the size of incoming messages has a label named [request] and the one that defines the size of returned messages has a label named [response].
We can use this data to check for any surpluses in the number of bytes of messages.
Pipeline CPU usage (%)
The report shows the CPU usage of all replicas of the pipeline, according to the size of its deployment. Each replica will be displayed as a new line on the graph.
The maximum percentage of the graph is related directly to the size of the implantation of the pipeline, as below:
Deployment Size | CPU | Maximum Value of the graph |
Small | 20% | 20% |
Medium | 40% | 40% |
Large | 80% | 80% |
Pipeline response time (ms)
The report brings an average time in milliseconds of the time it took the pipeline to produce a response. This metric is the average of all runs that occurred in the given time interval.
The execution time of a pipeline is measured from the moment the message is removed from the execution queue. If there is containment in the execution queue, this time will not be considered in the average response time of the pipeline.
To understand if there is containment in the pipeline execution queue, please review the metric "Pipelines messages in queue (messages)".
Pipeline Memory usage (%)
The report brings the memory usage data of the pipeline. This data is important to monitor if the size of the pipeline supports your demands. To avoid future problems, it is important to adapt the size of the pipeline with the usage of memory, an overload can lead to exhaustion of the available amount of memory and consequent recycling of the pipeline. This situation is reported as an "Out of Memory" error.
This graph shows a line for each replica of the pipeline deployed.
Note: The percentage of the graph is related directly to the size of the memory available for the execution of the pipeline. The deployment sizes of pipelines determine the amount of memory available:
Deployment Size | Capacity |
Small | 64MB |
Medium | 128MB |
Large | 256MB |
Note: The memory available for the pipeline is used for both message processing and to sustain the execution structures of a pipeline. Thus, the more complex the pipeline will be, the more memory it will use.
Pipelines currently running (inflights)
The report brings the number of simultaneous requests made to the pipeline. We can use this data to verify that the maximum number of requests made to the pipeline is being met. This metric includes the sum of all simultaneous requests in all replicas of the selected pipeline
In this case, the size of the deployment of the pipeline must be increased, allowing a greater number of simultaneous requests.
Simultaneous executions are calculated according to "scans" made by monitoring the pipelines. Thus, the metrics describe the number of simultaneous executions at the time the scan was made.
Pipeline messages in queue (messages)
The report brings the number of messages in the line of the pipeline the fewer messages in the queue, the better. We can relate this data to the Pipelines currently running (inflights) While this metric reports the number of messages waiting to be processed, the "Pipelines currently running" indicates those that are being processed.
This metric shows the total messages awaiting processing. All replicas of
the selected pipeline consumes messages from that same queue.
The number of queued messages indicates that the number of pipelines
replicas made available is failing to meet demand. For some scenarios, this
may be desirable, such as processing events to scale. For other scenarios,
the fact that there are queued messages indicates that the total
processing time is being degraded, since the messages cannot be processed
by the pipeline satisfactorily.