Skip to content

flaviomoringa/datadog_buildpack

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

64 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Datadog Decorator

Work in progress.

Yep! I lied this is not a full fledged buildpack but a decorator.

This is a Cloud Foundry decorator, unlike a "real" buildpack, a decorator doesn't produce a droplet from source. Instead, it "decorates" (hence the name) an already produced droplet to implement some kind of add-on feature.

This decorator injects Datadog environment variables inside the droplet.

For more information on the available environment variables:

https://docs.datadoghq.com/tracing/setup_overview/setup/java/?tab=otherenvironments#configuration

Deploying

cf push -f manifest-alpha.yml \ 
  -b https://github.com/flaviomoringa/datadog_buildpack.git  \
  -b datadog_application_monitoring \
  -b java_buildpack

How it works

There's three sources for Datadog environment variables:

  1. The manifest file
  2. A user provided service tagged with "datadog"
  3. The buildpack's defaults

Except for special cases, they're applied in that order, meaning that the manifest file can override the service values and defaults are only used as last resource.

In general, however, is cleaner to keep all Datadog configurations in the user provided service to avoid cluttering the manifest with too manyy variables and to keep everything related to Datadog in the same place.

Special cases

The DD_API_KEY can't be set in the manifest and must be in the service.

JAVA_OPTS must be set in the manifest. If it does not include a Datadog agent (named dd-java-agent-[0-9.]*.jar) as a javagent and some is found in the filesystem, that one is added to JAVA_OPTS.

DD_TAGS defined in the Datadog service are merged with the defaults, the former overriding the latter on key conflicts. However, defining DD_TAGS in the manifest allows to override it as a whole, meaning no values from the service or defaults are considered.

DD_VERSION can be explicitly set in the manifest or otherwise can be infered from the Implementation-Version key in META-INF/MANIFEST.MF, if present.

How to use it

Create a service

Create a PCF user provided service containing the relevant variables, eg:

cf cups appx-datadog -t "datadog" -p '{"DD_API_KEY":"53cr37"}'

The important here is adding the tag "datadog" to the service, you then can edit the content of the service in the AppsManager of PCF, if you are more visually inclined.

Update the manifest

The manifest must include the datadog service and the buildpacks in this order:

applications:
  - name: appx
    buildpacks:
      - dh_io_datadog
      - datadog_application_monitoring
      - java_buildpack
    ...
    services:
      - appx-datadog
      - ...

Since the dh_io_datadog buildpack is not published inside PCF buildpack manager you can replace it with the repository url: https://github.com/lmmendes/datadog_buildpack.git

Default env values

The decorator will expose the following variables

Variable Default Observation
DD_API_KEY None Needs to be declared inside the User Defined Service from PCF
DD_ENV Inferred from the PCF space
DD_SERVICE Application name inferred from PCF app name
DD_SITE datadoghq.eu
RUN_AGENT true
DD_APM_ENABLED true
DD_LOGS_ENABLED true
DD_LOGS_INJECTION true
DD_TRACE_ANALYTICS_ENABLED true
DD_ENABLE_CHECKS false
STD_LOG_COLLECTION_PORT 10514
DD_PROPAGATION_STYLE_INJECT Datadog,B3
LOGS_CONFIG type: tcp, port: STD_LOG_COLLECTION_PORT, source: pcf, service: DD_SERVICE
DD_TAGS service: inferred from pcf app name , tenant: inferred from pcf organization name , version: retrived from the

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published