You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The hostname value in Falco logs can be overridden but can not be omitted, which creates conflicts with logging providers like Datadog. Currently, Falco uses the node name (from FALCO_HOSTNAME environment variable) as the host/hostname attribute value. This is problematic because Datadog reserves this field and uses <node name>-<cluster name> as an internal ID for infrastructure/log correlation.
How to reproduce it
Deploy the latest version of Falco using the Helm chart (v4.12.0)
Observe the JSON output logs, which will contain a hostname entry like:
The system should provide an option to completely omit the hostname field from logs to avoid conflicts with logging providers
Environment
Falco version: 0.38.1
Cloud provider or hardware configuration: Azure Kubernetes Service
OS: Debian Bookworm
Additional context
A similar issue was reported in #2530 however the previously suggested solution (overriding hostname value viaFALCO_HOSTNAME) isn't adequate for our use case. The chart parameter suggested here would provide the solution we are looking for.
If the Falco team is open to it, we would be happy to have a go at implementing a fix.
Thanks!
The text was updated successfully, but these errors were encountered:
Describe the bug
The hostname value in Falco logs can be overridden but can not be omitted, which creates conflicts with logging providers like Datadog. Currently, Falco uses the node name (from FALCO_HOSTNAME environment variable) as the host/hostname attribute value. This is problematic because Datadog reserves this field and uses
<node name>-<cluster name>
as an internal ID for infrastructure/log correlation.How to reproduce it
Expected behaviour
The system should provide an option to completely omit the hostname field from logs to avoid conflicts with logging providers
Environment
Falco version: 0.38.1
Cloud provider or hardware configuration: Azure Kubernetes Service
OS: Debian Bookworm
Additional context
A similar issue was reported in #2530 however the previously suggested solution (overriding hostname value via
FALCO_HOSTNAME
) isn't adequate for our use case. The chart parameter suggested here would provide the solution we are looking for.If the Falco team is open to it, we would be happy to have a go at implementing a fix.
Thanks!
The text was updated successfully, but these errors were encountered: