Perhaps a deeper integration with logs and metrics would help. Today, I still need to jump to an external tool such as a logging or monitoring platform to fully understand the issue. Although Komodor is really good, having richer logs and metrics directly inside Komodor would reduce context switching. I really appreciate the timeline; it is great, but it still requires manual analysis. If Komodor could highlight it or perhaps give some artificial intelligence insights, that would be helpful. Sometimes I need to spend a lot of time to find specific issues, especially when I have different microservices that I need to drill down to find. If there were artificial intelligence insights available where I could write down my problem, it could really improve the experience, especially for junior developers who struggle since they do not know exactly what services are available.Solving the issue of reducing the switching between tools would be beneficial. I still need to switch tools, not so much, but I do use different logs such as Splunk.
There are some features related to the platform that are missing in Komodor, such as Tigera status or CNI pods. Including these features would be helpful for platform engineers.
There's nothing in particular that is wrong with Komodor. It's hard to say that there's something we would really like to see improved. I hope that the cost analytics and resource usage allocation areas will see further development. For example, where we can now see if the pods are over- or under-provisioned, I wouldn't mind higher-level development. I would like to see if we're utilizing nodes in the cluster, if pod allocation is optimal, how much idling we have, and whether we scale up and down efficiently. I would like to see them help us optimize costs further. Because, as our company grows and our clusters get busier and busier, any inefficiency is a lot of money wasted. That's definitely high on our wish list: anything that helps us track wasted resources.
I have used Komodor for two and a half years, and it has come a long way. However, I would say that performance could be improved. Sometimes, it takes longer than it should for developers to pull up logs or interact with the cluster. Komodor is aware of this issue and is working on a fix. Secondly, I like the alerts that Komodor provides, but I think the alert interface could be improved. It is not the most intuitive system in the world, and it can be difficult to set up. I think Komodor could improve the alert interface by making it more user-friendly. Finally, I would like to see Komodor add ServiceMaster visibility. This would give us greater insights into how our services interact with each other. This would be very helpful in troubleshooting problems, as it would allow us to quickly identify which services are affected when one service goes down. Komodor does not currently have this capability, but I hope they will add it in the future.
Senior SRE at a computer software company with 501-1,000 employees
Real User
May 23, 2023
Having an agent that's almost God-like makes us a little nervous. I would love to see the actions not be performed on behalf of the user, but rather as the user, perhaps by aligning SSO groups, as one approach to that. That is one reason that we're not using its actions, because we're a little nervous about granting all that access to Komodor. In terms of just read-only and presenting this data, you have to give it view access to practically everything to get value from it. Also, we get a steady stream of new users coming into Komodor, so I know people are using it. But one thing we don't have visibility into, which I would love to have, is metrics, such as user logins and usage. It's really hard to know what people are doing when I don't have any metrics on that directly. If somebody higher up wants to know how Komodor is being used over time, I can't query that. I know that Komodor has those metrics, but from my understanding, they're in another tool outside of the Komodor application. It would be nice if they found a way to funnel that back in. Currently, Komodor doesn't really focus on the managers and decision-makers when it comes to the engineering of the tool. They rely on quarterly meetings where they present usage but it would be so much nicer if that was built into the tool. They're also working on the audit log area and there is still a long way to go to make that look nicer and more feature-rich.
DevOps Engineer at a retailer with 1,001-5,000 employees
Real User
Mar 16, 2023
I would like to see improvements in how the product is installed. We've already communicated these things directly to Komodor. One feature we would like to see is for Komodor to be highly available on the clusters. Currently, it's only able to run in one instance within the cluster. It would be nice to have more configurability of what you see when and where instead of filtering so that you can save different views.
Komodor offers enhanced visibility and centralized event timelines for Kubernetes environments, enabling efficient debugging and proactive management across multiple clusters.Komodor provides a comprehensive platform for troubleshooting and monitoring Kubernetes deployments. It aids in root cause identification, deployment notifications, and tracking historical changes while maintaining real-time metrics and retained logs. The platform supports efficient CI/CD pipeline management and...
Perhaps a deeper integration with logs and metrics would help. Today, I still need to jump to an external tool such as a logging or monitoring platform to fully understand the issue. Although Komodor is really good, having richer logs and metrics directly inside Komodor would reduce context switching. I really appreciate the timeline; it is great, but it still requires manual analysis. If Komodor could highlight it or perhaps give some artificial intelligence insights, that would be helpful. Sometimes I need to spend a lot of time to find specific issues, especially when I have different microservices that I need to drill down to find. If there were artificial intelligence insights available where I could write down my problem, it could really improve the experience, especially for junior developers who struggle since they do not know exactly what services are available.Solving the issue of reducing the switching between tools would be beneficial. I still need to switch tools, not so much, but I do use different logs such as Splunk.
There are some features related to the platform that are missing in Komodor, such as Tigera status or CNI pods. Including these features would be helpful for platform engineers.
There's nothing in particular that is wrong with Komodor. It's hard to say that there's something we would really like to see improved. I hope that the cost analytics and resource usage allocation areas will see further development. For example, where we can now see if the pods are over- or under-provisioned, I wouldn't mind higher-level development. I would like to see if we're utilizing nodes in the cluster, if pod allocation is optimal, how much idling we have, and whether we scale up and down efficiently. I would like to see them help us optimize costs further. Because, as our company grows and our clusters get busier and busier, any inefficiency is a lot of money wasted. That's definitely high on our wish list: anything that helps us track wasted resources.
I have used Komodor for two and a half years, and it has come a long way. However, I would say that performance could be improved. Sometimes, it takes longer than it should for developers to pull up logs or interact with the cluster. Komodor is aware of this issue and is working on a fix. Secondly, I like the alerts that Komodor provides, but I think the alert interface could be improved. It is not the most intuitive system in the world, and it can be difficult to set up. I think Komodor could improve the alert interface by making it more user-friendly. Finally, I would like to see Komodor add ServiceMaster visibility. This would give us greater insights into how our services interact with each other. This would be very helpful in troubleshooting problems, as it would allow us to quickly identify which services are affected when one service goes down. Komodor does not currently have this capability, but I hope they will add it in the future.
Having an agent that's almost God-like makes us a little nervous. I would love to see the actions not be performed on behalf of the user, but rather as the user, perhaps by aligning SSO groups, as one approach to that. That is one reason that we're not using its actions, because we're a little nervous about granting all that access to Komodor. In terms of just read-only and presenting this data, you have to give it view access to practically everything to get value from it. Also, we get a steady stream of new users coming into Komodor, so I know people are using it. But one thing we don't have visibility into, which I would love to have, is metrics, such as user logins and usage. It's really hard to know what people are doing when I don't have any metrics on that directly. If somebody higher up wants to know how Komodor is being used over time, I can't query that. I know that Komodor has those metrics, but from my understanding, they're in another tool outside of the Komodor application. It would be nice if they found a way to funnel that back in. Currently, Komodor doesn't really focus on the managers and decision-makers when it comes to the engineering of the tool. They rely on quarterly meetings where they present usage but it would be so much nicer if that was built into the tool. They're also working on the audit log area and there is still a long way to go to make that look nicer and more feature-rich.
I would like to see improvements in how the product is installed. We've already communicated these things directly to Komodor. One feature we would like to see is for Komodor to be highly available on the clusters. Currently, it's only able to run in one instance within the cluster. It would be nice to have more configurability of what you see when and where instead of filtering so that you can save different views.