I received information from your team regarding a peer review of Honeycomb Enterprise. As an observability engineer using Honeycomb Enterprise extensively, I can provide substantial input. My primary tasks involve OpenTelemetry, where I send numerous traces and metrics to Honeycomb Enterprise and use it for visualizations of how our code is functioning and how data moves through our systems.

We have identified many problems using Honeycomb Enterprise, such as delays in the system where latency is observed by Honeycomb Enterprise traces, which we then investigate further and resolve. We have our SLA and SLOs configured on Honeycomb Enterprise, allowing us to monitor our reliability score. Additionally, we send many metrics to the platform. In my previous organization, we used it only for traces, but in my current organization, I use it extensively for traces, metrics, SLA, and SLO work. We also use Signoz for infrastructure-related APM metrics and other things, but we cannot use it for Honeycomb Enterprise capabilities.

Honeycomb Enterprise has genuinely helped us. We are not using Honeybee command line, which is a native solution by Honeycomb Enterprise. Instead, we use OpenTelemetry so that we can switch vendors easily. Our complete codebase now has proper telemetry data sending into Honeycomb Enterprise.

We have provided traces for each of the functions we are using. If we need more in-depth insights into what happens inside the code, we set up additional telemetry data points in the code. When you set those telemetry data points there in the code, you send those traces to Honeycomb Enterprise and then we can examine them.

In terms of customer usage, observing how customers are using our solution is very helpful in debugging aspects and also helpful in cost prioritization aspects. If a customer is not using our solution extensively, we can scale it down a bit in terms of servers where our solution is running. This has given us a better approach, particularly for Lambdas where Lambdas are deployed, and we can save considerable costs.

If traffic is not very high and we are able to see metrics where traces are not falling a lot, we can scale down our instances and save our AWS billing. If there is a sudden spike, we can get that monitored via the SLI and SLOs that I have configured. If there are sudden errors, I can scale the instance up.

If there is a genuine bug in the code, Honeycomb Enterprise is very useful for debugging the issues. Even a data-driven issue can be fixed using it because we get all the data when a user is providing any request. We actually get the input data in Honeycomb Enterprise and that way we can solve it very fast by seeing what query they hit or what workflow they have done.

I have been using this for almost three and a half years now.

Tracing is undoubtedly one of the best features they have developed. Tracing is basically the story in the code showing how the data is moving through. That is something which is extremely good. I can vouch for Honeycomb Enterprise, and that is the reason I brought Honeycomb Enterprise as our solution in my current organization.

That is the best thing Honeycomb Enterprise has done. In the past, in my previous organization, we were using something called GCID where if you send data, GCID is basically each document we are receiving. We were using an enterprise solution there called Smarsh. In that company, we were getting almost five petabytes of data per day, so that is the volume I was dealing with. Honeycomb Enterprise was actually really great in terms of tracing. We had a sampling rate and we were not sending all the traces, but the best part is we were able to add more cardinal events, such as GCID, which was getting mapped in each and every document. We were sending those metrics blindly and we did not have to think more about it. The amount of engineering that Honeycomb Enterprise has done is actually handling it very well. At that scale also, I can vouch for Honeycomb Enterprise that it manages traces beautifully.

That money is well spent. We do not have any complaints because tracing is something which is extremely good. How they cater to it and how they manage it is excellent. It is an extremely cost-effective solution right now in the market as compared to its peers like DataDog and other companies.

Throughput is something which I was using previously. There were around twenty million ingestions in my previous organization, obviously. Here the scale is not very high where I can challenge the engine. In my previous organization, when there were twenty plus million ingestions of data every day, in those kinds of scenarios, Honeycomb Enterprise actually stood very well. The major solutioning we were using was for traces. We were not using it for metrics. So if there are more data points, there might be a crash in Honeycomb Enterprise. However, honestly, I have not used it at that scale, so I cannot comment exactly on that point. I have used it for metrics and that performed well, but not on a very high volume of data where I can challenge the engine itself on how it is processing.

I would say it worked pretty well for mid-tier or similar tier companies. I do not have any complaints. But for enterprise solutioning, probably when a lot of data points come in, DataDog obviously has an edge there. They are actually the market leaders around it. They have better metrics, APM, and other aspects there.

Honeycomb Enterprise's tracing solution stands out. Whatever they have built, they have built an excellent product there. Honeycomb Enterprise actually works very well with traces. When you send traces, you will get the complete view of the life of the code and how it has been executed.

