You can leverage Usage Reporting to view the usage metrics for LM Uptime resources directly in the LogicMonitor portal. The usage metrics display the monthly average number of visits to your monitored websites.

Requirements for Viewing Usage Data for LM Uptime Monitoring

To view usage data for LM Uptime resources in Usage Reporting, you must have the LM Uptime license edition.

Viewing Usage Data for LM Uptime

1. In LogicMonitor, navigate to Settings > Usage.
2. Select “LM Uptime” from the Product dropdown menu.
3. To interact with the Usage Contributors table, select “All Child Accounts” from the Contributor Type dropdown menu.
4. Select a month to view the usage date for websites.
5. Do one of the following:
   • To view the combined metrics for all LM Uptime resources, select the Combined Metrics tab.
     The total number of datapoints defined for LM Uptime resources is displayed, and the visual components update accordingly. 
   • To view the metrics for Ping Checks, select the Ping Check tab.
     The total number of datapoints for ping checks is displayed, and the components update accordingly.
   • To view the metrics for Web Checks, select the Web Check tab.
     The total number of datapoints for web checks is displayed, and the visual components update accordingly.
6. To view usage metrics for a specific date, hover over that date in the bar graph.
   

Use the Script EventSource collection method to detect and alert on any event.  This may be useful if you don’t have LM Logs, and have custom logging that can’t be monitored with the other EventSource collection methods (for example log files, windows event logs, SysLogs, and SNMP traps.)

Format for Uploading External Script

Regardless of whether it is an embedded or external script, the output needs to be a JSON object with an array of one or more events, like this:

{
    "events" : [
                  {
                     "happenedOn":"Fri Jun 05 09:17:47 UTC 2015", 
                     "severity":"Warn", 
                     "message":"This is the first event's message", 
                     "Source":"This is the source of the first event"
                   },
                   {
                     "happenedOn":"Fri Jun 07 09:27:37 UTC 2015", 
                     "severity":"critical", 
                     "message":"This is the second event's message", 
                     "Source":"This is the source of the second event"
                   }
               ]
} 

The following fields can be used to describe an event in the script output:

Date and Time Formats for “happenedOn” Field

LogicMonitor supports the following logfile date/times formats:

Creating a Script EventSource

Follow these steps to create a Script EventSource:

1. Create a new Module. For more information, see DataSources Configuration.
2. When entering the DataSource information, set the Collection Method field in Basic Information to ‘Script Event’
3. In Collector Attributes, upload an external script or enter an embedded Groovy script.
4. Save the new EventSource.

Example

If the script output is:

{"events":[{"happenedOn":"Thu Jan 21 14:25:00 PST 2016","severity":"Warn","message":"This is the message of the event","source":"Custom"}]}

The associated device will trigger an alert, “happenedOn: Thu Jan 21 14:25:00 PST 2016 message: This is the message of the event severity: Warn source: Custom”

You can configure LogicMonitor to import AWS and Azure billing data using the Billing configuration tool to streamline the process of exporting cloud billing data from each provider into LogicMonitor.

You can also configure billing data imports from the Resource Tree by applying billing export data to your existing cloud resources. For more information on AWS billing Resource Tree configuration, see AWS Billing Monitoring Setup

Requirements for Configuring Billing Data for Cost Optimization

To configure billing, your LogicMonitor portal must already be set up to monitor AWS and Azure resources. You must also have the necessary IAM and Azure Entra roles in place to access billing data. For more information, see AWS Monitoring Setup and Adding Microsoft Azure Cloud Monitoring.

To configure AWS billing data for Cost Optimization, you must create a new Cost and Usage Report (CUR) within the AWS console. You will need the following information from the CUR:

• Name of your Amazon S3 bucket
  To obtain the name of your S3 bucket, you must set up an Amazon S3 bucket for your Cost and Usage Report.
  For more information, see Setting up an Amazon S3 bucket for cost and usage reports from AWS.
• Report path prefix of your cost and usage report
  To obtain the report path prefix, you must create a Cost and Usage Report that is enabled to integrate with Amazon Redshift.
  For more information, see Creating Cost and Usage Reports from AWS.

To configure Azure billing data for Cost Optimization, you must create a new data Export within the Azure console. For more information, see Create and manage exported data from Azure. You will need the following information from your Azure data export:

• Export Name
• Storage Account Name
• Storage Account Container Name
• Storage Account Container Directory

