Real-Time Metrics

Real-Time Metrics is an Observe product that provides you with real-time access to metrics, through charts, so you can analyze the events of your applications and products configured on Azion. It also helps you optimize the use of Azion products and how your content is delivered.

By analyzing data through Real-Time Metrics, you can check and track the behavior of your applications in near real time. Real-Time Metrics gives you the opportunity to:

• Gain insights on the performance of your application.
• Examine the availability of your content.
• Quantify accesses and traffic to your content.
• See bandwidth savings.
• Find security threats in real time.
• Troubleshoot problems in real time.
• Compare your application’s data through different data intervals.

Real-Time Metrics fetches your data and metrics using Azion GraphQL API and generates charts based on its response. The maximum time for data aggregation to occur is 10 minutes.

You can combine your metrics analysis with Real-Time Events to further inspect your logs.

See the first steps for Real-Time Metrics.

Grafana plugin

Real-Time Metrics also has an Azion Grafana plugin integration available for local installation. With it, you can use Grafana’s interface to create dashboards and complement your metrics visualization.

Your dashboards can be created using GraphQL queries. You can use it to view and create:

• Top X metrics (such as IP addresses or blocked countries).
• Security metrics.
• Customized alerts.
• Specific status codes.

See how to:

• Customize your own dashboard
• Use use a pre-built dashboard to view Data Transferred graphs

Data storage

Azion stores your metrics’ events and logs for 2 years, but the new Real-Time Metrics provides data and metrics starting from October 15th, 2022.

If you want to view metrics for up to 2 years and before October 15th, 2022:

Data consideration

When comparing the data displayed on Real-Time Metrics and Azion Billing data, you may find differences. Real-Time Metrics focuses on performance, using an at-most-once approach, while Billing seeks precision, using an exactly-once approach. If you find such differences, you should consider Azion Billing data as the correct one.

On average, the difference between the two is smaller than 1%. See Azion Pricing and the Billing documentation for more information.

Product choice to view metrics

Real-Time Metrics allows you to analyze your applications’ metrics through several products, indicated by separate tabs according to their category. You can choose to visualize your metrics through the following categories:

• Build
• Secure
• Observe

After selecting the category you want, you can select a product to view metrics.

On the Build tab, you’ll find metrics related to:

• Applications
• Tiered Cache
• Functions
• Image Processor

On the Secure tab, you’ll find metrics related to:

• WAF
• Edge DNS
• Bot Manager
• Threats Breakdown

On the Observe tab, you’ll find metrics related to:

• Data Stream

After selecting one of the category tabs and the product tab, you’ll see the available charts for that specific product according to the data on your account. If you select Data Stream, for example, you’ll see charts related to the streams configured in your account.

Some products, such as Applications, can also have subtabs, which separate different types of metrics for the same product. Each set of charts composes a dashboard. Find out more about each tab, subtab, and charts in the Metrics’ monitoring with charts section.

You must subscribe and activate the following products to view their metrics:

• Data Stream
• Functions
• Edge DNS
• Image Processor
• Tiered Cache
• Bot Manager

Data interval

After you decide which product you’ll be analyzing, you need to configure a data interval to fetch data for your charts.

On Real-Time Metrics’ screen, just before the section with the charts, you find the date interval filter, with two parts:

• Time range: options to select the time period you want to use to exhibit data on your charts. By default, it comes with the Last Hour range selected, but you can choose between:

  • Last Hour
  • Last 24 Hours
  • Last 7 Days
  • Last 30 Days
  • Last 6 Months

When you select Last Hour, Real-Time Metrics automatically refreshes your data every one minute.

• Date calendar: calendar field with the date and time of your chosen time range. When you select a time range, it automatically sets the begin and end dates. If you want to use a different time range, you need to manually set up the beginning and ending dates in the calendar fields.

The timezone used is the same as the one configured in your user preferences.

After you configure the Time range and Date calendar fields, your charts are refreshed to fetch the data related to the new configured data interval.

Filters

Real-Time Metrics allows you to filter your analysis, receiving specific fields and values. You can add a single or multiple filters depending on the analysis you want to conduct.

Chart view

On the second section of Real-Time Metrics, after the configuration filters, you find all the available charts.

Each chart displays the following properties:

• Title: descriptive name for the graph.
• Type of chart: tag representing who created the chart and to whom it’s available for.
  • Azion Chart: chart displayed by default by Azion’s servers.
• Context menu: extra options of actions related to the chart.
  • (?) Open Help Center: opens a Help Center article, which you can use to discover more about each chart and find a few tips and practical examples.
  • Copy Query: to copy the query of that specific chart to your clipboard.
  • Export CSV: to download and export the points presented on that specific chart according to the data displayed.
  • Show Mean Line/Hide Mean Line: to exhibit or stop exhibiting the average value of the chart. Each point of the chart is summed and divided by the total number of points, generating a mean for the data shown on that specific chart and time period.
  • Show Mean Line per series: to exhibit or stop exhibiting the average value for each data series in the chart. Instead of calculating a single mean for all points, it calculates and overlays a mean line for each individual series, helping to compare trends across different data sets.
