Introduction

ServiceNow Lightstep, now called ServiceNow Cloud Observability, is a cloud-native observability platform used to analyze application telemetry such as metrics, logs, and traces. In a ServiceNow implementation, its value becomes particularly important when application monitoring needs to be connected with the CMDB, Event Management, service topology, and incident-management processes. ServiceNow describes Cloud Observability as a platform for bringing telemetry into a unified workflow and tracing issues from their visible symptoms toward underlying causes.

A typical enterprise may already have Kubernetes, microservices, APIs, databases, and cloud infrastructure distributed across several environments. A monitoring tool can identify that an API is slow, but the operations team still needs answers to questions such as:

• Which business service is affected?

• Which application component generated the problem?

• Which infrastructure component is involved?

• Is there an existing incident?

• What other services depend on the affected component?

• Can the alert be correlated with a configuration item in the CMDB?

This is where the integration between ServiceNow Cloud Observability and the ServiceNow platform becomes useful.

ServiceNow provides integration capabilities that allow Cloud Observability telemetry and service information to participate in ServiceNow workflows. The Service Graph Connector for OpenTelemetry can import information into the CMDB, while Event Management can receive alerts from Cloud Observability.

Terminology note: Existing project documentation, scripts, staging tables, and connector names may still contain the word Lightstep. For example, ServiceNow documentation references staging tables such as sn_sg_lightstep_resources. This is a naming legacy of the former Lightstep product name.

What Is ServiceNow Lightstep?

ServiceNow Lightstep refers to the former name of ServiceNow Cloud Observability.

The platform focuses on observability rather than traditional infrastructure monitoring alone. It works with telemetry generated as application requests move through distributed services.

For example, consider an e-commerce application:

Customer
   |
   v
Web Application
   |
   v
Order API
   |
   +----> Inventory Service
   |
   +----> Payment Service
   |
   +----> Customer Database

A customer may simply experience:

“Checkout is taking 20 seconds.”

Traditional monitoring might show high response time on the checkout API.

Observability goes further by examining the transaction path and telemetry associated with the request. The operations team can investigate which downstream service introduced the latency.

ServiceNow Cloud Observability supports OpenTelemetry and accepts telemetry through the OpenTelemetry Protocol (OTLP), including HTTP and gRPC transport options.

This makes OpenTelemetry an important part of the technical architecture.

Lightstep and OpenTelemetry

OpenTelemetry provides standardized instrumentation and telemetry collection.

Instead of requiring a proprietary monitoring agent for every application, an organization can instrument applications using OpenTelemetry libraries and collectors.

The simplified architecture is:

Application
    |
    | OpenTelemetry
    v
OpenTelemetry Collector
    |
    | OTLP
    v
ServiceNow Cloud Observability
    |
    +------------------+
    |                  |
    v                  v
Service Graph       Event Management
Connector
    |                  |
    v                  v
ServiceNow CMDB     Events / Incidents

ServiceNow’s Service Graph Connector for OpenTelemetry uses REST APIs to bring Cloud Observability information into the CMDB and can also support pushing events into ServiceNow Event Management.

Real-World Integration Use Cases

Use Case 1 – Kubernetes Service Monitoring

Consider a retail organization running its order-management application on Kubernetes.

The environment contains:

• Kubernetes clusters

• Namespaces

• Pods

• Containers

• Microservices

• Application services

• Databases

The development team can use OpenTelemetry instrumentation to generate telemetry.

Cloud Observability analyzes the telemetry, while ServiceNow can consume relevant service and infrastructure information.

The Service Graph Connector supports importing Kubernetes-related information such as clusters, nodes, pods, containers, container images, services, deployments, namespaces, and other Kubernetes objects.

This gives the CMDB a more useful representation of the application’s technical topology.

Use Case 2 – Application Alert to ServiceNow Event Management

Suppose a payment API begins returning HTTP 500 errors.

Cloud Observability detects the problem based on an alert threshold.

The alert can be sent to ServiceNow Event Management.

The resulting process can look like:

Payment API Error
       |
       v
Cloud Observability Alert
       |
       v
ServiceNow Event Management
       |
       v
CI Identification
       |
       v
Event Correlation
       |
       v
Incident / Operational Response

ServiceNow documents a standard webhook-based integration for Cloud Observability events. The Cloud Observability notification destination points to the ServiceNow Event Management inbound endpoint.

Use Case 3 – Dependency Mapping

A large organization may have hundreds of microservices.

A manually maintained dependency map quickly becomes inaccurate.

Cloud Observability can use OpenTelemetry trace information to infer relationships between services. The Service Graph Connector can bring dependency-map information into ServiceNow and populate related CMDB structures.

