Observability vendor entity mappings for Service Observability

  • Release version: Australia
  • Updated March 12, 2026
  • 5 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Observability vendor entity mappings for Service Observability

    ServiceNow Service Observability integrates with various observability vendors to map and display metrics for services, hosts, databases, and network components on its dashboards. This mapping uses key:value pairs defined in configuration rules, enabling Service Observability to query vendor resources and present relevant data. Each vendor has specific methods and APIs for retrieving these entities, and the mappings ensure accurate correlation between ServiceNow entities and vendor resources.

    Show full answer Show less

    Vendor-Specific Entity Mappings

    • Amazon CloudWatch: Uses AWS GetResources API. Maps API Gateway, ELB, Lambda, EC2 hosts, and RDS databases to corresponding Service Observability dashboards.
    • AppDynamics: Retrieves resources via entityName property from AppDynamics APIs. Maps applications, server nodes, MySQL, and PostgreSQL databases.
    • Azure: Uses Azure ResourceGraph API. Maps cloud services, web sites, virtual machines, and MySQL/PostgreSQL databases to observability categories.
    • Datadog: Uses Software Catalog and Hosts APIs; filters MySQL and PostgreSQL databases by specific metrics. Services without metadata must be mapped by service name tags. Default dashboards depend on trace.http.request metrics but can be customized.
    • Dynatrace: Supports both Classic and Grail (DQL) queries with separate data connections; falls back from Grail to Classic. Maps services, hosts, and MySQL/PostgreSQL databases.
    • LogicMonitor: Uses Get Devices API filtering by entity properties. Maps services, physical/virtual hosts, and MySQL/PostgreSQL databases based on specific property values.
    • New Relic: Maps application services, hosts, and MySQL/PostgreSQL databases.
    • Prometheus: Maps applications, server nodes, and MySQL/PostgreSQL databases.
    • SolarWinds: Maps application services, hosts, firewall, load balancers, network interfaces, and other network devices. Defaults use Palo Alto firewall and F5 load balancer keys, but templates can be customized. Custom properties in mappings are optional but restrict returned entities if used.
    • Splunk: Uses Splunk Metric time series Metadata API, searching custom properties first then fallback to dimensions. Filters by metrics for application services, hosts, and MySQL databases. PostgreSQL is not supported.
    • Zabbix: Categorizes all monitored entities as hosts but differentiates entities via metadata keywords in tags and groups. Keywords are used to classify applications, hosts, databases, firewalls, load balancers, network devices, and more. Default dashboards use standard Zabbix keys; customization is needed for custom keys.

    Key Practical Considerations for ServiceNow Customers

    • Configure key:value mapping rules carefully to ensure ServiceNow queries the correct vendor resources and displays accurate metrics.
    • Be aware of vendor-specific APIs and filters used to retrieve entities, which impact what data is available on dashboards.
    • For vendors like Datadog and Zabbix, metadata presence and keyword matching are critical to entity mapping; manual mapping or customization may be needed if metadata is missing or custom keys are used.
    • Default dashboard templates rely on specific metrics; if your environment does not emit these, customize dashboards accordingly to surface relevant data.
    • Networking components mapped via SolarWinds and Zabbix default to Palo Alto and F5 keys; to monitor other devices, update dashboard templates as instructed.
    • Using custom properties in mappings can restrict returned entities, so configure mappings aligned with your metadata strategy.

    This integration framework empowers ServiceNow customers to unify observability data from multiple vendors into cohesive dashboards, enhancing visibility into service health and infrastructure performance across diverse environments.

    Understand how Service Observability maps service, host, and database entities to your observability vendor resources.

    Service Observability displays metrics from your observability vendor for services, hosts, databases, and network components on the Observability dashboards based on the key:value pairs in the mapping rules you create during configuration. Service Observability sends a request to the observability vendor using that mapping as a filter to find related entities. Any additional filtering needed to find the entities is noted in the following sections.

    Amazon CloudWatch entity mapping

    Resources are returned using the AWS GetResources API.

    Service Observability entity category Service Observability entity dashboard AWS resource
    Application API Gateway - HTTP API Gateway HTTP APIs
    API Gateway - REST API Gateway REST APIs
    ELB ELB application load balancers
    Lambda Lambda functions
    Compute Host EC2 instances
    Databases RDS RDS database instances

    AppDynamics entity mapping

    Resources are returned using the value of the entityName property.

    Service Observability entity category Service Observability entity dashboard AppDynamics resource
    Application Service AppDynamics applications returned by the /controller/rest/applications/ API
    Compute Host Server nodes for applications returned by the /controller/sim/v2/user/machines/keys/ API
    Databases MySQL MySQL database instances returned by the /controller/rest/databases/collectors/
    PostgreSQL MySQL database instances returned by the /controller/rest/databases/collectors/

    Azure entity mapping

    Resources are returned using the Azure ResourceGraph API.

    Service Observability entity category Service Observability entity dashboard Azure resource
    Application Service

    • Microsoft.Compute/cloudServices

    • Microsoft.Web/sites
    Compute Host

    Microsoft.Compute/virtualMachines

    Databases MySQL

    • Microsoft.DBforMySQL/servers

    • Microsoft.DBforMySQL/flexibleServers

    PostgreSQL

    • Microsoft.DBforPostgreSQL/servers

    • Microsoft.DBforPostgreSQL/flexibleServers

    Datadog entity mapping

    Service Observability entity category Service Observability entity dashboard Datadog resource
    Application Service Entities returned from the Software Catalog: List Entities API
    Compute Host Hosts returned from the Hosts: List Hosts API
    Databases MySQL Databases returned by filtering the mysql.net.max_connections metric, filtered by the provided key:value pair in the data mapping.
    Note:
    If your databases don't emit this metric, they aren't mapped.
    PostgreSQL Databases returned by filtering the postgresql.connections metric, filtered by the provided key:value pair in the data mapping.
    Note:
    If your databases don't emit this metric, they aren't mapped.
    Items of note:
    • Service entities: The Software Catalog list entities API only returns data for services that include metadata. If you want to map services that don't include metadata, you must create a mapping using service as the tag and the name of the service as the value.
      For example, say you have a service named internet-banking-4 that you want to use in a mapping and it doesn't contain metadata. You set up the mapping as shown in this screenshot.
      Figure 1. Datadog mapping if no metadata is present
      How to map a service that doesn't contain metadata
    • Default dashboard templates: The Requests, Errors, and Latency charts on the Overview and Observability dashboard templates are created using the Datadog trace.http.request trace metric. If a service isn't emitting that metric, no data is found. You can customize the template to use a different trace metric query. See Customize Service Observability dashboard templates for more information.

    Dynatrace entity mapping

    You can use either the Dynatrace Classic query or Grail (DQL) query, however both require separate data connections. For Grail queries, Service Observability first queries the Grail data source and if not found, will fall back to a Classic query.

    Service Observability entity category Service Observability entity dashboard Dynatrace resource
    Application Service Services
    Compute Host Hosts
    Databases MySQL MySQL database instances
    PostgreSQL PostgreSQL database instances

    LogicMonitor entity mapping

    Resources are returned using the Get Devices API, using specific property values on the entities as a filter.

    Service Observability entity category Service Observability entity dashboard LogicMonitor resource
    Application Service Entities with the predef.externalResourceType auto property set to Service
    Compute Host Entities with the predef.externalResourceType auto property set to PhysicalServer, Container, or VirtualMachine
    Databases MySQL Entities with the system.categories custom property set to MySQL
    PostgreSQL Entities with the system.categories custom property set to PostgreSQL

    New Relic entity mapping

    Service Observability entity category Service Observability entity dashboard New Relic resource
    Application Service Application services
    Compute Host Hosts
    Databases MySQL MySQL database instances
    PostgreSQL PostgreSQL database instances

    Prometheus entity mapping

    Service Observability entity category Service Observability entity dashboard Prometheus resource
    Application Service Applications
    Compute Host Server nodes for applications
    Databases MySQL MySQL database instances
    PostgreSQL PostgreSQL database instances

    SolarWinds entity mapping

    Service Observability entity category Service Observability entity dashboard SolarWinds resource
    Application Service Application services
    Compute Host Hosts
    Networking Firewall By default, data mappings find and display metrics using Palo Alto Firewall keys.

    If you want metrics from a different firewall, follow the instructions for customizing dashboard templates.
    Load Balancer By default, data mappings find and display metrics using F5 Big-IP Load Balancer keys.

    If you want metrics from a different load balancer, follow the instructions for customizing dashboard templates.
    Interface Network interfaces
    Other Network Devices Other network devices, such as switches and routers
    Items to note:
    • You can use custom properties for key/value pairs in a data mapping.
    • If you are using SolarWinds as an exception in your mapping to ingest networking metrics, using custom properties is optional. If you do use them, only entities with those properties in their metadata are returned. If you leave the tag and key values blank, all supported entities are returned.

    Splunk entity mapping

    Resources are returned using the Splunk Metric time series Metadata API. Service Observability searches for matching key:value pairs in custom properties and then falls back to searching dimensions.

    The returned payload is then filtered by the presence of a specific metric in the metadata that corresponds with an entity type.

    Service Observability entity category Service Observability entity dashboard Splunk Property or dimension Splunk metric used for filtering
    Application Service

    • Property: sf_service

    • Dimension fallback: service.name

    		 sf_metric:service.request
    Compute Host

    • Property: host.name

    • Dimension fallback: host.id

    		 sf_metric:disk.summary_utilization
    Databases MySQL

    • Property: mysql.instance.name

    • Dimension fallback: mysql.instance.endpoint

    		 sf_metric:mysql.threads
    PostgreSQL Not supported

    Zabbix entity mapping

    In Zabbix, every monitored entity is categorized as a host. To enable differentiation between entities, Service Observability searches for keywords in attributes on metadata tags, including host tags, inherited tags, templates, and host groups. Any Zabbix host that does not match a keyword are classified and displayed as Host entities.

    The following table shows the keywords used to find distinct entities. Keywords are case insensitive.

    Service Observability entity category Service Observability entity dashboard Metadata keyword
    Application Service
    • Apache
    • nginx
    • Kubernetes
    • cluster
    • application
    Compute Host Any non-matching keyword
    Databases MySQL
    • Mysql
    • Msql
    • mariadb
    PostgreSQL
    • Postgres
    • Psql
    • Pgsql
    • Postgresql
    Networking Firewall
    • Firewall
    • palo-alto
    • palo alto
    • pan
    • fortigate
    • fortinet
    • fgt
    • sophos
    • sonicwall
    • watchguard
    • zscaler
    By default, data mappings find and display metrics using Palo Alto Firewall keys.

    If you want metrics from a different firewall, follow the instructions for customizing dashboard templates.
    Load Balancer
    • Loadbalancer
    • load_balancer
    • alb
    • nlb
    • f5
    • netscaler
    • big-ip
    • bigip
    By default, data mappings find and display metrics using F5 Big-IP Load Balancer keys.

    If you want metrics from a different load balancer, follow the instructions for customizing dashboard templates.
    Other Network devices
    • Network
    • router
    • rt
    • gateway
    • gw
    • juniper
    • junos
    • switch
    • catalyst
    • nexus
    • arista
    Item to note:

    The default dashboards for each entity type display metrics using Zabbix standard keys. If your implementation uses custom item keys, you need to customize your dashboard templates accordingly.