https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> Hey Kapa I need to do some debuggin...
# replication-ask-ai
s
@kapa.ai Hey Kapa I need to do some debuggin on a woocommerce source. Is there an easy way on my OS instance that enables more thorough logging?
k
There isn’t a documented, per-connection “deep debug” switch for connectors like WooCommerce in the provided docs, and the knowledge sources don’t describe a way to turn on full HTTP-level logging just for one source. From what is documented: 1. Global log level (platform-wide) Airbyte supports a global 
LOG_LEVEL
environment variable (Log4J levels) that controls logging verbosity for the platform as a whole. You can increase verbosity (e.g., to 
DEBUG
) in your deployment configuration, but this affects the entire instance, not just WooCommerce. [[Configuring Airbyte logging](https://docs.airbyte.com/platform/operator-guides/configuring-airbyte#logging)] 2. Connector-level debug (CDK / custom connectors) There is an open GitHub issue discussing more detailed HTTP logging for connectors. The comments mention that the Python CDK already has infrastructure to support debug-level logging by passing 
DEBUG=true
, and that a future 
log-level
option for connector CLIs has been discussed, but this is not documented as a user-facing feature in the official docs yet. [[log http calls issue](https://github.com/airbytehq/airbyte/issues/52077)] 3. Workarounds mentioned by users In that same issue, a user describes setting up an HTTP proxy (e.g., nginx) with logging and routing the connector’s requests through it as a temporary way to see detailed HTTP traffic. This is a community workaround, not an official feature. [[log http calls issue](https://github.com/airbytehq/airbyte/issues/52077)] Given the available information: - The only documented “easy” knob you have on a standard OSS instance is raising the global 
LOG_LEVEL
to something more verbose. - For very deep HTTP-level insight into WooCommerce calls, you’d likely need either: - to rely on CDK-level debug (
DEBUG=true
) if you control the connector image (not documented in the official operator guides), or - to use an external HTTP proxy with logging as a workaround. If you can share how you’re deploying Airbyte (Docker, Kubernetes/Helm, abctl), I can outline the concrete steps to bump 
LOG_LEVEL
in that setup based on the logging config docs.
s
@kapa.ai So if I want to enable option one, the global debug. I have the OS instance running on a linux machine, installed with abctl. What steps do I TAKE?
k
A message from kapa.ai
The knowledge sources don’t describe a step‑by‑step way to change 
LOG_LEVEL
specifically for an abctl-installed OSS instance, so I can’t give an exact, guaranteed procedure. The docs only state that: - 
LOG_LEVEL
is a configuration option that “defines log levels. Defaults to INFO” and should be set to a valid Log4J level (e.g. 
DEBUG
). [[Configuring Airbyte logging](https://docs.airbyte.com/platform/operator-guides/configuring-airbyte#logging)] - 
abctl
itself has a 
--verbose
flag on all commands, which only affects the CLI’s own output, not connector logs. [[abctl help and debugging](https://docs.airbyte.com/platform/deploying-airbyte/abctl#help-and-debugging)] Because there’s no explicit documentation on how 
abctl local install
wires 
LOG_LEVEL
into the underlying Helm chart or values, I can’t reliably tell you which file or command to use to override it. What you can do with certainty from the docs: 1. Use abctl’s own verbose mode while you experiment Run your abctl commands with 
--verbose
to get more detailed CLI/debug output (this won’t change connector log verbosity, but can help with deployment/migration issues):
Copy code
bash    abctl local <command> --verbose
[[abctl help and debugging](https://docs.airbyte.com/platform/deploying-airbyte/abctl#help-and-debugging)] 2. Know that a global 
LOG_LEVEL
exists If you find where your abctl deployment stores Helm values or environment variables, you’d be looking to set:
Copy code
text    LOG_LEVEL=DEBUG
as per the logging configuration docs. [[Configuring Airbyte logging](https://docs.airbyte.com/platform/operator-guides/configuring-airbyte#logging)] Since the knowledge sources don’t show how to inject that into an abctl-managed kind cluster, I’d recommend: - Checking the abctl‑created Helm values or manifests for a 
LOG_LEVEL
field and setting it to 
DEBUG
, then redeploying; and/or - Opening an issue or discussion on the Airbyte GitHub repo specifically asking for documented steps to override 
LOG_LEVEL
when using 
abctl local install
. If you can share any existing 
values.yaml
or environment snippets from your abctl deployment, I can help you interpret them, but I can’t invent missing steps beyond what’s in the docs.
2 Views
Open in Slack
PreviousNext
Powered by