Filter probes

The filter chain is the heart of Magnolia’s request processing. While filter probes don’t use a lot of system resources in making their measurements, adding many filter probes to the filter chain may affect Magnolia’s ability to process requests.

Prometheus and Grafana can also post-process measurements collected by filter probes. You can make queries to pull larges amounts of request measurements into dashboards that can affect Prometheus and Grafana performance.

Here are some recommendations to keep in mind when using filter probes.

If you are not interested in the request details such as URI, URL or request method, use the "simple" versions of the filter probes - SimpleCounterFilterProbe, SimplePassthroughFilterProbe, SimpleSummaryPassthroughFilterProbe or SimpleFilterSequenceProbe - since these probes do not collect the request details.

If you do want the request details when using CounterFilterProbe, PassthroughFilterProbe, SummaryPassthroughFilterProbe or FilterSequenceProbe, try to limit the labels collected to just what is needed.

If you want to monitor requests to specific URLs, use voters to limit the requests monitored by filter probes.

All filter probes can use voters to limit the requests that are measured. Voters can check the attributes of a request to see if it should be measured by a filter probe, including:

You can configure voters in a filter probe like this:

SimpleCounterFilterProbe counts the total number of requests received or the current number of active requests.

SimpleCounterFilterProbe does not add any labels to its measurements; use CounterFilterProbe if you want to add labels based on request attributes to measurements.

SimplePassthroughFilterProbe measures the time taken for all filters after the filter probe to execute.

SimplePassthroughFilterProbe does not add any labels to its measurements; use PassthroughFilterProbe if you want to add labels based on request attributes to measurements.

SimpleSummaryPassthroughFilterProbe collects a distribution of the times taken for all filters after the filter probe to execute. While Prometheus queries and functions can compute histograms of measurements, SimpleSummaryPassthroughFilterProbe may be faster in generating a histogram.

SimpleSummaryPassthroughFilterProbe does not add any labels to its measurements; use SummaryPassthroughFilterProbe if you want to add labels based on request attributes to measurements.

SimpleFilterSequenceProbe measures the processing time taken by one or more following filters, though not necessarily the entire remaining filter chain.

SimpleFilterSequenceProbe uses a filter timer trigger to record the processing time.

Suppose you have the following sequence of filters configured:

When executed, SimpleFilterSequenceProbe starts a timer, FilterA and FilterB are executed. When FilterTimeTrigger is reached, the timer is stopped and the measurement is recorded.

If you don’t configure a FilterTimerTrigger, SimpleFilterSequenceProbe will stop the timer after the request has been processed by all remaining, but this is the same as, and less efficient as, using SimplePassthroughFilterProbe.

SimpleFilterSequenceProbe does not add any labels to its measurements; use FilterSequenceProbe if you want to add labels based on request attributes to measurements.

Counts the total number of requests received or the current number of active requests.

CounterFilterProbe adds labels to its measurements based on its labels configuration; use SimpleCounterFilterProbe if you don’t want to add labels based on request attributes to measurements.

PassthroughFilterProbe measures the time taken for all filters after the filter probe to execute.

PassthroughFilterProbe adds labels to its measurements as configured; use SimplePassthroughFilterProbe if you don’t need to add labels based on request attributes to measurements.

SummaryPassthroughFilterProbe collects a distribution of the times taken for all filters after the filter probe to execute. While Prometheus queries and functions can compute histograms of measurements, SummaryPassthroughFilterProbe may be faster in generating a histogram.

SummaryPassthroughFilterProbe does not add any labels to its measurements; use SimpleSummaryPassthroughFilterProbe if you don’t need to add labels based on request attributes to measurements.

FilterSequenceProbe measures the processing time taken by one or more following filters, though not necessarily the entire remaining filter chain.

FilterSequenceProbe uses a filter timer trigger to record the processing time.

Suppose you have the following sequence of filters configured:

When executed, FilterSequenceProbe starts a timer, FilterA and FilterB are executed. When FilterTimeTrigger is reached, the timer is stopped and the measurement is recorded.

If you don’t configure a FilterTimerTrigger, FilterSequenceProbe will stop the timer after the request has been processed by all remaining filters, but this is the same as, and less efficient as, using SimplePassthroughFilterProbe.

FilterSequenceProbe adds labels to its measurements as configured; use SimpleFilterSequenceProbe if you don’t need to add labels based on request attributes to measurements.

ServletContextProbe collects information about the servlet context Magnolia is running in, including:

The servlet context information above is recorded as labels. The value of the metric is always 1.

Since the servlet context information does not change while Magnolia is running, the servlet context information is collected once, from the first request arriving at the ServletContextProbe. Subsequent requests to ServletContextProbe will not capture the servlet context information and the request will just be passed along the filter chain.

ServletContextProbe should be positioned early in the filter chain. ServletContextProbe also supports use of voters to restrict requests received by the probe, however, since the servlet context information collected does not change between requests, using voters may delay the collection of the servlet context information.