We are using a custom in-house-built solution. I just moved companies.

I would rate the solution a seven out of ten.

If all of your services are in GCP, I would recommend this solution. If you have some services on-premise and some services in AWS Cloud, then I suggest using something else.

I would rate this solution an eight out of ten. 

You just have to know how to use it. I would rate the product eight or nine out of ten.

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.

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.

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. 

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. 

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.

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.