We are an HR analytics company, and we do a lot of data processing. Our customers send us their HR-related data, and we process it so that we can run analytics on it. We process it on Kubernetes clusters, and we use Komodor to monitor our clusters to ensure that the clusters are reliable, to troubleshoot them, and to optimize the setup to make it cost-efficient for us. My usage of Komodor may be a bit unusual because I go into it to troubleshoot or monitor something. I usually go in with a specific goal of looking at something via Komodor, so I use the workflows more than the dashboards. Either I'm running some process and want to monitor it in Komodor, or there is an incident and I want to find out what's going on via Komodor. I also look at the dashboard, and I can see at times that something does not look quite right. That's useful.
We use Komodor for two prominent use cases. The first is from an operational standpoint. It is our number one troubleshooting tool for our operations teams. The second is developer enablement. We use Komodor to allow developers to interact with their Kubernetes clusters, get alerts, and see what is going on without giving them direct access to Kubernetes. It is very helpful.
Senior SRE at a computer software company with 501-1,000 employees
Real User
Top 20
2023-05-23T19:17:00Z
May 23, 2023
We didn't have a very good story for our product engineers to help them visualize their application, post-deployment after migrating from Singularity to Kubernetes. Singularity has a nice user interface where they could see the deployments and scale, balance, restart, et cetera. When we moved to Kubernetes, things were more hidden. All we had was the Kubernetes Dashboard, which is verbose and clunky. We were looking for something to help our engineers visualize their deployments and troubleshoot them.
DevOps Engineer at a retailer with 1,001-5,000 employees
Real User
Top 10
2023-03-16T14:00:00Z
Mar 16, 2023
We have a multi-cluster setup with a lot of workloads being distributed throughout those clusters. Komodor is installed on all our clusters as a base component. We wanted an easy way for operations staff who are not as experienced to be able to look into what might be wrong with workloads across these clusters.
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.
We are an HR analytics company, and we do a lot of data processing. Our customers send us their HR-related data, and we process it so that we can run analytics on it. We process it on Kubernetes clusters, and we use Komodor to monitor our clusters to ensure that the clusters are reliable, to troubleshoot them, and to optimize the setup to make it cost-efficient for us. My usage of Komodor may be a bit unusual because I go into it to troubleshoot or monitor something. I usually go in with a specific goal of looking at something via Komodor, so I use the workflows more than the dashboards. Either I'm running some process and want to monitor it in Komodor, or there is an incident and I want to find out what's going on via Komodor. I also look at the dashboard, and I can see at times that something does not look quite right. That's useful.
We use Komodor for two prominent use cases. The first is from an operational standpoint. It is our number one troubleshooting tool for our operations teams. The second is developer enablement. We use Komodor to allow developers to interact with their Kubernetes clusters, get alerts, and see what is going on without giving them direct access to Kubernetes. It is very helpful.
We didn't have a very good story for our product engineers to help them visualize their application, post-deployment after migrating from Singularity to Kubernetes. Singularity has a nice user interface where they could see the deployments and scale, balance, restart, et cetera. When we moved to Kubernetes, things were more hidden. All we had was the Kubernetes Dashboard, which is verbose and clunky. We were looking for something to help our engineers visualize their deployments and troubleshoot them.
We have a multi-cluster setup with a lot of workloads being distributed throughout those clusters. Komodor is installed on all our clusters as a base component. We wanted an easy way for operations staff who are not as experienced to be able to look into what might be wrong with workloads across these clusters.