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

Elastic Beanstalk example doesn't support Rails application log file monitoring #201

Open
brian626 opened this issue Mar 21, 2017 · 3 comments

Comments

@brian626
Copy link

Hi,

First off - thanks for all the hard work that's gone into the integration documentation and examples! Really made it easy to get started with Papertrail.

I'd like to suggest one improvement to the Elastic Beanstalk example, however. As written, examples/remote_syslog.ebextensions.config uses a container_command to restart remote_syslog. However, container_command items are executed prior to deployment - that is, after the application has been extracted to /var/app/ondeck/ but before it's been deployed to /var/app/current/.

I wanted to monitor the Rails application log file at /var/app/current/log/production.log, but the daemon gets confused if it's started in a container_command, since /var/app/current/ will later be deleted and replaced by /var/app/ondeck/. The symptom is that Papertrail is successfully running and monitoring all files except the one under /var/app/current/, and the problem can be worked around by ssh'ing and executing sudo /sbin/service remote_syslog restart.

My solution (found at https://github.com/brian626/remote_syslog2/tree/eb_example) is to move the restart to a post-deploy hook. That way, /var/app/current/ has already been deployed and the daemon doesn't get confused. Unfortunately, Elastic Beanstalk does not provide an official way to add post-deploy hooks, so it involved a bit of a hack - namely, dropping a script into a specific directory.

This might not be widely applicable to common Papertrail/Elastic Beanstalk integrations, but I thought I'd write it up in case anyone else was having trouble.

@brian626 brian626 reopened this Mar 21, 2017
@brian626
Copy link
Author

Sorry - forgot that I meant to test using /var/app/support/logs/production.log (which is a symlink to /var/app/current/log/production.log, with the exception that /var/app/support/ persists between deploys) but that does not help.

@SimonVillage
Copy link

SimonVillage commented Aug 29, 2017

Can you explain your solution for this problem? We have the same issues and could figure out how to do a workaround.

Edit

Got it. You posted the link to the changed file :) Thanks!

@markdascher
Copy link
Contributor

Confirmed with @TAiS46 that the latest release v0.20-beta2 pre-release also solves this problem, by periodically checking for stale files.

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

No branches or pull requests

3 participants