community
community copied to clipboard
open-telemetry
Lua SIG: current level of interest?
Hello OTel community. This issue is to gauge interest in maintaining a Lua implementation.
Since newcomers may be reading this issue, here's brief overview of the components that an OpenTelemetry client is composed of:
- API: the public interfaces used by developers to instrument their code. At runtime, the API can be bound to an implementation. By default, the API provides a no-op implementation. The SDK and a mock/test implementation are the two other common implementations.
- SDK: a official implementation, which follows the SDK spec. The SDK is a framework which consists of plugin interfaces for Exporters, SpanProcessors, etc.
- SDK Plugins: official implementations of common plugins, such as Zipkin, Prometheus, and OTLP exporters.
- Instrumentation Libraries: packages which use the API to provide instrumentation for HTTP clients, databases, web frameworks, and other common libraries.
- Semantic Conventions: Constants and helpers which ensure that instrumentation libraries produce consistent data across different languages.
All of the nitty-gritty details can be found in the OpenTelemetry Specification.
At minimum, this group would need to do the following:
- Define the OpenTelemetry API and Semantic Conventions in Lua, following the spec.
- Define an installation mechanism for the OpenTelemetry SDK, plugins, and instrumentation libraries
- In some languages we try to automate installation, but that is not a requirement.
- Help the community maintain instrumentation for common Lua libraries.
The group would also need to pick one of two approaches to maintaining an SDK implementation:
- Maintain an SDK and the required SDK plugins in Lua.
- Build a bridge to another SDK implementation, such as C++.
The bridge approach may be attractive, as maintaining a production ready SDK represents a lot of work. But I'm not a Lua expert and I don't know what kinds of disadvantages this comes with.
If anyone has interest in contributing to this effort, please introduce yourself! Questions are welcome.
A quick google search turned up at least one implementation: https://github.com/yangxikun/opentelemetry-lua
👋 I work on the Ruby SDK and also have been contributing to @yangxikun's opentelemetry-lua repo, linked above. yangxikun/opentelemetry orients itself towards the OpenResty runtime. I've done a bit of work to make it more agnostic to other Lua contexts, but there's likely more work to do.
I'm not sure if @yangxikun is interested in making the library fully OpenTelemetry spec compliant, but maybe @yangxikun will reply to this thread with more details.
@codeboten to your point about building a bridge vs. SDK, It's possible @rnburn might have some lessons from implementing a bridge in OpenTracing, so I've tagged @rnburn here. I'm no Lua expert, so would love to have someone with deeper expertise comment on the issue.
Regardless of what route makes sense, I'm interested in helping contribute towards an officially supported OpenTelemetry Lua library, whether it ends up being yangxikun/opentelemetry or a new repo. I'm going to keep working in yangxikun/opentelemetry, but will keep an eye on this issue.
Hello, I'm glad to contribute opentelemetry-lua to open-telemetry community. In my opinion, implement in pure Lua is easy to develop/debug/maintain and maybe more simply to use in different runtime not only openresty.
The opentelemetry-lua has implemented the tracing spec, and used in https://github.com/apache/apisix/issues/3891. Generally people don't use Lua to implement complex business logic, so Metrics and Logs are not consider to implement yet.
But I also not a Lua expert, I'm glad to see someone with deeper expertise comment on the issue.
Upon reflection, the spec's clear API/SDK separation should make it easy for us to publish a compliant API and allow the community to implement/use both 1. pure Lua implementation and 2. a C++ bridge-like implementation (or 3. something else!). Writing a spec-adherent API won't be wasted work.
Following. I have a gateway that uses Lua for scripting and I'm interested in it starting a distributed trace if not already in the caller's context
