Honeycomb Enterprise

We are the customers of Honeycomb Enterprise .

Basically, the purpose of using Honeycomb Enterprise  is that it provides larger interfaces and dashboards for the logs of machines, terminals, and the debugging process is very easy because of Honeycomb Enterprise. Centralized logs are provided by Honeycomb Enterprise. We have integrated it into our services, including our deployed apps. So if any service goes down, any services are slow, or any APIs are crashing, then we use Honeycomb Enterprise very well for debugging purposes and tracing the logs between the services and microservices.

Structured  Tracing gives the whole structure of a user interaction. If a user logged in, then went to this service and went to another service, then used this feature of our app or web app, Structured  Tracing gives a full path. If we try to filter via user ID or correlation ID, we can see the full path a user has gone and how a user has interacted with the app or used our app, and where most people are going within our app, so we can analyze it, such as which functionality is most used by users.

We have used Honeycomb Enterprise in our services and deployed apps.

The biggest advantage of Honeycomb Enterprise for us is that it centralizes everything. For example, if we use AWS  CloudWatch for a service, it gives logs for that service only. We manually have to search and scroll down over multiple thousands of logs for the crashing or slowing services. Honeycomb Enterprise basically gives a proper dashboard for everything. For example, if we have deployed multiple apps, if we are connecting it from Kubernetes , if we are connecting it from Docker , if we are connecting from a machine such as an EC2  instance, it basically handles all the logs. So whenever we need some logs, such as for slowing or crashing services, we just go into the dashboards, run some queries, and get those logs for certain time frames and fix the bug. This is how we use it, and it helps. It quietly increases productivity and debugging efficiency.

We just use the Bubble  Up feature for identifying performance anomalies for API performance only. Because we have deployed our services including apps, web apps, and websites, we just need to figure out which service or which API for which microservice is going down or running poorly, giving some latency over the API calling. So we just analyze which service is running slow so we can increase its efficiency or make it better to use. This will increase our output.

One of the disadvantages or areas for improvement I see is that it is very costly. My honest opinion is that its service is very good, but for me as an individual, if I am using it in a small app, it creates a huge amount of data and it is very expensive to manage.

It has features for integrating into our apps, but regarding additional features, it should provide some global entry, such as a global SDK or system that captures the full services. We are facing an issue with integrating it. It provides an SDK to integrate into mobile applications or web applications, but we have to configure it manually in our services or microservices or APIs. It should capture all services by applying it globally on the app with the root of the app. Then it can capture the logs from the API calls. The root problem is that if we have 15 microservices in our app, we have to go and place it on the router, on the controller, and the service itself. So it takes place in every part of the code. That is the root problem. We have to hire two or three people that are masters in this platform and then apply the code in the codebase. So it can be improved via root SDKs so it can capture activity on a global level.

I have been using Honeycomb Enterprise for about a year.

Honeycomb Enterprise provides connections from everything in an IT company, basically. It provides logging, it provides connection with AWS , it provides connection with Docker , and machines, and local services, and mobile applications also. It covers pretty much everything for a software developing company or organization.

Honeycomb Enterprise is reliable. I can say it is around 98 percent reliable. It sometimes lags for larger systems or larger microservices, or for larger databases stored within its database. So I can say it is 98 percent reliable and productive.

If we use it in a larger platform which is regularly used by users, it creates a huge amount of data. It captures all the logs if we integrate it in our services. Then there is a huge amount of data, and it takes thousands of dollars per month for an enterprise level. So if we compare it to other tools, its service is very good. I know that. We know that its service is very good. We get interactive dashboards and features for filtering out and tracing the whole process. But if we talk about the pricing, it collects a huge amount of data, which then creates the large pricing for the enterprise level.

I am happy with Honeycomb Enterprise's customer service because we have never called them because we have never felt the need to call them. We have never faced an issue with Honeycomb Enterprise. Our main goal is the debugging process from Honeycomb Enterprise. We achieved it, and it is seamless, and we have never faced an issue with it.

The initial setup and deployment procedure for Honeycomb Enterprise is straightforward. It is quite simple to use. We can just deploy via Docker or Kubernetes  and these kinds of services. Honeycomb Enterprise provides quite a good setup for using these services. It provides the OpenTelemetry  SDK and the Honeycomb Enterprise SDK also. So we can just use and integrate with these systems including Docker and Kubernetes and make the deployment process very seamless and very easy. It is quite interesting to use it, and we can deploy products seamlessly.

If we talk about how I compare Honeycomb Enterprise to its competitors, I would say that if we talk about the competition such as OpenTelemetry , Grafana , some people are still using them because of their pricing only. The major factor is pricing. I just want to say the major factor is pricing. We have a banking system that is generating dozens of logs. So we are facing the pricing issue, which is thousands of dollars a month, so it is quite expensive. If we use Grafana  and other tools for logging and capturing these analytics, that is a time-consuming process but less costly. So that is the major issue with the competition.

