Not much to say. Here's the public url: https://zeit.co/morgs32/stackshirts/ekns24hcx/logs
And here is my now.json:
{
"version": 2,
"public": true,
"builds": [
{ "src": "/admin/package.json", "use": "@now/node-server" }
]
}
If I have devtools open while the app is "initializing", then I see the website polling for data from within _error.js
morgs32
All 29 comments
Same here. All my logs are empty. Can't see why my app is failing (!)
westhomas
on 1 Dec 2018
Here's a repo with code: https://github.com/westhomas/next-js-testapp
westhomas
on 3 Dec 2018
Experiencing same issue!
farid-ouachrar
on 28 Dec 2018
Same issue !!
now logs xxx.now.sh also returns nothing
abnerlee
on 31 Jan 2019
I can't see anything either
ekkis
on 10 Feb 2019
FWIW, I was experiencing this yesterday. I believe it may be due to the 1,000 line limit on the free plan. I upgraded to the unlimited plan (and entered my credit card info) and I'm not experiencing the issue today.
ecwyne
on 21 Feb 2019
This is super annoying. Most of the time (like 80%) I got 404 when my build fails and I can't even check the logs to see what happened (except for the CLI)
apieceofbart
on 16 Mar 2019
I have the paid tier and this is a consistent issue. It's a shame because I was trying to sell in Now at work : (
homerjam
on 25 Mar 2019
Same, happens every time.
reetou
on 28 Mar 2019
We have made very significant upgrades and improvements to the logging infrastructure. You should be seeing build and runtime logs with no issues.
We will close this issue once the work on this area completes. Thank you for your patience!
rauchg
on 31 Mar 2019
looking forward to it!
ekkis
on 1 Apr 2019
@ekkis are you still not seeing logs?
juliangruber
on 1 Apr 2019
I'm still using the GRU hack but I do see them now. a little slow but that's different. I meant I'm looking forward to the significant improvements in the platform
ekkis
on 1 Apr 2019
After redeployed my app (b), I'm facing the same issue. I do get build logs, but no application logs.
When I update the alias to the previous deployment (a) logging is working again. Switching again to the new deployment (b) does still not log any application logs.
a) octolinker-90txf3g39.now.sh (prints build and application logs)
b) octolinker-b1s50owwu.now.sh (just build logs)
stefanbuck
on 2 Apr 2019
@stefanbuck are you using Now 2.0 or 1.0?
juliangruber
on 6 Apr 2019
2.0
stefanbuck
on 6 Apr 2019
We're on it. I'm so sorry about this, please expect news _very_ soon.
juliangruber
on 8 Apr 2019
Hi, is this still broken?
It seemed like it was working again for a while. I saw some runtime logs from earlier today, and now I can only see the Build logs again.
naartjie
on 10 Apr 2019
Any updates on this? I have no logs displaying.
zoitsa
on 11 Apr 2019
@juliangruber is there an ETA on a resolution?
jrschumacher
on 18 Apr 2019
@jrschumacher I'm not maintaining this any more. Sorry!
juliangruber
on 18 Apr 2019
@rauchg is there an ETA on a resolution?
jrschumacher
on 19 Apr 2019
We fixed the issue and you should have logs by now... Did you redeploy @jrschumacher ?
paulogdm
on 19 Apr 2019
@paulogdm still having the same issue of no runtime logs, just build logs.
gtothesquare
on 20 Apr 2019
@gtothesquare Did you redeploy? This is supposed to be 100% fixed now.
paulogdm
on 24 Apr 2019
Closing. Let me know if you still face any issues.
paulogdm
on 24 Apr 2019
@paulogdm yes i redeployed and when i posted the comment it didn't work. What I had to do (maybe it was coincidence) was delete the project wait a bit till the project was actually deleted and redeploy. Can confirm it works.
gtothesquare
on 25 Apr 2019
(TLDR at the end)
Hey everyone,
In the past few months you have been experiencing poor reliability of Now 2.0 deployment logs – many logs were missing and, quite often, slow to load.
I'm more than happy to share that, as of last week, we have deployed very significant improvements to how we collect and store logs,
The problem
The reliability were issues due to a few limits we've encountered on the cloud providers we use for Lambda functions – we found that the way they buffer logs from Lambda functions doesn't scale to the volume of logs we were processing. That would cause two major issues:
- Logs would be dropped from the buffers and never delivered to our pipeline – that would cause logs to not be collected by our pipeline (a.k.a. "missing logs")
- The buffers would behave inconsistently: sometimes they would have buffer large quantities of logs (which is ideal) and sometimes they would buffer very small quantities of logs, which would cause large load on our pipeline. This would cause logs to be slow to load (and, in some cases, intermittently unavailable)
The solution
After close collaboration to said cloud providers, we have determined that the best course of action was to completely bypass their solutions for Lambda functions logs streaming and buffering, and develop our own: they do acknowledge that changes are needed in order to enable use cases like ours, but such changes aren't high priority for them.
With that in mind, we are now collecting the logs for Lambda function executions at the same time we collect the responses – at execution time. We then insert the logs into a highly performant data stream processor which reliably buffers the logs as per our configuration. In another words:
- Logs will no longer be dropped somewhere in the pipeline: they are collected and persisted right at execution time, excluding the possibility that we would invoke a function and not persist the resulting logs
- The buffers placed between the stdout/stderr of the Lambda functions and our long-term log storage are now behaving reliably and consistently, removing the unpredictable extra load from our long-term storage – accessing logs is now consistently snappy.
Future improvements
- We are working on short-circuiting the logs pipeline for real time streaming: if you are looking at the logs on the ZEIT Dashboard or using
now logs -fin the CLI, we'll make that more real-time by cutting some corners in the pipeline. - Log Drains: you'll be able to specify log drains for deployments under a project, so that you can bring your own log processing solution (Splunk, Papertrail, and friends). More news on that coming soon!
TLDR
We have made significant improvements to our log pipeline to ensure that logs are no longer missing and are always quick to access. In the coming months we will also improve real-time access and add Log Drains so that you can bring your own log processing solution.
I'm reopening the issue for visibility. Everyone is more than welcome to post any issues, questions, etc – I'll be around for anything related to logs :)
matheuss
on 13 Jun 2019
Closing due to age, and because logs on Now 2.0 are once again working.
TooTallNate
on 10 Aug 2019
Related issues
olivierlesnicki
·
36Comments
gadicc
·
48Comments
CaptainChemist
·
40Comments
jberglinds
·
59Comments
rgwozdz
·
40Comments
Most helpful comment
(TLDR at the end)
Hey everyone,
In the past few months you have been experiencing poor reliability of Now 2.0 deployment logs – many logs were missing and, quite often, slow to load.
I'm more than happy to share that, as of last week, we have deployed very significant improvements to how we collect and store logs,
The problem
The reliability were issues due to a few limits we've encountered on the cloud providers we use for Lambda functions – we found that the way they buffer logs from Lambda functions doesn't scale to the volume of logs we were processing. That would cause two major issues:
The solution
After close collaboration to said cloud providers, we have determined that the best course of action was to completely bypass their solutions for Lambda functions logs streaming and buffering, and develop our own: they do acknowledge that changes are needed in order to enable use cases like ours, but such changes aren't high priority for them.
With that in mind, we are now collecting the logs for Lambda function executions at the same time we collect the responses – at execution time. We then insert the logs into a highly performant data stream processor which reliably buffers the logs as per our configuration. In another words:
Future improvements
now logs -fin the CLI, we'll make that more real-time by cutting some corners in the pipeline.TLDR
We have made significant improvements to our log pipeline to ensure that logs are no longer missing and are always quick to access. In the coming months we will also improve real-time access and add Log Drains so that you can bring your own log processing solution.
I'm reopening the issue for visibility. Everyone is more than welcome to post any issues, questions, etc – I'll be around for anything related to logs :)