• Description: a short text that explains what data that specific chart displays.
• Aggregator: type of aggregation being used in the query to generate the metrics on the chart. Either Sum or Avg.
• Variation tag: information shown on chart with only one series. It provides a percentage comparing the previous and current values of the chart in the corresponding time period. The tag shows a ↑ if the current value is larger, a ↓ if the previous value was larger, and no sign if the value is the same. Example: if you’re using the “Last hour” period and it’s 10:00, the chart shows data for the period from 9:00-10:00, and the feedback will show a comparison with the data from 8:00-9:00. The colors indicate whether the metric is improving or worsening based on its direction (increase or decrease). For example, +10% (green) in OFFLOAD means the OFFLOAD metric is better when it increases, while MISSED DATA appears in red when it increases, indicating the opposite behavior.
• Graph series: representation of data categories.
  • Example: in a line graph that shows the number of requests over time, you can have several series, each one representing a different domain. Each series will have data points connected by a line to exhibit how the number of requests varied over time for each domain.
• Tooltip: information available by hovering the cursor over the graph series, which displays the value and the name of each series of that specific point in a descending order, according to the value. This feature isn’t available for viewports smaller than 540px.
• Time interval line: the x-axis of the graph, representing the time period line for the data on the graph.
• Legend: a list that reflects and describes series and data from the y-axis, based on the chart’s aggregation type. You can select and deselect each legend item to change the data displayed on the graph.

Legends can be displayed differently according to the type of chart and amount of series represented on it. They can appear on the bottom of the chart or on the right side, and the legend exhibits a maximum of 16 series per graph.

Metrics’ monitoring with charts

In the second section of Real-Time Metrics, right after the data interval filter, you find all the available charts for your account.

Even after you configure a data interval filter, you can still navigate through tabs and change the product you want to view metrics from. After you select a tab and, possibly, subtab, you can analyze your data for each chart.

Next, you can find detailed information about each tab and subtabs and about each of the charts available:

• Build

  • Applications - Tiered Cache - Functions - Image Processor

• Secure

  • WAF - Edge DNS - Bot Manager

• Observe

  • Data Stream

Build

Applications

The Applications tab displays metrics related to the accesses of your Applications configured in your account. You find four subtabs with different charts: Data Transferred, Requests, Status Codes, and Bandwidth Saving.

Data Transferred

Find out more about each chart:

Cache

The Cache graph represents how all information regarding your Cache data is being accessed on Azion’s edge.

It provides a first layer of caching to the client content on Azion edges. The graph is divided into:

• Data Transferred Total: all data that was transferred in the process; value of Data Transferred In + Data Transferred Out.

END USER -> EDGE -> ORIGIN + ORIGIN -> EDGE -> END USER

• Data Transferred In: data transferred from the user to the edges, and from the edges to the client origin.

END USER -> EDGE -> ORIGIN

• Data Transferred Out: data transferred from the client origin to the edges, and from the edges to the user.

ORIGIN -> EDGE -> END USER

To use Cache and analyze data on it, you must activate it in your account. See the Cache documentation for more information.

In what unit does data appear on graphs?

Real-Time Metrics uses bytes to show your data. It automatically converts your data into megabytes (MB), gigabytes (GB), or terabytes (TB), for example, according to the amount of data available to make your visualization easier.

Data Transferred In flow:

Data Transferred Out flow:

Data Transferred flow:

If you have Tiered Cache enabled, your Cache graph will exhibit:

• Data Transferred In: data transferred from the end user to the edges, and from the edges to the tiered cache layer.

• Data Transferred Out: data transferred from the tiered cache layer to the edges, and from the edges to the end user.

• Data Transferred Total: all data that was transferred in the process; value of Data Transferred In + Data Transferred Out.

Edge Offload

The Edge Offload graph shows the percentage of data delivered directly by the edge, without having to search for the content on the origin before delivering it.

END USER -> EDGE -> END USER

The higher the percentage of offloading, the better the efficiency of your applications regarding the use of cache policies to preserve infrastructure. Azion’s edge delivers the content from its cache, demanding less from your origin.

Practical example

Your application has 1 GB of data. If the graph shows your application had an average of 80% offload, this means 800 MB out of 1 GB were delivered directly by Azion’s edge.

In what unit does data appear on graphs?

Real-Time Metrics uses percentages to show your data on offload graphs. All data related to offloading reflects the average number of your applications’ access, and the graph then represents it with percentages (%).

Saved Data

The Saved Data graph shows the total sum of your application’s data that was delivered directly by Azion’s edge, without having to take the extra step of looking for the content on the origin.

Saved Data: content is delivered directly by the edge to the origin.

END USER -> EDGE -> END USER

A higher sum of saved data means your application is using cache policies on Azion’s edge more efficiently, demanding less from your origin during the period you’ve selected in the time range.

In what unit does data appear on graphs?

Real-Time Metrics uses bytes to show your data. It automatically converts your data into megabytes (MB), gigabytes (GB), or terabytes (TB), for example, according to the amount of data available to make your visualization easier.

Missed Data

The Missed Data graph shows the total sum of your application’s data when Azion’s edge had to look for the content on the origin and deliver it to the end user.

Missed Data: the edge looks for the content on the origin and then delivers it to the end user.

END USER -> EDGE -> ORIGIN -> EDGE -> END USER

When the content isn’t found on Azion’s cache, it’s necessary to take another step and look for it on the origin, and then deliver it to the end user.

In what unit does data appear on graphs?

Real-Time Metrics uses bytes to show your data. It automatically converts your data into megabytes (MB), gigabytes (GB), or terabytes (TB), for example, according to the amount of data available to make your visualization easier.

Total Bandwidth Usage

The Total Bandwidth Usage graph shows the total amount of bandwidth your application used during the period you’ve selected in the time range.

