<div dir="ltr">Thanks a lot for feedback, it's very interesting to look at things through different eyes.<div><br></div><div>From myself I would add about pipes:<div>- <a href="http://www.pixelbeat.org/programming/stdio_buffering/">http://www.pixelbeat.org/programming/stdio_buffering/</a><br></div><div>- <a href="https://brandonwamboldt.ca/how-linux-pipes-work-under-the-hood-1518/">https://brandonwamboldt.ca/how-linux-pipes-work-under-the-hood-1518/</a><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-11-29 9:12 GMT+03:00 Geoff Cant <span dir="ltr"><<a href="mailto:nem@erlang.geek.nz" target="_blank">nem@erlang.geek.nz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><fireside-chat-mode><br>
"12 Factor” (aka <a href="https://12factor.net" rel="noreferrer" target="_blank">https://12factor.net</a>) is a set of conventions to make linux applications easier to run in containers and to allow those containers to be managed and orchestrated uniformly. These conventions were established by one of Heroku’s co-founders, Adam Wiggins (hi Adam!), and are mostly still good ways to adapt linux applications to running on a Platform as a Service (Heroku/CloudFoundry/Deis/<wbr>Flynn/Mesosphere/Kubernetes/…)<wbr>. 12 Factor is a little dated now - it’s last update was in 2012, but the ideas are still mostly relevant.<br>
<br>
<br>
In the case of logging, the reasoning behind the stdout convention is that is was a relatively easy to implement (for the app developer), language/framework independent approach to getting a real-time ish stream of logs out of any application. The platform the application runs on can then handle log forwarding and distribution uniformly. This would have been hard to impossible to do if every application was allowed to choose its own method for emitting log events (syslog vs stdout vs files vs snmp traps vs probably lots of other things). Logs as files, in particular, would have to be a complicated convention (where do you write them, how many files do you write, how are they rotated, do they get truncated to avoid running out of space, what constitutes a complete message in a file if you’re trying to stream them, ...), and this complexity would have been development costs paid in every single application for the PaaS.<br>
<br>
The corollary of this is that if you’re not running your application on a PaaS, then you’re not going to get much benefit from writing logs to stdout.<br>
<br>
<br>
Aside: I worked on Heroku’s log pipeline systems for a while, and like to see this factor revisited. ‘\n' framed opaque-byte messages on stdout is a protocol due for improvement: you can’t write neatly formatted multi-line messages and have them pass through the log pipeline very easily (change the framing), it’s an async one-way protocol (there’s no facility for reliable transmission of messages, so you can’t use it for audit logs), it is sub-optimal transmission format for sending metrics (metrics can be aggregated during transport, and logs can’t). So let’s hope there are some updates to 12 factor in 2017. I have quibbles about configuration passed as environment variables too, but unix doesn’t offer a lot of good choices here.<br>
</fireside-chat-mode><br>
<span class="HOEnZb"><font color="#888888"><br>
-Geoff<br>
</font></span>ps: yeah - use lager. It’ll work both on a PaaS and your own box.<br>
<div class="HOEnZb"><div class="h5"><br>
> On 28 Nov, 2016, at 18:05, Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>> wrote:<br>
><br>
><br>
><br>
> On 25/11/16 11:34 PM, Alexander Petrovsky wrote:<br>
>> - Hey, boy, did you know about 12 app factor (*oh my god*)?<br>
><br>
> "12-factor app" was not handed down on Mt Sinai;<br>
> Jibril did not dictate it to the Prophet;<br>
> Joseph Smith Jr never found it on the golden plates.<br>
> Heck, even Raël never heard about it from the elohim.<br>
><br>
> "12-factor app" is OPINION.<br>
><br>
> Using lager, the vast bulk of your code doesn't know and<br>
> doesn't care where the logs are going.  It *can* go to<br>
> stdout if that's what you want.<br>
><br>
> On the other hand, if you need log rotation and such,<br>
> and you only write to stdout, then you have to depend<br>
> on something outside your application to do it.<br>
><br>
> stdout is where information is sent to die.  (:-)<br>
><br>
> ______________________________<wbr>_________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Петровский Александр / Alexander Petrovsky,<br><br>Skype: askjuise<br><div>Phone: +7 914 8 820 815<div><br></div></div></div></div>
</div>