Events and Logs API #202
Events and Logs API #202
Conversation
|
Related issue, which could allow for having a common EventsApi for using Logs or Traces, if the Attributes definition is expanded to match the protocol. open-telemetry/opentelemetry-specification#2581 |
|
As logs approvers, I would like more opinions: |
|
All, Log SIG has been discussing this initiative for the last few weeks. If you want to talk about this live please join the Log SIG meeting today. |
|
All, we had an extensive discussion of this OTEP in Log SIG. There is one major blocker which prevents us from moving forward: whether there needs to be a single Logs/Events API or 2 separate APIs. I started a document to compare the 2 approaches (separate vs one API) side-by-side: https://docs.google.com/document/d/1Uy5L3UThFyc4PelgH51G3OCLFbvzq2xWiNDy2G8iXxU/edit# We agreed in the Log SIG we are going to make the choice by the next Log SIG (next Wed). If you have any opinion on this topic please add arguments in favour of the one of the approach to the document. |
There was a problem hiding this comment.
The OTEP no longer contains the details that describe the API precisely and only contains the general description of the intent to add one.
I think this is fine, we do allow OTEPs which are an "intent", with a purpose to seek alignment in Otel community.
I agree with the intent and that's why I am approving the OTEP. The details of the Logs and Events API can be either a follow-up OTEP or direct PRs to the spec repo.
tigrannajaryan
requested review from
weyert,
tsloughter,
dyladan,
yurishkuro,
martinkuba,
reyang and
pmm-sumo
|
@open-telemetry/specs-logs-approvers please review. |
|
@open-telemetry/specs-approvers please review. |
I think we should clarify what is meant to be in an OTEP and how far it is acceptable to diverge from the OTEP when writing spec. The specification parts of this OTEP were removed because of concerns that it was too prescriptive and didn't leave room for the spec to make any decisions if something came up in a language SIG which required a change. If we're just going to add those things back in a follow-up OTEP, then maybe they should be added back to this one (with my apologies to @scheler and others who removed those at least partially due to my comments)? |
Normally some refinement happens when writing the spec. This is expected.
I think this OTEP in its current form is essentially an alignment document, which seeks agreement to add the Events and Logs API. It does not define the API itself and that's fine. We can define the API by working directly on the spec repo (like we did in the past for Traces). |
|
@open-telemetry/specs-approvers @open-telemetry/specs-trace-approvers @open-telemetry/specs-logs-approvers @open-telemetry/specs-metrics-approvers We have enough approvals to merge. I am going to let this open for a couple more days, but unless I see objections I am going to merge this OTEP and proceed to defining/adding the new Events and Logs API to Otel specification. |
|
No new comments, no objections for the last 5 days. Merging. |
We introduce an Events and Logs API that is based on the OpenTelemetry Log signal, backed by LogRecord data model and LogEmitter SDK. This is meant to be used by end-users for creating Events and by the Log Appender authors to create Logs.
We introduce an Events and Logs API that is based on the OpenTelemetry Log signal, backed by LogRecord data model and LogEmitter SDK. This is meant to be used by end-users for creating Events and by the Log Appender authors to create Logs.
We introduce an Events and Logs API that is based on the OpenTelemetry Log signal, backed by LogRecord data model and LogEmitter SDK. This is meant to be used by end-users for creating Events and by the Log Appender authors to create Logs.
We introduce an Events and Logs API that is based on the OpenTelemetry Log signal, backed by LogRecord data model and LogEmitter SDK. This is meant to be used by end-users for creating Events and by the Log Appender authors to create Logs.
We introduce an Events and Logs API that is based on the OpenTelemetry Log signal, backed by LogRecord data model and LogEmitter SDK. This is meant to be used by end-users for creating Events and by the Log Appender authors to create Logs.
We introduce an Events and Logs API that is based on the OpenTelemetry Log signal, backed by LogRecord data model and LogEmitter SDK. This is meant to be used by end-users for creating Events and by the Log Appender authors to create Logs.
We introduce an Events and Logs API that is based on the OpenTelemetry Log signal, backed by LogRecord data model and LogEmitter SDK. This is meant to be used by end-users for creating Events and by the Log Appender authors to create Logs.