https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> I've airbyte oss deployed in kubern...
# replication-ask-ai
s
@kapa.ai I've airbyte oss deployed in kubernetes, how can I enable debug logs
k
To enable debug logs for Airbyte OSS deployed on Kubernetes, you need to configure the log level setting to 
DEBUG
. The exact method depends on your deployment setup: 1. Via Helm Chart (values.yaml) If you are using the Airbyte Helm chart: • Helm Chart V2 (Core): Set the global logging level in your 
values.yaml
file [Upgrade to Helm chart V2]global logging: level: "DEBUG" • Direct Component Configuration (e.g., Server / Worker): In standard Helm chart configurations, you can configure the logging level directly under the component configuration [Github Issue (closed): [compose/api] Error upgrading Airbyte helm chart]server log: level: "DEBUG" 2. Via Environment Variables (LOG_LEVEL) Airbyte controls logging verbosity using the 
LOG_LEVEL
environment variable (which defaults to 
INFO
and accepts standard Log4J log levels like 
DEBUG
or 
TRACE
) [Configuring Airbyte; AirbyteLogMessage]. If you deploy via Kustomize or supply extra environment variables via Helm, set 
LOG_LEVEL
to 
DEBUG
for the relevant Airbyte pods (such as 
server
and 
worker
) [Datadog monitoring; Github Issue (closed): [compose/api] Error upgrading Airbyte helm chart]:
Copy code
extraEnv:
  - name: LOG_LEVEL
    value: "DEBUG"
After updating your configuration, apply the changes using 
helm upgrade
or by restarting the pods/deployments to load the new logging level. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
s
@kapa.ai still no debug logs in mysql source container when hitting set up source:
Copy code
2026-08-27 10:33:21,081 [main]  ←[34mINFO←[0;39m        i.m.c.e.DefaultEnvironment(<init>):170 - Established active environments: [worker-v2, control-plane, oss, local-secrets]                                                       2026-08-27 10:33:21,707 [main]  ←[34mINFO←[0;39m        i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.netty'                                                      2026-08-27 10:33:21,708 [main]  ←[34mINFO←[0;39m        i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'ERROR' for logger: 'com.zaxxer.hikari'                                            2026-08-27 10:33:21,708 [main]  ←[34mINFO←[0;39m        i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.grpc'                                                       2026-08-27 10:33:21,708 [main]  ←[34mINFO←[0;39m        i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.temporal'                                                   2026-08-27 10:33:21,709 [main]  ←[34mINFO←[0;39m        i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'ERROR' for logger: 'com.zaxxer.hikari.pool'                                       2026-08-27 10:33:21,709 [main]  ←[34mINFO←[0;39m        i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.fabric8.kubernetes.client'
k
Based on the logs you provided, what you are viewing are the startup logs from the platform container (
init
or 
connector-sidecar
), where libraries like Micronaut configure standard logger levels (such as 
INFO
for Netty/gRPC and 
ERROR
for HikariCP) [Airbyte 1.2.0 on Kubernetes/EKS: Cannot create new sources; Workload launcher false positive liveness probes]. When setting up a source ("Test the Source" / 
check
job), the workload pod runs multiple containers [Airbyte 1.2.0 on Kubernetes/EKS: Cannot create new sources]: 1. *Check the correct container logs:*# Find the running check pod kubectl get pods -l airbyte=job-pod -n namespace # Check the connector container or sidecar container logs kubectl logs pod-name -c main -n namespace kubectl logs pod-name -c connector-sidecar -n namespace ◦ In a 
check
pod, the actual connector execution is handled by the 
main
container, while the 
sidecar
container captures the connector output and logs [Airbyte 1.2.0 on Kubernetes/EKS: Cannot create new sources; Container Reference]. ◦ Inspect the logs directly by targeting the specific container: 1. Passing 
LOG_LEVEL
to spawned connector pods: ◦ Setting 
LOG_LEVEL
or 
global.logging.level
on the Airbyte server/worker might not automatically propagate dynamic log levels into the spawned check pods. ◦ For Java-based connectors (like MySQL), debug logging can be passed by configuring Java options if targeting debug containers (such as setting 
JAVA_TOOL_OPTIONS
or 
DEBUG_CONTAINER_JAVA_OPTS
on the worker launcher) [Debugging Containers Launched by the Worker; Update your values.yaml file]. Note: The provided knowledge sources do not explicitly detail a built-in UI toggle to dynamically force 
DEBUG
level logs on isolated 
check
connection operations for specific connectors in Helm deployments. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
2 Views
Open in Slack
PreviousNext
Powered by