-
Notifications
You must be signed in to change notification settings - Fork 887
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Event is one of the major verticals as well as Metrics, Tracing and Logging in observability from my perspective #176
Comments
Agree with that Events is import too. SaaS, like And also, I'm prefer to add events to span object as property. Here is an example in real word. I'm measuring the container startup time in K8s, one component is kubelet, the work node agent in K8s. The container startup process in one work node including pull image, create container and run the container, but we need not make all this step as separated spans, we can make it as one span including some events:
|
To me, an Event is just a special case of a Trace, with 1 span. |
Yeah. It is one way to look at it. There are a few differences between Span(trace) and Event in my opinion.
|
Alternatively, could we treat events as special logs with a known structure? |
Yes, We could. At the same time, We can treat Logs as Spans(Trace) too. |
Bumping this up since it was referenced from #67. What are Events if not just Logs?
Structured logs have been a thing for a long while. There is an RFC that defines how structured logs should be represented in text files [1] and AFAIK many modern logging backends support this format, in addition to other ways to ingest structured logs (e.g. as JSON). On Windows the system and application logs are even called just that: Event Logs [2] and are structured. So, the question is how are Events different from Logs? In what way? [1] https://tools.ietf.org/html/rfc5424#page-15 |
Yes, Events are Logs. |
I feel that Logs are a special class of events, where the payload is just {time: "yyyy-mm-dd hh:mm:ss +Z", data: "entire log line goes here"} |
Call it "structured logging" then, where structured attributes can be associated. Whether you want to call it events or logs, there isn't a reason to think of them separately.
All in logs. |
The way I see it, metrics track events (and other things), while traces and logs describe events. It's events all the way down. I think it would be beneficial in making that relationship clear in the documentation. |
I think this issue is not actionable as-is. Can it be closed? |
I vote for closing for reasons I outlined above. |
Closing this issue as it is non actionable and because there are existing reasons to do so. In any case, feel free to re-open (or open a new issue) if you think this still needs to be addressed in some form. |
It's 2022 - New Relic and Datadog (arguably two of the most dominant APM players) have well defined and separate APIs and documentation for events. To those that say events are logs, logs are unstructured and events are structured. https://docs.newrelic.com/docs/data-apis/understand-data/new-relic-data-types/#event-data |
@scheler Thanks. Is there an exporter of events (as events, not logs) into Datadog or New Relic APMs? |
Speaking for New Relic, we accept OpenTelemetry data via OTLP. From OTLP's perspective, both logs and events use the log data model, and that's fine with us. We're currently working on a strategy that would treat OpenTelemetry events in a similar way as New Relic events are treated today. Can't provide specifics quite yet. |
Opentelemetry logs (or the thing it calls logs) are in fact structured. |
As we stated:
In software, observability typically refers to telemetry produced by services and is divided into three major verticals:
These verticals are tightly interconnected. Metrics can be used to pinpoint, for example, a subset of misbehaving traces. Logs associated with those traces could help to find the root cause of this behavior. And then new metrics can be configured, based on this discovery, to catch this issue earlier next time.
I think we should consider Events as one of the major verticals in open-telemetry too.
Such as machine reboot, process core dump, deployment, a system kernel error, and even Java Exceptions.
Products like sentry and cloudtrail.
https://en.wikipedia.org/wiki/Event_monitoring
The text was updated successfully, but these errors were encountered: