Dilyan Stoev
06/08/2026, 12:22 PMcurl --request GET --url '<http://airbyte.ext.prod/api/public/v1/sources>' --header 'accept: application/json' --header 'authorization: Bearer sss'
where to see logs for that request on a Airbyte running on EKS ?kapa.ai
06/08/2026, 12:22 PM# List pods in the relevant namespace
kubectl get pods -n <namespace>
# Stream logs from the server/worker pod
kubectl logs -f <pod-name> -n <namespace> -c main
For a specific worker pod, you can exec in and browse files:
kubectl exec -it <pod-name> -n <namespace> -c main bash
[Browsing on Kubernetes]
3. Audit Logging (Self-Managed Enterprise) If you're on Self-Managed Enterprise, audit logging can be enabled to capture API-level operations (create/update/delete on sources, destinations, connections, etc.). These logs are written as JSON files to a configured blob storage bucket (e.g., S3). [Audit Logging]
4. Log Collection via DaemonSet (Enterprise Flex) If you're on Enterprise Flex, Airbyte emits structured JSON logs to stdout from all containers. You can collect these using a DaemonSet-based collector (Fluent Bit, Vector, or Datadog Agent) and ship them to your observability backend. [Log Collection]
Note: The Airbyte API server logs (for requests like your GET /api/public/v1/sources) are emitted to the server pod's stdout. On EKS, the most direct way to see them is via kubectl logs on the airbyte-server pod. The connection/sync logs visible in the UI are specific to data sync jobs, not general API requests. š 0 button š 0 button ā¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Dilyan Stoev
06/08/2026, 12:31 PMkapa.ai
06/08/2026, 12:31 PMairbyte-server pod for a GET /api/public/v1/sources request.
A few observations based on what the knowledge sources do mention:
⢠The LOG_LEVEL environment variable defaults to INFO. If the request is handled successfully without errors, it may simply not produce visible output at the default log level. You could try setting LOG_LEVEL=DEBUG to get more verbose output. [Configuring Airbyte]
⢠From a related GitHub issue, it was observed that the airbyte-server pod does log API requests in some cases (e.g., REQ 172.18.0.3 POST 200 /api/v1/workspaces/get), suggesting request logging is present but may depend on the log level or request type. [GitHub Issue]
Suggestions to investigate further:
1. Confirm you're tailing the correct container within the pod:kubectl logs -f deployment/airbyte-server -n namespace
2. Try increasing the log level to DEBUG in your deployment configuration.
3. Check if there is a reverse proxy or ingress (e.g., NGINX) in front of the server that may be handling the request before it reaches the server pod.
For a more definitive answer, I'd recommend reaching out to the Airbyte community on Slack or checking the Airbyte GitHub issues. š 0 button š 0 button ā¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.