Cisco ThousandEyes

My main use case for ThousandEyes is that it checks our product website, and if it flags that it is unable to log in, it checks for all the components from all the agents, which are from different locations. It keeps on scanning every five minutes or every minute, and it flags issues immediately through email alerts.

When we receive email alerts, we thoroughly troubleshoot what is causing the issue, whether it's a false alert or a true alert. If it's a false alert, we receive a recovery email, and if it's a true alert, we don't get recovery alerts. Then we engage the next level of support and keep checking the troubleshooting issue.

There are many situations where ThousandEyes has helped us catch an issue, such as a product login where there was a certification issue. In one of my use cases, the certificates were updated as part of one of the recent changes.

With the help of our monitoring team, we have defined a lot of use cases in ThousandEyes, and we have predefined sets that are very useful for us. That acts as a radar for us.

ThousandEyes positively impacts our organization by flagging issues immediately, which helps us reduce downtime whenever we seize or acknowledge the alerts. That is the benefit of ThousandEyes.

ThousandEyes has helped in a lot of situations, especially before the start of client login hours, by flagging issues immediately so we can resolve them and ensure the product is available all the time.

In my opinion, the best features ThousandEyes offers include its ability to act as a radar, logging in from different regions across the globe and confirming whether our product is working as expected. This is very useful for us.

The global monitoring from ThousandEyes alerts us immediately about issues, and troubleshooting is handled by us, allowing us to resolve the issue before the client reports it.

The alerting and reporting features are all done at the real-time level.

I believe ThousandEyes is working perfectly, but I feel that with more AI integration, it could flag issues with more detailed error information, which would help support engineers immediately pinpoint what exactly is causing the issue.

Regarding needed improvements, I think the user interface could be better. It is sometimes a little confusing and should be very user-friendly, including a guide for how alerts are configured to assist first-time users.

I have been using ThousandEyes for more than five years.

ThousandEyes is stable.

I believe it is scalable.

I deal with customer support through our dedicated team working with ThousandEyes team, and I believe they are doing great.

Regarding ThousandEyes's AI capabilities, I believe they are very capable, and from a security perspective, we haven't found any issues.

I haven't explored ThousandEyes's accuracy and reliability feature much, so if there is a feature that has not yet been introduced to us, I need to explore more on that.

My advice to others looking into using ThousandEyes is to go for it, as they are the best in the market.

I would rate ThousandEyes a nine because there are features I would like to see improved. Not every product can be perfect, and I believe it should evolve to have a more user-friendly UI.

ThousandEyes is utilized primarily for WAN observability, where we monitor the WAN circuit hop-by-hop from end-to-end to gain end-to-end visibility for application monitoring of Microsoft Teams, voice, and other critical applications in our organization. Whenever we experience any kind of alerts for these applications, we immediately investigate through ThousandEyes. ThousandEyes has a capability to integrate with the ServiceNow tool, where we receive notifications and alert integration, which provides us advanced notification and helps our engineers navigate the problem and identify exactly where it is occurring in the routing path.

Recently, we experienced one of our users having slowness while accessing their Teams calls. When we took the individual user's account details and diagnosed those reports in ThousandEyes with the username and the location, within a second, we were able to see exactly where the high latency and packet loss was happening. Due to this, the user was experiencing slowness while accessing their application. This helped us to immediately switch the route path from the primary to the redundant secondary link, which reduced the high latency and packet loss and also mitigated the problem.

Since we are using ThousandEyes at an enterprise level, this agent helps us to understand the latency, jitter, and intermittent performance of the applications and compare between the hops how exactly this latency, packet loss, or jitter is occurring. It helps us to rectify instantly where the abnormal path is and which path has no issues. If you have redundancy in place, that will work.

ThousandEyes is utilized as a monitoring tool and integrated with application monitoring to provide network-level visibility, which alerts us before an outage happens so we can investigate and fix the problem before it becomes a big outage.

Earlier, we were blindfolded to all of these application issues at the network level and used to have numerous incidents. For example, in the two years before we onboarded ThousandEyes four years ago, all the issues were being blindfolded, and our engineers used to end up troubleshooting for long hours. With ThousandEyes, we have reduced the time of investigation for any application issue at the network level, which helps us to focus on the genuine issues rather than simply sitting and troubleshooting network issues that are not actually network issues. We have reduced almost 76% of the incident count for issues that are not network issues but were application-based issues.

The best features offered by ThousandEyes that we are using in our GSK platform are Path Visualization, Network Performance Monitoring, and Internet Insights. No other platform provides Internet Insights. This is where we always lag with other monitoring platforms, but ThousandEyes provides Internet Insights, Enterprise Agents, and BGP visibility. These are the areas where we are majorly focusing and using ThousandEyes. There is also SaaS application monitoring so that we can correlate the application experience with the network behavior. Most of the time, we don't know whether the issue is happening at the application end or at the network level. ThousandEyes helps us to provide the correlation. When we have the correlation between the application and the WAN part through the SaaS platform, this helps us to understand exactly where the problem is occurring, whether at the network level or at the application level. ThousandEyes analyzes Cisco SD-WAN telemetry and provides path recommendations. As mentioned previously with the use case, ThousandEyes helps us by recommending the path and which path is clear without any issues and which path can be used when we encounter any issue in the routing path or the current path.

