Cloud Observability can ingest metrics, logs, and traces from a large number of tools, platforms, languages and frameworks that support sending data using standards like the OpenTelemetry Protocol (OTLP), statsd (Datadog), or the Elastic Bulk API.
However, using certain technologies ensures the best out-of-the-box experience and our recommendations on security, architecture, performance, and configuration. The following is a list of platforms, integrations, and open-source components that have been validated to work best with ServiceNow Cloud Observability.
|Official||Current stable + previous two releases||Linux (ARM, AMD64)|
|Amazon EKS||Current stable + previous two releases||Linux (ARM, AMD64)|
|Azure AKS||Current stable + previous two releases||Linux (ARM, AMD64)|
|Google Kubernetes Engine||Current stable + previous two releases||Linux (ARM, AMD64)|
When you run applications in the above Kubernetes distributions, you should deploy the recent version of the otel-cloud-stack Helm chart. This chart automatically configures collectors using best practices for monitoring the health of your Kubernetes clusters. Follow our quick start to deploy the chart.
We recommend using only OpenTelemetry code instrumentation components that are marked as “Stable” on the official OpenTelemetry status page.
|OpenTelemetry Collector Core||Current stable + previous four releases||Linux (ARM, AMD64)|
|OpenTelemetry Collector Contrib||Current stable + previous four releases||Linux (ARM, AMD64)|
|AWS ADOT||Current stable release||Linux (ARM, AMD64)|
You must configure the Collectors to use components that properly collect and annotate telemetry from Kubernetes and other infrastructure. Our otel-cloud-stack configures these components for you by default. For your production telemetry pipelines, we recommend OpenTelemetry Collector Contrib components with at least stability “beta” or “stable.”
For details on recommended annotations, see OpenTelemetry Semantic Conventions.
|OpenTelemetry Collector||See above||See above|
|Elastic Logstash||Current stable||Linux (ARM, AMD64)|
|Vector||Current stable||Linux (ARM, AMD64)|
Cloud Observability supports the last three versions of the OpenTelemetry Operator.
You can scrape Prometheus metrics in OpenMetrics format (Cloud Observability doesn’t support directly reading metrics from a Prometheus database). Use one of the following methods:
All scraped targets must follow the OpenMetrics v1.0 specification.
Cloud Observability integrates with the most current stable and previous two major releases of the ServiceNow platform.
If you’re using microsatellites, always use the most recent version for the latest performance and security updates.
For comprehensive information on integrations with Amazon Cloudwatch, Azure Insights, Google Cloud operations suite and third-party databases, service meshes, and other technologies, refer to our integration documentation.
Customers should follow OpenTelemetery semantic conventions when labeling metrics, logs, or traces or integrating with third-party metric data sources.
At minimum, the following resource semantic conventions should exist (where applicable) on all metrics, logs, and span data. Resources describe entities (like a server, or Kubernetes Pod) that emit telemetry.
Customers that run applications in Kubernetes distributions should deploy the otel-cloud-stack Helm chart, which automatically enriches metrics, logs, and traces with the following resource attributes. A quick start for deploying the chart is available here.
|Resource Type||Resource Attributes||Recommended Enrichment|
||Resource Detection Processor|
||OpenTelemetry SDKs and/or Resource Detection Processor|
|Kubernetes Cluster and Namespace||
Updated Jan 6, 2023