wu-sheng commented on code in PR #10808: URL: https://github.com/apache/skywalking/pull/10808#discussion_r1197315852
########## docs/en/setup/backend/log-otlp.md: ########## @@ -1,4 +1,46 @@ # OpenTelemetry Logging Format -OpenTelemetry Collector supports to transport the logs to SkyWalking OAP. -Read the doc on [Skywalking Exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/skywalkingexporter) for a detailed guide. +SkyWalking can receive logs exported from OpenTelemetry collector, the data flow is: + +```mermaid +graph LR + B[OpenTelemetry SDK 1] + C[FluentBit/FluentD, etc.] + K[Other sources that OpenTelemetry supports ...] + D[OpenTelemetry Collector] + E[SkyWalking OAP Server] + B --> D + C --> D + K --> D + D -- exporter --> E +``` + +where the `exporter` can be one of the following: + +- [OpenTelemetry SkyWalking Exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/5133f4ccd69fa40d016c5b7f2198fb6ac61007b4/exporter/skywalkingexporter). + An exporter that transforms the logs to SkyWalking format before sending them to SkyWalking OAP. Read the doc in the + aforementioned link for a detailed guide. +- [OpenTelemetry OTLP Exporter](#opentelemetry-otlp-exporter). An exporter that sends the logs to SkyWalking OAP in OTLP + format, and SkyWalking OAP is responsible for transforming the data format. + +## OpenTelemetry OTLP Exporter + +By using this exporter, you can send any log data to SkyWalking OAP as long as the data is in OTLP format, no matter +where the data is generated. + +To enable this exporter, make sure the `receiver-otel` is enabled and the `otlp-logs` value is in +the `receiver-otel/default/enabledHandlers` configuration section: + +```yaml +receiver-otel: + selector: ${SW_OTEL_RECEIVER:default} + default: + enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"otlp-metrics,otlp-logs"} +``` + +Also, because most of the language SDKs of OpenTelemetry do not support logging feature (yet) or the logging feature is Review Comment: We don't have to work with OTEL SDKs/Agents anyway. Abou that OTEL, we are always only adopting as much as possible no matter where the source is from and how the format is built. There are always a group of people who would think the OTEL is somehow a standard or much more meaningful than the other formats. But from my personal perspective and experiences, there is nothing new there. The metrics format is from Prometheus, the Trace format is from Zipkin, and logs are easy generally text only. All the points of this kind of support are, we could leverage some existing integrations, which the OTEL community would do. That is the only benefit. Don't worry whether their agents are supporting or not. The lessons I learned from OT are, these APIs would have special values when they are stale(not updated anymore). Ironically, but true. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
