Dynatrace / libbuildpack-dynatrace

Common resources used for Dynatrace integration in Cloudfoundry Buildpacks.
Apache License 2.0
1 stars 5 forks source link

Integration issues due to hard-coded "service.Name" and customizable credential params across different Oneagent integrations #13

Closed naveenbm closed 4 years ago

naveenbm commented 4 years ago

We are noticing a couple of issues when trying to get Dynatrace Oneagent working for non-java buildpacks

Some background - We have a common APM service broker which handles service creation for different APM tools (Dynatrace-AppMon, Dynatrace-Oneagent, AppD, etc) and sets the right VCAP variables based on the configurations.

  1. The service name within https://github.com/Dynatrace/libbuildpack-dynatrace/blob/master/hook.go#L198 is hardcoded to 'dynatrace' leading to integration issues in our environment.

To distinguish the two variants of the Dynatrace service - we use different names (oneagent is used as service.Name for Dynatrace_Oneagent). This hardcoding in the libbuildpack-dynatrace causes DT oneagent support to fail out of the box.

  1. Ability to support custom params for credentials. Currently the environmentID and other params are fixed and the credentials file is expected to support them in a pre-determined format (Lines 211-215 in https://github.com/Dynatrace/libbuildpack-dynatrace/blob/master/hook.go#L211). Given the custom broker, it would be good if this can be extended to support custom variables names, rather than a fixed format. This will allow for supportig a common variable name to support differences in DT library support for different buildpacks.

Please let me know if any other details are needed.

arthfl commented 4 years ago

Hi!

What's the exact problem you're trying to solve?

Because this library is meant for us (Dynatrace) to be used in go-based buildpacks to avoid a lot of code-duplication there. It kinds sounds like you're trying to use it to build a service broker with it.

Regarding item 1: The service name we look for is not hardcoded to be exactly dynatrace, we just look for a service that has dynatrace in the name: https://github.com/Dynatrace/libbuildpack-dynatrace/blob/master/hook.go#L198 This is also a requirement we mention in our official documentation: https://www.dynatrace.com/support/help/technology-support/cloud-platforms/cloud-foundry/installation-and-operation/application-only/deploy-oneagent-on-pivotal-web-services-for-application-only-monitoring/#expand-1354option-1-create-a-user-provided-service

We will definitly not change that, because we have to match for something.

Regarding item 2: I'm not sure i fully understood the problem here. Do you want the property names for the credentials to be customizable? If yes, how would we then find what we need to configure our agent?

Maybe a short explanation of how our buildpack integrations roughly work helps a bit here:

arthfl commented 4 years ago

@naveenbm Any updates from your side on this issue?

arthfl commented 4 years ago

Closing this, since there wasn't any feedback on this anymore.