Fortinet black logo

User Guide

Monitoring policies

24.1.0
Copy Link
Copy Doc ID af1daa65-c273-11ec-9fd1-fa163e15d75b:436335
Download PDF

Monitoring policies

Managing monitoring configuration at scale is often onerous, especially in diverse environments with many types of applications and technologies. To handle this, managing monitoring configuration as part of the build and release process is often viewed as the end-goal. However, many companies are far from ready for this, for various reasons. Thankfully, your Monitoring Policy enables you to manage your monitoring configuration from a central location using a workflow-like interface.

A Monitoring Policy is a series of rules that are applied to your instances as the instances are added to FortiMonitor. They usually include a condition - e.g. if Apache is on the instance - and an outcome - apply a template, apply a tag, etc. The policy conditions can be either a collection of OR or AND predicates, forming an IF...THEN statement. The conditions utilize our continually growing list of dimensions.

The rulesets are executed sequentially and will override any settings that were previously set. For example, if you set the instance group for an instance and then in the next ruleset it to a different group, the latter will be utilized.

Default rulesets

Out of the box, we supply default rulesets which help to enrich your instances. As the feature matures, more default rulesets will be introduced.

Default monitoring

For each application identified in an instance, a monitoring template will be applied so that metric collection will begin immediately. Note that most applications require at least some level of configuration (such as credentials) to enable monitoring. We'll still apply the appropriate template but the metric collection can not begin in its entirety until the configuration is completed. See our Application plugins section for more information.

Initial tagging

Based on the instance-type (cloud, agent, etc), we'll apply several tags based on the characteristics of the instance - cloud region, cloud service, OS, etc. These are helpful when building dashboards, creating maintenance periods, running reporting, and more.

Fallback location

If an instance group is not set via a custom ruleset, it will be placed in the group selected in the fallback location policy. While acting as the fallback group, a group cannot be deleted - a different fallback will need to be selected first.

Custom rulesets

To get started, click the + icon from the workflow sidebar. From there, you'll enter the ruleset builder where you can add any number of rules.

Always rules

Always rules allow you to take action on every instance that is processed by a Monitoring Policy. It has no requirements - it will always be executed when it's encountered. This is great for things such as applying foundational Templates or tags.

When configuring your rule, simply select Always from the first dropdown. Whatever is selected in the resulting action step will always be applied.

Conditional rules

Conditional rules are the type you'll utilize most often. As the name suggests, an action is performed assuming a given condition is met. If the condition is not met, it merely skips over it.

The example below checks to see if an instance is an EC2 instance. You can add as many condition requirements or actions to your ruleset rule as necessary; decoupling them is encouraged for maintainability.

AND and OR

You can toggle your Conditional rule between an AND requirement to an OR requirement by clicking the applicable term in your filter condition. AND requires all conditions to be met while OR requires only one of n.

Exiting Rulesets

Maintaining small, decoupled rulesets is encouraged for the sake of scalability and maintainability. One tool to aid in that is the ability to exit a ruleset. When a condition is met and the action is Exit Ruleset, processing of that particular ruleset will cease and the workflow will move on to the ruleset. This makes it really easy to do things like "If not an EC2 instance, move on to the next ruleset."

Filterable Dimensions

Dimension

Description

Always

When encountered, always evaluates to true and causes the action to always be executed

FQDN

Any known public or private IP or domain name. FQDN also supports filtering using regular expressions.

Tags

Existing tags on an instance, from the cloud provider, or agent manifest file. See Tag matching logic.

Applications

Name(s) of applications discovered to be running on the instance by the FortiMonitor monitoring agent

Instance Source

FortiMonitor Agent, Cloud, OnSight Discovery, or API

Instance Name

Name of the instance

CPU Architecture

CPU Architecture of the instance

CPU Core Count

number of cores on the instance

Kernel Version

OS kernel

Operating System

Windows, Linux

Operating System Distribution

Ubuntu, Red Hat, CoreOS, etc