Internet Insights uses collective intelligence to identify internet, network, and application outages and provides visibility into the impact involving providers and SaaS applications. When I say Internet Insights, today, once we exit the egress path, we will not have visibility. Outside our network, we will not have any visibility to troubleshoot. Internet Insights through ThousandEyes gives us, with the border patterns, geographical providers, domain servers, and network interfaces, a way to understand exactly what is happening on the internet. Today, we don't have visibility at the internet level, so that is where ThousandEyes helps us to track that as well.

ThousandEyes detects the degradation, identifies the affected path, SREs localize the domains, and correct the path. The team provides the engagement. These are some of the things we are utilizing ThousandEyes for.

For ThousandEyes, I am looking for AI integration, which would help us to auto-correct the problem and fix it before it creates any issues. Currently, whenever there is an issue, based on the threshold configuration, we receive an alert and then we utilize the platform for investigation purposes. Instead of that, if the platform itself is able to identify the problem and give a suggestion instantly for rectification or correction of the problem, through the necessary approval of the platform owner or the SMEs, with their approval, it could correct the problem by itself. This is the expectation from AI in ThousandEyes.

It has been four years since we started using ThousandEyes, which is one of the excellent platforms for monitoring, where we can monitor complete hop-by-hop and improved Microsoft Teams health and network metrics, enhanced end-to-end troubleshooting, and stronger WAN observability and visibility.

I have not experienced any issues with the hybrid cloud deployment. It was a very flawless deployment we experienced because Cisco expertise came and helped us complete the deployment.

ThousandEyes has reduced our troubleshooting time for our organization. This platform is very useful from the telemetric information for the WAN perspective and observability information. The primary opportunities for improvement are AI integration, as governance and security should be the primary focus when integrating AI capabilities, which we are missing today in the AI world. Everybody is talking about the data, but nobody is worried about data security.

Through SLA and SLO metrics, I assess the operational efficiency of Cisco in my IT environment.

This is a very good platform for monitoring purposes. If you are looking for a platform to have more telemetric information from the WAN perspective and from the application level, I always recommend ThousandEyes. I would rate this product an 8 out of 10.

We started using ThousandEyes after we moved to SD-WAN. Because we started using DIA circuits, which are not like MPLS ones, the DIA circuit was having so many issues, so we obtained this tool. We started monitoring the underlays first, from our site to our data center, from our sites to any destination. If any client or user is having an issue with some specific destinations, we monitor that. We use the Endpoint Agents for troubleshooting purposes.

We are using two different use cases. One is a standard test that we are running from all our sites as part of our standard protocol. Every site has those tests. The other part is on demand. Whenever we feel that something needs some more deep troubleshooting, we bring up that test for that troubleshooting purpose only. Apart from this, we are using the underlay for SaaS applications, DNS services, and DNS tests. We are using all parts of the Enterprise Agent and Endpoint Agents.

The best thing that I feel is that it holds the data. The purpose that we are using includes monitoring the underlay and monitoring the internet path. When we have an issue, by the time we get the notification and join the audio call, we realize that the issue is gone and we are clueless about what exactly happened. With ThousandEyes, we can go back in the history and see what exactly happened during that time. We can see the data for up to 90 days. In the normal dashboard, we can see data for 14 to 30 days, but if we do some additional things, we can see the data for 90 days.

Another best part is that it gives us where the loss is coming from. If we do a normal ICMP test, we can see from which node the drop is coming from or which node is spiking the latencies. If we do an HTTP server test, we can see the entire waterfall flow. We can see which object is taking how much time, which object is taking how long to load, and all those DOM and content delivery things. Everything we can see. It's actually amazing.

The first thing is that we don't have any option to export the reports. If we want to export any reports, we don't have any such options. Sometimes when we deal with leadership, they don't want to see the screen. They want to see the data on an Excel file or maybe in a graph. Even if we want the raw data, we need to do some API things or play with other workarounds, and then only we can get the raw data. We don't have the export options.

The other thing with the Endpoint Agent is a limitation. In our current scenario, we are not using Endpoint highly. We have a few licenses that we are still checking whether we need. If we have an available license for an Endpoint Agent and we ask our site IT team to install the agent on the machine, as soon as the agent is installed, it will show up on my ThousandEyes dashboard and it will consume the units. What I want is for it to be in a disabled mode, not an enabled mode, and not consume the units or the license until I assign it manually. This will help us a lot with license management.

The dashboard can be more flexible. The way we are monitoring, the dashboard length is getting very long. We need more options to bring all those things into one single dashboard on one single page. We don't need to scroll down and see what is going on.

There are a few more things concerning filters on the Endpoint Agent. When we see the results, the bare minimum option is 5%. If we are talking about packet loss, we can see only if there is a packet loss of either 5% or above 5%. There is no option for less than 5%. In my current organization, we are very strict with packet loss. Even if there is a 1% or 2% packet loss, we want to see from which node it is coming from. However, in ThousandEyes, we don't have any option to go below the 5%.

