Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a PASSENGER_MAX_LOG_LINE_BYTES option increase the number of characters allowed per log line #2442

Closed
wants to merge 1 commit into from

Conversation

tsu-shiuan
Copy link

@tsu-shiuan tsu-shiuan commented Sep 6, 2022

An attempt to resolve #2413

My particular issue with Passenger splitting logs into multiple lines is that we use Filebeat to pipe logs to Logstash, and Logstash expects our Rails logging to be in json format. In cases where we have long stack traces, these multiline logs end up not being parsed correctly (with a _jsonparsefailure on the Logstash side). Whilst there are multiline configurations available for both Filebeat and Logstash, it's recommended to use mulitline configs in Filebeat over Logstash. However, since Passenger appends App #{pid} output: to each of the log lines, it means we'd need to strip out the extra text before stitching logs together. Whilst I also know the latest version of passenger contains the option to remove the App #{pid} output: prefix, it feels a bit simpler to just be able to configure Passenger to log larger contents into a single line without breaking it up.

I tried looking at previous pull requests to figure out whether there's anywhere I would need to add this to the documentation, but couldn't find anything. Happy to add it if I'm pointed in the right direction.

Any feedback would be great! Thanks :)

@CamJN
Copy link
Member

CamJN commented Sep 13, 2022

This does a dynamic allocation in the hot path, it'll be too slow. Sorry.

@tsu-shiuan
Copy link
Author

This does a dynamic allocation in the hot path, it'll be too slow. Sorry.

Would it be acceptable to have it as a start-up arg then that's passed down to the PipeWatcher? If I'm understanding you correctly, you're suggesting that dynamically allocating the value where I've done it is too late and inefficient.

@CamJN
Copy link
Member

CamJN commented Sep 15, 2022

Just moving the allocation into the constructor might be enough, i'd recommend trying that and running a test to see how it performs.

@jtomson
Copy link
Contributor

jtomson commented Dec 7, 2022

Just moving the allocation into the constructor might be enough, i'd recommend trying that and running a test to see how it performs.

I've taken a stab at this in #2458 since this PR has maybe stalled?

@CamJN
Copy link
Member

CamJN commented Jan 18, 2023

superseded by other PR

@CamJN CamJN closed this Jan 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Application log lines > 8KB are split across multiple log lines by Passenger
3 participants