You must also assign a role within Azure to your LogicMonitor resource group. This process requires the following details associated with your LogicMonitor resource group:

• Azure Tenant ID
• Azure Client ID
• Azure Secret Key

For more information, see Assign Azure roles to external users using the Azure portal from Azure.

Configuring AWS Billing Data for Cost Optimization

1. In LogicMonitor, navigate to Cost Optimization > Billing and select Manage Billing Configurations.
2. In Manage Billing Configurations, select Create Billing Configuration.
3. In the Provider field, select “AWS.”
4. In the Display Name field, enter a name for your AWS configuration.
5. (Optional) Enter a Description.
   
6. In Permissions settings, the AWS Account ID field populates automatically with the ID of an AWS account. LogicMonitor uses this account to collect billing data from your AWS account.
7. (Optional) Enable Re-use External ID. This allows you to use the same External ID from an AWS account already connected to LogicMonitor.

8. In the Select an existing AWS Account field, enter or search for an AWS account from which to collect billing data.

9. The Create a new policy field comes pre-filled with a basic set of permissions to enable LogicMonitor access to your Cost and Usage Report

10. In the Add role ARN to LogicMonitor field, enter the Amazon Resource Number (ARN) for LogicMonitor’s IAM role. For more information, see IAM Identifiers from AWS.
    
11. In the Billing info tab, enter the S3 Bucket Name and Report Path Prefix into the provided fields.
    
12. Select Verify and add export.

Configuring Azure Billing Data for Cost Optimization

1. In LogicMonitor, navigate to Cost Optimization > Billing and select Manage Billing Configurations.
2. In Manage Billing Configurations, select Create Billing Configuration.
3. In the Provider field, select Azure.
4. In the Display Name field, enter a name for your AWS configuration.
5. (Optional) Enter a Description.
   
6. In the Permissions tab, enter the Azure Tenant ID, Azure Client ID, and Azure Secret Key into the provided fields.
   
7. In the Billing tab, enter the Export Name for your Azure data export.
8. Enter the Storage Account Name, Storage Account Container Name, and Storage Account Container Directory into the provided fields.
   
9. Select Verify and add export.

Configuring Azure Billing Using the Resource Tree

1. In your Azure console, create a new data Export. For more information, see Create and manage exported data from Azure.
2. Assign a role within Azure to your LogicMonitor resource group.
   • This process requires the Azure Client ID associated with your LogicMonitor resource group. For more information, see Assign Azure roles to external users using the Azure portal from Azure.
   • When editing the IAM config for the storage account to which you send exports, assign the Storage Blob Data Reader role to the AppRegistration used for LogicMonitor.
3. In LogicMonitor, navigate to Resource Tree and select the Manage icon for your Azure resource group, then select Permissions to locate the Client ID.
4. Select the report and copy the Subscriptionid assigned to it. The Subscription name provided by Azure in the cost export will appear as the Account Name in LogicMonitor Billing. If you want to enable enhanced billing features, copy the following details:
   • Export Name
   • Storage Account Name
   • Storage Account Container Name
   • Storage Account Container Directory
5. In LogicMonitor, navigate to Resource Tree and select the resource group used to monitor your Azure environment.
6. Select Manage > the Billing tab. Enter the information above into the provided fields,
7. Select Verify Enhanced Billing to validate any changes.

LogicMonitor uses the JMX collection method to collect performance and configuration data from Java applications using exposed MBeans (Managed Beans). These MBeans represent manageable resources in the Java Virtual Machine (JVM), including memory, thread pools, and application-specific metrics.

To collect data using the JMX collection method, configure a datapoint that references a specific MBean and one of its attributes. Specify the following:

• MBean ObjectName— A domain and one or more key–value properties.
  For example, domain=java.lang, properties type=Memory.
• Attribute— The attribute to collect from the MBean.

Each MBean exposes one or more attributes that can be queried by name. These attributes return one of the following:

• A primitive Java data type (for example, int, long, double, or string)
• An array of data (for example, an array of primitives or nested objects)
• A hash of data (for example, key–value pairs, including nested structures or attribute sets)

LogicMonitor supports data collection for all JMX attribute types.

When configuring the JMX datapoint, LogicMonitor uses this information to identify and retrieve the correct value during each collection cycle.

For more technical details on MBeans and the JMX architecture, see Oracle’s JMX documentation.

Simple Attribute Example

If the attribute is a top-level primitive:

• MBean ObjectName: java.lang:type=Threading
• MBean Attribute: ThreadCount

LogicMonitor collects the total number of threads in the JVM.

Nested Attribute Example

If the attribute is part of a composite or nested object, use the dot/period separator as follows:

• MBean ObjectName: java.lang:type=Memory
• MBean Attribute: HeapMemoryUsage.used

LogicMonitor collects the amount of heap memory used.

Multi Level Selector Example

To collect data from a map or nested structure with indexed values:

• MBean ObjectName: LogicMonitor:type=rrdfs
• MBean Attribute: QueueMetrics.move.key1

LogicMonitor retrieves the value associated with the key key1 from the map identified by index move under the QueueMetrics attribute of the MBean.

CompositeData and Map Support

Some JMX MBean attributes return structured data such as:

• CompositeData: A group of named values, like a mini object or dictionary.
• Map: A collection of key-value pairs.

LogicMonitor supports collecting values from both.

Accessing CompositeData Example

A CompositeData attribute is like a box of related values, where each value has a name (field). To collect a specific field from the structure, use a dot (.) separator.

MBean: java.lang:type=GarbageCollector,name=Copy

Attribute: LastGcInfo

Value Type: CompositeData

To access the specific value for the number of GC threads use: LastGcInfo.GcThreadCount

TabularData Support

Some MBean attributes return data in the form of TabularData, a structure similar to a table, with rows and columns. LogicMonitor can extract specific values from these tables.

A TabularData object typically consists of:

• Index columns: Used to uniquely identify each row (like primary keys in a database)
• Value columns: Contain the actual data you want to collect

You can access a value by specifying:

• The row index (based on key columns)
• The column name for the value you want

Single Index TabluarData Example

The MBean java.lang:type=GarbageCollector,name=Copy has an attribute LastGcInfo. One of its child values, memoryUsageAfterGc, is a TabularData.

The table has 2 columns – key and value. The column key is used to index the table so you can uniquely locate a row by specifying an index value.

For example, key=”Code Cache” returns the 1st row.

To retrieve the value from the value column of the row indexed by the key "Eden Space", use the expression: LastGcInfo.memoryUsageAfterGc.Eden Space.value
In this expression, "Eden Space" is the key used to identify the specific row, and value is the column from which the data will be collected.

Multi-Index TabularData Example

Some tables use multiple index columns to identify rows.

This TabularData structure has four columns, with process and heap serving as index columns. A unique row is identified by the combination of these index values.
To retrieve the value from the committed column in the row where process=Tomcat and heap=Perm Gen, use the expression: LastGcInfo.memoryUsageAfterGc.Tomcat,Perm Gen.committed
Here, Tomcat,Perm Gen specifies the row, and committed is the column containing the desired value.

Array or List Support

Some MBean attributes return arrays or lists of values. LogicMonitor supports collecting data from these array or list values using index-based access.

For example, the MBean: java.lang:type=GarbageCollector,name=Copy has an Attribute: MemoryPoolNames with Type: String[]

To access/collect the first element of this array, the expression “MemoryPoolNames.0“ can be used, where “0” is the index to the array (0-based).

You can access the array elements by changing the index as follows:

• MemoryPoolNames.0 = "Eden Space"
• MemoryPoolNames.1  =  "Survivor Space"

The same rule applies if the attribute is a Java List. Use the same dot and index notation.

To enable JMX collection for array or list attributes:

1. Make sure your Java application exposes JMX metrics.
2. Confirm that the username and password for JMX access are correctly set as device properties:
   • jmx.user
   • jmx.pass

These credentials allow the Collector to connect to the JMX endpoint and retrieve the attribute data, including elements in arrays or lists.

Configuring a Datapoint using the JMX Collection Method

1. In LogicMonitor, navigate to Modules. Add a new DataSource or open an existing module to add a datapoint for JMX collection.
   For more information, see Custom Module Creation or Modules Management in the product documentation.
2. In the Collection Method field, select “JMX”.
   
   
3. Select Add a Normal Datapoint.
4. In the Name field, enter a name for the datapoint.
5. In the Description field, enter a description.
6. In the MBean object field, enter the MBean path, including the domain and properties. 
7. In the MBean attribute field, enter the specific attribute or nested field to collect.
8. In the Metric Type field, select the metric type for the response.
9. Configure any additional settings, if applicable.
   
10. Select  Save.