Bandwidth represents the amount of information being received every second. At Azion, it represents the content that was delivered by your application every second.

In what unit does data appear on graphs?

Real-Time Metrics uses bits and bytes per second on all graphs related to bandwidth data. It automatically converts your data into megabits per second (bit/s) or kilobytes per second (kB/s), for example, according to the amount of data available to make your visualization easier.

Bandwidth Offloaded

The Bandwidth Offloaded graph shows the percentage of bandwidth that was delivered directly by the edge, without having to search for the content on the origin before delivering it.

Bandwidth represents the amount of information being received every second. At Azion, it represents the content that was delivered by your application every second during the period you’ve selected in the time range.

The higher the percentage of offloading, the better the efficiency of your applications regarding the use of cache policies to preserve infrastructure. Azion’s edge delivers the content from its cache, demanding less from your origin.

In what unit does data appear on graphs?

Real-Time Metrics uses percentages to show your data on offload graphs. All data related to offloading reflects the average number of your applications’ access, and the graph then represents it with percentages (%).

Saved Bandwidth

The Saved Bandwidth graph shows how much bandwidth was delivered directly by Azion’s edge, without having to take the extra step of looking for the content on the origin.

Saved Bandwidth: content is delivered directly by the edge to the origin.

END USER -> EDGE -> END USER

A higher number of saved bandwidth means your application is using cache policies on Azion’s edge more efficiently, demanding less from your origin during the period you’ve selected in the time range.

In what unit does data appear on graphs?

Real-Time Metrics uses bits and bytes per second on all graphs related to bandwidth data. It automatically converts your data into megabits per second (bit/s) or kilobytes per second (kB/s), for example, according to the amount of data available to make your visualization easier.

Missed Bandwidth

The Missed Bandwidth graph shows how much bandwidth was delivered when Azion’s edge had to look for the content on the origin and deliver it to the end user.

Missed Bandwidth: the edge looks for the content on the origin and then delivers it to the end user.

END USER -> EDGE -> ORIGIN -> EDGE -> END USER

When the content isn’t found on Azion’s cache, it’s necessary to take another step and look for it on the origin, and then deliver it to the end user.

In what unit does data appear on graphs?

Real-Time Metrics uses bits and bytes per second on all graphs related to bandwidth data. It automatically converts your data into megabits per second (bit/s) or kilobytes per second (kB/s), for example, according to the amount of data available to make your visualization easier.

Requests

Find out more about each chart:

Total Requests

The Total Requests graph shows you the sum, the total amount of all types of requests that were processed on the application’s domain configured in your account.

Whenever the content of your application is accessed, one request is processed. The graph then shows all requests that occurred during the period you’ve selected in the time range.

1 access = 1 request

The graph is divided into:

• Http Requests Total: processed requests using the HTTP protocol.
• Edge Requests Total: all types of requests; value of http + https.
• Https Requests Total: processed requests using the HTTPS protocol, which uses encryption and verification.

Requests Offloaded

The Requests Offloaded graph shows the percentage of requests that were delivered directly by the edge, without having to search for the content on the origin before delivering it.

END USER -> EDGE -> END USER

The higher the percentage of offloading, the better the efficiency of your applications regarding the use of cache policies to preserve infrastructure. Azion’s edge delivers the content from its cache, demanding less from your origin.

Practical example

Your application received 5 requests. If the graph shows your application had an average of 80% offload, this means 4 out of 5 requests were delivered directly by Azion’s edge.

In what unit does data appear on graphs?

Real-Time Metrics uses percentages to show your data on offload graphs. All data related to offloading reflects the average number of your applications’ access, and the graph then presents it as percentages (%).

Saved Requests

The Saved Requests graph shows the total sum of your application’s requests that were delivered directly by Azion’s edge, without having to take the extra step of looking for the content on the origin.

Whenever the content of your application is accessed, one request is processed. The graph then shows all requests that were saved during the period you’ve selected in the time range.

Saved Requests: content is delivered directly by the edge to the origin.

END USER -> EDGE -> END USER

A higher sum of saved requests means your application is using cache policies on Azion’s edge more efficiently, demanding less from your origin during the period you’ve selected in the time range.

Missed Requests

The Missed Requests graph shows the total sum of your application’s requests when Azion’s edge had to look for the content on the origin and deliver it to the end user.

Whenever the content of your application is accessed, one request is processed. The graph then shows all requests that were missed during the period you’ve selected in the time range.

Missed Requests: the edge looks for the content on the origin and then delivers it to the end user.

END USER -> EDGE -> ORIGIN -> EDGE -> END USER

When the content isn’t found on Azion’s cache, it’s necessary to take another step and look for it on the origin, and then deliver it to the end user. The entire process counts as 1 request.

Total Requests per Second

The Total Requests per Second graph shows you the average of requests per seconds that were processed on the application’s domain configured in your account.

Whenever the content of your application is accessed, one request is processed. The graph then shows the average of all requests that occurred per second during the period you’ve selected in the time range.

In what unit does data appear on graphs?

Real-Time Metrics uses averages of requests/second to show your data. Example: 0.026/s

Requests per Second Offloaded

The Requests per Second Offloaded graph shows the percentage of requests per second that were delivered directly by the edge, without having to search for the content on the origin before delivering it.

END USER -> EDGE -> ORIGIN

The higher the percentage of offloading, the better the efficiency of your applications regarding the use of cache policies to preserve infrastructure. Azion’s edge delivers the content from its cache, demanding less from your origin.