Operating System Distribution Version

e.g., Ubuntu 16.04.4 LTS

AWS Availability Zone

Availability Zone the instance resides in

AWS Image ID

Instance's Image ID

AWS Instance ID

Instance's Instance ID

AWS Instance Type

Size of the instance e.g., t2.micro

AWS Region

The region the instance resides in

AWS Service

EC2, RDS, DynamoDB, etc.

Azure Availability Zone

Availability Zone the instance resides in

Azure Instance Type

Dsv3, Dv3, Fsv2, etc.

Azure Region

The region the instance resides in

Azure Service

Virtual Machine, SQL Server Database, etc.

Cloud Provider

AWS, Azure

Tag matching logic

There are several conditional rules that you can select when using Tags as a filterable dimension. These conditions are described in the table below.

Condition

Description

Has Exact Tags (Some)

Instances that match at least one tag will be included in the ruleset.

Has Exact Tags (All)

Instances with tags that exactly match the tags entered will be added to the ruleset.

For example, if the tags linux, prod, app are entered, only instances with the linux, prod, app tags will be included in the ruleset.

Has Partial Tags (Some)

Instances that have at least one tag that partially matches the entered tags will be included in the ruleset.

For example, if the tag EC2 is entered, instances with the EC2 tag (EC2 Redis, EC2 db) tag will be included in the ruleset.

Has Partial Tags (All)

Instances with tags that partially match all the tags entered are included in the ruleset.

If the tags prod and database are entered, instances with tags that partially match all of the tags are included in the ruleset. For example, instances with the EC2 prod and linux database tags.

Does Not Have Exact Tags (Some)

Instances that do not match at least one tag will be included in the ruleset.

Does Not Have Exact Tags (All)

Instances with tags that do not match the tags entered will be added to the ruleset.

For example, if the tags linux, prod, app are entered, only instances without the linux, prod, app tags will be included in the ruleset. Instances with only the linux tag will still be included.

Does Not Have Partial Tags (Some)

Instances that do not have at least one tag that partially matches the entered tags will be included in the ruleset.

For example, if the tag EC2 is entered, instances without the EC2 tag will be included in the ruleset.

Does Not Have Partial Tags (All)

Instances with tags that do not partially match all the tags entered are included in the ruleset.

If the tags EC2 and database are entered, instances with tags that partially match all of the tags are not included in the ruleset. For example, instances with the EC2 prod and linux database tags.

Has Tag Matching Regex

Instances with tags that match the given regular expression will be included in the ruleset.

Case selection

You can also select the case sensitivity of the tags when creating the ruleset by clicking Aa.

Actions

Action

Description

Exit Ruleset

Immediately exits the current ruleset and moves onto the next one, if present.

Exit Entire Workflow

Immediately exits the workflow and bypasses any succeeding rulesets.

Set Destination

Sets the Instance Group where the instance will reside in.

Add Tags

Adds additional tags to the instance - it does not remove any that are already present.

Apply Template

Applies a template to an instance - previously applied templates are not removed. Enabling the Continually add new metrics on data collection allows continuous discovery of new resources. For more information, see Continual matching.

Set Alert Timeline

Sets the instance's Alert Timeline, replacing what was previously set.

Set Monitoring Location

Sets the instance's Monitoring Location, replacing what was previously set.

Set Attribute

Sets the instance's attribute.

Set Name

Sets/ replaces an instance’s name.

Set Destination - Computed

See Set Destination - Computed action.

Apply Template - Computed

See Apply Template - Computed.

Set Destination - Computed action

The Set Destination - Computed action allows you to assign instances to any Instance Group in the instance tree using a combination of string interpolation and attributes. Before using the action, attributes must be set either through a ruleset step (refer to the Actions table above) or through an Agent manifest file.

