First cut at Entity SDK specification.
Adds the initial Entity SDK specification, from OTEP#264
Changes
Adds an Entity SDK with the following components:
EntityEntityDetectorEntityProvider
Does NOT address the following:
- Storing
EntitywithinResourcefor generating correct OTLP. - Interaction between existing
Resourcemechanisms of SDK andEntityProvider - Stateful behavior for
Entity,ResourceandEntityProvideras described in OTEP#4316
Prototypes
Working on the JS prototype today. We don't have the EntityProvider but everything else is basically there.
This PR was marked stale due to lack of activity. It will be closed in 7 days.
@jsuereth glad to see this landing!
A couple of things:
I believe that the Java SIG already has something unrelated to this called a ResourceProvider, which is why we're going with EntityProvider.
But also, it would be helpful to use the term Entity to define the new objects and APIs that we are adding, and reserve the term Resource for existing objects that are getting extended. It's not totally clear to me in the PR what is new vs what is getting extended, and I think that naming convention could help. Either way, it would be good to clarify this.
One other point: The EntityProvider OTEP still hasn't been merged. It keeps getting closed automatically because there is no further work to do on it. If we are satisfied with that design, please merge the OTEP before merging the spec changes defined in that OTEP. 🙏
@tedsuo Regarding ResourceProvider vs. EntityProvider - The name ResourceProvider was given back by Java SIG, as per comments from @jack-berg, so that's not an issue.
The issue of discovery and confusion is real and present in my prototype, so that's worth evaluating.
This PR is still DRAFT. It's an update of OTEP 256 (merged/approved) but as we made specification we became increasingly certain this needs to be an API. What we need for OTEP 256 is somewhere between your OTEP and the original, i.e. your OTEP expands scope a bit more than we need, but also we should address concerns.
As discussed in the specification meeting today, I think this is the path forward:
- [x] Agree that we need an API for reporting entities against resource.
- [ ] Sort out the "CRUD" operations that would be within this API. This should be informed by SDK API.
- [ ] Sort out how changes to resource affect active SDK. (This, e.g. is the update API in your OTEP which I pushed as out-of-scope for this initial PR).
- [ ] Sort out "Resource Detection" and ensuring startup has a complete resource for telemetry sent early in an application/service/process.
I think each of these points should be discussed and sorted out. I'm planning to write up issues to discuss / design them, let me know if there are other major concerns you think we need to address here.
This PR was marked stale due to lack of activity. It will be closed in 7 days.
Closed as inactive. Feel free to reopen if this PR is still being worked on.
This PR was marked stale due to lack of activity. It will be closed in 7 days.
Closed as inactive. Feel free to reopen if this PR is still being worked on.