For example:

Customer Portal
      |
      v
Order Service
      |
      +------> Inventory Service
      |
      +------> Payment Service
                     |
                     v
                Payment DB

When the Payment Service becomes unavailable, the operations team can understand which higher-level service may be affected.

Architecture and Technical Flow

A practical implementation normally has several logical layers.

Layer 1 – Application Instrumentation

Applications generate telemetry using OpenTelemetry.

Typical telemetry includes:

• Traces

• Metrics

• Logs

• Resource attributes

• Service information

• Kubernetes metadata

The important implementation principle is consistency.

For example, service names should be standardized:

service.name = order-service
environment = production
team = payments

Poor metadata makes downstream correlation considerably harder.

Layer 2 – OpenTelemetry Collector

The OpenTelemetry Collector acts as a telemetry processing layer.

A simplified flow is:

Application
    |
    v
OTel SDK
    |
    v
OTel Collector
    |
    +---- Receivers
    |
    +---- Processors
    |
    +---- Exporters
    |
    v
Cloud Observability

The collector can receive telemetry, process it, and export it to the required destination.

Layer 3 – Cloud Observability

ServiceNow Cloud Observability provides the observability layer where telemetry can be analyzed.

The platform is designed to correlate metrics, logs, and traces to help teams move from symptoms toward causes.

Layer 4 – ServiceNow CMDB

The Service Graph Connector for OpenTelemetry can import relevant observability-derived configuration information into ServiceNow.

ServiceNow documentation identifies mappings for resources, pods, containers, container images, Kubernetes services, and dependency maps.

Layer 5 – Event Management

Alerts generated from Cloud Observability can be pushed into ServiceNow Event Management.

The resulting event can potentially be:

1. Received by Event Management.

2. Matched against event rules.

3. Bound to a CI.

4. Correlated with related events.

5. Used in operational workflows.

This is where observability becomes part of an enterprise service-management process instead of remaining isolated inside a monitoring platform.

Prerequisites

Before starting an implementation, confirm the following.

1. ServiceNow Instance

You need a ServiceNow instance with the required ITOM/Event Management capabilities.

2. Cloud Observability Subscription

The organization must have access to the required ServiceNow Cloud Observability capabilities.

3. OpenTelemetry Instrumentation

Applications must generate usable OpenTelemetry telemetry.

4. Network Connectivity

Confirm that the relevant endpoints can communicate securely.

5. CMDB Model

Decide which application and infrastructure objects should exist as CIs.

6. Naming Standards

Define standards for:

• service.name

• Environment

• Cluster

• Namespace

• Application

• Business service

• CI names

7. Security

Create integration users with the minimum permissions required.

ServiceNow’s current Cloud Observability Event Management documentation specifically recommends using a least-privileged user with the evt_mgmt_integration role rather than a highly privileged account.

Step-by-Step Build Process

Step 1 – Define the Integration Scope

Do not start by installing connectors immediately.

First document:

This prevents unnecessary telemetry and CMDB data from being imported.

Step 2 – Instrument the Application

Configure the application to produce OpenTelemetry data.

For example:

service.name = order-service
deployment.environment = production
k8s.cluster.name = prod-cluster
k8s.namespace.name = orders

The exact instrumentation method depends on the programming language and deployment architecture.

The key consultant-level consideration is not simply “does telemetry exist?”

It is:

“Does the telemetry contain the attributes required for ServiceNow correlation?”

ServiceNow documentation notes that Cloud Observability can recognize CI-related attributes such as service.name, cloud.provider, and k8s.cluster.name.

Step 3 – Configure Cloud Observability

Configure the required telemetry ingestion and monitoring.

Create alerts around meaningful operational conditions.

For example:

Alert Name:
Payment API - High Error Rate

Condition:
HTTP 5xx > 5%

Evaluation:
5 minutes

Environment:
Production

Avoid creating alerts for every minor metric fluctuation.

A production implementation should focus on alerts that require operational action.

Step 4 – Create the ServiceNow CI

For Event Management integration, ServiceNow documentation requires a CI that can be associated with the incoming Cloud Observability service.

Navigate through:

All → Configuration → Application Service

Create the application service.

For example:

Name: payment-service
Operational Status: Operational

The service name is important because ServiceNow’s documented binding process expects the Cloud Observability service name to match the CI name.

Step 5 – Configure the Service Graph Connector

The Service Graph Connector for OpenTelemetry can be used to bring Cloud Observability data into the CMDB.

The connector uses scheduled import jobs.

The conceptual flow is:

Cloud Observability
       |
       | REST APIs
       v
Service Graph Connector
       |
       v
Staging Tables
       |
       v
