[chore] Create an event registry #2382

[thompson-tomo]

Progresses #2382

Changes

This introduces an event registry to reside alongside the attributes registry and the soon to be released entities registry. This provides pure code generated documentation for events which reduces maintenance effort and makes things more discoverable.

Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[jsuereth]

Why are entities in the event namespace?

[thompson-tomo]

I was hoping to get this index page to show all the signal types grouped by type but was stuck on the filter hence my other comment (#2464 (comment)). That way a user could go to the rpc index page and see all attributes, events, log records, metrics & spans.

[thompson-tomo]

Will need to eventually find a way to get rid of the startsWith

[thompson-tomo]

Would be great to see this as a table with a count of items per signal type which is linked to the section especially if we combine based on namespace.

[jsuereth]

A few thoughts on this:

• Can you comment on why each event is its own markdown file? I think this is likely the right way forward but want to be explicit as we move forward on signals. It is not what we did for Entity.
• Can you add a link to the Event registry from the registry/README.md file?
• Can you modify this to pull in every event without using startswith. I think you had at one time split logrecord vs. event. We do not want that distinction going forward, so this should just grab all group.type=event.

[thompson-tomo]

Thanks for the feedback @jsuereth

Can you comment on why each event is its own markdown file? I think this is likely the right way forward but want to be explicit as we move forward on signals. It is not what we did for Entity.

Reason for 1 page per signal definition is so that we could have a namespace index page which would hopefully list everything in that namespace be it events, log records, metrics, spans etc. If we have 1 page it quickly grows out of hand and this approach is inline with the proposal to update the metric layout.

Can you add a link to the Event registry from the registry/README.md file?

Yes can do

Can you modify this to pull in every event without using startswith. I think you had at one time split logrecord vs. event. We do not want that distinction going forward, so this should just grab all group.type=event.

If possible I would get rid of the starts with altogether and just do filtering on the last mapping and is what is required for the general namespace page.

[thompson-tomo]

@jsuereth Following on from the semconv meeting, I will do the following:

• Raise a seperate pr to introduce the namespace index page as seen here so it can be used for entities.
• Add entities to the namespace index page & dedicated pages
• Allow this PR to focus on adding events to the registry
• Work through existing event pages inspecting what has been migrated