cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Service configuration: settings API vs dedicated endpoints

pahofmann
DynaMight Leader
DynaMight Leader

The API is getting more and more coverage in terms of configuration, especially with the recent additions to the settings API, which is great for big customers were config as code is the only option to keep up with the environment size.

 

One example were I see an issue in terms of usability is the service configuration, when trying to configure Error and Anomaly detection.

 

For Error Detection there is a dedicated Endpoint failure detection in the Configuration API. This makes it very easy to define a set of error detection parameters and match it to many services via conditions in a detection rule with two API calls.

 

For Anomaly Detection there is a schema (builtin:anomaly-detection.services) available in the Settings Endpoint of the Environment v2 API. But there we can only modify a global configuration or configuration per service.  From the schema it looks like multi objects are possible in general but not for this one:

...  
"multiObject": false, "maxObjects": 1, "allowedScopes": [ "SERVICE_METHOD", "SERVICE", "HOST_GROUP", "environment"
...

 

Of course, could still automate this by getting the relevant entities via the entity API and applying settings object for each one. But that would need hundreds to thousands of requests and a scheduled execution to apply the setting to new services.

 

 

My question is what the plans are in regard to the setting and configuration API. 

Are there plans to move all (new) configuration to the settings API?

Is multi object support planned with flexible rules like matching tags or management zones?

Or would this be a case for a Product Idea to create an Endpoint in the configuration API for anomaly detection like there is for failure detection?

 

 

 

Dynatrace Certified Master, AppMon Certified Master - Dynatrace Partner - 360Performance.net
0 REPLIES 0