Temperstack
Main WebsiteFeaturesPricingBlogAbout usRequest a Demo
  • Overview
    • What is Temperstack?
    • Use Cases
  • User Managment
    • Getting started as Admin
      • Inviting Users
      • Mapping multiple services to a Team
      • Single Sign-On (SSO)
      • Customising ALCOM Audit & scanning
    • Getting Started as a User /Responder
    • Managing profile & contact details
  • Integrations
    • Integrating your Observability tools
      • Setting up AWS Integration
        • Multiple AWS Account Integration
        • IAM Setup Guide
          • Creating IAM User: Temperstack with Policy
          • Creating IAM Role: Temperstack with Policy
      • Setting up Microsoft Azure Integration
        • Creating Access for Temperstack in Azure
      • Setting up Google Cloud Platform Integration
        • Creating Access for Temperstack in GCP
      • Setting up Datadog Integration
        • Creating Access for Temperstack in Datadog
        • Managing resources with Datadog
      • Setting up NewRelic Integration
        • Creating Access for Temperstack in NewRelic
        • Managing resources with New Relic
      • Setting up Splunk Integration
        • Creating Access for Temperstack in Splunk
        • Managing resources with Splunk
      • Setting up Appdynamics Integration
        • Creating Access for Temperstack in Appdynamics
        • Managing resources with Appdynamics
      • Setting up Dynatrace Integration
        • Creating Access for Temperstack in Dynatrace
        • Managing resources with Dynatrace
      • Setting up Oracle Cloud Infrastructure
        • Creating Access for Temperstack in OCI
    • Integrating Custom Alerts & Other Alerting sources
      • Webhook Integration
      • Ingesting Emails as alerts
      • Integrating alert listeners from other observability tools
  • Alert routing & Response Managment
    • On-call scheduling and Escalation Policies
    • Setting up Services
    • Alert notification channels
      • Integrating Slack channels
      • Integrating MS Team
    • Mapping resources to Services
      • Rule based resource to Service Mapping
      • Using AI suggested mapping rules
    • Testing Alerting and Notifications
    • Responding to Alerts
  • Monitoring
    • Setting up and maintaining Comprehensive alerting
      • Alerting Templates- metrics & customisation
      • ALCOM and identifying monitoring gaps
      • Programmatically setting up missing alerts in your Observability tool
      • Alert noise Reduction & Optimisation
  • Uptime Monitoring
    • Real time Availability Monitoring
  • Incident analysis & communication
    • External and Internal service Status Pages
      • Instruction to migrate subscribers from Statuspage
  • AI-Powered Issue Resolution
    • AI powered contextual Runbooks
    • Incident command - alert grouping by incident
    • AI Powered Root cause Identification
  • Reporting & Governance
    • Temperstack Dashboard
    • SLO Dashboard
    • MTTA MTTR
  • Billing & Help
    • FAQs
    • Support
Powered by GitBook
On this page
  • Mapping Table Overview
  • Mapping Sections
  • Creating an Auto Mapping Rule
  • Arranging Rule Priority
  • Example Scenarios
  1. Alert routing & Response Managment
  2. Mapping resources to Services

Rule based resource to Service Mapping

Last updated 6 months ago

Automated Service Mapping is a powerful feature in TemperStack that simplifies the process of mapping services to resources. Instead of manually mapping each service to individual resources, users can define a set of rules that automatically handle the mapping process. This feature significantly reduces the time and effort required for service management, especially in large-scale environments.

Key Benefits:

  • Reduces manual effort in service mapping

  • Ensures consistency in mapping across resources

  • Allows for dynamic and flexible mapping based on various criteria

  • Supports scalable service management in complex environments

Mapping Table Overview

The Automated Service Mapping interface presents a table with the following columns:

  1. Mapping Type: Indicates the chosen mapping method (e.g., Name-based or Tag-based).

  2. Mapping Condition: Displays the specific condition set for the mapping rule.

  3. Mapped to Environment/Services: Shows the target Environment or Application Service for the mapping.

  4. Override Mapping: Indicates whether the rule will override existing mappings.

  5. Actions: Allows for reordering of rules to set priority. Rules higher in the list take precedence.

Mapping Sections

The interface is divided into two main sections:

  1. Environment Mapping Rules: Lists rules that map resources to specific environments.

  2. Service Mapping Rules: Contains rules for mapping resources to application services.

Creating an Auto Mapping Rule

  1. Log in to the Temperstack dashboard

  2. Navigate to Admin > Manage Organisation

  3. Click on "Org Service Mapping"

  4. Click the "Add New" button on the right side of the interface

  5. Select Mapping Type: - Name-based: Maps based on resource names - Tag-based: Maps based on resource tags

  6. Define Mapping Condition: For Name-based mapping: - Select a match type:

    • starts_with

    • ends_with

    • exact_match

    • contains

    • Enter the string to match

Example:

Match Type: starts_with String: new This rule will apply to all resources whose names start with "new".

  1. Set Mapping Target: Choose to map to either: - Environment - Application Service

  2. Configure Override Behaviour: - Check the "Override" box if you want the rule to change existing mappings - Leave unchecked to apply only to unmapped resources

  3. Save the Rule: Click the "Save" button to activate the new mapping rule

Arranging Rule Priority

Rules are applied in the order they appear in the list. To change the priority:

  1. Locate the drag icon (usually represented by hamburger icon) on each rule card

  2. Click and hold the icon

  3. Drag the rule to its new position in the list

  4. Release to drop the rule in its new place

  5. Click "Save" to confirm the new order

Important Notes:

  • The rule at the top of the list has the highest priority

  • Always save changes after reordering to ensure the new priority is applied

Example Scenarios

Scenario 1: Development Environment Mapping Mapping Type: Name-based Condition: starts_with "dev-" Map to: Environment (Development) Override: Yes

This rule automatically maps all resources with names starting with "dev-" to the Development environment, overriding any existing mappings.

Scenario 2: Production Service Mapping Mapping Type: Tag-based Condition: contains key"servicename" and value “prod” Map to: Application Service (Production-App) Override: No

This rule maps resources that have tag key as ‘servicename’ and value as ‘prod’ to the Production-App service, but only if they're not already mapped.