What advice do you have for others considering Google Stackdriver?

The Ops Agent and logging transport feature of the solution have had a major impact on improving application performance. The solution also allows the transport of logs into log buckets, which is highly useful for future purposes. Google Cloud's operations suite also caters to log analytics and helps in log export from an organization, folder, or project label. Another vital feature of the solution is the query drag-and-drop feature on the interface. The error reporting and diagnostics tools have helped address application issues through JSON. The solution allows drag-and-drop between different layers to identify the exact error. The solution already provides error color coding. The solution can be easily integrated with third-party tools. For instance, if I have a log that I exported in BigQuery, I can obtain meaningful insights effortlessly from there. As part of our company, we have witnessed the proper functioning of error logging and caching in the solution. I would definitely recommend Google Cloud's operations suite to others, similar to how, as part of our company, we suggest it to clients or customers. Some other on-premise version competitor products provide their own cloud, but there is an additional log exporting cost. This is why our company always suggests customers to use a cloud operations suite. I would rate the solution as eight out of ten.

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.