はてなブックマーク
http://b.hatena.ne.jp/search/tag?q=＜keyword＞&users=3&mode=rss
※ 最低はてブ数を変えたいときはusersをいじる
Slideshare
https://www.slideshare.net/rss/tag/＜keyword＞
Qiita
https://qiita.com/tags/＜keyword＞/feed

その分野で精力的に情報発信している人が居れば、以下のURIでQiitaやSlideshareがストーキングできます。

Slideshare
https://www.slideshare.net/rss/user/＜username＞
Qiita
https://qiita.com/＜username＞/feed.atom

あと、個人的にはDevelopers.IOも追いかけてます。

https://dev.classmethod.jp/category/cloud/＜keyword＞/feed/ とか

特定のブログを追いかけたいときは、メジャーどころなブログエンジンなら、ソース開いて「feed」とか「atom」「rss」あたりを検索すればRSSフィードのURIがmeta要素とかに入っているので、そこから持ってきます。

2019-06-24

デザインテーマ変えてみました

こちらのMinimalismにしてみました。

あと、いいかげん記事も増えてきてるのでサイドメニューとか整理しました。

hitsuzi.hatenablog.com

2019-06-22

Dockerのログ出力先

Docker

ツイートしてて自己完結してしまったので記録のために。

あーそういや今更だけど、stdoutとstderrはまとめてlogging driverに渡されちゃうのか。どちらなのかはdriverには渡っているのでfluentdに出せばラベル付いてるので、ログのことだけ考えれば仕組み的にはどちらに出しても扱うこと自体には問題が無さそう。
— Aki (@nekoruri) June 22, 2019

デーモンアプリケーションで想定外のエラーが出うるのであれば、構造化ログをstdoutという分離は全然ありうると思う。
— Aki (@nekoruri) June 22, 2019

でもそうしちゃうとエコシステムから外れちゃうので、やっぱり最大公約数としてはparseableなテキストでstdout/stderrかなあという気がしてきた。やはりDockerにfile descripterの概念が欲しい。チャンネル2個じゃ足りない。
— Aki (@nekoruri) June 22, 2019

理想論はさておき、現実的にはやはりコンソールアプリならstderr、デーモンアプリケーションならstdoutに構造化ログ(JSON)を出してlogging driverで振り分けてparse、stderrは想定外の非構造化エラーログに備える、が万能そう。
— Aki (@nekoruri) June 22, 2019

Dockerを使う最大のメリットは、その「踏み込んだ割り切り」という制約によるエコシステムなので、エコシステムから外れた時点で負けなんだよなあ……。Railsで車輪ガン無視しても別にアプリ書けるけどそれRailsじゃなくていいよねって話と同じ。
— Aki (@nekoruri) June 22, 2019

前提と考察

Unixの世界では、stdout(標準出力)とstderr(標準エラー出力)という二つの出力チャンネルが標準として提供されている。
Twelve-Factor Appでは、アプリケーション側はログをイベントストリームとして出力し、実行環境側のほうで開発環境であればstdout、運用環境ならばfluentdなどに送って処理するべきとされている。
近年[要出典]のログは、そもそも古臭いNCSA combinedアクセスログのような複雑怪奇な正規表現で取り出すようなテキストではなく、最初からJSONやLTSVなど構造化されたデータとして扱われるべきものである。
Dockerではコンテナのログをlogging driverという仕組みで処理し、stdoutとstderrを1行1エントリとしてloggin driverに送る。logging driverは標準出力なりFluentdなりAWS CloudWatch Logsなりに送る。
コンソールアプリでパイプ使う場合は、docker runに-aでstdoutだけ出力できるので、きちんとやる必要があれば出力はstdoutでパイプにつなぎ、ログはstderr経由でloggin driver送り、という使い分けができそう(未確認)