OpenTelemetry and Access Logging
OpenTelemetry
Introduction
Modern production environments require visibility into application behavior, performance, and failures.
DecisionRules provides built-in observability capabilities through OpenTelemetry (OTLP) and structured logging. These capabilities allow organizations to integrate DecisionRules into existing monitoring platforms, troubleshoot production issues, analyze rule execution behavior, and correlate requests across distributed systems.
Depending on the deployment architecture, observability can be implemented in several ways:
Full OpenTelemetry integration with an observability platform
Trace-only, log-only, or metrics-only telemetry exports
Structured access and audit logging to stdout
Audit-only logging without database persistence
The platform allows these approaches to be combined according to operational and compliance requirements.
Feature Overview
DecisionRules provides built-in OpenTelemetry support for production-grade observability using the OTLP (OpenTelemetry Protocol) standard.
The platform can export:
Traces — request execution flow and dependency spans
Logs — structured access, audit, and application logs
Metrics — runtime and service performance metrics
Telemetry can be sent to any OTLP-compatible observability platform, including:
Grafana
Jaeger
Datadog
OpenTelemetry Collectors
Existing enterprise monitoring stacks
A single request can be correlated end-to-end using shared traceId and spanId values across:
inbound API requests
outbound dependency calls
audit records
runtime/application logs
distributed traces
This provides a unified operational view of rule execution behavior and system performance.
Deployment Patterns
DecisionRules supports multiple observability deployment patterns. The following sections describe the most common approaches.
1. Full OpenTelemetry Integration
This mode exports telemetry data directly to an OTLP-compatible observability platform.
Typical use cases:
Centralized monitoring
Distributed tracing
Production diagnostics
SLA monitoring
Enterprise observability platforms
Traces, Logs and Metrics
Logs Only
Useful when a centralized logging platform is available but distributed tracing is not required.
2. Structured Logging to Stdout
DecisionRules can emit structured JSON logs directly to stdout without requiring any telemetry collector.
This mode is often sufficient for troubleshooting, operational monitoring, and log aggregation performed by the container platform itself.
Generated logs include:
Access logs
Audit logs
Application logs
Benefits:
No OpenTelemetry collector required
No additional infrastructure components
Works with Kubernetes log collection out of the box
Full request correlation through
traceIdandspanId
Example Configuration
3. Stdout Logging with Audit-Only Persistence Disabled
By default, audit logs are persisted to the audit database.
Some deployments prefer audit records to be exported through the logging pipeline only, without storing them in MongoDB.
In this configuration:
Audit logs are generated
Audit logs are exported to stdout
Audit logs are not persisted in the audit database
Example Configuration
This approach is commonly used when audit retention is handled by an external logging platform.
4. Hybrid Mode
OpenTelemetry export and stdout logging can be enabled simultaneously.
This provides:
Centralized telemetry collection
Local container visibility
Easier debugging during deployments and migrations
Example Configuration
Log Formatting and Filtering
The platform provides several optional controls for shaping telemetry output.
These settings allow organizations to:
sanitize sensitive information
control request/response body formatting
limit exported log attributes
exclude health-check traffic
restrict telemetry to Solver-related endpoints
Commonly used options include:
OTLP_LOG_SANITIZATION_ENABLEDOTLP_TRACE_SANITIZATION_ENABLEDOTLP_ACCESS_BODY_FORMATOTLP_LOG_ATTRIBUTE_ALLOWLISTOTLP_ACCESS_EXCLUDE_HEALTHCHECKOTLP_ACCESS_ONLY_SOLVEROTLP_STDOUT_WRAPPED_KEY
Detailed descriptions are available in the Environment Variables section below.
Implementation Notes
Outbound logs generated from Script Rules are currently not supported.
The reason is that OpenTelemetry instrumentation is not initialized inside the isolated worker process that executes JavaScript code.
Log Examples
The following examples show the primary telemetry log types emitted by the platform.
All logs are structured JSON and can be correlated using traceId and spanId.
Access Log — Inbound Request
Generated when the API receives a request.
Access Log — Inbound Response
Generated when the API sends a response.
Access Log — Outbound Request
Generated when the API sends a request to an external or internal dependency.
Access Log — Outbound Response
Generated when the API receives a response from an external or internal dependency.
Audit Log
Generated for rule execution auditing and operational tracking.
The log is generated only when audit logging is enabled on the rule.
Application Error Log
Generated for internal runtime or application errors.
Common Correlation Fields
traceId
Correlates logs, spans, and metrics belonging to the same request flow
spanId
Identifies the specific operation/span within a trace
logType
Distinguishes access, audit, and application logs
timestamp
Event creation time
statusCode
HTTP response status when applicable
Environment Variables
Feature Activation
OTLP_URL
Base OTLP endpoint (required to activate telemetry pipeline).
undefined
OTLP_TRACES_ENABLED
Enables trace exporter and runtime instrumentations.
false
OTLP_LOGS_ENABLED
Enables OTLP log exporter.
false
OTLP_METRICS_ENABLED
Enables periodic metric reader/exporter.
false
OTLP_STDOUT_ACCESS_LOGS_ENABLED
Emits access logs to stdout (structured JSON), gated by license.
false
OTLP_STDOUT_AUDIT_LOGS_ENABLED
Emits audit logs to stdout (structured JSON), gated by license.
false
Logging Configuration
OTLP_LOG_SANITIZATION_ENABLED
Redacts sensitive keys (authorization/api keys/etc.) in telemetry logs.
true
OTLP_TRACE_SANITIZATION_ENABLED
Redacts sensitive data (authorization/api keys/etc.) in traces.
true
OTLP_STDOUT_ACCESS_BODY_FORMAT
Controls body formatting strategy for access logs in stdout. Valid values: JSON, string, string-pretty.
'JSON'
OTLP_STDOUT_WRAPPER_KEY
Wraps stdout payload into a nested key for downstream parsers. Example: logDataBody.
undefined
OTLP_LOG_ATTRIBUTE_ALLOWLIST
Optional comma-separated allowlist of log fields sent to collector. Example: level,logType,timestamp,traceId,spanId,statusCode,url,headers.authorization. Note that spanId, traceId, and level are always present even when not defined in the allowlist.
undefined
OTLP_ACCESS_EXCLUDE_HEALTHCHECK
Excludes health endpoints from access traces/logs.
false
OTLP_ACCESS_ONLY_SOLVER
Limits telemetry to solver/job-related traffic paths.
false
Logging Options
LOGGER_TYPE
Controls console log format. Valid values: STRING, JSON, NONE.
STRING
LOGGER_LEVEL
Minimum log level to print/emit through the application logger (e.g. error, warn, info, debug).
info
Audit Logs in Database
AUDIT_MONGO_ENABLED
If false, audit logs are created but not persisted to the audit database (useful when audit logs should only be emitted to stdout).
true
Conclusion
DecisionRules observability support can be deployed in multiple ways ranging from simple structured stdout logging to full OpenTelemetry integration with enterprise monitoring platforms.
The most common deployment patterns are:
Full OpenTelemetry integration
Stdout-only structured logging
Audit logging without database persistence
Hybrid deployments combining both approaches
All telemetry data can be correlated using shared traceId and spanId values, providing complete visibility into rule execution, API behavior, and platform operations.
Last updated
Was this helpful?