Practical example

Your application received 5 requests in 1 second. If the graph shows your application had an average of 80% offload, this means 4 out of 5 requests in that second were delivered directly by Azion’s edge.

In what unit does data appear on graphs?

Real-Time Metrics uses percentages to show your data on offload graphs. All data related to offloading reflects the average number of your applications’ access, and the graph then represents it with percentages (%).

Saved Requests per Second

The Saved Requests per Second graph shows the average of your application’s requests per second that were delivered directly by Azion’s edge, without having to take the extra step of looking for the content on the origin.

Whenever the content of your application is accessed, one request is processed. The graph then shows the average of all requests that were saved per second during the period you’ve selected in the time range.

Saved Requests: content is delivered directly by the edge to the origin.

END USER -> EDGE -> END USER

A higher average of saved requests per second means your application is using cache policies on Azion’s edge more efficiently, demanding less from your origin during the period you’ve selected in the time range.

In what unit does data appear on graphs?

Real-Time Metrics uses averages of requests/second to show your data. Example: 0.026/s

Missed Requests per Second

The Missed Requests per Second graph shows the average of your application’s requests per second when Azion’s edge had to look for the content on the origin and deliver it to the end user.

Whenever the content of your application is accessed, one request is processed. The graph then shows the average of all requests that were missed per second during the period you’ve selected in the time range.

Missed Requests: the edge looks for the content on the origin and then delivers it to the end user.

END USER -> EDGE -> ORIGIN -> EDGE -> END USER

When the content isn’t found on Azion’s cache, it’s necessary to take another step and look for it on the origin, and then deliver it to the end user.

In what unit does data appear on graphs?

Real-Time Metrics uses averages of requests/second to show your data. Example: 0.026/s

Requests by Method

The Requests by Method graph shows the sum of HTTP methods that were used in the requests made to your domain. At Azion, it indicates how the client interacted with the content on the domain associated with an application.

The graph is divided into:

• Requests Http Method Get: retrieves resources from the server.
• Requests Http Method Post: sends resources to the server.
• Requests Http Method Head: retrieves data about the resource but doesn’t return the content.
• Requests Http Method Others: all other request methods, such as PUT or PATCH, are gathered on this option.

Average Request Time

The Average Request Time graph shows the average duration of requests over a specified period. It measures how long, on average, a server or application takes to process and respond to a request. With this information, you can quickly identify trends and patterns in request processing times, such as bottlenecks or issues requiring attention. If you identify these issues, you can address them with solutions such as:

• Improve your database queries for optimal performance.
• Define cache policies and Advanced Cache Key.
• Configure multiple origins with load balancing algorithms.

In what unit does data appear on graphs?

Real-Time Metrics uses averages of seconds to show your data. Example: 1.7/s

Practical example

You can use the Metrics filters to refine your analysis by focusing on specific criteria, such as host, status code, request method, or geographic location. For example, in the Filter section, you can use Host, Equals, and example.com to see the average request time for each host.

Requests by Scheme

The Requests by Scheme graph displays the total number of requests over the selected period, categorized by scheme.

It breaks down traffic into:

• HTTP: requests transmitted without encryption, which may be vulnerable to interception.
• HTTPS: requests secured with encryption, ensuring data integrity and confidentiality.

With this information, you can analyze how requests are being handled and identify trends in secure (encrypted) versus non-secure traffic. Read more on How to configure HTTP and HTTPS ports for origins and delivery address.

Status Codes

Find out more about each chart:

HTTP Status Codes 2XX

Whenever a domain that’s associated with an Azion application receives a request, it also receives a specific status code according to the server’s response. The graph then shows the sum of total requests that received a status 2XX.

The 2XX status codes indicate successful requests on the server’s side. This means the request passed the stages of: received, understood, accepted, and processed by the server, and the end user is able to see your domain’s content.

The graph is divided into:

• Requests Status Code200: the content was delivered to the user correctly. Standard status for a successful HTTP request.
• Requests Status Code204: the server completed the request, but had no content to deliver.
• Requests Status Code206: the server delivered only a part of the content because it was divided into parts.
• Requests Status Code2xx: the server indicated other status of the 2XX type. They rarely occur, and are all gathered on this option.

HTTP Status Codes 3XX

Whenever a domain that’s associated with an Azion application receives a request, it also receives a specific status code according to the server’s response. The graph then shows the sum of total requests that received a status 3XX.

The 3XX status codes indicate redirection on the server’s side. This means the request wasn’t fully completed because the content was in another location, and it had to perform one more action to deliver your domain’s content.

The graph is divided into:

• Requests Status Code301: current and all future requests will be redirected to another URL.
• Requests Status Code302: this request was temporarily redirected to another URL.
• Requests Status Code304: the content header indicates that it hasn’t been modified and doesn’t need to be resent. It can deliver the existing file to the user’s browser.
• Requests Status Code3xx: the server indicated other status of the 3XX type. They rarely occur, and are all gathered on this option.

HTTP Status Codes 4XX

Whenever a domain that’s associated with an Azion application receives a request, it also receives a specific status code according to the server’s response. The graph then shows the sum of total requests that received a status 4XX.

The 4XX status codes indicate there was an error on the client’s side. This means the request couldn’t be completed by the server because it identified an error, likely due to the page being unavailable or the request containing bad syntax. Therefore, the server couldn’t deliver your domain’s content.

The graph is divided into:

• Requests Status Code400: the server can’t process the request. Generally occurs due to an error with the request format.
• Requests Status Code403: the request is valid, but wasn’t authorized by the server. This means that the user or the IP address that’s making the request isn’t authorized to do so.
• Requests Status Code404: the file that was requested doesn’t exist on the origin server.
• Requests Status Code4xx: the server indicated other status of the 4XX type. They rarely occur, and are all gathered on this option.

HTTP Status Codes 5XX

Whenever a domain that’s associated with an Azion application receives a request, it also receives a specific status code according to the server’s response. The graph then shows the sum of total requests that received a status 5XX.

The 5XX status codes indicate there was an error on the server’s side. This means that the request by the end user seemed to be valid, but for some reason the server couldn’t perform the request or encountered an error in the process. Your domain’s content still exists, it just couldn’t be delivered.

The graph is divided into:

• Requests Status Code500: generic message given when an unexpected error occurs on the server and it’s unable to handle the request.
• Requests Status Code502: when the server is acting as a Gateway or Proxy and receives an invalid response from the origin. Generally occurs when the origin server is offline.
• Requests Status Code503: server isn’t available. Generally a temporary status.
• Requests Status Code5xx: the server indicated other status of the 5XX type. They rarely occur, and are all gathered on this option.

Requests by Status and Upstream Status

The Requests by Status and Upstream Status table shows the total number of processed requests, categorized by both Status Codes (responses generated by your application or infrastructure) and Upstream Status Codes (responses returned by upstream servers or external services).

The table is divided into:

• Status: indicates how requests were processed at the edge, such as successful responses (2XX), client errors (4XX), or server errors (5XX).
• Upstream Status: provides insights into responses from external services or backend servers, helping identify connectivity issues, timeouts, or failures in upstream dependencies.
• Total: the sum of the requests according to the Status and Upstream Status.

By analyzing this graph, you can detect trends in request handling, pinpoint sources of errors, and optimize your infrastructure for better performance and reliability.

The graph includes the 10 most frequent request cases, but you can apply filters to access more specific information.

Bandwidth Saving

Bandwidth Saving

The Bandwidth Saving graph shows you the sum of savings on all transmissions of images that were somehow processed and deliver by Image Processor.

The processing of images can be related to resizing, cropping, changing quality, or any other feature that Image Processor provides. If an image had any kind of treatment through Image Processor, the savings of those images in your domain are shown in the graph.

In what unit does data appear on graphs?

Real-Time Metrics uses bytes to show your data. It automatically converts your data into megabytes (MB), gigabytes (GB), or terabytes (TB), for example, according to the amount of data available to make your visualization easier.

Requests Breakdown

IP Address Information

The IP Address Information table provides an overview of the distribution of requests based on different geographical and network attributes, breaking them down by:

• Remote Address: individual IP addresses making requests.
• ASN: Autonomous System Number, the network operator or organization responsible for the IP address.
• Country: the specific country from which the requests are coming.
• Region: the geographic location from which the requests originate.
• Total: the total number of requests associated with a specific Remote Address.

By examining this data, you can identify regional traffic patterns, detect unusual activity from specific countries or networks, and take targeted security actions. For example, you can create a network list based on user’s IP addresses or geolocation to block these requests.

The table displays the 10 most frequently used Remote Addresses, but you can apply filters to access more specific information.

Tiered Cache

The Tiered Cache tab displays metrics related to the data of your applications using Tiered Cache configured in your account.

Find out more about each chart:

Tiered Cache

The Tiered Cache graph represents how all information regarding your Tiered Cache data is being accessed on Azion’s edge.

Tiered Cache is a feature for Applications that adds an extra layer of cache between the edge and the client origin. The graph is divided into:

• Data Transferred Total: all data that was transferred in the process; value of Data Transferred In + Data Transferred Out.

EDGE -> TIERED CACHE -> ORIGIN + ORIGIN -> TIERED CACHE -> EDGE

• Data Transferred In: data transferred from the edges and through Tiered Cache until the client origin.

EDGE -> TIERED CACHE -> ORIGIN

• Data Transferred Out: data transferred from the client origin and through Tiered Cache to the edges.

ORIGIN -> TIERED CACHE -> EDGE

To use Tiered Cache and analyze data on it, you must activate it in your account. See the Tiered Cache documentation for more information.

In what unit does data appear on graphs?

Real-Time Metrics uses bytes to show your data. It automatically converts your data into megabytes (MB), gigabytes (GB), or terabytes (TB), for example, according to the amount of data available to make your visualization easier.

Tiered Cache flow:

Tiered Cache In flow:

Tiered Cache Out flow:

Tiered Cache Offload

The Tiered Cache Offload graph shows you the percentage of data delivered through Tiered Cache, without having to search for the content on the origin before delivering it.

EDGE -> TIERED CACHE -> EDGE

The higher the percentage of offloading, the better the efficiency of your applications regarding the use of Tiered Cache policies to preserve infrastructure. Azion’s edge delivers the content from its cache, demanding less from your origin.

Practical example

Your application has 1 GB of data. If the graph shows your application had an average of 80% offload, this means 800 MB out of 1 GB were delivered through Tiered Cache.

In what unit does data appear on graphs?

Real-Time Metrics uses percentages to show your data on offload graphs. All data related to offloading reflects the average number of your applications’ access, and the graph then represents it with percentages (%).

Functions

The Functions tab displays metrics related to the invocations of the Functions configured in your account.

