Financial-Times/dotcom-reliability-kit

Align app info properties with OpenTelemetry

Closed this issue · 1 comments

rowanmanning commented

OpenTelemetry have already done a lot of work around consolidating the different environment variables you find across different cloud platforms. We should lean on their work and group our app info properties in the same way.

What problem does this feature solve?

We align more with a well-defined standard and tidy up the slight mess that is all of app info's top-level properties. We'll also have easy answers if we want to add future properties, we just go with whatever OpenTelemetry have done.

Ideal solution

Deprecate existing properties

Firstly we should leave the existing properties in place so as not to introduce a breaking change. Instead of removing them we should use getter methods and log deprecation warnings the first time one is used. See the logger for an example of how we've done this in the past.

We should deprecate the following properties:

  • appInfo.cloudProvider
  • appInfo.commitHash
  • appInfo.processType
  • appInfo.region
  • appInfo.releaseDate
  • appInfo.releaseVersion

I don't think we should deprecate these properties:

  • appInfo.environment: This is accessed really frequently and I think it deserves a shortcut
  • appInfo.systemCode: Similarly this ensures that system code is easy to find, even if it's an alias of a newer property

Add new properties

We should add the following properties:

New property Old property Where from?
service.name systemCode SYSTEM_CODE or package.json name property
service.version releaseVersion HEROKU_RELEASE_VERSION or AWS_LAMBDA_FUNCTION_VERSION
service.instance.id - HEROKU_DYNO_ID
heroku.app.id - HEROKU_APP_ID
heroku.release.commit commitHash HEROKU_SLUG_COMMIT
heroku.release.creationTimestamp releaseDate HEROKU_RELEASE_CREATED_AT
cloud.provider cloudProvider conditionally set based on presence of env vars
cloud.region region AWS_REGION, AWS_DEFAULT_REGION, or REGION
deployment.environment environment NODE_ENV

Alternatives

We could do nothing, but we'll keep cluttering up the top level properties the more we add. We'll also have to have more conversations about naming things.

alexmuller commented

I wonder if in the future we'll end up exporting a Resource with all of our properties already set