Key requests filtering is not possible with bg-deploy

[BoazW]

Hi,

After we have changed our deployment to bg-deploy, the key requests that were defined in our Dynatrace environment have stopped functioning, because they depend on the service Id, which changes every deployment.

Therefore, we request that the key requests will be based on the service name instead of the Id.

Kindly assist

Thanks,
Boaz

[JamesKitson · Accepted solution]

I moved this to the Dynatrace Open Q&A because service detection is not related to or handled by extensions.

Key requests have to be associated with a single service and service names are not guaranteed to be unique, so grouping them by a service name is not an option. You may need to look at some of the service detection options that are available to find a way of ensuring that new services are not detected in such scenarios where you would prefer to keep them the same.

https://www.dynatrace.com/support/help/platform-modules/applications-and-microservices/services/serv...

[BoazW]

Hi James,

We have a service naming rule, which aggregates all the blue-green services to a single service. Hence, we were expecting that the key request feature will work, because the service name is unique. The filtering is important for us, because we need to opt-out irrelevant customer-related info.

[tim_gerlach]

Hi @JamesKitson ,

Thanks for your idea to use service naming rules.

Unfortunately, I don't think it will solve this case, because configuring a key request requires the Service ID.

Generally speaking, we believe that the only way to make "key requests" transportable (config as code) will be to allow mapping key requests to services by some filters or rules since the Service ID is not stable enough.

I'm wondering how Dynatrace attempts to approach this problem with monaco?

[thorsten_roth]

Hello,

we are currently working on a solution to remove the above-mentioned limitations.

Here in a nutshell what you can expect:

• No longer having a key request subscription approach, as endpoints will completely replace this.
• No dependency between service ID and endpoint.
• New endpoint detection rule (related to the span attributes), enables monitoring as code.
• And much much more

The goal is to provide superb out of the box experience and detection (services & endpoints) with zero or less config effort. In case modifications are needed, then this is of course doable. 

There is no final ETA yet, but we're already working on it. 

Thanks,
Thorsten