Transform / Mapping
       |
       v
CMDB

ServiceNow documents dedicated staging structures for resources, pods, containers, services, and dependency maps.

Important current-release consideration

ServiceNow’s current Australia release documentation states that the Service Graph Connector for OpenTelemetry is being prepared for future deprecation. It will be hidden and no longer installed on new instances, although it continues to be supported.

This is extremely important when designing a new implementation.

Do not automatically build a new long-term architecture around a connector that is already marked for future deprecation. Confirm the supported replacement architecture with the current ServiceNow documentation and your ServiceNow account team before committing the design.

Step 6 – Configure Event Management

ServiceNow documents Cloud Observability integration through an Event Management connector and notification destination.

The documented flow includes configuring a ServiceNow destination in Cloud Observability with the ServiceNow Event Management endpoint.

The endpoint follows the documented inbound-event pattern:

https://<instance-name>.servicenow.com/
api/sn_em_connector/em/inbound_event?source=lightstep

Use the exact endpoint and authentication approach supported by the target release rather than copying credentials or URLs from an old project.

Step 7 – Configure the Cloud Observability Notification Destination

In Cloud Observability:

Alerts → Notification destinations → Create a destination

Select the ServiceNow integration or webhook approach supported by the implementation.

Configure:

• Destination name

• ServiceNow URL

• Authentication

• Payload/template

• Service name or CI-binding information

ServiceNow’s current documentation also describes using a webhook with the ServiceNow Event Management payload template when required.

Step 8 – Configure the Alert

Create an alert in Cloud Observability.

For example:

Alert:
Order API High Latency

Threshold:
p95 latency > 2 seconds

Evaluation window:
5 minutes

Notification:
ServiceNow Event Management

When the threshold is reached, Cloud Observability sends the event to ServiceNow.

Testing the Technical Component

A good implementation should use a controlled test rather than waiting for a production incident.

Test Scenario

Generate an application condition that crosses the alert threshold.

For example:

Normal response:
350 ms

Alert threshold:
2000 ms

Test response:
2500 ms

The expected sequence is:

Application
   ↓
OpenTelemetry
   ↓
Cloud Observability
   ↓
Alert
   ↓
ServiceNow Event Management
   ↓
Event
   ↓
CI Binding

Validation Checklist

Check the following:

• Did telemetry reach Cloud Observability?

• Did the alert trigger?

• Was the notification destination executed?

• Did ServiceNow receive the event?

• Was the event classified correctly?

• Was the correct CI identified?

• Did the service name match?

• Was the severity mapped correctly?

• Was the event correlated with related events?

• Was the expected incident or operational workflow initiated?

ServiceNow documents five severity values for the connector flow:

The documented default severity for stream-based alerts is Critical, and this can be changed through the relevant connector configuration.

Common Errors and Troubleshooting

Error 1 – Event Arrives but CI Is Not Identified

This is one of the most common implementation problems.

Check:

Cloud Observability service name
            =
ServiceNow CI name

ServiceNow specifically documents name matching as part of CI binding for this integration.

Also verify the relevant service metadata or service-name header.

Error 2 – Telemetry Exists but Dependency Mapping Is Poor

Usually this is a metadata problem.

Check whether traces contain consistent:

• service.name

• Kubernetes attributes

• Cloud attributes

• Environment information

Do not attempt to fix a topology problem entirely inside ServiceNow if the source telemetry is incomplete.

Error 3 – Duplicate Events

Duplicate events can occur when multiple monitoring rules represent the same underlying condition.

Review:

• Alert conditions

• Notification rules

• Event rules

• Correlation logic

• Source identifiers

The goal is not simply to make the event appear. The goal is to make one operational condition produce a manageable event lifecycle.

Error 4 – Authentication Failure

Check:

• Integration user

• Role

• Password/token

• Endpoint

• Network access

• Authentication method

• Expiration of credentials

Use a dedicated integration identity instead of a personal administrator account.

Error 5 – CMDB Contains Duplicate CIs

This is a classic ServiceNow implementation problem.

Before enabling imports, understand the existing CMDB population.

For example:

Existing CI:
payment-service

Imported CI:
payment-service-prod

If identification rules are poorly designed, the same real-world service can become multiple CIs.

Always establish reconciliation and identification rules before increasing import volume.

Error 6 – New Instance Does Not Have the Connector

This may not necessarily indicate a technical installation failure.

The current Australia documentation states that the Service Graph Connector for OpenTelemetry is being prepared for future deprecation and will be hidden/not installed on new instances.

For a new project, verify the current supported integration path before troubleshooting installation.

Best Practices

1. Treat OpenTelemetry Metadata as an Integration Contract