If we speak about whether Honeycomb Enterprise is worth the money, I would say if we speak about enterprises or companies such as mine, we have dozens of applications we have developed or deployed or are running live. It provides a single dashboard for all of them. We can select projects and see their logs and debug from there. Basically, it is based on OpenTelemetry. So, OpenTelemetry provides great graphical analytics. We can trace each and every call from there, historic calls also, from two or three years ago. So, it helps a lot in debugging. What does a developer need? If a bug came out, if a service fails, then we should work on it immediately. Before, we had to watch AWS CloudWatch logs and see terminals of the EC2  instance machines. So, that is quite time-consuming and very irritating. This resolves all of that because we have a dashboard and we can run queries to get these error logs. For debugging, we can just run queries such as what API is taking more than five milliseconds. It is just amazing working with it. We can get directly what we want within the time frame, and it helps debug the code and the terminal. I gave this review a rating of nine out of ten.

Honeycomb Enterprise  is used in support of global clients for observability and debugging cloud-native applications. It is utilized for tracing different types of observation of processes and tools as an automated tool. Depending on client requirements at global locations, Honeycomb Enterprise  is selected from among other competitors.

For example, work with refineries within the energy space has involved using applications supported by Honeycomb Enterprise to understand and support clients in those projects. This includes understanding their processes and observing the different applications they use within AWS  and the enterprise version. Using these tools, numerous different processes within the energy sector have been observed, and Honeycomb Enterprise is used for refineries and other operations. In specific cases, processes and how applications are run are observed, and different metrics like Honeycomb Metrics and other tools within the Canvas and other available options for model content protocol are used for different approaches. Anomalies are detected as part of MCP, and then efforts are made to debug those anomalies and work with the applications. For all clients, the process is generally the same, though specifics vary by application.

Honeycomb Enterprise is generally used to observe processes, understand anomalies, detect them, and work with applications to debug problems that surface. One challenge is that many things have to be defined manually and are not totally automated, while some competitors used for different projects or clients do have automation. Despite this, Honeycomb Enterprise remains a good tool for these purposes.

More automation would be great with Honeycomb Enterprise, as some competitors have more automation in this area. Dynatrace  and others that have been used do provide more automation. Frequent evaluations of these tools against each other within the competitive landscape are conducted, so there is definitely room for improvement, and more can be done with Honeycomb Enterprise. However, at the moment, there is happiness with some abilities like natural language interactions and creating live diagrams through the process, which are all advantages that are beneficial.

Further automation of Honeycomb Enterprise and a reduction in the number of manual inputs currently required would be very beneficial. While it is known that they are working on that, some competitors already have automated features, with Dynatrace  being one of them, and Grafana  providing telemetry standards and other features. There are other things that could be done regarding further automation to reduce manual input, which does create challenges and slows progress.

Debugging  could be improved with suggestions for improvement or for solving the problems. If suggestions were provided in the process of debugging, that would also be very helpful with Honeycomb Enterprise.

The AI capabilities of Honeycomb Enterprise are good, and this is considered positive. The interaction with these capabilities has not presented any issues.

In terms of accuracy, there is room for improvement, and for reliability, results are usually compared with other data and other approaches used for specific projects to ascertain that the results obtained are accurate. Since it is still in early stages and early use, full reliance cannot be placed on everything obtained from it. Results have to be compared and common sense and due diligence must be applied with other observations and analytic work to qualify the results. In terms of security, no breaches or issues have been noticed.

Honeycomb Enterprise offers excellent features that include the ability to define different triggers. Within Honeycomb Enterprise, 300 triggers can be defined, and different activities like single sign-on can be performed using various service level objectives available within the enterprise package. Queries can be defined manually, providing significant customization and the ability to customize and define as needed. Since it is cloud-native, it helps because applications supported are that way for global clients. Most importantly, Honeycomb Metrics for debugging and identifying issues and anomalies is a good step, though it is not sufficient because clients require remedies for the challenges encountered. The ability with Honeycomb Metrics in particular to debug those issues is very helpful. These advantages stand out for the enterprise version as opposed to Pro, where only two triggers can be defined, but in Enterprise, 300 or more can be configured.

The feature relied upon most day-to-day is Honeycomb Metrics. As a consulting company solving problems, identifying and solving issues is really important, and this feature facilitates workflows and expedites and provides efficiency within processes. It gives access to tools and techniques that would not otherwise be available.

Efficiency improvements in processes with Honeycomb Enterprise have definitely been seen, and the most representative example is that more projects can be handled than could be done prior to using Honeycomb Enterprise. Issues for clients can be resolved in an expedited fashion, and more projects can be accepted, making these efficiency improvements quite advantageous.

Honeycomb Enterprise has been used for the past five years.

