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
Top 20
2023-05-23T19:17:00Z
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
Top 10
2023-03-16T14:00:00Z
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 is the missing piece in your DevOps toolchain - offering one unified platform from which you can gain a deep understanding of all of your system events and changes. We integrate with all of your tools, monitor changes and alerts and organize information on a clear digestible dashboard and provide you with the right context at the right time.
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.