Displaying a longer history of live Logs for my App

Hey everyone!

On my deployed App, I can only display 1 hour of logs, I can’t display what’s before that hour.

I’m currently in need of at least 24 hours of logs to debug an issue, could you please point me to a solution?

Is there a solution for that on Fly.io, or should I use an external service for that? In that case what service works the best with Fly.io?

Cheers.

You should be able to see logs for up to 30 days. Go to your app dashboard and click log search

Hey @khuezy thank you for replying,
I tried it, clicking on log search and it redirects me to fly-metrics.net, the problem is I still got only the last 30 minutes of logs.

Could you tell me how do you happen to access the last 30 days of logs on that platform?

The infinite scroll seems to be broken, it doesn’t load any extra data. Fly devs need to fix that.
Workaround: You can drag on the timeline and select the range to filter by a specific range.

Hey @khuezy

thanks for sharing the info, I happen to be able to scroll infinitely (I mean I selected a window of the last 24 hours) I just had to switch to the Explore tab on the left, then select 24 hours and scroll all the way down.
image

Infinite scrolling works now :person_shrugging:
nvm, only when you search.

@khuezy , Is there a way to display directly the logs you want? like the 08/20/2024 at 03:15pm, instead of scrolling infinitely until I arrive at the right timeline.

Yes, in the timeline, drag your mouse to the start/end of the time you want. Or in the toolbar, click the clock item and select Absolute time range

thank you so much @khuezy , I selected your last reply as a solution for this thread. I’ve got another question for you, I hope I’m not abusing your kindness, as I was scrolling on my logs looking for the issue of one of my webhooks, the failure happened at a certain time let’s say 03:00 pm, so when I’m near that timeline I find a timeskip and before that, there is a warning.
“WARN could not unmount /rootfs: EINVAL: Invalid argument
[3:33 PM]”

this is something coming from the deploy on fly, could it be the docker file? Did you ever encounter the same issue?

np, that’s a benign message. You can ignore it.

@khuezy , but it makes my logs timeskip.
I will add pictures to explain more.


You see from 07:07:03 to 08:39:13 there was a timeskip, no logs in between as if the machine shut down. this causes problem with my app because I had a webhook that needed to run at 07:39:18 and it failed.

I wanted to read the logs first to know why the webhooks failed but now it is clear that they didn’t run in the first place because the machine was down due to that unmount warning thing. so yeah I bothers me a bit and I don’t know what to do to fix it. (this thing happened with other webhooks as well multiple times) and it’s the same thing its a timeskip caused by the unmount warning.

The blank times are b/c your machine shut down. If you’re sending an http webhook, it should autostart your machine, assuming you’ve configured that.

@khuezy , yes it’s an http webhook, but weirdly enough my webhook works sometimes, like I get to see the logs.

By configuring that do you mean the docker file?

Are you sure that the machine shut down mainly because of the webhook?

No, your fly.toml configures your machine’s autostop/start policy.

@khuezy , this is my http service and VM from my fly.toml

[http_service]
force_https = true
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
processes = [‘app’]

[[vm]]
memory = ‘1gb’
cpu_kind = ‘shared’
cpus = 1

So I guess I should do the following modifications. in HTTP service
auto_stop_machines = false
min_machines_running = 1

right? any opinion on that?

That would fix your issue, but would be a waste of resources. Your machine should have woken up from the http webhook. Does discord have any logs of failed webhooks? Perhaps it took too long. Change auto_stop_machines true to "suspend"

@khuezy , my failure is always a timeout with a duration of 6seconds, while the successful webhook takes only 1 or 2 seconds.

so I will go with auto_stop_machines = “suspend” and keep
min_machines_running = 0
and see if it will change anything.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.