cgo connects Go plugin code to Fluent Bit’s C core without recompiling Fluent Bit. It maps Go functions to C headers, passes parameters across language boundaries, and helps manage memory at the binding layer. section 10.4 section 10.11
A cgo-based Fluent Bit extension typically involves these pieces:
- Implement Go functions for each plugin lifecycle phase and expose the required C-compatible entry points. section 10.11 section 10.4
- Compile the binding into a shared object file with a .so extension that Fluent Bit can load at startup. section 10.4
- Use Fluent Bit configuration attributes to tailor plugin behavior, while respecting its naming constraints. section 10.11
- Account for hot reload, which can reload plugin shared objects without fully restarting Fluent Bit. section 10.4
- Compile separately for each operating system and CPU architecture when distributing the plugin across platforms. section 10.4
Keep database or other domain logic independent from the cgo layer when possible. This permits more agnostic local testing and isolates extension behavior from language-boundary mechanics. Shared input and output logic can be organized separately and included during each plugin build. section 10.4.2 section 10.4.2
Passing output-plugin data across the boundary
An output callback receives context and payload data through C-compatible pointers. The implementation retrieves plugin context, converts configuration into insertion parameters, decodes MessagePack records, converts values into Go types, and sends them to the database. Pointer-based context handling uses cgo C functions so data can pass safely between Go and C. section 10.6.4
Figure 10.2 The straight lines represent development relationships. The curved lines are execution-related relationships. The dashed lines show what artifacts contribute to the creation of the artifact pointed at. The diamonds represent our generated .so (shared object) files. The Dockerfile drives everything.
Use the repository relationship diagram to trace how source files, Dockerfile steps, generated shared objects, and runtime execution relate. section 10.4.2
