Logs
When designing the logging strategy, we focused on a key principle: avoid overwhelming users with internal messages that do not contribute to your goal — running a stable, scalable federation of Kubling instances.
For this reason, Kubling provides a mechanism to filter log messages, keeping only the relevant ones.
In addition, logs can be routed to the console, OpenTelemetry, or both.
There are three independent log handlers:
- Core: Handles most printable system messages (after filtering).
- Script: Captures log streams from script contexts, such as messages from the
loggerobject. - Agentic: Captures log streams from the Agentic logic, especially interactions with upstream capability implementations.
Configuration
Logs configuration section
logs:
type: "object"
id: "schema:kubling:dbvirt:config:app:instrumentation:LogsProperties"
properties:
scheduleDelayInSeconds:
type: "integer"
description: "The delay interval (in seconds) between each batch export\
\ operation. Controls how frequently accumulated telemetry data is flushed\
\ to the exporter. Default: 5 seconds."
maxExportBatchSize:
type: "integer"
description: "The maximum number of telemetry items (spans, logs, etc.)\
\ included in a single export batch. Larger batches improve throughput\
\ but may increase export latency. Default: 512."
maxQueueSize:
type: "integer"
description: "The maximum number of telemetry records that can be queued\
\ for export. If the queue reaches its capacity, new records may be\
\ dropped. Default: 512."
exporterTimeoutInSeconds:
type: "integer"
description: "The maximum time (in seconds) allowed for a single export\
\ attempt. If the exporter does not complete within this timeout, the\
\ batch is considered failed. Default: 6 seconds."
url:
type: "string"
headers:
type: "object"
additionalProperties:
type: "string"
core:
type: "object"
id: "schema:kubling:dbvirt:config:app:instrumentation:CommonLogsProperties"
properties:
enabled:
type: "boolean"
level:
type: "string"
enum:
- "DEBUG"
- "INFO"
- "WARN"
- "ERROR"
consoleEcho:
type: "boolean"
script:
type: "object"
$ref: "schema:kubling:dbvirt:config:app:instrumentation:CommonLogsProperties"
agentic:
type: "object"
$ref: "schema:kubling:dbvirt:config:app:instrumentation:CommonLogsProperties"Example
instrumentation:
logs:
url: "http://127.0.0.1:4318/v1/logs"
scheduleDelayInSeconds: 5
maxExportBatchSize: 512
maxQueueSize: 512
exporterTimeoutInSeconds: 6
headers:
some: "header"
core:
enabled: true
level: "DEBUG"
consoleEcho: true
script:
enabled: true
level: "DEBUG"
agentic:
enabled: true
level: "WARN"Contexts
All log entries include a context, which indicates the module emitting the entry. In the log line, this context appears enclosed in square brackets, like this:
04-11-2025 11:35:19.469 INFO - [INST>METRICS] Enabling OpenTelemetry.
04-11-2025 11:35:19.525 INFO - [INST>TRACING] Tracing enabled: using OTLP exporter -> http://0.0.0.0:4318/v1/traces
04-11-2025 11:35:19.560 INFO - [CORE] Loading VDB <<Azure>>
04-11-2025 11:35:19.560 INFO - [CORE] Loading Data Source <<app_delegate>>
04-11-2025 11:35:19.875 WARN - [CORE] WARNING! Native Protocol is marked as SECURE but no SSL configuration is specified. Ignoring.
04-11-2025 11:35:19.875 WARN - [CORE] WARNING! No authentication delegation informed in the Bundle, all connections will be accepted by default.
04-11-2025 11:35:19.971 INFO - [CORE] << Kubling Data Virtualization Engine v25.6 Started >>
04-11-2025 11:35:19.972 INFO - [CORE] HTTP API Services and Observability on port 8282
04-11-2025 11:35:19.972 INFO - [CORE] DB Native UNSECURED protocol started on 0.0.0.0:35482
04-11-2025 11:35:19.972 INFO - [CORE] SQL: Maximum Thread Pool Size: 25 | Maximum Waiting Queue Capacity: 10
04-11-2025 11:35:19.972 INFO - [CORE] HTTP: Maximum Thread Pool Size: 100 | Maximum Waiting Queue Capacity: 50
04-11-2025 11:35:19.972 INFO - [CORE] Soft TX DB: //kubling-stx.dbWhen logs are sent via OpenTelemetry, the context is added as an attribute you can use for filtering:
"attributes":{"log.source":"core"}Echoing to console
When the url property is not set but the handler is enabled, Kubling defaults to outputting logs to the console.
If you want to export logs to a remote collector and print them to the console, use the consoleEcho property.
In production environments, we strongly recommend disabling console output and relying entirely on OpenTelemetry — especially when running on small, resource-constrained ARM-based devices like a Raspberry Pi.