Add semantic conventions for log record ID

[svrnm]

Fixes #597

Changes

Please provide a brief description of the changes here.

• Add a section for "generic attributes" to the log semconv
• Add an attribute log_record.id making use of ULID as discussed in Decide if we need log record ID field #597

Some additional notes:

• I kept the PR small, so I left out some other potential attributes, e.g. something for pre-existing ID (like windows event logs) or for storing the used logging/eventing system or even something like a "signature" that might be worth discussing, etc.
• I followed the structure of "generic attributes" from the spans semconv
• I took some of the existing wording from Decide if we need log record ID field #597 & Define Log Data model oteps#97 (comment) to describe the field

[djaglowski]

• Add an attribute log_record.id making use of ULID as discussed in Decide if we need log record ID field #597

Should we call this log.record.id, to match the pattern used by other log attributes?

[svrnm]

• Add an attribute log_record.id making use of ULID as discussed in Decide if we need log record ID field #597

Should we call this log.record.id, to match the pattern used by other log attributes?

works for me, I just picked log_record.id to start with something but I don't have a strong opinion for/against it.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[tigrannajaryan]

• Add an attribute log_record.id making use of ULID as discussed in Decide if we need log record ID field #597

Should we call this log.record.id, to match the pattern used by other log attributes?

I agree. We already have log. as a top-level namespace, let's use it. log.record_id is another alternate. If we think we need to add anything else about the record then log.record.id is a better choice.

[svrnm]

anything missing to get this merged? TY

[jack-berg]

I still think we should define how these can be automatically added by the SDK. Opened #3277 with a suggestion on how we might do so with another built-in LogRecordProcessor. Can add in a separate PR.

[svrnm]

I still think we should define how these can be automatically added by the SDK. Opened #3277 with a suggestion on how we might do so with another built-in LogRecordProcessor. Can add in a separate PR.

Thank you.

[svrnm]

Anything missing before this can be merged? TY

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[svrnm]

/unstale

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[tigrannajaryan]

Thank you for the PR and for your patience @svrnm