4 ms·

I might be missing something, but wouldn't the point be that it's not the log writer's responsibility to do this, but rather some other service that consumes th

I might be missing something, but wouldn't the point be that it's not the log writer's responsibility to do this, but rather some other service that consumes the unparsed output and sends the notification?

keyle 5y ago
Agreed. It's all nice to have. People want push. You can eat your pizza slice whichever way you want. Arguably this would be useful for critical events.
makeitdouble 5y ago
This is the obvious solution now. I think 20 years ago it would have been slammed as overkill to have a separate process just to send logs. Even now actually, there is a flurry of libs/gems to send events/logs/analytics to a remote server (Datadog, NewRelic, Slack…)from the application itself. It’s usually not directly coupled with the logger, but it’s not far.
- abhishekjha 5y ago
  Apps do send metrics from the process itself. Dropwizard metrics comes to mind. Wonder what timing RCE is waiting to happen there.
- Thorrez 5y ago
  Putting a feature in a logger to send logs remote is one thing. Putting a special syntax into the log message itself that gets parsed to decide where to send it is much weirder.
  - tmd83 5y ago
    Exactly and this being enabled by default seems specially more unusual. I can understand config being parseable even though log configurer directly pulling a remote config is a stretch specially by default. But I don't think it's unlikely that people would by default assume that their log message would be parsed that way and as someone said it even works if that's used as a user input using {} instead of +.
- spc476 5y ago
  syslog() has been around for a lot longer than 20 years, and that's a function that logs to a separate process. What's so bad about syslog that people need to invent new logging systems?
  - funcDropShadow 5y ago
    Because it is not portable and therefore not the blessed Java entreprise way of doing things. /rantoff

keyle 5y ago

Agreed. It's all nice to have. People want push. You can eat your pizza slice whichever way you want. Arguably this would be useful for critical events.

makeitdouble 5y ago

This is the obvious solution now. I think 20 years ago it would have been slammed as overkill to have a separate process just to send logs. Even now actually, there is a flurry of libs/gems to send events/logs/analytics to a remote server (Datadog, NewRelic, Slack…)from the application itself. It’s usually not directly coupled with the logger, but it’s not far.

abhishekjha 5y ago
Apps do send metrics from the process itself. Dropwizard metrics comes to mind. Wonder what timing RCE is waiting to happen there.
Thorrez 5y ago
Putting a feature in a logger to send logs remote is one thing. Putting a special syntax into the log message itself that gets parsed to decide where to send it is much weirder.
- tmd83 5y ago
  Exactly and this being enabled by default seems specially more unusual. I can understand config being parseable even though log configurer directly pulling a remote config is a stretch specially by default. But I don't think it's unlikely that people would by default assume that their log message would be parsed that way and as someone said it even works if that's used as a user input using {} instead of +.
spc476 5y ago
syslog() has been around for a lot longer than 20 years, and that's a function that logs to a separate process. What's so bad about syslog that people need to invent new logging systems?
- funcDropShadow 5y ago
  Because it is not portable and therefore not the blessed Java entreprise way of doing things. /rantoff