Generic Format for OpenTelemetry Analysis #818
Replies: 1 comment
-
OpenTelemetry is mostly concerned with the telemetry data collection. There is a concept of processors - some data processing can be done in-process on SDK side or in the OpenTelemetry collector (see processors or this FR). But this processing is typically realtime and concerned mostly with the data collection, not alerting and reporting. Quick search revealed thing like this https://github.com/jaegertracing/jaeger-analytics-java (see https://medium.com/jaegertracing/jaeger-data-analytics-with-jupyter-notebooks-b094fa7ab769) - data analysis on the trace data once it is collected. This can give you inspiration on what to analyze. Otel telemetry unification efforts will definitely make data analysis easier going forward. Instrumentation WG (#803) is discussing this unification. In any way, if you plan to work on this, you might find people interested to join your project in opentelemetry slack, and share your feedback with the instrumentation WG. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello everyone! I am not sure where exactly to ask this question but wanted to give it a try this way. Also, I am fairly new to the topic of OpenTelemetry and hope this question makes sense at all.
As far as I understand otel is an effort to standardize the complete telemetry collection process except for the analysis part. In the infosec world, there is this common exchange format for data analysis called sigma. It helps to exchange analysis methods when it comes to threat hunting and incidence response.
Now my question is if there is something similar for otel? Would it even be useful to have that? Why not?
One could exchange techniques on how to find less performant parts of the application or parts whose performance decreases over time.
Looking forward to your responses!
Beta Was this translation helpful? Give feedback.
All reactions