You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user who is instrumenting a service with fluent logging, I am concerned about blocking requests affecting my service in different scenarios:
The fluentd server going down or degrading.
Fluent requests slowing down the requests being processed by my service. I'd rather stop logging than degrading the performance of my service.
As a result I ended up incorporating asynchronous logging through a worker goroutine reading from a small memory buffer on top of your Go client. If the buffer gets full for whatever reason (logging slowing down, fluent going down ...), events will get dropped but the service won't be affected.
Admittedly, if my service goes down, the events inside the buffer will be lost, but I am perfectly fine with that.
I believe others would benefit from this scheme and probably should be shipped by default with the client.
My code is pretty ad-hoc at this point but I may consider cleaning it up and upstreaming it at some point.
The text was updated successfully, but these errors were encountered:
2opremio
changed the title
Add buffering to client
Add buffering/asynchronous requests to client
Jun 12, 2016
2opremio
changed the title
Add buffering/asynchronous requests to client
Add asynchronous requests to client
Jun 12, 2016
As a user who is instrumenting a service with fluent logging, I am concerned about blocking requests affecting my service in different scenarios:
As a result I ended up incorporating asynchronous logging through a worker goroutine reading from a small memory buffer on top of your Go client. If the buffer gets full for whatever reason (logging slowing down, fluent going down ...), events will get dropped but the service won't be affected.
Admittedly, if my service goes down, the events inside the buffer will be lost, but I am perfectly fine with that.
I believe others would benefit from this scheme and probably should be shipped by default with the client.
My code is pretty ad-hoc at this point but I may consider cleaning it up and upstreaming it at some point.
The text was updated successfully, but these errors were encountered: