We are experiencing major issues with REST API speed. It takes over 50-55 seconds to change ONE of the service phase from eg. undecided to monitored or ignored. If we do this from GUI it also takes a lot of time for one configuration but here you can select several in one change that is not possible with the RESP-API.
Right now we are reading in approx. 2,000 databases from our CMDB, which will have different statuses. It will take us weeks to use the REST_API. You need to get this sorted ASAP. Questions move quickly with just changes and write-ups take forever.
We are currently running the latest version of applience 1.7.2 and 2.3.0p6 by checkmk. But we’ve had the same problem since we started developing with Checkmk’s REST API.
Short question - why do you do such things? Single item operations that trigger a rescan of the device should be avoided under any circumstances in bigger environments. It is way better to create rules that do this than moving manually a service around.
Rules cannot handle receiving information from other sources. For example, should a database be active or not. If it should be active but is shut down, controls will not work as they should. It is also difficult to manage changes and multiple instances with different names. Then we don’t want to manually manage in several places as we get it automated. If it takes 50 seconds to write to an API, you have thought completely wrong about what to use an API for. An API must be created for it to be used for best practice.
@Ahlen I see your frustration, but Andreas has a point: Only because something can be done a certain way, does not mean, it is the most efficient way.
On top of that: An API is a mere interface, which triggers tasks and needs to wait for them to finish. If that is an expensive operation, even the greatest API needs to wait.
Last remark from me: I doubt, that what you need to do cannot be done using rules (at least for the better part of it). But as with most things, it is hard to tell that from a distance. So I can only hope, that you are willing to consider the ideas put out and maybe take a step back to double-check, if there really is no other approach to your use-case.
Thanks for your comments @robin.gierse.
But why have you built the API to make rescans after each update when change the service status. Why not use a commit when you have made the changes you need? The information you need to make changes you allready got before you proceed the changes.
We will to rebuild the script but we will not have the control we need when we need to use rules. But It will work OK. But It will be a lot of rules, when we have almoust 300 database servers.
Hi Robin. Sorry for late reply but this PUT call “Update the phase of a service” is what I use to set “ignored” or “monitored”. Each change per service check take 50-52 seconds. It should be good if you can make several changes and after that make a commit of your changes. Today you make an commit and save change for each call.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.