Allow positively overriding hostname

[paweljw]

• combines "positive signal" requirement with ability to set it per-machine
• covers bootstrap, service starts/stops etc, because it's implemented in supervisor start script

should be enough to:

mkdir -p /var/lib/better-stack
cat /etc/hostname > /var/lib/better-stack/hostname.txt

and (re)starting containers

[curusarn]

combines "positive signal" requirement

I don't know what this means please. Could you dumb it down for me? 🙏

[paweljw]

@curusarn apologies for opaque language 🙏

I mean: we already have $HOSTNAME set in install scripts on all-ish platforms. Rather than overriding user's choice by e.g. always reading /etc/hostname, I wanted a strong positive signal the user wants the hostname overridden at runtime. In this case, explicitly creating a file means: "I know what I'm doing and I want this overridden".

[curusarn]

This allows us to override ENV HOSTNAME by writing /var/lib/better-stack/hostname.txt.

When do we plan to write into /var/lib/better-stack/hostname.txt please?

Does the customer need to write the hostname?

[paweljw]

When do we plan to write into /var/lib/better-stack/hostname.txt please?

Does the customer need to write the hostname?

We don't, because for most use-cases setting HOSTNAME at install-time is sufficient. I'm imagining the file would be created e.g. in an instance setup script. That's why I wanted the action needed to be blazing-fast and one-time.

Hence my point about adding it to the docs. It'd be part of Advanced configuration.

[curusarn]

@curusarn apologies for opaque language 🙏

I mean: we already have $HOSTNAME set in install scripts on all-ish platforms. Rather than overriding user's choice by e.g. always reading /etc/hostname, I wanted a strong positive signal the user wants the hostname overridden at runtime. In this case, explicitly creating a file means: "I know what I'm doing and I want this overridden".

Why don't we read /etc/hostname anytime HOSTNAME env is unset?

• We'd get /etc/hostname at runtime normally.
• Overriding hostname would be possible via setting HOSTNAME before running install.sh.

I'm not excited to see a custom file introduced for something as simple as setting hostname. 🙏

[paweljw]

@curusarn

Why don't we read /etc/hostname anytime HOSTNAME env is unset?

Would it be ever? Or are you thinking that it should be overridden if e.g. explicitly set to an empty string? HOSTNAME="" ... install.sh?

Probably would need uts: host on both containers + Kubernetes equivalent + Swarm equivalent. Or mounting /etc/hostname on Beyla container.

The more mounts/more privileges slightly scared me off going that route :) But if you feel strongly that's the way to go, I'll do that 🙏

[paweljw]

@curusarn adjusted to use uts: host. On second thought, for Kubernetes and Swarm this shouldn't be an issue at all.

[curusarn]

@curusarn adjusted to use uts: host. On second thought, for Kubernetes and Swarm this shouldn't be an issue at all.

Thanks! 🙏
Generally, I didn't want extra steps to get correct hostname. Feels like something that should "just work". (even when baking collector into AMI)

ChatGPT claims Datadog get hostname from docker socket via docker info --format '{{.Name}}'.
If that works we wouldn't need UTS.

I'm fine with uts: host in docker compose. We set the env in Kubernetes and Swarm so we don't need it there. 👍

[paweljw]

@curusarn

ChatGPT claims Datadog get hostname from docker socket via docker info --format '{{.Name}}'. If that works we wouldn't need UTS.

True, but we also don't ship docker binary in our containers. Could be done with raw API access, but that's sort of out there. :)

[curusarn]

Thanks!

[curusarn]

Thanks! "uts: host" seems fine & simple. We can always adjust later. 🙏