Google Cloud's operations suite (formerly Stackdriver) Reviews

I use the solution for logging, defining alerts, and monitoring. Our company's Java and Python logging teams mainly use it. We also used for database request processing SLA Monitoring. for our Dev env, we are using google provided dashboards for Monitoring service performance.

As part of our company, we implemented several changes in our log analytics pattern, including the storage and procurement process. Earlier, before implementing the solution, our company was able to procure only one year of data, but later, we came to the three-year mark. Around 15-20% reduction has been witnessed in the total analytic consumption of our company.

The aforementioned result was possible because the solution allowed the creation of a dashboard where factors like storage costs, proportion of logs, and logs presence in a storage bucket or Big Query can all be checked. Earlier all logs were stored in a raw storage, but currently our company is able to move logs in table bucket that contributes towards cost savings. 

It has default integration for all gcp services. recently managed Prometheus support gives more flexibility to organizations to remain connected with their current Prometheus setup. We leveraged integrated FinOps Hub for recommendations for our workloads and server configurations, helpd us lot in order to get maximum TCO.

Logging is the most valuable feature of the solution for our company. 

Monitoring with default metrices also a good part of it's as a predefined monitoring dashboard. 

Trace, Debugger and Profiler services are good services for troubleshooting code, finding out latencies and to identify problematic code in cloud, however no such any incidents, to utilize its capabilities.

If the errors are caught early in the interface, it would be easier for users to manage. The process of logging analytics can be improved. Its integrations with cloud storage, Pub/Sub and other webhooks gives more integration options while using it.

I have been using the solution for 6+ years. 

The resources of our company remain distributed across multiple regions, and sometimes, when we as part of the company need to find logging data from the US region, it's very time-consuming on a few occasions. 

The solution is scalable. At our company, 150+ servers are used in the environment provided by Google Cloud's operations suite. Four people from the operations team and four from the development team are using the solution in our organization. 

No such incident to interact with Google Customer support team

Positive

Our company is using a different tool for monitoring purposes, we transformed to Google Cloud's operations suite, and we are preparing the monitoring dashboards as part of our company. 

The initial setup of the product is very simple. At our company, we selected a project and started working on it using Google Cloud's operations suite. The solution allowed easy logging and monitoring data, but for creating the log router at our company, we had used Terraform script. In our organization, we created a bucket to route the major logs and we specifically used BigQuery for the billing logs. 

The entire deployment process of the solution took just half an hour and the solution has been very easy to maintain from that time. 

we implemented through in-house talent team, having basic experience on integration.

Overall, ROI with Google Ops Suite is lesser compared to other Monitoring suites in Google.

As Ops Suite, is a google product which effectively comes at zero setup cost, in order to manage your on-premises logs on onsite, it involves negligible cost for using ops agent and it also includes network cost during transfer of data. data storage cost compared to cloud storage bucket pricing is very lesser for some free quota. for usage of managed Prometheus, enterprise license cost involved in it.

Before choosing the solution, we evaluated the merits and demerits of competitor products as well like Datadog, Dynatrace, splunk, new relic and many more. We explored six tools in terms of integration availability, reliability and downtime because at our company, we use multiple NoSQL databases like MongoDB, Bigtable, Firestore, etc. 

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 9 out of 10. 

It's basically for troubleshooting when you are in performance engineering load tests. Then all the logs are monitored from stack home, and each and every component that's involved is on there.

It has reduced the amount of time that we would take for troubleshooting.

The logging and tracing aspects are great.

It's scalable.

We find the solution to be stable. 

The logging functionality could be better.

We'd like to see more profiling capabilities. 

I've been using the solution for about two years. 

The solution is stable and reliable. There are no bugs or glitches, and it doesn't crash or freeze. 

We can scale the product.

At this point, we have 50 to 75 users on the solution. 

We don't have any plans to increase usage right now. 

The DevOps team handles any technical support issues. I don't have any visibility into that.

We have used Dynatrace and Splunk in the past.

I did not handle the initial setup. It was usually the DevOps team who sets it up. I have no idea about the process.

The DevOps team also manages any maintenance that may be required. 

Our DevOps team handles the setup process. 

We've seen an ROI. 

I'm not sure what the licensing costs are. 

We did not evaluate any specific solutions before choosing this product.

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

I would rate the solution a seven out of ten.

We use the latest version of this solution for the storage of our logs. For example, we use Stackdriver to send our logs directly to GCP. We are able to pull metrics such as how many errors occurred, which service is giving the most amount of errors and which service is giving the least amount of errors. This solution is used by 50 people in our organisation. 

This solution could be improved if it offered the ability to analyze charts, such as a solution like Kibana.

I have been using this solution for four years. 

This is a stable solution. 

This is a scalable solution. 

We have not needed to get in touch with the customer service team for this solution. 

Our company has a corporate account for Google Cloud and so our systems and clusters integrate really well. This is why we decided to use this solution. If we had gone for Datadog, we would've been required to set up the service in every machine. This is the main reason we opted for Stackdriver.

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. 

We use it for a very basic purpose. Whenever we have some workload that is running, we turn on the hook to configure the monitoring.

It's easy to use. You don't have to do anything with it, just use it. Google provides an interface to get all the components monitored as long as you are plugged in. This is sometimes automatic.