When we create tests to monitor applications on the Endpoint Agent part, we have very limited options with the protocols. Only the ICMP and the TCP packets can be monitored. If we want to do some other kind of port, it's not there. It's not flexible.

Regarding stability, I feel there is none. I have never experienced any kind of downtime with this tool.

On the scale of how scalable ThousandEyes is, I find scalability easy. It's stable, and we can install it wherever we want. We have many options regarding exactly where we need to install. In our current scenario, we are using it on four different platforms. Two are on the Cisco SD-WAN on different router models that we are using. We are using it on our servers at our sites. And we are using it on Linux, which is on the GCP. It's very scalable, and we can install it wherever we want.

If I have to contact technical support, I think the speed and the quality of the support is very good. A while ago, I raised a concern with the TAC team, and I see there is a response from them within 15 minutes. I didn't see the response immediately, but I did receive an email that the case has been updated and is ready for my view. It's fast and on point. If I were to put the support on a scale from 1 to 10, with 10 being the highest, I would give a nine.

I haven't used any alternatives to ThousandEyes, so this is something different. This is not a traditional monitoring tool. In traditional monitoring tools, we work with SNMP and just do the ping-pong and nothing else. This one is different. It's not traditional. I haven't come across any other similar tools that have this number of flexibility and this number of options.

The initial deployment of ThousandEyes is very easy for me. There is no rocket science that we need to understand. The GUI of this tool is very friendly. The installation and implementation processes are very friendly as well.

ThousandEyes does require maintenance on my end, such as upgrading. Currently, the version that is being used is going to be EOL by November. We need to upgrade and do some manual work on any agents that we have on SD-WAN and on our Catalyst switches because it is EOL. Otherwise, it upgrades itself without any intervention. Pricing is not in my view because it is being managed by the leadership team, so I am not sure what exactly and how exactly they are purchasing from Cisco. All I am doing is handling the tool. My overall review rating for ThousandEyes is 10 out of 10.

We were using ThousandEyes to monitor our Cisco SD-WAN and some Juniper switches and SBCs and our whole network infrastructure. We installed ThousandEyes agents on our multiple devices to monitor their activities. We were also using it for DNS servers.

My favorite feature is that we were able to see everything on a map. It shows how the connection is going from one device to another device and we can see where the issue is happening. It is easy to find the point where an error is occurring or something is down. We can easily map it out, which is why we were using it.

There were many compatibility issues and integration issues which we were facing. We could not easily connect it with different types of devices and we were facing the integration aspect. There is very limited API support. When we were integrating with Splunk, we could only pull a little data, not all of the data.

I would like to see better support from ThousandEyes, along with improved documentation. They can provide FAQs and troubleshooting guides so we can resolve issues before reaching out to them. There should be a list of things we can do independently. Documentation should be provided for all supported products, including how we can integrate Splunk, Cisco, and other portals. API documentation can be increased. From the time I used it, it was not updated. It was kind of a beta experience, I would say. It was not fully developed at that time. It looked like an unfinished project with many gaps.

I did not use it this year. Last year, I used it for almost eight to nine months in my previous organization.

I did not see any downtime. However, it used to be a little laggy, but I do not know if that was from their end or our end. I think it was good. I would rate it an eight.

I think it is good. I would rate it an eight to nine. It was scalable. We could easily add hundreds of devices with no issue.

ThousandEyes technical support is slow until you mark the issue as a P1 or P2. They have categories for issues, and if you don't mark it as higher priority, they will not reply as soon as possible. They will take two or three days to respond.

We need to clarify the severity of the ticket. If it is a P1, then they will respond faster. Otherwise, they will send us the documentation link and tell us to review the documentation. After four or five days of continued messaging, they will set up a call and send an analyst or support engineer, but they will also not be able to help us the first time. Then they will call our senior in another call and maybe then the issue will be resolved. It is slow. I would rate their support a six out of ten.

The initial deployment was not that hard. It was a cloud-based solution, so only the agent installation was required. It was easy. However, if some product is not supported or if there is no documentation, we need to find a lot of workarounds. When we were trying to integrate some Cisco switches with SNMP, there were a lot of problems and we were not able to figure it out. We reached out to Cisco technical support and they helped us, but it took a lot of time, like two weeks to integrate one switch for our testing. I would say it was not a good experience for our whole team.

I have not used alternatives, but I have used Splunk to monitor our devices via SNMP and Syslog. I have also used one more product, an open-source tool called Zabbix.

Zabbix has more templates and better documentation. They keep updating it, and I see a lot of updates coming for Zabbix on a daily basis. It is open-source, not a Cisco product or some big company product. I would say it provides a lot of features. Zabbix does have some issues, but I don't think we can compare them directly. It is also a good tool.

I don't think there was scheduled maintenance. However, sometimes the connection used to go out, but that was kind of an internal network issue, not a ThousandEyes-related issue.

Regarding ThousandEyes pricing, I don't know about the specific costs because my management was dealing with that. They did not tell me the pricing details. However, I think they did not buy the license later. They used it for one year and then canceled it.

My overall rating for this product is seven out of ten.