Open cartermp opened 2 years ago
An addition to option 1) would be to ensure SDKs that manually set service.name
also set the corresponding environment variables so auto instrumentation picks them up. This would likely be an spec and subsequent SDK change.
Here's where we're at for setting service names for getting started:
Language | Sets service name? | Using Env Var so it works with agents (if/should they exist) |
---|---|---|
C++ | no | no |
.NET | yes | yes |
Erlang/Elixir | no | no |
Go | yes | no |
Java | no | no |
JavaScript | no | no |
PHP | no | no |
Python | yes | yes |
Ruby | yes | no |
Rust | no | no |
Swift | no | no |
+1 for this, we can turn this into a meta issue once again and tackle languages 1-by-1
As we know,
service.name
is a required resource attribute andservice.version
is a "this is not required but you should really set this damn thing" resource attribute too.The two major ways to set these are in code or environment variables. Each has a drawback though:
service.name
is actuallyunknown_service
for automatic instrumentation, but your manual instrumentation has the rightservice.name
.In Honeycomb docs, we've opted for the environment variable route: https://docs.honeycomb.io/getting-started/quickstart/#add-auto-instrumentation-to-your-application
The rationale is that it's better to be correct (and frankly follow some best practices)
Should this also be done for all docs here?