The only complaint I have is that even though we are on a paid tier where we are paying one hundred thirty dollars per month, we are still lacking the amount of ingestion we have to do. It counts each and every event. We cannot blindly send the performance metrics and other things directly to Honeycomb Enterprise as it will raise our bills. They have some buffer protection, but that only happens twice or three times a month. After that, the number of events will get billed accordingly.

On the negative side, dashboarding is not that great. I have used solutions like Signoz which are open-source and Grafana. In those platforms, where we have open-source solutions where we are sending in the metrics, we are getting a complete dashboard and a complete solution around it where we can analyze everything in one shot. That is not something which is really great with Honeycomb Enterprise.

People, I think, are very resistant to adopting Honeycomb Enterprise. If you see the community, I am in the Honeycomb Enterprise community right now. I usually ask a lot of questions there. Now that AI came, the questions volume has decreased significantly. However, previously it was a very healthy community where a lot of questions came in. If you go through those questions, the major things are around how to set up things. It is not always about the metrics cardinality or how things are not working around it or if there are any solutions. People are not using it very extensively for metrics or dashboarding kind of solutions where you can see the pulse of the system in one shot.

These kinds of solutions in Honeycomb Enterprise feel very difficult to build because I think it is an over-engineered product in terms of metrics. For traces, I have to give it to them. They have done an excellent job.

The only thing is the UI is not that great for Honeycomb Enterprise. That is something where it is not very appealing when I am looking into it. It is more of an engineered thing. I am an engineer and I understand this. You cannot make the UI very beautiful. However, if you use its peers, such as DataDog or Signoz, there are very interactive dashboards and other things. The dashboard is not that great, honestly, in Honeycomb Enterprise.

There is a cold start problem because we were using something called Lambda in AWS. The cold start issues basically occurred because we had not provided proper RAM to our Lambda function. Because of that, the Boto3 boot up was taking a lot of time. That was caught during these tracing sessions when we added the traces. We were able to identify that the Boto3 startup, the init part of Boto3, was taking more than twelve seconds or ten seconds to boot up. That is basically a very huge latency when it comes to a SaaS product.

Those are the major things. One thing they should do is discontinue Honeybee CLI. Right now, no one is using Honeycomb Enterprise like Honeybee CLI as per my understanding. Very few people are using it, and only POC kind of things are happening on this. People are shifting to OpenTelemetry. They should actually discontinue that product. It does not make much sense because they are trying to bring a dependency on people who are using that and they want to lock them into Honeycomb Enterprise because once the code is telemetered, it is very difficult to change it again.

However, now with cloud and everything we have, it is very easy to make those changes. There is no mode there. If there are engineers around it who are managing those things, they can actually shift to a better place where they can provide more value around it. Because people will eventually move to OpenTelemetry where they will set up their OpenTelemetry system, one OTel collector, and then OTel collector will send everything to Honeycomb Enterprise. People are moving out of these enterprise solutions mostly and they are using OpenTelemetry day in and day out. Most of the architects I talk to in terms of these things always talk about this.

Personally, I have also not used Honeycomb Enterprise CLI. I have read a lot of things and articles around it. They are actually maintaining it very well it seems, but I think they should discontinue it. That is just my opinion based on my observations. I may be wrong, I am not sure. This is what I have observed during communication channels, followed by the usage I have done, and followed by people I talk around. All have similar opinions.

Dashboarding is something which they have to improve. It is very bad.

I have not had any stability issues.

Honeycomb Enterprise's tracing solution stands out. Whatever they have built, they have built an excellent product there. Honeycomb Enterprise actually works very well with traces. When you send traces, you will get the complete view of the life of the code and how it has been executed. However, on the negative side, dashboarding is not that great. I have used solutions like Signoz which are open-source and Grafana, using a lot of things. There we have open-source solutions where we are sending in the metrics and we are getting a complete dashboard and a complete solution around it where we can analyze everything in one shot. That is not something which is really great with Honeycomb Enterprise.

People are very resistant to using Honeycomb Enterprise. If you see the community, I am in the Honeycomb Enterprise community right now. I usually ask a lot of questions there. Now that AI came, the questions volume has decreased significantly. However, previously it was a very healthy community where a lot of questions came in. If you go through those questions, the major things are around how to set up things and how to do things. It is not always about the metrics cardinality or how things are not working around it or if there are any solutions. People are not using it very extensively for metrics or dashboarding kind of solutions where you can see the pulse of the system in one shot.