It could be even more automated. For instance, the moment you deploy something, the monitoring can be there for everything. You will just have to launch or click the console in the morning, and then you won’t even have to think about it.

I heard the solution has good stability but I don’t know. I don’t use it that much.

You just have to enable the API features, like every other Google product.

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

Our use cases of Stackdriver are for cloud monitoring, cloud logging, and APM.

It has really been helpful in detecting, identifying, and troubleshooting issues with cloud services used in the organization.

The cloud logging is really awesome. It enables us to get our logs from the different platforms that we currently use. The ability to iterate entire logs is great and you can export logs for better management. They can be exported to a third party and be broken down more easily. The documentation is great and in general, this is a user-friendly solution.

The cloud monitoring metrics collection and instrumentation could be extended to client-side, instead of just cloud services.

I've been using this solution for three years. 

The solution is stable. 

It's very scalable. We haven't had any issues. There is a minimal additional cost for this.

We haven't had any interaction with customer support. 

The initial app engine came out of the box and the setup was so easy. The documentation for setting up is also great. We deployed in-house.  

This is a very cheap product.

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 use Google Stackdriver for support monitoring.

I like the monitoring feature.

It could be more stable.

I have been working with Google Stackdriver for about two and a half years. 

Google Stackdriver is a stable product, but there is some lagging we cannot stop.

Scalability is very straightforward. We had five or six users using this solution at that time.

The initial setup was straightforward. It's not a complex one.

We implemented this solution ourselves.

We have a basic standard license without any additional costs. 

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.

While we are satisfied with the overall performance, in certain cases we must add additional metrics and additional tools like Grafana and Dynatrace. 

We would like to improve the application log. Most of these logs are derived from Grafana and not from Google Stackdriver. 

The application locker should be addressed. 

We have been using Google Stackdriver from the beginning, since 2019. 

Google's technical support is very good.

In addition to Google Stackdriver, we use Dynatrace, Grafana and Kibana.

We use all of these solutions in a complementary manner, for different purposes. 

The cost could be lower. When it comes to the cost component in cloud, it is problematic that we are only in a position to know how much we must pay upon arrival of the invoice after 15 days. 

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. 

We use Stackdriver for real-time log management analysis, it provides cloud log in a fully managed service for the GKE requirements. We also use it to collect messages, some events,  metadata and the like from cloud. I'm the director and function head of risk and technology change, and we are customers of Google. 

The solution has improved our organization by reducing latency and also monitoring the costs of GCP usage by using the logging and monitoring features. We've been able to look at it and see the optimal size of infrastructure and figure out costing. That's a good site outcome, other than the regular application monitoring that we get.

Stackdriver provides visibility into the performance uptime and the overall health of the cloud applications that we have.

I think given it's a new application, a new solution on the block, operations documentation could be a bit better. It took us some time to get up and running with it. It would have been helpful if they had provided some migration tools. For example, you're never going to get away from Genius. We have to do most of the work manually. The tools would have helped us to migrate scripts from other well-known software products and other management tools for Stackdriver. A helpful feature would be for them to improve cost transparency. 

We've been using this solution for the past six months. 

I believe the solution is stable, we haven't had any problems. 

The solution provides observability at scale which is good. For now, we're still in pilot mode but plan to increase usage in the next phase. 

We switched from Genius to Stackdriver because we went from an in-house platform to Google Cloud providers. We needed a performance solution that was on cloud. 

The initial setup is not complex but it would have been better if they had a few tools to help migrate off the Legacy platforms that we use. Deployment took a few weeks and we did it ourselves. 

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. 

We have some projects on the Google Cloud Platform and we are looking into how we can use Stackdriver to monitor our workloads.

The most valuable feature is the multi-cloud integration, where there is support for both GCP and AWS. 

The APM functionality needs to be improved.

It is difficult to estimate in advance how much something is going to cost. Often, you don't know how much it costs until you are finished.

We have been working with Stackdriver for less than one year.

My impression is that this is a stable solution because we have only had a few minor problems.

Stackdriver is very scalable.

The technical support is good and I found them to be very helpful.

The implementation involves setting up the correct metrics, which is something that needs to be properly researched and tested.

The cost of using Stackdriver depends on usage.

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.

The features that I have found most valuable are its graphs - if I need any statistics, in Kubernetes or at a VPN level, I can quickly get the reports.

As far as what can be improved in Stackdriver, on the application side, if I want to track any round-trip or breakdowns of my response times, I'm not able to get it. My request goes through various levels of the Google Cloud Platform (GCP) and comes back to my client machine. Suppose that my request has taken 10 seconds overall, so if I want to break it down, to see where the delay is happening within my architecture, I am not able to find that out using Stackdriver. It can give me the utilization reports, and other network traffic information, but it is not able to provide me answers in detail at a request level. That is why I have to rely on some other APM tools.

It would be better if they could provide the round-trip of the response time at a request level because on an overall basis it gives the traffic, transactions per second, etc. if any drops happen, what could be the reason for the drops? Suppose I have a Kong, Kubes,NAT and VPN. With these kinds of things, If any drop happened, it will show me that the drop happened, but it will not give me the reason why it got dropped.

I have been using Google Stackdriver for around six months.

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.