Skip to content
This repository has been archived by the owner on Oct 3, 2023. It is now read-only.

attributes: distinguish multiple agent exporters sharing the same PID #11

Open
odeke-em opened this issue Sep 14, 2018 · 3 comments
Open

Comments

@odeke-em
Copy link
Contributor

If a user decides to make more than one exporter in the same process, we need to distinguish such scenarios by updating their identifier. This could happen as a bug but legitimately say if they made a proxy with a Go process as the frontend and then forked/exec'd process in the back. We should still be able to distinguish between these process and send unique information about each exporter.

Perhaps an atomic incrementer per-instance that will be sent in the attributes.

@odeke-em
Copy link
Contributor Author

@songy23 I think this issue might affect every language and now wondering if we should promote this to the specs?

@songy23
Copy link
Contributor

songy23 commented Sep 14, 2018

Agree that this scenario is legitimate and I believe that's why we have the attributes map in the Node. Are you suggesting we should have some pre-defined attributes that specifically serve this purpose?

I think this issue might affect every language and now wondering if we should promote this to the specs?

That makes sense - feel free to open an issue in the proto repo. We can then decide whether we need a new message to handle that, or using the current attributes map is enough.

@odeke-em
Copy link
Contributor Author

Agree that this scenario is legitimate and I believe that's why we have the attributes map in the Node. Are you suggesting we should have some pre-defined attributes that specifically serve this purpose?

Yes, in deed that's why we have the attributes map. The problem then is that every implementation has to use the exact same key. At that point I believe we'd just rather make this a field in the Node identifier and ask language implementors just increment it.

That makes sense - feel free to open an issue in the proto repo. We can then decide whether we need a new message to handle that, or using the current attributes map is enough.

In deed :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants