5 Commits

Author	SHA1	Message	Date
Miroslav Zagorac	bab0ea7b77	MEDIUM: otel: implemented scope execution and span management ... Implemented the scope execution engine that creates OTel spans, evaluates sample expressions to collect telemetry data, and manages span lifecycle during request and response processing. The scope runner flt_otel_scope_run() was expanded from a stub into a complete implementation that evaluates ACL conditions on the scope, extracts span contexts from HTTP headers when configured, iterates over the scope's span definitions calling flt_otel_scope_run_span() for each, marks and finishes completed spans, and cleans up unused runtime resources. The span runner flt_otel_scope_run_span() creates OTel spans via the tracer with optional parent references (from other spans or extracted contexts), collects telemetry by calling flt_otel_sample_add() for each configured attribute, event, baggage and status entry, then applies the collected data to the span (attributes, events with their own key-value arrays, baggage items, and status code with description) and injects the span context into HTTP headers when configured. The sample evaluation layer converts HAProxy sample expressions into OTel telemetry data. flt_otel_sample_add() evaluates each sample expression against the stream, converts the result via flt_otel_sample_to_value() which preserves native types (booleans as OTELC_VALUE_BOOL, integers as OTELC_VALUE_INT64, all others as strings), and routes the key-value pair to the appropriate collector based on the sample type (attribute, event, baggage, or status). The key-value arrays grow dynamically using the FLT_OTEL_ATTR_INIT_SIZE and FLT_OTEL_ATTR_INC_SIZE constants. Span finishing is handled in two phases: flt_otel_scope_finish_mark() marks spans and contexts for completion using exact name matching or wildcards ("*" for all, "*req*" for request-direction, "*res*" for response-direction), and flt_otel_scope_finish_marked() ends all marked spans with a common monotonic timestamp and destroys their contexts.	2026-04-13 09:23:26 +02:00
Miroslav Zagorac	2e962a5443	MEDIUM: otel: implemented filter callbacks and event dispatcher ... Replaced the stub filter callbacks with full implementations that dispatch OTel events through the scope execution engine, and added the supporting debug, error handling and utility infrastructure. The filter lifecycle callbacks (init, deinit, init_per_thread) now initialize the OpenTelemetry C wrapper library, create the tracer from the instrumentation configuration file, enable HTX stream filtering, and clean up the configuration and memory pools on shutdown. The stream callbacks (attach, stream_start, stream_set_backend, stream_stop, detach, check_timeouts) create the per-stream runtime context on attach with rate-limit based sampling, fire the corresponding OTel events (on-stream-start, on-backend-set, on-stream-stop), manage the idle timeout timer with reschedule logic in detach, and free the runtime context in check_timeouts. The attach callback also registers the required pre and post channel analyzers from the instrumentation configuration. The channel callbacks (start_analyze, pre_analyze, post_analyze, end_analyze) register per-channel analyzers, map analyzer bits to event indices via flt_otel_get_event(), and dispatch the matching events. The end_analyze callback also fires the on-server-unavailable event when response analyzers were configured but never executed. The HTTP callbacks (http_headers, http_end, http_reply, and the debug-only http_payload and http_reset) dispatch their respective request/response events based on the channel direction. The event dispatcher flt_otel_event_run() in event.c iterates over all scopes matching a given event index and calls flt_otel_scope_run() for each, sharing a common monotonic and wall-clock timestamp across all spans within a single event. Error handling is centralized in flt_otel_return_int() and flt_otel_return_void(), which implement the hard-error/soft-error policy: hard errors disable the filter for the stream, soft errors are silently cleared. The new debug.h header provides conditional debug macros (FLT_OTEL_DBG_ARGS, FLT_OTEL_DBG_BUF) and the FLT_OTEL_LOG macro for structured logging through the instrumentation's log server list. The utility layer gained debug-only label functions for channel direction, proxy mode, stream position, filter type, and analyzer bit name lookups.	2026-04-13 09:23:26 +02:00
Miroslav Zagorac	f05a6735b1	MEDIUM: otel: added memory pool and runtime scope layer ... Added the memory pool management and the runtime scope layer that track per-stream OTel spans and contexts during request processing. The pool layer in pool.c manages HAProxy memory pools for the runtime structures used by the filter: scope spans, scope contexts, runtime contexts, and span contexts. Each pool is conditionally compiled via USE_POOL_OTEL_* macros defined in config.h and registered with REGISTER_POOL(). The allocation functions (flt_otel_pool_alloc, flt_otel_pool_strndup, flt_otel_pool_free) transparently fall back to heap allocation when the corresponding pool is not enabled. Trash buffer helpers (flt_otel_trash_alloc, flt_otel_trash_free) provide scratch space using either HAProxy's trash chunk pool or direct heap allocation. The scope layer in scope.c implements the per-stream runtime state. The flt_otel_runtime_context structure is allocated when a stream starts and holds the stream and filter references, hard-error/disabled/logging flags copied from the instrumentation configuration, idle timeout state, a generated UUID, and lists of active scope spans and extracted scope contexts. Scope spans (flt_otel_scope_span) carry the operation name, fetch direction, the OTel span handle, and optional parent references resolved from other spans or extracted contexts. Scope contexts (flt_otel_scope_context) hold an extracted span context obtained from a carrier text map via the tracer. The scope data structures (flt_otel_scope_data) aggregate growable key-value arrays for attributes and baggage, a linked list of named events with their own attribute arrays, and a span status code with description, representing the telemetry collected during a single event execution.	2026-04-13 09:23:26 +02:00
Miroslav Zagorac	8126fd569b	MEDIUM: otel: added configuration and utility layer ... Added the configuration structures that model the OTel filter's instrumentation hierarchy and the utility functions that support the configuration parser. The configuration is organized as a tree rooted at flt_otel_conf, which holds the proxy reference, filter identity, and lists of groups and scopes. Below it, flt_otel_conf_instr carries the instrumentation settings: tracer handle, rate limiting, hard-error mode, logging state, channel analyzers, and placeholder references to groups and scopes. Groups (flt_otel_conf_group) aggregate scopes by name. Scopes (flt_otel_conf_scope) bind an event to its ACL condition, span context declarations, span definitions and a list of spans scheduled for finishing. Spans (flt_otel_conf_span) carry attributes, events, baggages and status entries, each represented as flt_otel_conf_sample structures that pair a key with concatenated sample-expression arguments. All configuration types share a common header macro (FLT_OTEL_CONF_HDR) that embeds an identifier string, its length, a configuration line number, and a list link. Their init and free functions are generated by the FLT_OTEL_CONF_FUNC_INIT and FLT_OTEL_CONF_FUNC_FREE macros in conf_funcs.h, with per-type custom initialization and cleanup bodies. The utility layer in util.c provides argument counting and concatenation for the configuration parser, sample data to string conversion covering boolean, integer, IPv4, IPv6, string and HTTP method types, and debug helpers for dumping argument arrays and linked list state.	2026-04-13 09:23:26 +02:00
Miroslav Zagorac	cd14abf9f3	MEDIUM: otel: added OpenTelemetry filter skeleton ... The OpenTelemetry (OTel) filter enables distributed tracing of requests across service boundaries, export of metrics such as request rates, latencies and error counts, and structured logging tied to trace context, giving operators a unified view of HAProxy traffic through any OpenTelemetry-compatible backend. The OTel filter is implemented using the standard HAProxy stream filter API. Stream filters attach to proxies and intercept traffic at each stage of processing: they receive callbacks on stream creation and destruction, channel analyzer events, HTTP header and payload processing, and TCP data forwarding. This allows the filter to collect telemetry data at every stage of the request/response lifecycle without modifying the core proxy logic. This commit added the minimum set of files required for the filter to compile: the addon Makefile with pkg-config-based detection of the opentelemetry-c-wrapper library, header files with configuration constants, utility macros and type definitions, and the source files containing stub filter operation callbacks registered through flt_otel_ops and the "opentelemetry" keyword parser entry point. The filter uses the opentelemetry-c-wrapper library from HAProxy Technologies, which provides a C interface to the OpenTelemetry C++ SDK. This wrapper allows HAProxy, a C codebase, to leverage the full OpenTelemetry observability pipeline without direct C++ dependencies in the HAProxy source tree. https://github.com/haproxytech/opentelemetry-c-wrapper https://github.com/open-telemetry/opentelemetry-cpp Build options: USE_OTEL - enable the OpenTelemetry filter OTEL_DEBUG - compile the filter in debug mode OTEL_INC - force the include path to the C wrapper OTEL_LIB - force the library path to the C wrapper OTEL_RUNPATH - add the C wrapper RUNPATH to the executable Example build with OTel and debug enabled: make -j8 USE_OTEL=1 OTEL_DEBUG=1 TARGET=linux-glibc	2026-04-13 09:23:26 +02:00