ServiceNow Cloud Observability Reviews

ServiceNow Cloud Observability's main use case is end-to-end automation starting from the trigger in the cloud. Currently, it focuses more on self-healing and understanding the complete uptime of end-to-end services, particularly services and application availability rather than just servers. My focus is on enabling this by integrating it with any monitoring tools, understanding how events trigger, and handling the whole lifecycle with recent AI initiatives. ServiceNow itself has AI agents that I use as an orchestrated layer to define workflows for evaluating and taking appropriate actions, which helps reduce overall manpower and human errors.

When discussing ServiceNow Cloud Observability, the major aspect is seamless integration with all enabled services and monitoring services. It allows me to look at the overall picture, capturing and integrating it with platform analytics and the numbers. It provides a real-time view of metrics and traces, enabling more real-time visibility. Looking at MTTR, earlier we were getting MTTR, but this gives us faster visibility into where we are, where the issue would be, and how we can quickly reduce the overall impact.

One use case I had done recently with cloud and hybrid environments as part of transformation includes workloads still on-premises and others transitioning in three-tier architecture. When the backend remains on-premises or is hosted elsewhere and the applications or front end are on the cloud, it allows for a single-pane view to see end-to-end and correlate. Monitoring tools do help, but this gives us a placeholder to view an end-to-end application stack or workflow in a single pane of view. With a few customizations, such as integrating multiple monitoring tools for the cloud, we can either use cloud-native tools to capture and understand, notify where we see latencies, and then it also integrates with on-premises, which is more aligned with the hybrid cloud model. One of the recent features I found valuable is the plugins that ServiceNow provides, integrating it with Grafana dashboards or other open-source dashboards.

ServiceNow Cloud Observability's valuable features include AI agents that can be integrated and triggered with workflows for evaluating and taking the right action in both process and technical aspects. On the process side, it ensures the right approvals are triggered. From the technical aspect, it allows integration for taking relevant action without human intervention, moving towards self-healing.

The main benefit of ServiceNow Cloud Observability is real-time data, which helps us move from being reactive to more proactive. By defining and fine-tuning workflows, we were able to implement timely notification and auto-action or auto-remediations. At the same time, if anything involves additional cost or requires intervention, it helps trigger approval notifications, and once approval is received, it timely takes the action. The AI agents help define and fine-tune those workflows further.

The cost could be reduced or lightweight agents and lightweight modules could be introduced, which would make it much easier to implement.

I have been working with ServiceNow Cloud Observability for close to three years.

I would rate the stability of the product at ten.

I would rate the scalability and ability to scale at nine.

The technical support for ServiceNow Cloud Observability is good.

I am managing ServiceNow solutions and am no longer doing vendor management. Currently, I focus more on ITOM solutions and integrations and transformations of services. I have changed my role and am more into transformations. I leverage ServiceNow in implementing it across clients and onboarding them onto it.

I am no longer working with Loom Systems or Cognizant. My focus is on ITOM solutions and Performance Analytics. I am aware of the Performance Analytics module, which is platform analytics.

I am no longer closely working with CMDB.

The initial setup is straightforward and not critical or confusing. It is pretty straightforward from what I found.

I manage the ServiceNow product, but I do not handle it on a day-to-day basis as it is handled by someone else. I work for a reseller, so we have our own different team that takes care of it, and I am not much involved in the day-to-day operations.

I would keep the price for ServiceNow Cloud Observability somewhere in the middle range, and as I mentioned, if lightweight modules could also be introduced, that would be helpful.

Regarding security, I unfortunately do not have much hands-on experience. My focus has been majorly on self-healing activities, but given what I have observed, it does provide a good opportunity in terms of proactively looking at it. I believe it could also allow us to ensure all relevant SOC compliances or GDPR compliances by monitoring in real-time where we can set rule sets, and if there is any deviation, it could automatically trigger the workflow and alarms saying that these are the baselines and there is a deviation here. In one of my engagements, I implemented that to a very basic level where I was inclined from the infrastructure side on both cloud and on-premises, implementing CIS benchmarks and integrating and highlighting any deviations.