The datapoint is saved for the module and you can configure additional settings for the module as needed. For more information, see Custom Module Creation or Modules Management.

Troubleshooting JMX Data Collection

Collector does not support the first-level JMX attributes that contain dots(.). By default, the Collector treats dots as path separators to access nested data. If the dot is simply a part of the attribute’s name and not intended to indicate a hierarchy, it can cause:

• ANullPointerException in the JMX debug window,
• NaN (Not a Number) values in the Poll Now results, and
• Failure to collect data correctly

Mitigating JMX Data Collection Issues

To prevent data collection errors with attributes that include dots, do the following:

1. Identify the attribute name in your MBean that contains dots.
   For example (attribute name): jira-software.max.user.count
2. Determine whether the dots are part of the attribute name or indicate a nested path.
   • If the dots are part of the attribute name, escape each dot with a backslash (\.).
     For example: jira-software\.max\.user\.count
   • If the dots indicate navigation inside a structure, do not escape them.
3. Enter the attribute in the LogicModule or JMX Debug window, using the escaped form only when the dots are part of the attribute name.
4. Verify the data collection using the Poll Now feature or JMX debug window.

Attribute Interpretation Examples

The Active Discovery Port method attempts a TCP connection on a list of ports, and returns the ports that respond as instances, using the port value as both the Wildcard Alias and Wildcard Value.

Active Discovery Port Parameters

Example: Memcached Detection with Port Discovery Method

If you run multiple memcached applications on a device, or on different ports on a variety of devices, you can use the “Port” method of Active Discovery to detect and monitor them automatically. The following steps modify a standard DataSource to detect a memcached application on any device that responds on any port from 11211 through 11300:

1. In LogicMonitor, navigate to Settings > Modules. Locate or create the datasource for your memcached application. For more information, see Creating a Datasource.
2. Under Arguments, select “Port” from the Discovery Method dropdown menu.
3. In the Ports List field, enter “11211-11300”.
   
4. Select Save.

If the memcached application is running on ports 11211, 11230, and 11231 of the host, this Active Discovery configuration returns 3 instances that correspond to each of the responding ports.

LogicMonitor provides common configuration monitoring modules from Scripted to BatchScript implements to enhance consistency and maintainability. BatchScript Config Monitoring improves module consistency, supports better maintainability, and aligns with platform-wide modernization efforts.

Requirements for BatchScript Config Monitoring

You must have LogicMonitor Collector version 36.200 or later to use the BatchScript-based ConfigSources.

Migrating to BatchScript Config Monitoring

If your environment currently uses Scripted ConfigSources, you can import the BatchScript versions without losing historical configuration data.

LogicModules in Package

LogicMonitor’s package for BatchScript Config Monitoring consists of the following LogicModules. For full coverage, ensure that all of these LogicModules are imported into your LogicMonitor platform:

When setting static datapoint thresholds on the various metrics tracked by this package’s DataSources, LogicMonitor follows the technology owner’s best practice KPI recommendations.

Edwin AI models have the option to use list-based correlations, enabling you to group deduplicated alerts based on shared values in list-type fields, such as services, locations, or tags. List-based correlation is ideal when multiple alerts involve entities that support overlapping applications or features (for example, the same business service or infrastructure tier).

Models that use list-based correlation work by doing the following:

1. Edwin evaluates alerts that contain values in a specified list-type field.
2. Edwin calculates the number of exact matches between list items in the specified field.
3. If the number of matching items equals or exceeds theminimum overlap count defined in the model, the alerts are grouped into a cluster.

Configuring a list-based correlation requires setting the following parameters: 

• Delimiter (for example, comma, semicolon)
• Trim rules (defining the clean brackets or quotes)
• Escape character (for special parsing)

For more information on how to configure a model using list-based correlations, see Edwin AI Model Creation.

List-based Correlation Scenarios

Use the following table to help you understand how Edwin applies list-based correlation logic:

Alerts:

• Alert A: [inventory, cart, payment]
• Alert B: [inventory, orders]

JMX Active Discovery is a LogicMonitor feature that automatically detects and monitors Java Management Extensions (JMX) objects on a device.

It can identify the following:

• All instances of a specified MBean.
• Instances filtered by specific attributes of a fully defined MBean.
• Multiple Java instances running on different ports. For each instance, it enumerates the available MBean objects.