To the degree expected from Honeycomb Enterprise, it has been stable.

In terms of the number of triggers and service level objectives, Honeycomb Enterprise's scalability is good and adequate. In terms of adding team members or multiple team members using it, no challenges have been encountered. Since we are a relatively small consulting practice, only that perspective can be offered.

Dynatrace, New Relic , and some other tools like DataDog have been used for different purposes and some for observability. Honeycomb Enterprise was not necessarily switched to but rather added to the suite of tools used for different projects.

New Relic , Dynatrace, DataDog, and Grafana  have been considered as alternate solutions.

About 30% more projects can be handled than prior to the use of observability tools as a whole. Although more than one type of tool is used because diverse clients with different requirements are served, in general, 30% improvement has been observed. This is measured based on the number of new projects that can be taken and the revenues that can be generated as a result. Due diligence and evaluations should be conducted before choosing if Honeycomb Enterprise is optimum for what is required. The review rating for this product is 6 out of 10.

We generally use it to create dashboards through Honeycomb Enterprise . What we do is we have Splunk for separate things for getting the traces and debugging and examining what are the errors or if all our services are up to date. The tracking of the logs and tracing them through the trace IDs is separately done through Splunk logs. However, Honeycomb Enterprise we use for observing and debugging. We don't need any pre-built dashboards in Honeycomb Enterprise. It helps us in addressing the production issues very quickly and identifying the current outliers. That is the reason why we are using Honeycomb Enterprise. It is not just for observability and debugging, but also for health checks of the services to ensure that all the services are up and running steadily and what are the statistics so far.

We are utilizing Honeycomb Enterprise because it addresses multiple concerns at the same time, not just debugging and observability alone, but also checking the health checks of the services. We can even create our own custom dashboards utilizing whatever kind of graphs we want, a pie chart or even bar graphs for analyzing different aspects of our services to ensure they are correctly satisfying our parameters, which is the basis for which we are trying to root our observations. If you go for Splunk, then maybe you can just use it for observing and debugging using their log traces. That is quite limited. You have to use the queries also which can get complex when there is so much nesting in the queries or it has to handle a large amount of data. When we scale up the data set, at that time it becomes a challenge in Splunk. Whereas in Honeycomb Enterprise, it is a little bit made easier.

In Splunk we write custom queries and then we try to find the log traces, but in Honeycomb Enterprise it is very fast querying. It doesn't need many pre-built dashboards. It serves us by offering great support for high cardinality data. It is also very useful for distributed tracing.

In our enterprises we are using cloud native systems. We are using applications which have support for cloud technology. Honeycomb Enterprise is designed for modern cloud native systems. Honeycomb Enterprise has that cutting edge technology that we actually want nowadays. Observability  and debugging, it is excellent for that. Splunk can at times maybe slow speed can be the cause which we will not prefer Splunk for that because if we have a large data set then maybe we will not prefer Splunk. We can go for Honeycomb Enterprise because the speed which is offered by Honeycomb Enterprise is much more than what we get in Splunk. That is why we say that we don't need to write the complex queries which we have been doing so far in Splunk. Here  the advantage is the speed. It is less focused on traditional log management than Splunk.

There are a lot many negatives that Honeycomb Enterprise is having. One of them is that it needs good instrumentation and instrumentation to work properly. It is not as strong as what a traditional log management. It may not suit security compliance heavy teams. It can feel expensive when we have a large data set and when we want to engage a larger data set, and when many people want to be engaged for analyzing a particular issue. It is less familiar if your team is used to the dashboard first tools. Here  we don't prefer pre-built dashboards. If the team is accustomed to using the kind of tools wherein the dashboards are already in use, then at that time it can appear as if it is less familiar. Honeycomb Enterprise's downside is that it is powerful for observability, but it can be harder to learn and maybe not fit every use case.

I have been using Honeycomb Enterprise for two years.

Glitches are a part of every tool and they do keep on happening. Mostly it is reliable, but at times, maybe one or two times in two to three months, these issues do happen. Sometimes errors happen in Honeycomb Enterprise or sometimes latency comes. That kind of issues sometimes happen maybe in three months, around one or two times. I won't say that it is fully robust, but at times it does give us some problems.

I think it can be expensive because if we want to scale it up, they are having some charges on that. At times we can be shocked to see that this price is too high for involving too many developers on one peak or having a much bigger data set or more advanced features for our use. At times I have seen that there are very high incurring costs noticed in Honeycomb Enterprise. Sometimes when our requirement is not too high, we may feel that it is a decent cost, but at times when we want more features, the cost sometimes is higher.

