We approved the APP for our Managed to SaaS migration case and below are the improvement points we identified (out of 15k configurations, an error occurred in 5k):
object ID = builtinmetric.metadata
Many errors related to Cloud or Extensions built-in metrics, wouldn't it make sense to skip this type of configuration?
--------------------------------------------------------------------------------------------------------------
objects ID = builtinspan-attribute and builtinspan-event-attribute
message example:
Schema "builtin:span-attribute" is deprecated - please update your configurations: this setting was replaced by 'builtin:attribute-allow-list' and 'builtin:attribute-masking
This seems like a problem to be fixed where the JSON provided in the API's GET is not accepted to make the POST because the object's id has been "updated"
-----------------------------------------------------------------------------------------------------------------------------
objects ID = builtinsynthetic.browser.assigned-applications, builtinsynthetic.browser.outage-handling, synthetic-monitor, builtinsynthetic.browser.name, builtinsynthetic.http.scheduling, builtinsynthetic.http.performance-thresholds, builtinsynthetic.http.cookies
message example:
Skipping deployment of toDeploy:builtin:synthetic.browser.assigned-applications:{ID}, as it depends on toDeploy:synthetic-monitor:SYNTHETIC_TEST-{ID} which was not deployed after root dependency configuration toDeploy:synthetic-location:SYNTHETIC_LOCATION-{ID} failed to deploy
We have environments with 200 to 900 synthetic monitors, it is completely unfeasible to update the ID property manually 1 by 1, this is a point of attention that needs to be evolved (applies to any similar dependency error by entity ID of the env origin).
--------------------------------------------------------------------------------------------------------------------------
object ID = calculated-metrics-service
message:
failed after 60 retries: (HTTP 400) (HTTP 400): {"error":{"code":400,"message":"Constraints violated.","constraintViolations":[{"path":"conditions","message":"At least one condition of the following types must be used: [SERVICE_DISPLAY_NAME, SERVICE_PUBLIC_DOMAIN_NAME, SERVICE_WEB_APPLICATION_ID, SERVICE_WEB_CONTEXT_ROOT, SERVICE_WEB_SERVER_NAME, SERVICE_WEB_SERVICE_NAME, SERVICE_WEB_SERVICE_NAMESPACE, REMOTE_SERVICE_NAME, REMOTE_ENDPOINT, AZURE_FUNCTIONS_SITE_NAME, AZURE_FUNCTIONS_FUNCTION_NAME, CTG_GATEWAY_URL, CTG_SERVER_NAME, ACTOR_SYSTEM, ESB_APPLICATION_NAME, SERVICE_TAG, SERVICE_TYPE, PROCESS_GROUP_TAG, PROCESS_GROUP_NAME]","parameterLocation":"PAYLOAD_BODY","location":null}]}}
I understand it as a product failure, since the Calculated Metric is normally created with the attribute condition as shown in the JSON:
attribute":string"REQUEST_TYPE"
And the Dynatrace API doesn't support it.
------------------------------------------------------------------------------------------------------------------
object ID = request-attributes
message: Deployment failed - Dynatrace API rejected HTTP request / JSON data: Failed to create DT object pix (HTTP 403)! Response was: {"error":{"code":403,"message":"Token is missing required scope. Use one of: CaptureRequestData (Capture request data)"}} (HTTP 403): {"error":{"code":403,"message":"Token is missing required scope. Use one of: CaptureRequestData (Capture request data)"}}
The documentation regarding Token creation needs to be updated, as it does not request this scope!
"If you decide to manually create a token it has to be scoped with:
Write configuration
Read configuration
Write settings
Read settings
Write SLO
Read SLO
Access problem and event feed, metrics, and topology
Create and read synthetic monitors, locations, and nodes"