To use the action, perform the following steps:

  1. Create a step in a ruleset by selecting +.

  2. Set the ruleset condition to Always.

  3. Set the action to Set Destination - Computed.

  4. In the Path field, enter the target destination using an interpolated string format. Refer to the example in the following section.
    Instances matching the ruleset will automatically be assigned to the Instance Group. Note that the Instance Group will be created if it does not already exist.

Example

The following attributes are set using either the ruleset or the Agent manifest file.

Commas are not supported.

  • Attribute 1

    • Key: env

    • Value: prod

  • Attribute 2

    • Key: app

    • Value: web

If the path entered in the Path field is, All Servers/{{env}}/{{app}}, instances will be added to group All Servers > prod > web.

Where:

{ } – Curly braces are used for syntax.

/ – The slash is used to walk down the tree structure.

Apply Template - Computed action

The Apply Template - Computed action allows you to apply templates to any instance in your account using a combination of string interpolation and attributes. Before using the action, attributes must be set either through a ruleset step (refer to the Actions table above) or through an Agent manifest file.

To use the action, perform the following steps:

  1. Create a step in a ruleset by selecting +.

  2. Set the ruleset condition to Always.

  3. Set the action to Apply Template - Computed.

  4. In the Path field, enter the target template using an interpolated string format. Refer to the example in the previous section.
    The template will automatically be applied to instances matching the ruleset. Note that the template must be existing.

Test a ruleset

To test a ruleset, perform the following:

  1. In the Workflow Sequence section of the Monitoring Policy Workflow page, select the ruleset that you want to test.

  2. Click the Test Ruleset icon.


    The Apply Policy Workflow drawer will slide out.

  3. Select the instance or instances where you want to test the ruleset.

  4. Click Apply.

  5. You can see the results in the Output section of the drawer.

    Note: Enable the Commit Changes option to apply the ruleset to the selected instances.

Test the Monitoring Policy Workflow

To test the workflow, perform the following:

  1. Click Test Workflow.

    The Apply Policy Workflow drawer will slide out.

  2. Select the instance or instances where you want to test the workflow.

  3. Click Apply.

  4. You can see the results in the Output section of the drawer.

    Note: Enable the Commit Changes option to apply the workflow to the selected instances.

Monitoring policies

Managing monitoring configuration at scale is often onerous, especially in diverse environments with many types of applications and technologies. To handle this, managing monitoring configuration as part of the build and release process is often viewed as the end-goal. However, many companies are far from ready for this, for various reasons. Thankfully, your Monitoring Policy enables you to manage your monitoring configuration from a central location using a workflow-like interface.

A Monitoring Policy is a series of rules that are applied to your instances as the instances are added to FortiMonitor. They usually include a condition - e.g. if Apache is on the instance - and an outcome - apply a template, apply a tag, etc. The policy conditions can be either a collection of OR or AND predicates, forming an IF...THEN statement. The conditions utilize our continually growing list of dimensions.

The rulesets are executed sequentially and will override any settings that were previously set. For example, if you set the instance group for an instance and then in the next ruleset it to a different group, the latter will be utilized.

Default rulesets

Out of the box, we supply default rulesets which help to enrich your instances. As the feature matures, more default rulesets will be introduced.

Default monitoring

For each application identified in an instance, a monitoring template will be applied so that metric collection will begin immediately. Note that most applications require at least some level of configuration (such as credentials) to enable monitoring. We'll still apply the appropriate template but the metric collection can not begin in its entirety until the configuration is completed. See our Application plugins section for more information.

Initial tagging

Based on the instance-type (cloud, agent, etc), we'll apply several tags based on the characteristics of the instance - cloud region, cloud service, OS, etc. These are helpful when building dashboards, creating maintenance periods, running reporting, and more.

Fallback location

If an instance group is not set via a custom ruleset, it will be placed in the group selected in the fallback location policy. While acting as the fallback group, a group cannot be deleted - a different fallback will need to be selected first.

Custom rulesets

To get started, click the + icon from the workflow sidebar. From there, you'll enter the ruleset builder where you can add any number of rules.

Always rules

