Also, I see the following in documentation: log Enables access/request logging
That’s an access log. Is there something similar for error log per-vhost? For example - where stderr from PHP would be logged, aborted requests (due to timeouts), denied access entries etc. would be logged.
Caddy 2 uses structured logging, which is how we recommend doing logging. It’s more efficient (zero-allocation, in fact) and provides more options for processing in a pipeline. Most users will not need to use more than the already-default log – maybe with minor customizations – in order to be able to do the processing they want. For example, if you need to split certain logs out to different files, your system can read each incoming log message for a certain field, and then switch which file it gets written to.
With Caddy 2, you’ll need to discard assumptions from old web servers and think about things in a new – usually simpler, more refined and compartmentalized – way.
@matt any suggestions for the error log per-vhost?
Regarding the log format - it’s totally fine for humans, but I guess log analyzers (stats: AWstats, webalizer, analog), firewalls (like CSF), control panels aren’t ready for Caddy format, unless custom hooks are written. This would slow our integration down, as that’d be a lot of work, but it’s doable… Just wanted to be sure there is no easy way to set combined log format in caddyfile.
Yes, like I said, just direct each log message to your preferred file based on the hostname of the request in the log message.
Well, this isn’t “Caddy format” – this is just JSON (but can be any structured log format), and it’s been around for a decade or more… unfortunately, Common Log Format and Combined Log Format aren’t very useful these days except in legacy systems, as you’ve noted. (For instance, CLF doesn’t even include the request’s hostname?? How is that even useful??)
There are numerous tools available which can ingest streaming log messages and direct them to files or where ever else.
Hm… I’m not sure which configuration option is used for that? (to filter stderr’s by domain name and direct them to files defined). We provide an option for end-customers to check their error-logs on Nginx/Apache/OpenLiteSpeed/LiteSpeed, because it’s hard for them to debug error cases otherwise. Or did you have some own-coded log parser in your mind?
But there must have been a reason why you’ve made this available Anyway, it’s clear that it’s unavailable for error logging and implementation isn’t planned. Thanks for letting me know this, I’ll just check/code some workarounds then.
Not really – dumping logs to files is pretty minimally expected even by most streaming log tools. But logic that splices and dices logs into different outputs based on the values of certain fields is much more complex and really quite a different problem domain.
I have /home/admin/public_html/index.php, which has a syntax error. FastCGI outputs it to stderr. Are you saying this stderr output from FastCGI interface gets logged to the caddy access/request log defined in vhost configuration?
That’s why I was asking in my initial post if there is any possibility to specify error_log for vhost, because I was unable to find it in documentation
I’m sure you log way more things to the error log, than just stderr from the fastcgi interface (denied access entries, timeouts etc.).
So, can we specify it per-vhost, or the only solution is to code something that reads main error log and splits it per-vhost? (I wouldn’t like to do this as it’s error-prone, would require parsing/locking etc…)
Like I said, aggregating and processing logs is outside the scope of the HTTP app of Caddy – all it does is emit logs. If you want to process them more specifically later, you can do that because they are structured logs, not the old-school rather useless “common log format”. There are a ton of tools that can process logs, and someday maybe a Caddy app will even be written just for log processing.
I would also like to be able to have two files, one for access/standard log, and the other one for errors. It was possible and convenient with Caddy 1, so it would be great for me if it would be possible with Caddy 2…