Breaking Changes To Extensions - Mass Configuration Re-creation

[mmevanson]

Greetings Community,
We are looking to upgrade our extensions, as we normally do, but this time there is a big warning about

⚠️WARNING⚠️: Possible breaking changes and warnings - PLEASE READ before upgrading:

Some of us have multiple hundreds, perhaps thousands, of configurations to have to "recreate" to adopt.
What is Dynatrace's best practice to achieve this without having to manually recreate each configuration?
There HAS to be a mass update procedure that Dynatrace provides to the customer for situations where there are large scale configuration re-creations needing to be done.   Not to mention, I believe will will then lose all historical information linked to the previous configuration.  I understand Dynatrace's urge and the benefits of getting to Grail based extensions.  But you can't just forklift over a bunch of manual work to your customers.  Please assist us by providing scripts and DQL checks to support methodologies for this transformation.   Not just say the customers need to adapt and manually recreate a lot of previous work.

⚠️WARNING⚠️: Possible breaking changes and warnings - PLEASE READ before upgrading:

• This version requires a minimum Dynatrace version of 1.338.0 and a minimum EEC version of 1.337.0.
• This version includes a breaking change for Dynatrace on Grail.
  • With the inclusion of OpenPipeline processing rules, any metrics ingested from the extension will be processed by a dedicated OpenPipeline pipeline.
  • This means that any dynamic route configured to process any metrics from the extension will be dropped in favor of the dedicated pipeline. Please, refer to pipeline groups to continue using dynamic routes.
  • With the inclusion of OpenPipeline processing rules, any logs ingested from the extension will be processed by a dedicated OpenPipeline pipeline instead of the classic log pipeline.
  • This means that classic rules will no longer be used on logs ingested from the extension. Please be sure to migrate any you still need to OpenPipeline rules.
  • Additionally, some field names are handled differently in OpenPipeline, e.g. capitalization. Please double-check any custom dashboards and alerts you have created for this extension.
  • You must opt-in to OpenPipeline configuration via Settings API – see the documentation.
• Feature sets have been refactored, with new feature sets added and some other ones removed, meaning that in most cases,
  Spoiler

  you will need to re-create monitoring configurations when updating to this version, as well as check properly all the new feature sets to ensure you're enabling the same insights as before
  .
• SQL Agent removed from Classic Topology.
• Log entries captured from the agent_requests and application_requests event groups have been removed in favor of the generic all_requests event group. Please use the program_name attribute to correctly filter for agent or application requests.

[AntonioSousa]

@mmevanson ,

Could you please clarify what extension(s) are you referring to? I suppose you are referring to the upgrade to SQL Server extension version 3.1.2, but could you please confirm?

[mmevanson]

Correct - this one is the SQL Server 3.1.2, but there a large amount of our extensions also citing re-creation of configurations.   Like IBM MQ, or IBMi.   

[Mike_L]

I’ve forwarded this thread to the product manager of the extension framework. It is the framework that “decides” when a monitoring configuration can be upgraded vs when it needs to be recreated.

Thinking outside of the box, an LLM together with dtctl could most likely recreate the configurations for you. The main challenge would be passwords as they don’t get exposed by the API, but if you use the credential vault it should work.

[AntonioSousa]

@Mike_L ,

I have a client that has almost 4K databases.

I don't want to think out of the box... And I won't say more!