Find out more about the chart:

Total Invocations

The Total Invocations graph shows you the sum of all occasions in which your functions were called.

The graph is divided into:

• Firewall Invocations: total amount of executed functions associated to a firewall.
• Applications Invocations: total amount of executed functions associated to an application.

Whenever one of your configured functions is executed, one invocation is calculated.

Find out more on how to build applications with Functions.

Image Processor

The Image Processor tab displays metrics related to the requests made to your images processed through Image Processor configured in your account.

Find out more about each chart:

Total Requests

The Total Requests graph shows you the sum of all requests related to a content that has images processed by Image Processor.

The processing of images can be related to resizing, cropping, changing quality, or any other feature that Image Processor provides.

If an image had any kind of treatment through Image Processor, the requests to the image in the domain it’s configured on are shown in the graph.

Total Requests per Second

The Total Requests per Second graph shows you the average of requests per second related to a content that has images processed by Image Processor.

The processing of images can be related to resizing, cropping, changing quality, or any other feature that Image Processor provides. If an image had any kind of treatment through Image Processor, the average of requests to the image in the domain it’s configured on that occurred per second during the period you’ve selected are shown in the graph.

In what unit does data appear on graphs?

Real-Time Metrics uses averages of requests/second to show your data. Example: 0.026/s

Secure

WAF

The WAF tab displays metrics related to threats protected by WAF in your account.

Find out more about each chart:

Threats vs Requests

The Threats vs Requests graph shows you the sum of attacks and regular requests made to your domain that were processed by Web Application Firewall (WAF).

WAF analyzes the requests made to your domain associated with an application, detects, and blocks any threats it identifies as malicious activity.

The graph displays the total amount of requests and attacks that were processed, and divides it into:

• Waf Requests Blocked: requests that were identified as a malicious threat and were blocked.
• Waf Requests Threats: requests that were identified as possible threats but weren’t blocked.
• Waf Requests Allowed: normal requests that weren’t identified as a threat.

For a more detailed view on the threats occurring against your domains, see your logs through Real-Time Events.

Cross-Site scripting (XSS) Threats

The Cross-Site Scripting (XSS) Threats graph shows you the sum of XSS attacks type made against your domains.

An XSS threat injects client-side malicious scripts into pages viewed by your visitors, compromising your application and website’s security. WAF analyzes each request and, when it’s identified as a threat, blocks it.

Then, the graph displays all requests that were identified as XSS threats during the period you’ve selected in the time range.

For more details on how WAF analyzed the requests, see your logs through Real-Time Events.

Remote File Inclusion (RFI) Threats

The Remote File Inclusion (RFI) Threats graph shows you the sum of RFI attacks type made against your domains.

An RFI threat usually includes remote files or scripts to your domain, compromising your application and website’s security. WAF analyzes each request and, when it’s identified as a threat, blocks it.

Then, the graph displays all requests that were identified as RFI threats during the period you’ve selected in the time range.

For more details on how WAF analyzed the requests, see your logs through Real-Time Events.

SQL Injection Threats

The SQL Injection Threats graph shows you the sum of SQL Injection attacks type made against your domains.

An SQL injection threat injects a code to your domain seeking to view and attack data that they shouldn’t be able to access, compromising your application and website’s security. WAF analyzes each request, and when it’s identified as a threat, blocks it.

Then, the graph displays all requests that were identified as SQL injection threats during the period you’ve selected in the time range.

For more details on how WAF analyzed the requests, see your logs through Real-Time Events.

Other Threats

The Other Threats graph shows you the sum of all requests that WAF considered as a threat and didn’t fit in other specific categories, such as XSS or RFI threats.

WAF analyzes all requests made to your domains, and when it identifies one as a threat, blocks it. Then, the graph displays all requests that were identified as threats during the period you’ve selected in the time range.

For more details on how WAF analyzed the requests, see your logs through Real-Time Events.

Top WAF Threat Requests by Country Pie Graph

The Top WAF Threat Requests by Country pie graph shows the distribution of requests identified as threats by the Web Application Firewall (WAF).

It breaks down the data by country, highlighting the top sources of flagged requests. The graph displays percentages, allowing you to quickly assess which regions generate the most WAF-detected threats over the selected period.

You can use this alongside the bar graph that shows the total number of detected threats, providing a deeper analysis to identify trends and patterns in the origins of the threats.

With this information, you can set up security policies. For example, you can create a network list based on the user’s geolocation to block these requests.

Top WAF Threat Requests by Country Bar Graph

The Top WAF Threat Requests by Country bar graph shows the distribution of requests identified as threats by the Web Application Firewall (WAF).

It breaks down the data by country, highlighting the top sources of flagged requests. The graph displays the number of threats by country, allowing you to quickly assess which regions generate the most WAF-detected threats over the selected period.

You can use this alongside the pie graph that displays the distribution of requests identified as threats in percentages, providing a deeper analysis to identify trends and patterns in the origins of the threats.

With this information, you can set up security policies. For example, you can create a network list based on the user’s geolocation to block these requests.

WAF Threat Requests by Family Attack

The WAF Threat Requests by Family Attack graph displays the total number of requests identified as threats by the WAF, categorized by attack family over the selected period.

The graph is divided into:

