Hi, I have a hard time understanding the behaviour of the multiple host based

macros with respect to the value of the use-fqdn(), and keep-hostname() params.

This is a confusing part of our documentation that I tried to clarify a few months ago. Unfortunately, it is still not the best.

First of all, when setting use-fqdn(yes), isn't the network destination supposed to send the fqdn? In our case, tcpdump shows that the short hostname is sent instead.

use-fqdn(), use-dns(), normalize-hostnames() and dns-cache() are actually source options but they can be used in the global "options" block as well. They do NOT really have effect if the keep-hostname option is set to "yes". If you set use-fqdn to "yes" for a source (or globally), you might want to set keep-hostname() to "no" in order to overwrite the original hostname that was parsed from the message. The original hostname may not be an FQDN, but syslog-ng can not touch it when keep-hostname() is enabled. As an alternative (if you also want to keep the original hostname), you can write a custom template for the destination where ${HOST_FROM} is used instead of ${HOST}. Additionally, what does the following paragraph from the documentation mean?

The hostname-related macros (${FULLHOST}, ${FULLHOST_FROM}, ${HOST}, and ${HOST_FROM}) do not have any effect if the keep-hostname() option is disabled

Does that mean they are empty if keep-hostname(no) ?

This sentence from the documentation is completely incorrect. Let me summarize the real behavior: FULLHOST is just an alias for HOST. FULLHOST_FROM is an alias for HOST_FROM. HOST_FROM always contains the hostname resolved by the current syslog-ng instance (using the values of use-fqdn(), use-dns(), normalize-hostnames() and dns-cache()). HOST contains the original (parsed) hostname of the message if keep-hostname() is enabled. Otherwise, it contains the value of HOST_FROM (or chained hostnames if chain-hostnames() is set). -- László Várady