Regarding ITSM, we are slowly moving towards ITOM. ServiceNow Cloud Observability provides good features on ITOM, and it has been easier on configurations. Earlier, we needed developers or someone with good knowledge of ServiceNow development, but now it is pretty straightforward for anyone with some knowledge of it. The user interface and usability make it much easier to configure. Unfortunately, I have not done much of a proof of concept, so I would only have theoretical knowledge on that aspect.

My overall review rating for ServiceNow Cloud Observability is nine.

I use the solution in my company since it has multiple tenants available. Basically, what happens in business is that you have a hybrid setup model, and for that, you extensively use a cloud platform, so for that purpose, AWS and Azure are used.

The feature of the tool that is more impactful for cloud performance stems from the area revolving around analytics and reporting. It is an easy-to-use tool. There is something known as performance analytics within ServiceNow that offers complete analytics, which offers end-to-end analytics along with the KPI metrics with what we have in place and so on. With the aforementioned aspects of the tool, I think we should be able to create a dashboard according to the operations view called the operation dashboard view, specifically for C-level executives.

There are a lot of workflows and connectors. In terms of licensing, users would want the product to offer them the ability to tailor the tasks offered in the solution to suit their needs.

I have been using ServiceNow Cloud Observability for five years.

Stability-wise, I rate the solution a six out of ten.

In terms of stability, it's good, but there are a lot of things as well, too. When the tool goes down, in terms of reliability, there are instances where we have to keep them going in parallel. If there is a lot of load on the server, there is a chance that users may face some performance issues.

Scalability-wise, I rate the solution a seven out of ten.

The product is suitable for enterprise-sized businesses.

I have had issues with the technical support of the product since I don't usually get to speak with them on the call whenever I need them. I rate the technical support a six out of ten.

Neutral

I have worked with Spectrum's cloud services and its integration features.

On a scale of one to ten, where one is difficult, and ten is easy to set up, I rate the product's initial setup phase a seven.

The solution is deployed on a hybrid cloud.

The deployment time of the solution depends on the environments of our clients.

To a certain extent, it is possible to save on the costs of the product.

I rate the tool's ROI a seven out of ten.

The product is expensive. I rate the tool's pricing model an eight out of ten.

I recommend the product to others.

I rate the tool an eight out of ten.

In use cases, we have tons of microservices. So, we need observability. We heavily rely on LightStep streams for monitoring as well as alerting purposes.

For example, suppose we don't expect traffic in a certain period. If we are getting more traffic, we get alerted. Basically, it is for monitoring our microservices and creating some alerts out of those so that if something goes wrong, we get alerted. We are also helpful in case of any errors because there is an option called streams, which can create it, and we can go through the streams to see what calls were made in that single request. Where was the error? What was the error? That's helpful.

For me, there are two most valuable features. The ability to create a stream based on different parameters, operation name, service name, URL, tags, and URI part, is one feature.

And another one is the notebooks. With the streams, I can simply integrate it with Grafana as well to create dashboards so that we don't have to see in a single place all the activities happening, the company requests we are getting, how many are errors, how many are successful, and how many failed. So integration with the dashboard is also easy with Lightstep because of streams.

We use some SDK to integrate like tips in our code, in our Java code or whatever code, rightly, Skylight or whatever. So, the SDK that we use is not very easy to get a hold of. So, a person who is more experienced is able to write proper code so that an operation can have an operation name to set. So, SDK would be improved for developers so that the integration and code will get easier.

The support team could be better. Because of the different versions of different tactics of integrating reactive code base, the documentation is not very clear if someone has to be onboard. I would rate the documentation of Lightstep a five out of ten. It could need improvement.

Currently, what happens is, suppose in a stream, we have lots of spans. So if there is something I can filter, for example, in a single trace, there are ten calls with it. And if I have to filter, I have to go inside the individual trace to get the call.

