Cases1 case

1 to 1 of 1

1. IL-0174 After an upgrade to Fluent Bit 2.0, logging sidecars that used the Kafka output plugin kept restarting with SIGSEGV because the plugin read a corrupted record as a map without checking its type

   Hyperconnect2023

   Symptoms

   Hyperconnect upgraded the Fluent Bit sidecar of one service with little user impact to Fluent Bit 2.0 and watched it for several days. Only the containers that used the Kafka output plugin were being restarted, each time on SIGSEGV. The stack trace printed at the crash pointed into the Kafka output plugin, but no core file was left behind, because Fluent Bit ran inside Kubernetes.

   Container crash loop

   Trigger

   Upgrading the Fluent Bit logging sidecar to version 2.0 (the 2.0.3 image) on a service with low user impact.

   Root cause

   Software defect

   Component

   Telemetry agent

   Contributing factor

   Limited debug access

   Detection

   The team monitored the upgraded sidecars for several days after the upgrade and saw that the containers using the Kafka output plugin were restarting with SIGSEGV.

   Remediation

   • patched the Fluent Bit Kafka output plugin to skip data that is not a map before calling produce_message()
   • ran a custom build with the patch as the sidecar, which stopped the segmentation faults
   • submitted the patch upstream as fluent-bit pull request 6452, which was merged eight days later

   Lessons

   A segmentation fault in a container can be debugged from its core file, but Kubernetes does not keep one by default: a volume mounted into the pod and a core_pattern pointing into it on the node are needed first. The debug image of the same version, run locally on the same CPU architecture with the matching source checkout, gives a gdb environment that matches production. Core files contain part of the process memory and may hold sensitive data, so they should be shared with care.

   View case

By root cause1