Define telemetry naming standards before development teams start instrumenting applications.

For example:

service.name
environment
team
application
k8s.cluster.name
k8s.namespace.name

This makes downstream CMDB and event correlation considerably easier.

2. Do Not Import Everything Into the CMDB

A CMDB is not a telemetry warehouse.

Only bring information that provides operational value.

A useful model is:

Telemetry → Observability Platform

Operational Configuration → CMDB

Actionable Conditions → Event Management

This separation prevents unnecessary CMDB growth.

3. Design CI Binding Before Alert Configuration

Do not create hundreds of alerts first and then ask how they will bind to CIs.

Start with:

Service
 ↓
CI
 ↓
Telemetry attributes
 ↓
Event
 ↓
Correlation

Then create alert rules.

4. Use Least-Privilege Integration Accounts

Integration accounts should have only the permissions necessary for the workflow.

ServiceNow explicitly recommends a least-privileged user for the Cloud Observability Event Management integration.

5. Establish a Naming Convention

For example:

Application:
Order Management

Service:
order-service

Environment:
production

Kubernetes:
prod-orders-cluster

Without naming standards, service correlation becomes increasingly difficult as the organization grows.

6. Control Alert Volume

More alerts do not necessarily mean better observability.

For example, an alert for every temporary CPU spike may create noise.

A better operational alert might combine:

High latency
+
High error rate
+
Production environment

This gives operations teams a condition that is more actionable.

7. Validate the Architecture Against Current ServiceNow Releases

This is particularly important for Lightstep-related integrations.

ServiceNow’s current documentation identifies the OpenTelemetry Service Graph Connector as being prepared for future deprecation beginning with the Australia release.

Therefore, consultants should distinguish between:

• Existing supported implementations

• Existing legacy implementations

• New implementations

• Long-term target architecture

Do not assume that an integration documented for an older ServiceNow family should automatically be the architecture for a new project.

Real Implementation Example

Consider a financial-services application consisting of:

Customer Portal
       |
       v
API Gateway
       |
       v
Account Service
       |
       +----> Payment Service
       |
       +----> Customer Database

The application runs on Kubernetes.

The organization implements OpenTelemetry instrumentation.

When Payment Service latency increases:

1. OpenTelemetry captures the transaction.

2. Cloud Observability analyzes the telemetry.

3. The alert threshold is exceeded.

4. Cloud Observability sends an event toward ServiceNow.

5. Event Management receives the event.

6. ServiceNow attempts to associate the event with the appropriate CI.

7. Operations can investigate the affected application service and related infrastructure.

8. The incident-management process can proceed using ServiceNow workflows.

The important point is that observability and IT service management are connected.

Without the integration, the SRE team might know that the payment service is slow while the Service Desk knows only that customers are reporting checkout problems.

With appropriate integration, both teams can work from a common operational context.

Frequently Asked Questions

1. Is Lightstep still the current name?

No. ServiceNow documentation now refers to the product as ServiceNow Cloud Observability, formerly Lightstep. Existing integrations and technical artifacts may still contain Lightstep terminology.

2. Does ServiceNow Lightstep use OpenTelemetry?

Yes. ServiceNow Cloud Observability supports OpenTelemetry for telemetry collection and supports OTLP over HTTP or gRPC.

3. Can Cloud Observability alerts create ServiceNow events?

Yes. ServiceNow provides an Event Management integration in which Cloud Observability alerts can be sent to ServiceNow using a ServiceNow destination or webhook.

Summary

ServiceNow Lightstep, now known as ServiceNow Cloud Observability, is best understood as part of an observability architecture rather than simply another monitoring tool.

The practical integration pattern is:

Applications
     ↓
OpenTelemetry
     ↓
OpenTelemetry Collector
     ↓
ServiceNow Cloud Observability
     ↓
+-----------------------+
|                       |
v                       v
CMDB / Service Graph   Event Management
|                       |
v                       v
Service Topology       Events / Incidents

For implementation teams, the most important areas are not merely connector installation. The quality of the solution depends heavily on OpenTelemetry metadata, service naming, CI identification, CMDB governance, event correlation, alert design, and release compatibility.

One particularly important consideration for new implementations is the current ServiceNow product direction: the Australia-release documentation states that the Service Graph Connector for OpenTelemetry is being prepared for future deprecation and will not be installed on new instances.

Therefore, consultants working on a new project should validate the current supported architecture before designing a long-term dependency on the connector.

For additional information, refer to the current ServiceNow Cloud Observability documentation and the relevant ServiceNow Service Graph Connector for OpenTelemetry documentation. Also review the current ServiceNow release-specific documentation before implementing the integration in a production environment.