ServiceNow treads everywhere with Lightstep UQL

code | ServiceNow and Lightstep

ServiceNow has unveiled the general availability of Lightstep UQL (Unified Query Language) which will help companies extend visibility across Kubernetes applications.

Businesses will be able to use observability-as-code to manage Kubernetes applications at scale, allowing for greater consistency, maintainability, and reproducibility across cloud-native architectures.

After acquiring Lightstep in 2021 to extend the benefits of observability across the enterprise through digital workflows and also announcing an agreement to acquire Era Software this month, ServiceNow is accelerating a path towards unified telemetry.

With Lightstep UQL, teams can have an easier time migrating their observability from other scattered tools onto a unified Lightstep platform through a single query language, making it possible to query and correlate metrics, logs, and traces on demand across thousands of Kubernetes nodes, servers, or serverless functions.

Ben Sigelman, general manager and co-founder of Lightstep from ServiceNow, said: “Engineers today can leverage observability-as-code for more powerful and flexible insights into the health and performance of their cloud-native applications. This is especially important when thinking about modern architectures like Kubernetes, which are highly complex and dynamic. Lightstep UQL works to ensure that every Kubernetes application deployed is fully instrumented and observable by default.”

Andy Thurai, vice president and principal analyst at Constellation Research, said: “Because of current limitations within observability tools, many enterprises still observe applications at the application level instead of the infrastructure/microservice level. By instrumenting Kubernetes clusters, distributed applications can have observability baked in from inception instead of being an afterthought. Offering observability-as-code can help developers adhere to fully observable standards from the design level, which reduces friction between DevOps and SRE/Ops teams.”