SPLK-3002 Templates and Dependencies

Templates and Dependencies Detailed Explanation

1. What Are Service Templates in ITSI?

Simple Definition

A Service Template is a reusable blueprint for building services in ITSI.
It allows you to define a standard set of KPIs, thresholds, and health scoring rules—and then apply that structure to multiple services.

It’s similar to creating a “master layout” that other services can follow.

Why Use Templates?

Without templates:

• You have to configure each service manually

• Changes have to be applied to every service one by one

With templates:

• You create a single definition once

• All services linked to the template inherit updates automatically

This makes monitoring faster, more consistent, and easier to scale.

2. Use Cases for Service Templates

Here are a few practical situations where templates shine:

a. Scaling Across Environments

If you monitor the same app in 10 different regions, you don’t want to build 10 identical services manually.

Instead:

• Create a template for “App Monitoring”

• Apply it to each region’s service

• Now all 10 services have the same structure and KPIs

b. Maintaining Consistency

Templates make sure:

• Every team uses the same thresholds

• All services are measured using the same logic

• Alerts behave consistently across departments

This is especially useful in large organizations with many teams.

c. Speeding Up Service Creation

Templates help you launch new services quickly:

• New team?

• New product line?

• New cloud service?

Just apply an existing template and you're up and running.

3. What’s Inside a Service Template?

A service template usually includes:

KPI Base Searches

The SPL searches used to calculate metrics.

Thresholds and Time Policies

Predefined rules that determine when a KPI changes state.

Health Score Rules

How the KPIs contribute to a service's health score (e.g., weighted averages, worst KPI rule).

When you apply the template to a new service:

• You can override some details (like entity names)

• But the core logic stays the same

4. Understanding Dependencies Between Services

What Are Service Dependencies?

In ITSI, dependencies define relationships between services.
Usually, this is in a parent-child structure.

Example:

• “Checkout Service” (parent)

  • Depends on “Payment Gateway” (child)

  • Depends on “Database Service” (child)

If the Payment Gateway fails, it will lower the health score of the Checkout Service.

Why Are Dependencies Important?

They allow you to:

1. Model Service Trees

• You can visualize how services are connected

• Helps in understanding upstream and downstream impact

2. Perform Impact Analysis

• If a database goes down, you can instantly see:

  • Which web services are affected

  • How critical the overall business impact is

3. Use Weighted Health Scoring

• Not all dependencies are equally important.

• You can set weights (e.g., Database = 60%, Search API = 40%)

• This reflects the real impact of failures more accurately

5. Best Practices for Templates and Dependencies

Keep Templates Modular and Reusable

• Avoid hardcoding specific names or conditions.

• Use tokens or variables so templates work across different teams or environments.

Avoid Circular Dependencies

• A service should not depend on another service that depends on it.

• Circular dependencies create confusion and break impact analysis.

Use Meaningful Weighting

• Assign weights that reflect real-world importance.

• Example: If a database is mission-critical, give it a higher weight than a reporting tool.

Summary: What to Remember About Templates and Dependencies

• Service Templates help you standardize KPIs, thresholds, and scoring logic across multiple services.

• Templates save time, ensure consistency, and make updates easier.

• Dependencies model how services rely on each other, creating a service tree.

• They support impact analysis, visualization, and smart health scoring.

• Use best practices to keep your design scalable, clean, and easy to maintain.

Templates and Dependencies (Additional Content)

1. How Templates Bind to Services

Templates in ITSI are not limited to new service creation—they can be:

• Applied during the creation of a new service (standard use case)

• Attached to an existing service to retrofit it with standard KPI logic and structure

This flexibility allows teams to:

• Enforce standardization over time

• Update existing services to reflect new monitoring practices

Template Updates and Synchronization

When a template is updated, ITSI provides an option to:

• Push updates to all linked services automatically, or

• Allow manual review and selective synchronization

This helps maintain controlled scalability without forcing immediate changes.

2. Tokenization and Variable Use in Templates

Templates in ITSI support dynamic tokenization, allowing placeholders that can be replaced based on the target service or entity.

Common Use Case Example:

index=app_logs host=$host$ | stats count as error_count

Here, $host$ acts as a token that is replaced with the actual host of each entity when the template is applied.

This makes the template:

• Reusable across services or environments

• Capable of automating customization without hardcoding

You can tokenize:

• KPI names

• Search filters

• Split-by fields

• Entity references

3. Templates and Time Policies

Time Policies define context-sensitive thresholds (e.g., business hours vs. off-hours).

Templates can include:

• Predefined Time Policies, such as:

  • "Business Hours Policy"

  • "Weekend Maintenance Window"

When a template is applied:

• These time policies are automatically assigned to corresponding KPIs

• No need to manually reconfigure time-sensitive behavior for every service

This supports consistent temporal logic across all derived services.

4. Dependency Tree Visualization (Service Analyzer)

ITSI supports visual dependency modeling through the Service Analyzer, where users can:

• View a dependency tree

• Identify parent-child service relationships

• Monitor the real-time health of each service

This view is known as the Dependency View, and it enables:

• Root Cause Analysis (see where failure originates)

• Impact Analysis (understand cascading effects across tiers)

In the exam, if asked where service dependencies are visualized, Service Analyzer is the correct answer.

5. Propagation of Notable Events and Health Impact

When a child service experiences an issue (e.g., a KPI enters Critical state):

• This change can propagate upward to affect the parent service’s health score

• A Notable Event generated at the child level can:

  • Be aggregated at the parent level

  • Trigger correlation searches that incorporate dependency awareness

This propagation supports:

• Automated escalation of critical incidents

• Clear mapping between symptoms (child) and business impact (parent)

This mechanism is fundamental to ITSI's service-centric monitoring model.

Summary

• Templates can be applied to both new and existing services

• They support tokenization to allow reusability across services and entities

• Time Policies can be included within templates to enforce consistent time-aware behavior

• Dependencies are visualized in the Service Analyzer's Dependency View

• Notable Events and Health Scores can propagate through service hierarchies for better visibility and alert escalation