log4jの割とでかい脆弱性が世間を賑わせていますねー。年に一度のお祭りといった趣。このサイトのアクセスログにすら出てきてます。Wordpress丸出しで、まあだいぶ古いですがnginxとphp-fpmだから(リプレースしたい)、log4jを使ってるとは思えないはずですが、まあインターネット全体が見境なくフルスキャンされまくってるってことなんでしょうね。

このサイトは「ログ取得ツール」という名前にしていますけど、ログの取得と蓄積はソフトウェア技術においてはかなり重要度の高いもので、適切なログを吐くコードになってるかというのはプログラマが優秀かそうでないかを見分ける要素の一つだったりしますね。何かトラブルが起きた時は必ずログを見るわけで。それは昔から、このサイトを作った頃(2008年)にはすでにそうで、もしかしたら先代サイトの2003年ですらそうで、それから今に至るまで、変わりません。このくらい続くと、もはや「真理」と言ってもいいのでは？

最近はメトリック情報とかトレース情報とかも含めて、データ処理の効率も上がっているので、そいつらも広義のログではあります。またロガーを使ったログの重要性もより高まっていると言えると思います。

私も仕事でJavaを使っていた頃はロガーはSLF4j? logbackか何かを使ってファイルに吐いてたと思います。途中から参画したからそうなった経緯はよく分からないけど、詳しい人が選定したんじゃないかな、たぶん。最初にリリースした頃に、自前でローテートの設定を入れてたなー。今回問題になってるのは、その頃に開発されて今も現役のプログラムかもね。

今はPythonなので標準ロガーです。これは自分がノータイムで選んだ。標準機能で済むものは標準で。Pythonのloggingモジュールは割とよくできてるしね。昨今はだいたいコンテナ環境ですから、ファイルに出すとかsyslogに出すとか考えることはなくなって、シンプルに標準出力に吐いとけばそれで済む世界になってるよね。あとはOpenTelemetryでトレース情報をjaegerとかに出す設定にして。OpenTelemetryは、OpenTracingって言ってた頃に採用したから、そのあとAPIも名前も色々変わって大変だった。変わって何かと便利になったのは認めるけれども、さすがに途中でバージョン固定する羽目に…標準以外のものを使うと、こういう非互換変更に振り回されがち。