Always rules allow you to take action on every instance that is processed by a Monitoring Policy. It has no requirements - it will always be executed when it's encountered. This is great for things such as applying foundational Templates or tags.

When configuring your rule, simply select Always from the first dropdown. Whatever is selected in the resulting action step will always be applied.

Conditional rules

Conditional rules are the type you'll utilize most often. As the name suggests, an action is performed assuming a given condition is met. If the condition is not met, it merely skips over it.

The example below checks to see if an instance is an EC2 instance. You can add as many condition requirements or actions to your ruleset rule as necessary; decoupling them is encouraged for maintainability.

AND and OR

You can toggle your Conditional rule between an AND requirement to an OR requirement by clicking the applicable term in your filter condition. AND requires all conditions to be met while OR requires only one of n.

Exiting Rulesets

Maintaining small, decoupled rulesets is encouraged for the sake of scalability and maintainability. One tool to aid in that is the ability to exit a ruleset. When a condition is met and the action is Exit Ruleset, processing of that particular ruleset will cease and the workflow will move on to the ruleset. This makes it really easy to do things like "If not an EC2 instance, move on to the next ruleset."

Filterable Dimensions

Dimension

Description

Always

When encountered, always evaluates to true and causes the action to always be executed

FQDN

Any known public or private IP or domain name. FQDN also supports filtering using regular expressions.

Tags

Existing tags on an instance, from the cloud provider, or agent manifest file. See Tag matching logic.

Applications

Name(s) of applications discovered to be running on the instance by the FortiMonitor monitoring agent

Instance Source

FortiMonitor Agent, Cloud, OnSight Discovery, or API

Instance Name

Name of the instance

CPU Architecture

CPU Architecture of the instance

CPU Core Count

number of cores on the instance

Kernel Version

OS kernel

Operating System

Windows, Linux

Operating System Distribution

Ubuntu, Red Hat, CoreOS, etc

Operating System Distribution Version

e.g., Ubuntu 16.04.4 LTS

AWS Availability Zone

Availability Zone the instance resides in

AWS Image ID

Instance's Image ID

AWS Instance ID

Instance's Instance ID

AWS Instance Type

Size of the instance e.g., t2.micro

AWS Region

The region the instance resides in

AWS Service

EC2, RDS, DynamoDB, etc.

Azure Availability Zone

Availability Zone the instance resides in

Azure Instance Type

Dsv3, Dv3, Fsv2, etc.

Azure Region

The region the instance resides in

Azure Service

Virtual Machine, SQL Server Database, etc.

Cloud Provider

AWS, Azure

Tag matching logic

There are several conditional rules that you can select when using Tags as a filterable dimension. These conditions are described in the table below.

Condition

Description

Has Exact Tags (Some)

Instances that match at least one tag will be included in the ruleset.

Has Exact Tags (All)

Instances with tags that exactly match the tags entered will be added to the ruleset.

For example, if the tags linux, prod, app are entered, only instances with the linux, prod, app tags will be included in the ruleset.

Has Partial Tags (Some)

Instances that have at least one tag that partially matches the entered tags will be included in the ruleset.

For example, if the tag EC2 is entered, instances with the EC2 tag (EC2 Redis, EC2 db) tag will be included in the ruleset.

Has Partial Tags (All)

Instances with tags that partially match all the tags entered are included in the ruleset.

If the tags prod and database are entered, instances with tags that partially match all of the tags are included in the ruleset. For example, instances with the EC2 prod and linux database tags.

Does Not Have Exact Tags (Some)

Instances that do not match at least one tag will be included in the ruleset.

Does Not Have Exact Tags (All)

Instances with tags that do not match the tags entered will be added to the ruleset.

For example, if the tags linux, prod, app are entered, only instances without the linux, prod, app tags will be included in the ruleset. Instances with only the linux tag will still be included.

Does Not Have Partial Tags (Some)

Instances that do not have at least one tag that partially matches the entered tags will be included in the ruleset.