In future releases, I want to see if it is possible to filter them at a very high stream level. So, for example, I want to filter the calls only from service A, ten calls, and I want to filter only two calls out of ten. So, instead of doing that filter at the trace level, can I do it at a stream level.

I have been using LightStep for one year. I currently use the latest version. 

It's very stable. I didn't have any issues so far, anything that it's not working or it's not available. I would rate the stability a ten out of ten. My entire company uses this solution. 

It is a scalable solution. However, some rate-limiting exceptions happened in our company, and the system slowed down.

For me, it was difficult. The integration part was also a bit difficult. It took around 10 to 15 minutes to deploy a service. 

Overall, I would rate the solution an eight out of ten. I really rely on Lightstep to identify any issues.

When I was first introduced to LightStep, visualizing how it works was difficult. So, I would advise it's better to first understand how the flow works and then see LightStep so that you can understand what's happening. 

If you directly see LightStep traces, it has multiple calls, developers get confused. So if I have the understanding of how the particular request works, which all calls escalate, and then seeing LightStep makes life a bit easier.

We use Lightstep/ServiceNow to monitor the traces in our distributed applications and microservices. Our services were instrumented using open telemetry and then we sent the data to the configured microsatellites. We also use this tool to send alerts to our slack channels when something is not right according to our expected SLAs. This solution is used primarily for those who are working on call in our teams and need to investigate performance problems and deviations in our production environment.

The benefit of using this tool is to monitor latency and find out possible performance problems in our services. 

Some of our services are designed in an event-driven architecture model, and others are called directly by other services; as we deal with billions of data and calls every day, it is really important to have good tools to help us pinpoint problems faster when they happen. 

On the other side, it is hard to use different tools for each part of the observability (traces, logs, and metrics), and it would be even better if we could use only one tool for everything. 

The solution Lightstep/ServiceNow has a couple of pretty advanced functionalities to help us investigate a deviation and help the development teams have better observability in the environment using distributed and complex services. We can create, save, and share notebooks, and this helps us a lot when sharing issues with the team. When the application is well instrumented with the right attributes, the feature to view correlation and find data that correlates with unusual behavior is very useful.

The design of this solution is not very intuitive and probably could come with more friendly tips for beginners. For example, it is not clear how to list or edit alerts for a specific service. If you have several services for the same account, it is very hard to manage them. If you are not an experienced user, you probably will be a little lost and will not know what to do with all the data on the screen. Also, it would be very helpful to be able to see not only traces but metrics and logs in the same solution.

I have been using this solution for at least one year.

We've never had any problems related to stability when using Lightstep.

You have the flexibility to send the data to internal servers or directly to Lightstep, then the scalability depends on how you configured your structure.

This was the first time that I used a tool to monitor traces. We use a couple of other tools to monitor logs and metrics, though.

The company was already using this solution when I started to work there.

We use the product for traceability.

In terms of code, the tool is very easy to work with. It provides good libraries. The UI is very intuitive. It helps diagnose the traces and map information. It is easy to create new streams and patterns. It is quite easy and nice to use. We use the tool to find the latency and error rate in our services.

The dashboard and graphics must be improved. We export the information to Grafana because it provides better visualization. The performance is a bit slow when we deal with the traces and spams to load the graph. When we start a service, create some spam, and start to put some traffic, it takes 15 to 20 minutes for it to be reflected in LightStep.

I have been using the solution for the last two years.

I rate the tool’s stability a ten out of ten. We never had any issues.

I rate the scalability a six or seven out of ten. Sometimes, the tool gets a bit slower for certain things. We have a very high traffic and a large amount of data. It might be because we have a lot of services. We get more than 100 or 1000 requests per second. There’s a lot of spam. We have more than 2000 engineers using the tool in our organization.

The solution is deployed on the cloud.

I had used Elastic APM in a different company but had very little experience with it. I don't have much to compare with. People who want to use the product must read the documentation and understand what they can do. The solution has a lot of features. Overall, I rate the tool a seven or eight out of ten.