This results in a structured array of discovered JMX objects across one or more Java Virtual Machines (JVMs), enabling streamlined monitoring in complex Java environments.

Requirements for Enabling JMX Active Discovery

To configure JMX Active Discovery, toggle the Enable Active Discovery switch. 
This enables LogicMonitor to automatically find the DataSource’s instances and the resources they apply to. For more information, see Active Discovery.

Parameters for JMX Active Discovery

You need to define key parameters that determine how LogicMonitor identifies and connects to JMX objects.

Enabling JMX Active Discovery

1. In LogicMonitor, navigate to Modules.
   
2. Select the DataSource you want to edit (for example, a Windows-based DataSource).
   
3. Select   Edit.
   
4. Select the Active Discovery tab.
   
5. Toggle the Enable Active Discovery switch. 
   
6. In the Arguments section, select “JMX” from the Discovery Method dropdown.
   
7. In the JMX Path field, enter the path to the MBean object or attribute you want to discover. 
   The structure and type of the attribute specified in the JMX Path determines how instances are discovered:
   • Primitive type (string or integer) — The attribute’s value is returned as both the alias and the instance value.
   • Array — The array index is used as the alias, and each element is returned as a separate instance.
   • Map — The keys are used as aliases, and the values are returned as instance values.

For example: To return the serverInfo value from the Catalina:type=Server MBean, use the following format: Catalina:type=Server:serverInfo
This would return an instance value such as:  Apache Tomcat/5.5.25
You can use this value in filtering.

8. (Optional)In the Service URL field, enter the URL of the JMX server.
   
9. In the Ports List field, enter a comma-separated list of ports to scan for JMX objects.

10. You can filter discovered instances based on ports, MBean paths, or attribute values.
    To add a filter do the following:
    1. Select Add Filter.
    2. In the Property Name field, enter ##WILDVALUE## or ##WILDVALUE2## if using port-based discovery.
    3. Select an Operator from the dropdown list.
    4. In the Value field, enter the value to filter against.
    5. (Optional) Enter a Comment to describe the filter purpose.
    6. Select Apply to save the filter.
       
11. Select Save.

LogicMonitor now automatically discovers JMX objects across the specified Java instances, enabling monitoring of key performance metrics without manual setup.

Use the SNMP Trap MIBs to upload MIB files for SNMP Trap Logs ingestion. When you upload a MIB and dependent files, LogicMonitor automatically validates the files and uses them for SNMP trap translation. This provides an efficient method for uploading MIB files in LogicMonitor.

SNMP Trap MIB Validation

MIB validation consist of the following:

• During validation, LogicMonitor verifies the file extension and content of the MIBs. It also validates the MIB dependencies (the MIB names mentioned in the IMPORTS section of the MIB being uploaded) across files currently being uploaded and the previously uploaded MIB files.
• Validation results are retained for two hours. You must add the valid MIB files within two hours or start a new validation request.

Uploaded SNMP Trap MIB Details

You can view the following details about the uploaded MIBs on the SNMP Trap MIBs page:

Requirements for Uploading SNMP Trap MIBs

To upload SNMP trap MIBs, you need the following:

• To upload MIB files, you need a LogicMonitor user with the “Manage” permission set. For more information, see LogicMonitor Roles.
• LogicMonitor Collector version must be EA 38.300 or later to consume the uploaded MIBs for trap translation.
• The Collector must be configured to ingest SNMP trap logs using any of the SNMP trap processing preferences. For more information, see SNMP Traps Processing Preference.
• The MIB and all dependent files must be available to upload.
• The MIB files that you want to upload must meet the following requirements:
  • Size of a single MIB file must be less than 2 MB.
  • Only a single MIB definition is allowed per MIB file.
  • The cumulative limit across all uploaded files in a single request is 9 MB for a single upload request. The total MIB upload limit is 1000 MIB files.
  • The supported file extensions are .mib, .txt, or files with no extension.

Uploading SNMP Trap MIBs

1. In LogicMonitor, navigate to Settings > SNMP Trap MIBs.
   The SNMP Trap MIBs page is displayed.
   
2. Select to upload a MIB file.
   The Add MIBs dialog box is displayed.
3. Browse and select one or multiple MIB files.
   
   