For example, if the tag EC2 is entered, instances without the EC2 tag will be included in the ruleset.

Does Not Have Partial Tags (All)

Instances with tags that do not partially match all the tags entered are included in the ruleset.

If the tags EC2 and database are entered, instances with tags that partially match all of the tags are not included in the ruleset. For example, instances with the EC2 prod and linux database tags.

Has Tag Matching Regex

Instances with tags that match the given regular expression will be included in the ruleset.

Case selection

You can also select the case sensitivity of the tags when creating the ruleset by clicking Aa.

Actions

Action

Description

Exit Ruleset

Immediately exits the current ruleset and moves onto the next one, if present.

Exit Entire Workflow

Immediately exits the workflow and bypasses any succeeding rulesets.

Set Destination

Sets the Instance Group where the instance will reside in.

Add Tags

Adds additional tags to the instance - it does not remove any that are already present.

Apply Template

Applies a template to an instance - previously applied templates are not removed. Enabling the Continually add new metrics on data collection allows continuous discovery of new resources. For more information, see Continual matching.

Set Alert Timeline

Sets the instance's Alert Timeline, replacing what was previously set.

Set Monitoring Location

Sets the instance's Monitoring Location, replacing what was previously set.

Set Attribute

Sets the instance's attribute.

Set Name

Sets/ replaces an instance’s name.

Set Destination - Computed

See Set Destination - Computed action.

Apply Template - Computed

See Apply Template - Computed.

Set Destination - Computed action

The Set Destination - Computed action allows you to assign instances to any Instance Group in the instance tree using a combination of string interpolation and attributes. Before using the action, attributes must be set either through a ruleset step (refer to the Actions table above) or through an Agent manifest file.

To use the action, perform the following steps:

  1. Create a step in a ruleset by selecting +.

  2. Set the ruleset condition to Always.

  3. Set the action to Set Destination - Computed.

  4. In the Path field, enter the target destination using an interpolated string format. Refer to the example in the following section.
    Instances matching the ruleset will automatically be assigned to the Instance Group. Note that the Instance Group will be created if it does not already exist.

Example

The following attributes are set using either the ruleset or the Agent manifest file.

Commas are not supported.

  • Attribute 1

    • Key: env

    • Value: prod

  • Attribute 2

    • Key: app

    • Value: web

If the path entered in the Path field is, All Servers/{{env}}/{{app}}, instances will be added to group All Servers > prod > web.

Where:

{ } – Curly braces are used for syntax.

/ – The slash is used to walk down the tree structure.

Apply Template - Computed action

The Apply Template - Computed action allows you to apply templates to any instance in your account using a combination of string interpolation and attributes. Before using the action, attributes must be set either through a ruleset step (refer to the Actions table above) or through an Agent manifest file.

To use the action, perform the following steps:

  1. Create a step in a ruleset by selecting +.

  2. Set the ruleset condition to Always.

  3. Set the action to Apply Template - Computed.

  4. In the Path field, enter the target template using an interpolated string format. Refer to the example in the previous section.
    The template will automatically be applied to instances matching the ruleset. Note that the template must be existing.

Test a ruleset

To test a ruleset, perform the following:

  1. In the Workflow Sequence section of the Monitoring Policy Workflow page, select the ruleset that you want to test.

  2. Click the Test Ruleset icon.


    The Apply Policy Workflow drawer will slide out.

  3. Select the instance or instances where you want to test the ruleset.

  4. Click Apply.

  5. You can see the results in the Output section of the drawer.

    Note: Enable the Commit Changes option to apply the ruleset to the selected instances.

Test the Monitoring Policy Workflow

To test the workflow, perform the following:

  1. Click Test Workflow.

    The Apply Policy Workflow drawer will slide out.

  2. Select the instance or instances where you want to test the workflow.

  3. Click Apply.

  4. You can see the results in the Output section of the drawer.

    Note: Enable the Commit Changes option to apply the workflow to the selected instances.