Note: This feature is currently in Beta. To become a Beta participant, contact Customer Success Manager.

Service Auto Creation Rules allow you to create and manage multiple services easily. You can select and group services based on property keys (cardinality), visualize the created services and their members and define the required service hierarchy. This streamlined approach simplifies service management and organization.

For more information on advanced features in Service Auto Creation Rules, refer to Using Conditional Count and Service Property.

Requirements for Adding Services Using Auto Creation Rules

You require administrator access to create service rules.

Adding Services Using Auto Creation Rules

  1. In LogicMonitor, navigate to Services.
  2. Select  add services and select Multiple services, via a new Auto-Creation Rule.

    Service Auto Creation Rules template
  1. Under the Add multiple services from new Auto-Creation Rule: Members wizardconfigure the rule basics.
    • In the Rule name field, enter a name for the rule.
    • (Optional) In the Description field, enter an appropriate description to help identify the rule later.
    • In the Default service criticality field, select a default value: LowestLowMediumHigh, or Highest.

      Add multiple services from new Auto-Creation Rule: Members wizard
  1. In Step 1: Select members properties, select one option from the following:
    • Resource members only: Includes only resources as members in the service. The Group by field must use property keys that are defined at the resource level.
    • Individual instance members only: Includes only instances as members in the service. The Group by field must use property keys that are defined at the instance level.
    • Both resource and individual instance members: Includes both resources and instances in the service. The Group by field must use property keys that exist on both resources and instances.

Note: LogicMonitor evaluates the presence of each property key used in the Group by field.

  • If a property key exists on only one entity type (either resource or instance), LogicMonitor does not create the service.
  • If all selected property keys exist only on resources, LogicMonitor creates the service with resource members only.
  • If all selected property keys exist only on instances, LogicMonitor creates the service with instance members only.
  • If all selected property keys exist on both resources and instances, LogicMonitor creates the service with both resource and instance members.
  1. In the Group by field, select one or more property keys to define service groupings. You can add up to five cardinality properties in the Group by field.
    In addition, you can use custom property keys if they don’t currently exist on any resource.
    Once those properties are assigned to resources, services are created automatically if the rule is active.

Note:

  • You cannot use restricted or sensitive property keys as Group by fields.
  • Restricted keys include properties such as predef.externalResourceID, system.categories, system.groups, system.ips, system.pushmodules, and so on.
  • Sensitive keys include any credentials or secrets, such as auth.key, azure.secretkey, user.pass, admin.password, aws.accesskey and similar credentials.
  • If you attempt to use a sensitive or restricted key, LogicMonitor will display an error, “Custom property key cannot include sensitive or restricted keys.”

For example, to prepare for future resource onboarding, a user creates a service template using the property key country1. Although this key is not currently assigned to any resources, it enables the rule to group resources automatically once they are added.

Creating custom properties with non-existent resources



Service Group Creation preview  for non existing properties

  1. In the Filter by field, define filters to include specific resources.
    Filters support non-existent property keys and values. This enables you to predefine logic even if the resource data hasn’t been added yet.

Note: LogicMonitor supports the propagation of non-cardinality properties to service definitions.
Non-cardinality properties refer to any properties not used in the Filter By configuration or properties that are not used for grouping or naming services. These properties can still be promoted and included in the created service, offering more flexibility in how service metadata is defined and used.

Note: Both grouping and filtering values cannot be modified after rule creation.

  1. In the Service naming pattern field, define the service names by modifying the text and property references as needed.
    You can customize the name, by removing any unnecessary cardinality properties by selecting the remove icon icon from the property tile in the preview area of the Service naming pattern.

    Instance filtering options

    Flexible Naming Pattern

Note: Service names support the same character rules as LogicMonitor resource names.
All characters are valid and accepted in the service name except the following: * ? , ; `(backtick) (\n)line breaks.

  1. Under Service preview, you can have a live preview of the service names based on the GroupBy, the FilterBy and the naming pattern. 
    • Select any previewed service to view its associated resources.
    • In the Services preview section, you can view the following information:
Service DetailsDescription
Service NameDisplays the name of the services created.
ResourcesDisplays the number of resources associated with each service.
Service criticalityDisplays the default criticality level assigned to each service (for example, Low, Medium, High). You can customize this value.
Create statusDisplays the status of the service creation process.
Status detailDisplays detailed status messages, including any errors or warnings.
Services preview section

Note: Select any Service name to get the service member preview. Depending on the instance filtering option selected, the preview varies.
For example, for Both resource and individual instance members, the preview displays both resources and their individual instances.

  1. In the Default membership re-evaluation interval field, select how often LogicMonitor should re-check service membership:
    • Every 5 minutes — Ideal for environments where resource changes are frequent and need near real-time updates.
    • Every 30 minutes — Recommended for moderately dynamic environments.
    • Every 24 hours — Best suited for stable environments with minimal changes to service membership.
  1. (Optional) Under Step 2: Service groups and properties, do the following:
    • Enable Create service groups for these services.
    • In the Parent service group field, enter the name of the parent service group to organize your services hierarchically.
    • In the Service group naming pattern field, select Insert Token to build dynamic folder names.

      Note: The forward slash / indicates folder hierarchy. Tokens are replaced with their actual property values.

      Service groups and properties
    • Select Preview to review the resulting service group structure.

      Preview to review the resulting service group structure
    • In the Other service groups to add these services to field, specify additional service groups.
  1. Add custom key-value pairs to the New properties section if needed for LogicModule integration.

Note: LogicMonitor supports the propagation of non-cardinality properties to service definitions.

Non-cardinality properties refer to any properties not used in the Group by configuration — in other words, properties that are not used for grouping or naming services. These properties can be promoted and included in the created service, offering more flexibility in service configuration.

In addition, you can do the following:

Rename non-cardinality properties as part of the service definition.

Use tokens within property values for dynamic customization and mapping across services.

  1. Select Next: Save rule and add metrics to finalize the auto-creation rule.