Expert Mode: Model Generation Setup

Table of Contents

• General Description
• 1. Data Context Configuration
• 2. Model Services Configuration
• 3. Model Metrics Configuration
• 4. Removing Circular Dependencies
• 5. Model Run Schedule

---

General Description

The expert mode for model generation setup provides detailed configuration of all aspects of the model with flexible customization capabilities. It is suitable for experienced users who need full control over data structure, filtering, service templates, and metrics.

---

1. Data Context Configuration

Purpose of this step - to build a hierarchy (tree) of data sources (assets) that determines where, in what order, and with what filters the data is loaded for the model.

Description

Data context is a sequence of nodes arranged in a tree. Each node describes one data source. The system traverses this tree from top to bottom and sequentially loads data, substituting filters from parent steps into child steps.

Node Structure

Each node is a settings block that contains:

Parameter	What it defines	Example
Node Name	Unique name of the node in the tree	resources
Parent Node	Which node the current one depends on (can be empty for root)	all_services
Active's config	Data source	[pg] APM: Services
Fields for view	Which fields to load from the asset	service, resource
Filters	Data selection conditions. Can reference parent step fields via {{ ... }} or be explicit values	{{ all_services.source_services }}, host_office
Hide node	If checked - node participates in calculations but is not displayed in the final visualization. Node is automatically hidden if data obtained at its stage exceeds 30 records	-

Information

The system supports any number of independent trees. Each tree is processed separately, and results are combined into the final context.

Filter Operation Principle

Filters allow loading only the data that relates to the parent step.

Example: need to load services only for a specific host.

1. Node Hosts loads all hosts (fields: id, name)
2. Node Services has filter: host_id = {{ hosts.id }}
3. The system substitutes each host's id into the filter and loads only its services

Information

Reference syntax: {{ node_name.field }}.

Step-by-Step Instructions

To create a new node:

1. Click the + Add Node button
2. Enter Node Name - unique name
3. Select Parent Node from the dropdown list (or leave empty for root)
4. Select Active's config - where to get data from
5. Check Fields for view - which fields are needed
6. If necessary, add Filters and specify conditions
7. If necessary, check Hide node

To edit an existing node:

1. Click on the node block
2. Change the required parameters
3. Changes are saved automatically

To delete a node:

1. Click on the trash icon in the node block
2. Confirm deletion

Key Rules

Rule	Description
Node name must be unique	Cannot create two nodes with the same name
Parent node must exist	Parent must already be created when specified
Cannot create cycles	A node cannot be a parent to itself or its descendant
Filters reference only parent nodes	Cannot reference a node from another branch or child
Hidden nodes are not visible in visualization	But participate in calculations and pass data to descendants

---

2. Model Services Configuration

Purpose of this step - to define the template of how services will look in the final model: which fields to take for identifier, how to form the name, and how services are related to each other.

---

Configuration Parameters

Basic service parameters:

Parameter	What it defines	Example
Node	Name of the node created in the first step	all_services
Identifier	Template by which the unique service ID is built	{{ all_services.service }}
Service Name	Template of the name that will be displayed on the model	{{ all_services.title }}
Description	Additional explanation for the service (optional)	-

Setting up connection with another service (if the current service depends on another):

Parameter	What it defines	Example
Node	Name of the node where the dependent service is located	resources
Target Service Identifier	Template of the ID of the service on which the current one depends	{{ resources.service }}

Configuration Example

Suppose the following nodes were created in the first step:

• all_services - list of all services
• resources - list of resources that services depend on

Process of configuring a service with a connection:

1. Select node all_services
2. Specify identifier: {{ all_services.service }}
3. Specify name: {{ all_services.service }}
4. In the Connection block, specify node resources
5. Specify target service identifier: {{ resources.service }}

Result in the model: a service with a name and an arrow to the resource it depends on will appear.

Step-by-Step Instructions

To configure basic service parameters:

1. Select Node from the dropdown list (nodes created in Step 1 are available)
2. Enter a template using {{ ... }} in the Identifier field
3. Enter a template for display in the Service Name field
4. Fill in Description if necessary

To configure connection with another service:

1. Expand the Connection block
2. Select Node where the dependent service is located
3. Enter a template in the Target Service Identifier field
4. Add multiple connections if necessary (if supported)

To delete a service or connection:

• click on the trash icon next to the corresponding block

---

3. Model Metrics Configuration

Purpose of this step - to define the metrics template: what indicators will be collected for services, where to get them from, and how to aggregate them. The template is applied to all services automatically. For each service, the system will substitute its own values (via {{ ... }}) and generate metrics according to the specified rules.

Description

Metrics are indicators that characterize the state of a service (for example, CPU load, number of requests, response time).

In this step, you bind global metrics (from the Service Monitor Toolkit monitoring system) to your services and configure exactly how they will be calculated.

Service Structure

At the top, the Service Structure block is displayed - this is a list of previously configured services for which metrics will be collected. Service structures are formed in Step 2.

Configuration Parameters

Parameter	What it defines	Example
Global Metric	Global metric available for binding	cpu_usage, request_duration
Metric Service Name	Template of the metric name for a specific service	{{ service.name }}_cpu
Description	Explanation of what the metric shows and how it is calculated	"CPU load in percent"
Filter group	Filtering of global metric objects for binding to the required service	namespace = {{ service.namespace }}
Common State Detection Function	Method of combining indicators into one service metric	avg, min, max

Step-by-Step Instructions

To create a new metric:

1. Click + Add Metric Structure
2. Select Service Monitor Toolkit Metric from the dropdown list
3. Enter a template using {{ ... }} in the Service Metric Name field
4. Fill in Description (recommended)
5. Add filtering conditions in the Filter Groups block
6. Select Aggregation Function (avg, min or max)
7. Click Save

To edit a metric:

1. Click on the metric block
2. Change the required parameters
3. Changes are saved automatically

To delete a metric:

• click on the trash icon in the metric block

Filter Operation Principle

A global metric can contain data for multiple objects. Filters allow selecting only the data that relates to a specific service.

Example: global metric cpu_usage has tags: service_name, pod, namespace.

To bind it to service payment:

Parameter	Value
Service Monitor Toolkit Metric	cpu_usage
Filter Groups	service_name = "payment"
Metric Service Name	{{ service.name }}_cpu_usage

Information

Reference syntax: {{ node_name.field }}.

Aggregation Functions

When multiple metric values are found by filters (for example, multiple pods of a service), they need to be combined into one service metric.

Function	What it does	Example usage
avg	Arithmetic mean	Average CPU load across all pods
min	Minimum value	Lowest load (to identify idle pods)
max	Maximum value	Peak load (to identify overloaded pods)

---

4. Removing Circular Dependencies

Purpose of this step - to eliminate circular connections that may arise due to complex data structure and lead to incorrect model operation.

Step-by-Step Instructions

Automatic removal:

1. Click the Remove all cycles (n) button, where n is the number of found cycles
2. The system will automatically find and delete all circular dependencies

Manual removal:

1. Find the problematic connection in the interface (usually highlighted)
2. Click on the trash icon next to the dependency

---

5. Model Run Schedule

Purpose of this step - to configure the schedule according to which the model will be automatically recalculated.

Schedule Types

Type	Description	Example
Cron Expression	Flexible configuration through standard cron-syntax	*/5 * * * * - every 5 minutes
Interval	Simple selection: start time/interval/units	01/01/2026 / 20 / days