<div dir="ltr">For pushing to ELK, why not use something more efficient like Kafka or Flume? ZeroMQ might be better there, too, but it's about as reliable as normal socket programming (i.e., in-memory messages are all lost in the event of a crash). I'm not a big fan of pulling in heavyweight messaging protocols or frameworks like JMS or AMQP nowadays for things like logging.</div><div class="gmail_extra"><br><div class="gmail_quote">On 18 March 2017 at 19:02, Adam Gent <span dir="ltr"><<a href="mailto:adam.gent@snaphop.com" target="_blank">adam.gent@snaphop.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Matt,</div><div id="m_2693522875122947351AppleMailSignature">We use a push model (pros and cons to both) with AMQP to ELK.</div><div id="m_2693522875122947351AppleMailSignature"><br></div><div id="m_2693522875122947351AppleMailSignature">But even if you use a pull model you may want to log out meta data (like region or version info) which would come from a metadata service.</div><div id="m_2693522875122947351AppleMailSignature"><br></div><div id="m_2693522875122947351AppleMailSignature">We log like 30 or so attributes per event. I'll have to look how many come from the metadata services.<br><br>Sent from my iPhone</div><div><div class="h5"><div><br>On Mar 18, 2017, at 7:16 PM, Matt Sicker <<a href="mailto:boards@gmail.com" target="_blank">boards@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Kryo was already brought up, but on Android, if no-op logging is somehow affecting performance (is Android's JVM *that* terrible that it can't optimize that away? or is that an issue with the various ARM CPUs not doing branch prediction well enough?), then just stick to using Minlog from Kryo.<div><br></div><div>As for the error message on startup: it's definitely an error, not a warning. An error indicates that a thing is broken, and in this case, that means you forgot a dependency or you're in some strange ClassLoader environment that didn't link the two libraries together properly. Log4j2 has a similar error message.</div><div><br></div><div>Now I know this doesn't solve everyone's use case, but for all you users depending on Zookeeper or whatever to get logging configuration info, have you considered just writing logs to stdout and collecting those log messages via something like graylog? It's a lot easier to make things consistent across dozens or hundreds of instances that way.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 March 2017 at 17:24, Adam Gent <span dir="ltr"><<a href="mailto:adam.gent@snaphop.com" target="_blank">adam.gent@snaphop.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Like I said in another thread I concede particularly on the<br>
performance part. You have successful bashed me into thinking it was a<br>
terrible idea to bring up. Your points are all valid and I was more on<br>
your side than you think. I also frankly don't have the time to make<br>
terribly compelling arguments ... nor your apparent skill.<br>
<br>
However I do think I have a strong understanding of what SLF4J does (I<br>
almost take that particularly comment as an insult but I said you had<br>
stockholm syndrome sooo anywhoo :P).<br>
<br>
BTW the library isn't setting an application-wide policy its just<br>
ignoring the one the users is picking unless they explicit tell it not<br>
to (I used the serviceloader but you could use system properties or<br>
any  many other things... but I concede this is generally just making<br>
shit worse).<br>
<span><br>
> I'm still waiting to see one of those 20% cases...<br>
<br>
</span>I guess I failed to explain the configuration requiring logging issue<br>
or you are just ignoring that part. It just feels wrong to make<br>
Appenders or whatever logging framework specific code to do that sort<br>
of initialization. And yes I understand the event replay.<br>
<br>
How do you configure your logging framework? We have code that presets<br>
System.properties (since sadly system.properties is the universal<br>
config) before the logging framework. Do you just hard code it and<br>
rely on some external mechanism for collecting logs? Remember I'm<br>
dealing with several logging backends.<br>
<div class="m_2693522875122947351HOEnZb"><div class="m_2693522875122947351h5"><br>
<br>
On Sat, Mar 18, 2017 at 5:57 PM, Joachim Durchholz <<a href="mailto:jo@durchholz.org" target="_blank">jo@durchholz.org</a>> wrote:<br>
> Am 18.03.2017 um 20:04 schrieb Adam Gent:<br>
>><br>
>> I generally agree with your points but I also know there are plenty of<br>
>> people that completely disagree.<br>
>> Just check out<br>
>> <a href="https://bill.burkecentral.com/2012/05/22/write-your-own-logging-abstraction/" rel="noreferrer" target="_blank">https://bill.burkecentral.com/<wbr>2012/05/22/write-your-own-logg<wbr>ing-abstraction/</a><br>
><br>
><br>
> That post motivates writing yet another SLF4J replacement to get rid of both<br>
> SLF4J and whatever backends are being used, reinventing the SLF4J wheel.<br>
> He's writing a logger facade to end all logger facades -<br>
> <a href="https://xkcd.com/927/" rel="noreferrer" target="_blank">https://xkcd.com/927/</a> comes to mind.<br>
><br>
> Or maybe he's writing his own logger library. In which case all the<br>
> 3rd-party libraries he's using are still happily logging to whatever (now<br>
> left-unconfigured) backend they always have been logging to.<br>
><br>
>> This would be an effort to some what mitigate those who have concerns<br>
>> have SLF4J and its depenency.<br>
><br>
><br>
> The post actually focuses on dependency hell.<br>
> Except it's no hell with SLF4J - newer versions are generally API-compatible<br>
> with older versions, so you simply use the newest version of SLF4J.<br>
> And you use whatever backend you want, be it JUL, commons logging, log4j, or<br>
> even logback - SLF4J can talk to all of them, in whatever version you're<br>
> throwing at it.<br>
><br>
>> I also wonder if your general opinion isn't stockholm syndrom.<br>
><br>
><br>
> Nope.<br>
> In fact I dislike a few things about SLF4J, but they are different from your<br>
> pain points.<br>
> My impression is that you're working off some very basic misunderstanding of<br>
> how SLF4J works, but I can't put my finger on it. I've been trying to sort<br>
> that out, but whenever I explain something, you continue with a totally<br>
> unrelated topic and one message later you still stick with the idea I tried<br>
> to explain away two messages ago. It's a bit frustrating, and I may give up<br>
> on that - maybe somebody else has more luck.<br>
><br>
>> Do you have any idea how many people hate:<br>
>><br>
>><br>
>> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBi<wbr>nder".<br>
>> SLF4J: Defaulting to no-operation (NOP) logger implementation<br>
>> SLF4J: See <a href="http://www.slf4j.org/codes.html#StaticLoggerBinder" rel="noreferrer" target="_blank">http://www.slf4j.org/codes.htm<wbr>l#StaticLoggerBinder</a> for<br>
>> further details.<br>
><br>
><br>
> Yeah I hated that, too.<br>
><br>
>> As a library writer it is fairly annoying to have to deal with users<br>
>> complaining about.<br>
><br>
><br>
> WTF?<br>
> If I'm an application writer, I visit the URL given, read that all I need to<br>
> do is to explicitly add a backend adapter to the class path, then I do it.<br>
> If I'm a library writer and application writers come to me complaining, I<br>
> tell them to Read The Friendly Error Message and buzz off.<br>
><br>
> Really. It's SLF4J telling you you misconfigured it, and it's going to do<br>
> its best but please fix that.<br>
> Maybe SLF4J should mark this as a WARNING so people don't get scared if they<br>
> see "failed to load class", though the second line of text actually tells<br>
> you what's going on.<br>
><br>
> I hated seeing that message, but the fix was just a dependency in the main<br>
> application's(!) dependencies (you don't add it to a library, nope, no,<br>
> never - it could be used as a scope=test dependency but that's about it).<br>
><br>
>>> How would the library know whether it's called in Android?<br>
>>> Should it even care?<br>
>><br>
>><br>
>> Yes. The reality is often it has to. Maybe not the code itself but the<br>
>> library maintainers might have to be concerned with Android (this<br>
>> includes backporting at times).<br>
><br>
><br>
> If the code does not have to care, then it shouldn't configure the logging<br>
> backend.<br>
><br>
>> Of course if you don't care about Android...<br>
><br>
><br>
> Oh I do.<br>
><br>
>>> Your proposal does not change anything about the performance of trace<br>
>>> messages.<br>
>><br>
>><br>
>> Yes it does! I have benchmarked it myself... but alas I don't feel<br>
>> like pulling JMH out now nor the hassle of dealing with Android to<br>
>> prove such.<br>
><br>
><br>
> Benchmarking is notoriously tricky, and it is very, very easy to measure<br>
> something totally different than what you think.<br>
> So to make sure that your claim is based on actual performance, you need to<br>
> have somebody independent double-check your test code and your measurements.<br>
><br>
>> Unless you are extremely careful about configuration or<br>
>><br>
>> just always globally using the NOPLogger there is generally some<br>
>> overhead the logging framework will do per call.<br>
><br>
><br>
> Since the noop looger does nothing, it's pretty impossible to have extra<br>
> overhead.<br>
><br>
>> Now I admit this is a<br>
>><br>
>> while ago and I can't remember what logging framework was underneath.<br>
>> Maybe logback does a better job. I can't imagine it some how has<br>
>> specially loggers for each level (or maybe it does).<br>
><br>
><br>
> As I already explained elsewhere, it has just a small three-field<br>
> configuration object per "logger".<br>
> Initialization and configuration are done just once, anything else would be<br>
> madness.<br>
><br>
>>> That's a solved problem: SLF4J is collecting log messages during startup,<br>
>>> and emitting them once the backend is ready.<br>
>><br>
>><br>
>> That doesn't fix anything. I have to now figure out how to intercept<br>
>> the backend before it does whatever you know like connecting to a<br>
>> message queue.<br>
><br>
><br>
> Why do you still need to do that?<br>
><br>
>> Really... I don't think you realize how successful you guys have been<br>
>> in getting everyone to use SL4J.<br>
><br>
><br>
> That's unrelated - logging has been a thing long before even Java entered<br>
> the scene.<br>
> It's just that with Java, writing servers became commonplace, and since you<br>
> can't usefully run a debugger on a server, logging is your substitute.<br>
><br>
>> Application startup time is a big deal... it is the number one hate of<br>
>> Java I hear most.<br>
><br>
><br>
> Yeah, but SLF4J is pretty innocent.<br>
> Swing is pretty slow to start, so interactive software used to take a looong<br>
> time to start up.<br>
> Plus with Hotspot (i.e. the JVM that's standard everywhere except Android),<br>
> any application starts fully interpreted, has the JIT compiler eat CPU<br>
> cycles in the background, and only after a while it becomes fast.<br>
><br>
>> But you missed my point that most library consumers (applications)<br>
>> really just don't give crap about what their libraries are logging.<br>
>> And when they really really do they can go to the libraries web site<br>
>> and figure out how to turn on logging. I mean you have to figure out<br>
>> the logger names anyway.<br>
><br>
><br>
> Yeah, but my point is that the library shouldn't try to set an<br>
> application-wide policy. It shouldn't even set a logging policy for itself,<br>
> because it cannot know what context it is running in.<br>
><br>
>> My point was I only care about the parent framework and my<br>
>> applications codes logging. It seems a shame to have innocuous<br>
>> libraries  instantiating 1-3 different libraries indirectly (depending<br>
>> on how many wrappers, bridges, and converters you are using). It is<br>
>> just the kind of thing people complain about Java.<br>
><br>
><br>
> Actually SLF4J cuts down on that: you have only one backend, not three.<br>
> This also means you have only one configuration, so startup becomes faster.<br>
><br>
>> All in all I was *trying* to improve the adoption of SLF4J and have it<br>
>> handle more than 80/20 but 100 of most use cases.<br>
><br>
><br>
> I'm still waiting to see one of those 20% cases...<br>
> ______________________________<wbr>_________________<br>
> slf4j-user mailing list<br>
> <a href="mailto:slf4j-user@qos.ch" target="_blank">slf4j-user@qos.ch</a><br>
> <a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" rel="noreferrer" target="_blank">http://mailman.qos.ch/mailman/<wbr>listinfo/slf4j-user</a><br>
<br>
<br>
<br>
</div></div><span class="m_2693522875122947351im m_2693522875122947351HOEnZb">--<br>
CTO<br>
SnapHop (<a href="http://snaphop.com" rel="noreferrer" target="_blank">snaphop.com</a>)<br>
(twitter) @agentgt (linkedin) <a href="http://www.linkedin.com/in/agentgt" rel="noreferrer" target="_blank">http://www.linkedin.com/in/age<wbr>ntgt</a><br>
(cell) <a href="tel:781-883-5182" value="+17818835182" target="_blank">781-883-5182</a><br>
</span><div class="m_2693522875122947351HOEnZb"><div class="m_2693522875122947351h5">______________________________<wbr>_________________<br>
slf4j-user mailing list<br>
<a href="mailto:slf4j-user@qos.ch" target="_blank">slf4j-user@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" rel="noreferrer" target="_blank">http://mailman.qos.ch/mailman/<wbr>listinfo/slf4j-user</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_2693522875122947351gmail_signature" data-smartmail="gmail_signature">Matt Sicker <<a href="mailto:boards@gmail.com" target="_blank">boards@gmail.com</a>></div>
</div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>slf4j-user mailing list</span><br><span><a href="mailto:slf4j-user@qos.ch" target="_blank">slf4j-user@qos.ch</a></span><br><span><a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" target="_blank">http://mailman.qos.ch/mailman/<wbr>listinfo/slf4j-user</a></span></div></blockquote></div></div></div><br>______________________________<wbr>_________________<br>
slf4j-user mailing list<br>
<a href="mailto:slf4j-user@qos.ch">slf4j-user@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" rel="noreferrer" target="_blank">http://mailman.qos.ch/mailman/<wbr>listinfo/slf4j-user</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Matt Sicker <<a href="mailto:boards@gmail.com" target="_blank">boards@gmail.com</a>></div>
</div>