Open voropaevp opened 3 years ago
It seems to me that this is achievable already without a change to the tracker, by adding this information via a custom context.
I think an argument to consider on the topic is that the scala tracker is intended for use in any scala project, and this kind of feature feels specific to a particular set of deployments.
Not that I think this should be the definitive argument, I'd just like to beg the question - is there a good case for instrumenting this as a method of the tracker vs. as a custom event? (or is there a good case vice-versa?)
I hadn't realised that we already have a module which establishes something of a precedent for this kind of feature: https://github.com/snowplow/snowplow-scala-tracker/tree/master/modules/metadata/src/main/scala/com/snowplowanalytics/snowplow/scalatracker/metadata
I think as long as we gracefully/sensibly handle the case where a method like this is called in some other environment (which doesn't support these things), there's no harm in adding to it. (and I presume the existing design does so)
Would the AWS module handle Kafka or EKS deployments?
I would imagine that we'd need to write something to accommodate Kafka and possibly EKS. Whether that's adapting the existing code or adding new code, I don't know - that surely depends on the detail.
All I'm suggesting is that the most obvious way to extend this feature is to do so using the existing module.
There is no way to include the cloud platform-dependent information into the emitted events.
The suggestion is to add the helper methods for the
Subject
includeCloudRegion( ): Subject
- injecting the"region" : string
includeCloudPlatform( ): Subject
- injecting the"region" : enum [ 'gcp', 'aws', null ]
This could be achieved by querying cloud URLs:
This functionality will be used by: https://github.com/snowplow/stream-collector/issues/167 And in other snowplow components, that will use telemetry.