Is your feature request related to a problem? Please describe.
Environments & Services are coming to Honeycomb. The beeline should be updated to support sending data to environments while maintaining backward compatibility. To achieve this, we will set dataset from service name, and provide appropriate warnings depending on environment vs. non-environment teams.
Describe the solution you'd like
Tracing scenario for environment-aware teams:
Dataset should no longer propagate across services for new environment key.
ServiceName "required"†. If unset, will warn and set service_name AND service.name to unknown_service:<process> or unknown_service:language. Service name is used to populate dataset name; if unknown_service.* then truncate tounknown_service for dataset name. service.name field will be added to the already added service_name for closer consistency with OTel.
WriteKey required. If unset, will warn.
Datasetignored. If unset, no warning (because no longer used). If set, will warn to clarify that it will be ignored in favor of service name.
Tracing scenario for legacy (non-environment-aware) teams:
ServiceName "required"†. If unset, will warn.
WriteKey required. If unset, will warn.
Dataset required. If unset, will warn and default to beeline-<language>.
† While not technically required, service name is highly encouraged to avoid unknown_service and to instead properly describe the data being sent to Honeycomb (and the data being viewed in Honeycomb UI).
Notes from decision around defaulting when no service name is provided:
Given a beeline configured with a v2 api key and without a service name
When it sends HNY events
Then it should use unknown_service as the dataset
And it should use unknown_service:process-name as service_name
When given a legacy key, the behavior remains the same as today.
Is your feature request related to a problem? Please describe.
Environments & Services are coming to Honeycomb. The beeline should be updated to support sending data to environments while maintaining backward compatibility. To achieve this, we will set dataset from service name, and provide appropriate warnings depending on environment vs. non-environment teams.
Describe the solution you'd like
Tracing scenario for environment-aware teams:
ServiceName"required"†. If unset, will warn and setservice_nameANDservice.nametounknown_service:<process>orunknown_service:language. Service name is used to populate dataset name; ifunknown_service.*then truncate tounknown_servicefor dataset name.service.namefield will be added to the already addedservice_namefor closer consistency with OTel.WriteKeyrequired. If unset, will warn.Datasetignored. If unset, no warning (because no longer used). If set, will warn to clarify that it will be ignored in favor of service name.Tracing scenario for legacy (non-environment-aware) teams:
ServiceName"required"†. If unset, will warn.WriteKeyrequired. If unset, will warn.Datasetrequired. If unset, will warn and default tobeeline-<language>.† While not technically required, service name is highly encouraged to avoid
unknown_serviceand to instead properly describe the data being sent to Honeycomb (and the data being viewed in Honeycomb UI).This will be addressed in a separate issue/PR: Set spanKind value based on OTel spec for consistency across beelines and OTel.
Notes from decision around defaulting when no service name is provided:
Given a beeline configured with a v2 api key and without a service name When it sends HNY events Then it should use
unknown_serviceas the dataset And it should useunknown_service:process-nameas service_nameWhen given a legacy key, the behavior remains the same as today.
Notes on trimming whitespace