Senior Specialist at LTI - Larsen & Toubro Infotech
Real User
Top 5
2022-06-06T09:41:38Z
Jun 6, 2022
I would tell potential users that the current version is much nicer than the previous one. On a scale from one to ten, I would give Google Stackdriver an eight.
Infrastructure/Cloud Architect at a comms service provider with 1,001-5,000 employees
Real User
2021-07-13T11:21:00Z
Jul 13, 2021
Google Stackdriver is all about activity. If one switches from, say, Grafana or another performance and monitoring application, it takes time to adjust one's expectations. All the items desired are present, but these must first be configured. I rate Google Stackdriver as an eight-and-a-half out of ten.
Director, Function Head, RISK Technology and Change at a financial services firm with 5,001-10,000 employees
Real User
2020-10-06T06:57:45Z
Oct 6, 2020
If you're moving to GCP, then Stackdriver is the right way to go. However, if you're moving to a different platform that's not GCP, Stackdriver may not integrate with it well. I would rate the solution higher but because we had some initial hiccups I would rate it an eight out of 10.
Infrastructure/Cloud Architect at a comms service provider with 1,001-5,000 employees
Real User
2020-04-30T10:58:57Z
Apr 30, 2020
My advice to anybody who is implementing Google Stackdriver is to explore what metrics they want to use. I would rate this solution an eight out of ten.
Find out what your peers are saying about Google, Datadog, Amazon Web Services (AWS) and others in Application Performance Monitoring (APM) and Observability. Updated: March 2024.
Program Manager at a tech services company with 201-500 employees
MSP
Top 5
2020-03-05T08:39:00Z
Mar 5, 2020
Google Stackdriver is good because when you are using the GCP, there is no need to rely on any other monitoring tools, it gives the majority of the reports. But when you're stuck with any issue, and the team needs to do fine-tuning, it is a little difficult to analyze, especially while performing the load or stress tests. If everything is good, then you can get the reports. However, when something happens, they have to improve reporting. On a scale of one to ten, I can give Google Stackdriver an eight. As I said in our previous discussion, we are finding it difficult to develop the breakdown of the round-trip at a request level, especially pertaining to the response time. That's why if any drops happen in the network layer, it would be good if it could find out and then come up with some reasons, various reasons, potential reasons, why that drop happened and where the drop happened. Also, at the VPN level, there is a replay issue happening. Suppose the request is coming multiple times, we'll call it a replay issue. So to monitor the replay issue, if they would provide any specific functionality it would be good.
You just have to know how to use it. I would rate the product eight or nine out of ten.
The python SDK for cloud logging might require additional tweaks to ensure more readable logs are sent by your apps to the cloud logging service.
I would tell potential users that the current version is much nicer than the previous one. On a scale from one to ten, I would give Google Stackdriver an eight.
Google Stackdriver is all about activity. If one switches from, say, Grafana or another performance and monitoring application, it takes time to adjust one's expectations. All the items desired are present, but these must first be configured. I rate Google Stackdriver as an eight-and-a-half out of ten.
If you're moving to GCP, then Stackdriver is the right way to go. However, if you're moving to a different platform that's not GCP, Stackdriver may not integrate with it well. I would rate the solution higher but because we had some initial hiccups I would rate it an eight out of 10.
My advice to anybody who is implementing Google Stackdriver is to explore what metrics they want to use. I would rate this solution an eight out of ten.
Google Stackdriver is good because when you are using the GCP, there is no need to rely on any other monitoring tools, it gives the majority of the reports. But when you're stuck with any issue, and the team needs to do fine-tuning, it is a little difficult to analyze, especially while performing the load or stress tests. If everything is good, then you can get the reports. However, when something happens, they have to improve reporting. On a scale of one to ten, I can give Google Stackdriver an eight. As I said in our previous discussion, we are finding it difficult to develop the breakdown of the round-trip at a request level, especially pertaining to the response time. That's why if any drops happen in the network layer, it would be good if it could find out and then come up with some reasons, various reasons, potential reasons, why that drop happened and where the drop happened. Also, at the VPN level, there is a replay issue happening. Suppose the request is coming multiple times, we'll call it a replay issue. So to monitor the replay issue, if they would provide any specific functionality it would be good.