-
Notifications
You must be signed in to change notification settings - Fork 75
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
Logging not working, or not well documented #91
Comments
Hi @dmlond! Yep, the likelihood is gruf may not have its railtie configured properly for Rails 6. I have tested it with Rails 5 and know it's compat there, but YMMV on how you've got logging initialized with 6. |
ok. thanks for letting me know. |
@dmlond I'll see about getting some time this week to test Rails 6 and see what changes may have affected logging. Thanks for raising this! |
great! thanks for building this. I am writing a rails 5 version of my rails 6 grpc service for now. |
I am still seeing the same behavior in a rails 5.2.4.1 server. I am running the gruf command. It is loading the gruf.rb initializer, it logs the hostname, then starts the GRPC server, then nothing gets logged again to STDOUT until after I stop the service. I am not sure what I am doing wrong. |
Oh, okay. So the
LOG_LEVEL_MAP = {
'GRPC::Ok' => :debug,
'GRPC::InvalidArgument' => :debug,
'GRPC::NotFound' => :debug,
'GRPC::AlreadyExists' => :debug,
'GRPC::OutOfRange' => :debug,
'GRPC::Unauthenticated' => :warn,
'GRPC::PermissionDenied' => :warn,
'GRPC::Unknown' => :error,
'GRPC::Internal' => :error,
'GRPC::DataLoss' => :error,
'GRPC::FailedPrecondition' => :error,
'GRPC::Unavailable' => :error,
'GRPC::DeadlineExceeded' => :error,
'GRPC::Cancelled' => :error
}.freeze So unless you have You can override this map via the c.interceptors.use(
Gruf::Interceptors::Instrumentation::RequestLogging::Interceptor,
formatter: :logstash,
log_levels: {
'GRPC::InvalidArgument' => :info,
}
) |
in https://github.com/bigcommerce/gruf/blob/master/lib/gruf/server.rb at line 88, the start! method creates a thread, logs logger.info { "Starting gruf server at #{@hostname}..." }, then runs server.run. In my logs for the running server, I see the following at startup:
I make a request to the grpc service, and get a response, but I do not see anything new in the log. I then stop the grpc server, and the following prints to the log:
I could make lots of requests to the service, but nothing is logged until I stop the server. The key for me is the line that says 'log writing failed. can't be called from trap context'. There is something about running the server in a Thread that is preventing log output until the server shuts down |
that may be an issue with rails logger. i think by default gruf sets |
I had a similar issue where the gruf logs were not synced immediately, but synced after some number of grpc requests. Setting |
Got the same issue, already killed about 6-8 hours on it, and still no luck, none of the solutions above helped. Any other ideas on how to get Gruf logs to the STDOUT instantly and not just on shutting down the app? |
|
Closing this - feel free to open another, specific issue if you'd like more clarity in the docs, or find a bug/issue related to this again. Thanks! |
Please describe the issue
I am trying to log information to the log the way I can in a normal rails application
A clear and concise description of what the bug is.
I am trying to add a GRPC service to an existing rails 6 api service. It may be that gruf isnt ready for rails 6.
I have the following in config/initializers/gruf.rb
I have tried putting the following in my Controller (which inherits from Gruf::Controllers::Base)
I also add the following line after the logger.error line to immediately fail the request, which should also log
This results is a fail response in my client, and nothing is logged
When I ctrl-c the server, the following logs before shutdown:
I have tried adding the following line to my Controller with the logger.error and fail lines
I get the fail response exception in my client
I do not see anything output in the log until I ctrl-C the server, then I get the following in my log output:
How to Reproduce
Steps to reproduce the behavior:
What should happen?
it should log to the logger output (STDOUT)
Describe what expected behavior should be.
Anything else we should know?
no all the time
The text was updated successfully, but these errors were encountered: