Design a Telemetry Interface
The telemetry interface should be a Typescript interface that should be part of the BullMQ package. In this milestone it is expected to have a complete (or almost complete as a future implementation may prove that the interface must be changed), and some pseudo code showing the feasibility of the interface for implementing observability add-ons.
The chall…
The telemetry interface should be a Typescript interface that should be part of the BullMQ package. In this milestone it is expected to have a complete (or almost complete as a future implementation may prove that the interface must be changed), and some pseudo code showing the feasibility of the interface for implementing observability add-ons.
The challenge here is that the interface must be used internally in BullMQ, for example, lets say that we enhance BullMQ Queue constructor to accept a Telemetry plugin, something like this:
import { Queue } from "bullmq";
import { Otel } from "bullmq-otel"
const queue = new Queue("test-otel", { telemetry: new Otel(…)});
So when giving a Telemetry plugin the queue will now call the interface methods when doing different operations, for example when the user calls queue.add(…), we may now need to call some method of the plugin to register that call and so on, and similarly with the Worker class in BullMQ.
Some references for inspiration are these third party implementations: https://github.com/appsignal/opentelemetry-instrumentation-bullmq and https://github.com/jenniferplusplus/opentelemetry-instrumentation-bullmq
These are based on monkey patching BullMQ, which is what we want to precisely avoid by defining this new interface.
Here some summary from ChatGPT:
To develop a Telemetry interface for BullMQ with the ability to integrate with frameworks like OpenTelemetry, it's crucial to understand some key OpenTelemetry concepts: Spans, Traces, and Context Propagation.
Key Concepts:
-
Spans:
- A span represents a unit of work or operation. Each span includes a name, start and end timestamps, attributes, and optionally events and links to other spans.
- Spans can be nested to represent parent-child relationships, forming a trace. A trace is a collection of spans that share the same
trace_id
oai_citation:1,Traces | OpenTelemetry oai_citation:2,OpenTelemetry Concepts | OpenTelemetry.
-
Traces:
- A trace tracks the progression of a single request as it moves through various components of a distributed system. It consists of multiple spans that are related to each other through parent-child relationships oai_citation:3,Traces | OpenTelemetry oai_citation:4,OpenTelemetry Concepts | OpenTelemetry.
-
Context Propagation:
- Context propagation is the mechanism by which trace and span information is passed between different parts of a system. This ensures that the spans created in different parts of the system are correlated correctly and assembled into a trace oai_citation:5,Context propagation | OpenTelemetry oai_citation:6,Context | OpenTelemetry.