Not sure if this is the correct channel. I am usin...
# fluent-operator
d
Not sure if this is the correct channel. I am using the fluent-operator and I am running into an issue where sometimes when fluent-bit pods startup they are unable to send data to the backend. It never sends logs and then if I restart the pod everything seems to start working. I am running as a daemonset. I am sending metrics via opentelemetry and logs via forward. • How I can get more information about why the failure is happening? • Any strategies I can employ to recover or fix this? A sample of the logs I see looks like the following
Copy code
[2025/07/01 16:39:09] [error] [io fd=123] error sending data to: <tcp://10.0.75.209:24224> (Broken pipe)
[2025/07/01 16:39:09] [error] [output:forward:forward.0] could not write forward entries
[2025/07/01 16:39:09] [ warn] [engine] failed to flush chunk '14-1751387948.402920859.flb', retry in 11 seconds: task_id=0, input=tail.1 > output=forward.0 (out_id=0)
[2025/07/01 16:39:20] [error] [io fd=123] error sending data to: <tcp://10.0.75.209:24224> (Broken pipe)
[2025/07/01 16:39:20] [error] [output:forward:forward.0] could not write forward entries
[2025/07/01 16:39:20] [error] [engine] chunk '14-1751387948.402920859.flb' cannot be retried: task_id=0, input=tail.1 > output=forward.0
[2025/07/01 16:39:49] [error] [http_client] broken connection to redacted.svc.cluster.local:4318 ?
[2025/07/01 16:39:49] [error] [output:opentelemetry:opentelemetry.1] redacted.svc.cluster.local:4318, HTTP status=0
[2025/07/01 16:39:49] [ warn] [engine] failed to flush chunk '14-1751387988.401066631.flb', retry in 6 seconds: task_id=0, input=fluentbit_metrics.0 > output=opentelemetry.1 (out_id=1)
v
What are logs on your end-server where you are expected to receive data? Have you tried to enable debug info there, is there anything suspicious? Is your software on both sides up to date?
I also guess tat this channel isn't really one for your use case, since you don't have a dedicated issue with the operator, rather with the fluent-bit/fluentd itself, therefore, try to ask in a specific to your use case channel -> #C0CTQGHKJ, #C0CTT63EE
d
Sorry I was out for the US holiday. Thanks for the response. I was able to track down that this seems to be happening with a switch to the istio ambient service mesh but I don't know why yet exactly. It seems that it takes a little bit for the connection to become stable and when that takes over a certain amount of time it just never works. I did notice that we didn't have the liveness probe configured so I have gone ahead and configured that. I am waiting to see if that helps (the issue isn't that common). I didn't see anything in the fluent operator helm chart regarding readiness probes. Do you think that deserves an issue?
v
It doesn't impose problem I can think of, but might be a valid use case for an issue. Double-check if they've maybe there readiness probes issues closed, so you don't duplicate already existing request. For the Istio part - I would highly recommend to cross-check Istio repo on issues similar, could be there's some random feature flag to enable. Won't be able to help, since haven't used Istio.
d
I found https://github.com/fluent/fluent-bit/issues/9927 which seems to be the same issue. Thanks again!