These kinds of solutions in Honeycomb Enterprise feel very difficult to build because I think it is an over-engineered product in terms of metrics. For traces, I have to give it to them. They have done an excellent job.

The setup is pretty easy. That is straightforward. I do not have any complaint there. The documentation is well written. I set up Honeycomb Enterprise traces just for a POC kind of thing within less than thirty to forty minutes just for a small code. The actual production code took one day, but that is because the code was long. That was easy. It was not very difficult. Things were very clear around it regarding how to generate the API keys to send those things and how to send it.

The load balancer API of Honeycomb Enterprise is extremely good. It accepts everything. I do not have any concerns there. I have never brought it down. I am not sure about the reliability aspect of it, but it accepts everything and I have never seen it down in my experience. I do not have any concerns there.

What we have done in terms of ROI using Honeycomb Enterprise, I still remember one use case where we reduced our overall latency because there was one Boto3 library which was not getting the expected performance. There was a cold start problem because we were using something called Lambda in AWS.

Honeycomb Enterprise played a vital role in identifying the problems in the initial calls itself. That has actually saved us a lot of incidents. Previously, there were a lot of customer complaints coming in. I have taken one step at a time and I have added all these things in our code and followed by the customer complaints are almost ninety to ninety-two to ninety-three percent down as per the data I have.

Honeycomb Enterprise has actually helped us in various ways. The major complaints were around latency. We were able to switch our databases also because there was one problem that was identified by Honeycomb Enterprise where we were trying to fetch more than one megabyte of data from DynamoDB at one point in time. However, the problem was there is a hard limit set to DynamoDB to fetch these kinds of data.

That was a serious problem because customers were expecting data what they want to see on their screen. These kinds of issues were identified during our initial checks on DynamoDB and we were able to move to Snowflake. This has given us better solutioning around it.

In those scenarios where you are not getting the complete data to the customer, it will cap the data to one megabyte.

For tracing solution, definitely, I will always suggest Honeycomb Enterprise is a better solution. Other observability solutions out there are expensive and they are not that reliable in terms of tracing, to be honest.

If there is a genuine bug in the code, then Honeycomb Enterprise is also very useful for debugging the issues. Even a data-driven issue can be fixed using it because we get all the data when a user is providing any request. We actually get the input data in Honeycomb Enterprise and that way we can solve it very fast. We can see what kind of query they hit or what kind of workflow they have done.

I would say it worked pretty well for mid-tier or similar tier companies. I do not have any complaints. For enterprise solutioning, probably when a lot of data points come in, DataDog obviously has an edge there. They are actually the market leaders around it. They have better metrics, APM, and other aspects there.

My overall review rating for Honeycomb Enterprise is eight out of ten.

The solution is mainly used for stack observability. It observes service behavior or any kind of failure that may be happening. The tool is also related to research. My company is working more on this, but I have been working on my SLOs and defining SLOs for the last seven months.

The solution's most valuable features are the queries for the OpenTelemetry events and all the tracing. The solution is very easy to use, and the dashboard is very intuitive.

We faced some OpenTelemetry metrics lost between the communication from the service and the Honeycomb.io. I can't say if this is a Honeycomb.io issue or if there are some limitations in OpenTelemetry.

Alerts are very helpful in Honeycomb.io, but we don't usually merge because we can compare queries with queries for making alerts. We can make alerts based on static numbers, which may block us from building alerts that could be generic enough or could be serviced.

I have been using Honeycomb.io for two years.

We’ve never had any issues with the solution’s stability.

Honeycomb.io is a scalable solution. The service is very resilient and can handle a lot of data. The quantity of data Honeycomb.io can parse and use to create charts is really good. More than 100 users are using the solution in our tech team.

I rate the solution’s scalability an eight or nine out of ten.

The solution's initial setup is easy. I think the hardest part is to understand OpenTelemetry in general.

We set up Honeycomb.io on all the services so that we can have all the set traces of the communication between all the services inside the company. This helps us understand where it could be failing, which in turn helps with failures and observability.

When we are not thinking about one specific failure but a major one, we can create queries for statistics views like the P99 or P95 behaviors. That's very helpful. I would recommend the solution to other users because it is very helpful.

Overall, I rate the solution a nine out of ten.