• If you are not able to upload all dependent MIBs together, you must first upload the parent MIBs (or the MIBs mentioned in Missing Dependencies message).
• If a MIB fails validation due to invalid file extension, you can rename it with .mib, .txt, or a file without extension.
• If a MIB file that you uploaded has a MIB definition that already exists in the system, during the MIB validation, a message indicating that the existing MIB will be replaced with the newly uploaded MIB is displayed. If you continue with the upload, the existing MIB definition is overwritten by the MIB definition in the new MIB file.
• If a file fails validation while other files succeed, you can do one of the following:
  • Upload necessary MIBs to resolve dependency issues without losing prior result.
  • Add valid MIBs immediately for further processing.
• If multiple files with the same MIB definition are included in a single upload request, only one of the files is considered for upload.
• The system validates the files and displays the validation result. If the validation fails due to a missing dependent file, upload the missing file.

4. Select Add X valid MIBs. 
   
   The valid MIBs are uploaded to LogicMonitor.
   On the SNMP Trap MIBs page, the MIBs are processed and you can view status of the uploaded MIBs. For more information, see Uploaded SNMP Trap MIB Details.
   

The Cost by Tag is a multi-instance DataSource that enables you to collect values for tagged items in the AWS Cost and Usage report, providing a detailed cost breakdown. LogicMonitor automatically adds the AWS Cost by Tag DataSource when you configure AWS billing.

To use this DataSource in a multi-instance configuration, add instances using one of the following methods:

• Enabling Active Discovery (AD)—When AD is enabled for the Cost by Tag DataSource, LogicMonitor automatically discovers one instance per tag value. This enables you to avoid manually entering values for each tag.
  For example, if you use the Cost by Tag DataSource to track applications, and your environment has 100 applications, LogicMonitor automatically discovers and adds each application as a separate instance associated with your AWS account. For more information, see Active Discovery.
• Manually adding instances—You can manually add instances to a DataSource by entering each tag value that you want to track.

For each tag you want to track costs for, you must use a different DataSource. You can clone the DataSource as needed. For more information, see Cloning a LogicModule.

Requirements for Monitoring the AWS Cost by Tag DataSource

To monitor the AWS Cost by Tag DataSource you need to do the following:

• You must set up monitoring for AWS billing. For more information, see AWS Billing Monitoring Setup.
  
• If your environment does not include the Cost by Tag DataSource, you must import it. For instructions on importing DataSources, see LogicModule Updates.

Enabling Active Discovery for the Cost by Tag DataSource

1. In LogicMonitor, navigate to Settings > LogicModules.
   
2. In the Filter Modules… search bar, search and select the “AWS_Billing_CostByTag” from the DataSources list.
   
3. Select  Edit to expand the Active Discovery options.
   
   
   
4. Update the values in the Name, Resource Label, and Description fields, if necessary.
   
5. Toggle the Enable Active Discovery switch. This enables LogicMonitor to dynamically identify and track new values for user-defined tags in your AWS billing data.
   
6. Select the Active Discovery tab.
   
7. In Arguments, select “AWS BILLING REPORT” from the Discovery Method dropdown.
   
8. In the AWS Billing Report Attribute field, enter a the tag to track.
   You must prefix the value with user.
   For example, enter user:OS to discover the supported operating systems.
   

9. Select Save.
   LogicMonitor discovers all values and monitors costs for the specified key.

Manually Adding Instances to the Cost by Tag DataSource

1. In LogicMonitor, navigate to the Resource Tree.
   
2. Select the AWS account where you want to add the instance.
   
3. Select the account-level resource.
   
4. Select  More, then select Add Monitored Instance.
   The Add Monitored Instance settings panel is displayed. 
   
   Note: If you currently have a Cost by Tag DataSource with instances, you can add instances from the Instances tab.
   
5. In the Add Monitored Instance settings panel, enter the following information:
   • In the DataSource field, enter “Cost by Tag” and select a suitable value. 
     
   • In the Name field, enter the display name for the instance in the Resource Tree.
     
   • In the Wildvalue field, enter the tag you want to track. Prefix the value with “user“.
     For example, enter user:OS to discover operating system tags.
     
   • (Optional) In the Description field, enter a description for the instance.
     
     
     

6. In the Instance Group section, select one of the following:
   • Add to existing instance group — Enter the instance group name in the Instance Group field.
     
   • Create new instance group— Enter an Instance group name and description for the new group.
     
7. Select Save.

Depending on the selection, the instance is added to the existing or a new instance group under the instance is now added under the Cost by Tag DataSource in the Resource Tree. Repeat these steps to add more instances as needed.