BubbleUp anomalies is actually a very important feature and it is very much used in our organization. Assume that you are having a total of 100 requests. One of them is very, very slow due to some cause, maybe there are some errors, some maybe downstream service might be failing due to which it is getting slow. But now the cause is, should we let all the other 100 requests suffer because of just this one request? The answer is no. To highlight what is the issue going on in our currently running 100 requests, we just highlight that one request which is very slow or maybe we just move it to the top so that we can alert everybody that this is the problem. All the 99 are okay, but the only issue which we are facing is with this single request which is very slow. What is the reason? We can identify that through the log traces again. If we see any odd patterns, then it automatically highlights them. Any outliers are there, so it makes them a bit visible so that we can make the investigation a bit fast paced. Unusual behavior can be highlighted to everyone so that we could be exploiting the solution that we might have, the developers we can engage so that they can rectify that problem and all the 100 requests are in shape again and do not cause the unwanted latency which we sometimes do experience just because of maybe one or two requests.

Since our teams involve multiple users and this is not just a situation where we are in one location, somebody might be from abroad. The team is quite vast and has everybody from every corner of the globe. What this means is that it enables everybody to log in and collaborate together and work on the single task. Sometimes when the major issue happens, just a single developer is not given the priority to be doing the same task and multiple users are required to be involved in this kind of issues at the same time. They can address the different aspects of the same, but the logs are common. The collaboration feature, which is a very highly rated feature of Honeycomb Enterprise is offered by it for keeping multiple logins for all the users across the team. That way we can share the data amongst each other. We can add the comments so that everybody can view what are the observations of some other person from some other aspect of the issue. That way everybody is on the same page. Dashboards can be viewed together. We can even sometimes see multiple people viewing the same dashboard at the same time. This is a part of this collaboration feature. This enables the team, the global team for investigating the issues together and not just investigating it, but also collaborating with each other to help each other and to resolve this issue in a lesser amount of time. That way everybody could trace the logs and keep tracking simultaneously. Suppose that if we are working on one issue, maybe some other issue also comes up, but few developers couldn't notice it, but the third one could notice that and can bring it to the forum and everybody could then work on that.

The installation and deployment procedure is quite easier. Basically what happens is we just want to put a tool into the system and it's easy for Honeycomb Enterprise. It's not that complex. I don't find it complex.

Honeycomb Enterprise helps the ROI by reducing debugging time, speeding up the incident resolution, and helping teams find production issues faster. If you do ask for cost, then I would say I am also somewhere in that much amount, approximately 10 to 20 percent.

Effectiveness means, Honeycomb Enterprise is very effective. We have all these kind of things structured tracing, collaborating feature, and data analysis. Honeycomb Enterprise is more effective than Splunk. When we are working on a large data set, we have a lot of values. High cardinality data support is offered by Honeycomb Enterprise, which means we can analyze lots of unique values. It helps in fast debugging. This is a major win. Fast debugging is what it offers. In Splunk, tracing becomes very slow if we have complex queries. That is something which we cannot afford to have when we are having immediate deadlines, very tight deadlines. At that time we need a very fast debug. If we build new dashboards, then even it helps in tracking these issues very fast. You have graphs also, you have a tabular format of analysis. BubbleUp anomalies again, because they highly, if any issue occurred in any of the request, it will be shooting it up directly on the dashboard and you can see from there that this is the issue, it is highlighted. We need to address it quickly because the deadline is nearing and it is a very close call. It has a good tracing support. It helps tracking the request across the services. It offers better collaboration because teams can investigate the incident together by this collaboration feature of Honeycomb Enterprise. Honeycomb Enterprise is effective because it helps teams quickly find, understand and debug unusual behavior in the complex systems.

Whenever we make a request, there is an inter-service communication. One service makes a request to another service. In that journey, we have a trace ID, we have a span ID, we have a service name, a status and duration. This gives us proper fields and the format to record the behavior of each request while it is making the transition from one service to another service. This is a transit. During this transit, we need to maintain the logs. Honeycomb Enterprise has given us a very good facility where we have a few fields. The trace ID is the main, span ID comes under it and the service name, status and the duration for which this request happened. This is one thing that we have these kind of format wherein these kind of parameters are there. But ideally, everybody looks for the benefit. That is one aspect that we have this kind of format, but what will this help in? It helps in finding the problem a bit faster. Anomalies, requests, wherever it went slower, wherever we found some bug or maybe the request got stuck somewhere. It is helpful in identifying it a bit easily and maybe faster. It is helpful in understanding that flow, how we are navigating from one request to the other request, what are the intermediate processes happening in between and whatever operations are happening between this one request, we have each thing properly formatted with the help of these parameters like the trace ID and span ID. That way we can probably identify the root causes of our if any issues occur. Even if the issues don't occur, then it is a good practice to keep the logs so that some or another day, maybe if you want to track yourself back to the previous logs, you can basically possibly track it. You can address the issue or maybe that aspect or behavior which you want to monitor in some time in the future.

My overall review rating for Honeycomb Enterprise is 9 out of 10.