• SQL: attempts to exploit SQL injection vulnerabilities to manipulate database queries.
• SQL, XSS: requests that combine SQL injection with Cross-Site Scripting (XSS) attacks.
• SQL, TRAVERSAL: attacks leveraging both SQL injection and path traversal techniques to access restricted files or directories.
• OTHERS, SQL: less common SQL-related attack patterns grouped.
• RFI: Remote File Inclusion attacks that attempt to load external malicious scripts.
• TRAVERSAL: directory traversal attempts to access unauthorized files or directories.
• SQL, RFI: attacks that combine SQL injection and Remote File Inclusion techniques.
• SQL, XSS, RFI: multi-vector attacks that leverage SQL injection, Cross-Site Scripting (XSS), and Remote File Inclusion (RFI).
• OTHERS: attack patterns that don’t fit into the predefined categories.

This graph helps you quickly identify which attack families are generating the most flagged requests, allowing for a clearer analysis of threat patterns and setting up policies to contain these threats. For example, by creating a WAF Rules Set, you can protect your Applications against specific threat families.

How does a WAF Rules Set work?

Each threat receives a score and it’s processed according to the sensitivity level set.

If there’s more than one case for the same threat type, the score will increase.

After creating a rule set, you must create a Rules Engine rule to execute the criteria and behavior. For example, if a request has a high SQL score (criteria), it’ll be dropped (behavior).

WAF Threat Requests by Host

The WAF Threat Requests by Host graph displays the total number of requests identified as threats by the WAF, categorized by the top hosts generating the most flagged requests over the selected period.

This graph helps you quickly identify which hosts are responsible for the highest volume of detected threats. By analyzing this data, you can take targeted security measures to mitigate risks, protect your applications, and take proactive steps to mitigate potential risks. For example:

• Analyze flagged request logs to identify patterns or potential vulnerabilities that need addressing.
• Adjust WAF Rules Sets to strengthen filtering policies to block or challenge suspicious requests from high-risk hosts.
• Implement rate limiting and restrict the number of requests from specific hosts to prevent abuse.
• Define blocklists with identified threat sources to prevent repeated attacks.

Edge DNS

The Edge DNS tab displays metrics related to queries made to the DNS configured in your account.

Find out more about the chart:

The Total Queries graph shows you the total amount of queries received by your DNS configured on Edge DNS.

By using Edge DNS, your domains are hosted and managed on Azion. Then, whenever a query is made to your DNS during the period you’ve selected in the time range, the graph displays it.

Bot Manager

The Bot Manager tab displays metrics related to Bot Manager activity. It has two sections: Overview and Breakdown.

Find out more about each chart:

Overview

Bad Bot Hits

The Bad Bot Hits graph shows the total number of requests identified as bad bots within the defined period.

Azion Bot Manager analyzes incoming requests and gives them a score. If the score is equal to or greater than the predetermined threshold you set when configuring Bot Manager, the request is considered a bad bot, and the defined action is executed. Otherwise, the request is processed.

Good Bot Hits

The Good Bot Hits graph shows the number of requests identified as good bots within the defined period.

Azion Bot Manager analyzes incoming requests and gives them a score. If the score is equal to or greater than the predetermined threshold you set when configuring Bot Manager, the request is considered a bad bot, and the defined action is executed. Otherwise, the request is processed normally. Good bots are classified as allowed traffic, and their requests proceed as usual.

Bot Hits

The Bot Hits graph shows the total number of requests identified as bots within the defined period. A request is considered a bot when it exhibits non-human characteristics or behavior, including abnormal patterns, missing or unusual request headers, suspicious user-agent strings, requests from IP addresses with a history of malicious activity, failing challenges such as CAPTCHAs, or automation tools.

In this context, bots can be either good or bad. Good bots, like search engine crawlers, are permitted. Bad bots, however, engage in harmful activities like scraping data, launching attacks, or overloading systems.

Azion Bot Manager analyzes incoming requests and gives them a score. If the score is equal to or greater than the predetermined threshold you set when configuring Bot Manager, the request is considered a bad bot, and the defined action is executed. Otherwise, the request is processed.

Transactions

The Transactions graph shows a sum referring to the total number of requests evaluated by Azion Bot Manager.

Bot Traffic

The Bot Traffic graph shows the evolution of bot traffic over time. It presents historical data by identifying the traffic into:

• Legitimate: the request wasn’t identified as an attack and there’s enough data to ensure it isn’t an attack, being considered legitimate human users.
• Bad Bot: the request reached the score threshold or it was identified as an attack.
• Good Bot: the request wasn’t identified as an attack and matched any of the commonly used good bots, such as search engines.
• Under Evaluation: the request wasn’t identified as a bot, but there isn’t enough data to ensure it isn’t an attack, being considered suspicious access.

It helps to identify periods of suspicious activity and allows you to detect patterns and anomalies. By hovering over the lines in the graph, a card will appear with more detailed information about the date, time, and the number of bots in each category.

Top Bot Traffic

The Top Bot Traffic graph is a pie chart that displays the distribution of bot traffic in percentages over the selected period. It categorizes traffic into:

• Legitimate: the request wasn’t identified as an attack and there’s enough data to ensure it isn’t an attack, being considered legitimate human users.
• Bad Bot: the request reached the score threshold or it was identified as an attack.
• Good Bot: the request wasn’t identified as an attack and matched one of the commonly used good bots, such as search engines.
• Under Evaluation: the request wasn’t identified as a bot, but there isn’t enough data to ensure it isn’t an attack, being considered suspicious access.

This graph helps you quickly assess the proportion of bot traffic, detect anomalies, and identify trends in malicious or suspicious activity.

