Best practice for running the fly-log-shipper

[thewilkybarkid]

Fly Log Shipper Duplicate Logs on Apps v2

Hi @jfrydman Yea the change to deploy two instances by default in my opinion was a bandaid for users who don’t understand what high availability requires. Fly have also dropped the ball on updating all previous docs that were impacted by this change. Luckily a fix for you should be pretty simple, you just need to set another environment variable. Set QUEUE to pretty much any value and you should be good to go. E.g. [env] QUEUE = "org-logs"

Related to this, what is the best practice for having two (or more) instances of fly-log-shipper?

Based on the thread and the default fly.toml in the repo, I have:

flyctl config show
{
  "app": "prereview-log-shipper",
  "build": {
    "image": "ghcr.io/superfly/fly-log-shipper:latest"
  },
  "env": {
    "ORG": "prereview",
    "QUEUE": "prereview-logs"
  },
  "metrics": {
    "port": 9598,
    "path": "/metrics"
  }
}

I’ve created a second machine but have stopped it (with flyctl machine stop), so the warning’s gone, and while they were both running temporarily I didn’t see duplicate logs.

I don’t have any configuration to say just always run 1 of these. My understanding of the min_machines_running and similar options is that they’re all related to services, which this doesn’t have.

Should there be some kind of health check too?

[charsleysa]

Hi @thewilkybarkid

I would personally say the best practice is to leave the machines running all the time, and have 1 in each region you deploy your apps to.

I’m pretty sure the warning works by simply counting the number of machines, not checking whether the machines are running or not.

As you aluded to, the autostop/autostart features don’t work without a services section in your config and that’s not applicable to this app. This means that your stopped machine will never be automatically started and your running machine will never be automatically stopped.