Service configuration: settings API vs dedicated endpoints

[pahofmann]

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?

[pahofmann]

Any input on this?

[Julius_Loman · Accepted solution]

@pahofmann  I think the goal is to move the configuration API  into Settings API sooner or later. With the current options, you will lose some flexibility (regarding anomaly detection for example), but I think Dynatrace mainly aims large environments so dedicated teams can do configurations on their own without affecting other teams. This is not really possible with config APIs.

@tom_rothschaedl are there any plans of introducing additional scopes or rules? For example for builtin:failure-detection.service.general-parameters there is only the SERVICE scope defined which will make it difficult to maintain same setting across many services for example in a Host Group or Process group.

[Ingrida]

I fully agree with @Julius_Loman ,

On one side Settings API is great to use as it provides kinda standardizes access to any kind of settings (if you can deal with one, you can deal with same code with the rest, at least most of the time) despite being pain in a... to understand and use shemas itself (it's kinda trial and error till you get it right).

On the other side binding of settings to EntityID's is  almost not managable, not easy storable in repo and enforces us custom coding using entity selector as step 1 and then looping thruth the entities as step 2 in order to provide all entities required settings we need.

On the top you have to run all your configurations on regular basis as you entities keeps komming and goign and you just run after all the time. 

It's not what I would like to have as "monitorjng-as-a-code" as it is not "transportable"