By hovering over the graph, a card will appear with the total number of requests for each category.

Top Bot Action

The Top Bot Action graph shows the actions performed by Azion Bot Manager for accesses identified as bots.

These actions could be:

• Allow: allowed the continuation of the request. If the score is less than the predetermined threshold, the request is processed, being allow the default action.
• Deny: delivered a standard Status Code 403 response.
• Drop: terminated the request without a response to the user.
• Redirect: allowed the request to be redirected to a new URL/location when the security threshold is reached, including CAPTCHA challenges.
• Custom_html: delivered customized HTML content to the user in a threshold violation.
• Random_delay: made the function wait for a random period between 1 and 10 seconds before allowing the request to proceed.
• Hold_connection: held the request, keeping the connection open for 1 minute before dropping it.

Bot CAPTCHA line graph

The Bot CAPTCHA metric refers to the results of the challenge returned for requests classified as bots. This metric is presented in two graphics: a pie and a line graph.

In the case of the line graph, it displays the traffic identified as bots over time, being:

• Solved: if the challenge was solved. In this case, the bot completed the CAPTCHA challenge, providing the correct response and proceeding.
• Not Solved: if the challenge wasn’t solved or was solved incorrectly. In this case, the bot either failed to complete the challenge provided an incorrect response, or didn’t attempt to solve it, triggering the defined action for blocked or suspicious bots.

By hovering over the lines in the graph, a card will appear with more detailed information about the date and time, as well as the number of bots that either passed or failed the CAPTCHA.

Top Bot CAPTCHA Pie Graph

The Bot CAPTCHA metric refers to the results of the challenge returned for requests classified as bots. This metric is presented in two graphics: a pie and a line graph.

In the case of the pie graph, it displays the percentage of bots that either passed or failed the CAPTCHA, being:

• Solved: if the challenge was solved. In this case, the bot completed the CAPTCHA challenge, providing the correct response and proceeding.
• Not Solved: if the challenge wasn’t solved or was solved incorrectly. In this case, the bot either failed to complete the challenge provided an incorrect response, or didn’t attempt to solve it, triggering the defined action for blocked or suspicious bots.

It helps to adjust the difficulty or frequency of challenges to improve bot detection. It’s also useful for optimizing user experience and the effectiveness in bot mitigation.

Top Bot Classifications

The Top Bot Classifications graph shows you the sum of requests classified according to the tactics used and the purpose of the bots, including Crawling, Brute Force, Scraping, Bad Bot Signatures, Malicious Browser Behavior, Scripted Bots, Enterprise Bots, Reputation Intelligence, Monitoring Bots, and Malicious Intent Detected, among others.

Bot Activity Map

The Bot Activity Map displays the geographic origin of bot attacks.

Countries are color-coded based on the number of detected bot attacks:

• Red: more than 1,000,000 requests.
• Light red: between 100,000 and 1,000,000 requests.
• Orange: between 10,000 and 99,999 requests.
• Light orange: between 1,000 and 9,999 requests.
• Yellow: between 1 and 999 requests.

This information helps you identify regional patterns and implement geo-blocking and other region-specific mitigation strategies.

Breakdown

Impacted URLs

The Impacted URLs graph shows the total number of distinct URLs bots request.

Top Impacted URLs

The Top Impacted URLs graph shows the total number of requests detected as bots, broken down by the most affected URLs.

This allows you to identify which URLs are most frequently targeted by bots, empowering you to analyze patterns and define more protective measures.

Top Bad Bot IPs

The Top Bad Bot IPs graph shows the total number of requests detected as bad bots from different IP addresses, listing those with the highest activity.

You can use this data to:

• Identify IP addresses frequently used by bad bots to attack your site.
• Discover trends and patterns in bad bot activity.
• Block or limit traffic from risky IP addresses.
• Gain insights to respond quickly to bad bots attacks.

Threats Breakdown

Top WAF Threat Requests by IP

The Top WAF Threat Requests by IP graph shows the sum of requests identified as threats by WAF, broken down by the top IP addresses. It displays the total number of requests detected as threats for each IP.

With this information, you can quickly identify your traffic and focus on creating policies to stop the biggest threats. For example, you can create a network list based on user’s IP addresses to block these requests.

For a more detailed view of the threats occurring against your domains, see your logs through Real-Time Events.

Observe

Data Stream

The Data Stream tab displays metrics related to the data and requests of the stream configured in your account.

Find out more about each chart:

Total Data Streamed

The Total Data Streamed graph shows you the total amount of data that was sent by the data streaming configured in your account.

Data Streaming sends your logs in packets. Once you have 2,000 records, every 60 seconds pass, or data reaches the max size you’ve defined, one packet is sent. The graph then shows the sum of all packets sent during the period you’ve selected in the time range.

In what unit does data appear on graphs?

Real-Time Metrics uses bytes to show your data. It automatically converts your data into megabytes (MB), gigabytes (GB), or terabytes (TB), for example, according to the amount of data available to make your visualization easier.

Total Requests

The Data Streaming Total Requests graph shows you the sum, the total amount of requests that were processed by the data streaming configured in your account.

Each request is made out of successful Data Streaming packets: when a packet with your logs is completed and sent, one request is created. Packets are created when you have 2,000 records, every 60 seconds pass, or data reaches the max size you’ve defined.

The graph shows the sum of all requests that occurred during the period you’ve selected in the time range.

Find out more about Data Streaming.

Limits

These are the default limits: