🪵 Go1.21 log/slogパッケージ超入門
はじめに 2023年8月9日(日本の場合)Go1.21がリリースされました🎉。Go1.21ではさまざまな変更点や追加機能が加わります。その中でもGo標準ライブラリに導入される構造化ロギングパッケージlog/slog(以下、slog)を楽しみにしている方は多いのではないでしょうか？ 本稿では、slogを実際に触りつつ、機能の解説をしていきます。 TL;DR 本稿の概要をスライドにもまとめているので、ご参考にして下さい。 従来のlogパッケージについて slogの説明に入る前に、Go標準のlogパッケージについて簡単に紹介する。logパッケージを用いると、 io.Writer インターフェースを実装する任意の型にログメッセージを書き込むことができる。しかし以下のような制限があった。 ログレベルをサポートしていない ログレベルはほとんどのログパッケージの定番機能の一つだが、logパッケージには
マイクロサービスのアプリケーションログ転送量の抑制と改善 | DevelopersIO
はじめに こんにちは。こむろ＠事業開発部です。あ、今回も改善の話です。新機能開発とかそういった話はありませんのであしからず。 所属している事業開発部では、prismatixというECプラットフォームサービスを開発・運用しております。ECですので、商品の管理、検索、購入や会員管理等の多種多様な機能があり、それぞれのサービスでは日々膨大なアプリケーションログを記録しています。 アプリケーションログは正常動作している時は、あまり必要ではないのですが、いざ何らかの問題が発生した際に、原因究明やデータ復旧には欠かせないデータです。従って保険としてできれば全てを保存しておきたいところです。 しかしながら、このログの保存。機能の数やリクエスト規模にもよりますが、膨大が故に非常にお金がかかります。そして正直なところ大抵は利用されないゴミです。 *1 このあたりの話については、Release It! 本番用
ロギングベストプラクティス - kawasima
#翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
ログ設計指針
概要 このドキュメントは、効率的かつ安定した、システム開発/運用をするためのログ設計指針です。 的確かつ無駄のない、ログ出力を目指します。 ログレベル ログの緊急度や用途により、以下のようにログレベルを設定する。 Log4j のログレベルを踏襲しているため、運用の状況によっては Critical などのレベルを適宜追加すると良い。 PHP における PSR-3 では、さらに細分化され emergency, alert, critical, error, warning, notice, info, debug となっている。 「出力先」「運用時の対応」は、各プロジェクトのポリシーに準じてください。 レベル 概要 説明 出力先 運用時の対応
java.util.loggingの闇 - nekop's blog
Javaの1.4からjava.util.logging(以下JULと表記)というロギングパッケージが標準で使えるようになって、ログ出力のためにlog4jなどのサードパーティライブラリをいちいち導入したりする必要がなくなりみんな幸せになりました。 と言いたいところですこいつが超不便なAPIをしていてとてもとてもとっっっても使い辛い。ふざけんな。 まずさらっと使ってみましょう。Java 7です。 Logger.getGlobal().info("log") Logger.getLogger("foo").info("log") 出力はこうなります。 Jan 15, 2015 5:11:41 PM JUL main INFO: log Jan 15, 2015 5:11:41 PM JUL main INFO: log はい、キモイですね。軽くつっこむと なんで2行なんだよ 日時AM/PM表記か
JavaScript 祭で発表してきました - 若くない何かの悩み
秋のJavaScript祭 in mixi で、「バグの見つけ方」について発表してきました。 speakerdeck.com 過去二つのスライドをくっつけたものなので、既視感があるかもしれませんが気のせいです。 さて、前の発表を終えてから、いくつか直したかった点があったので、その点だけ修正してあります。 例えば、「ステップ実行」→「手動動作確認」のあたりですね。 ステップ実行でバグを見つけるというより、見て触っておかしいと気づいて、ステップ実行へ突入するはずですから、「手動動作確認」の方がふさわしいと思ったためです。 あと、次の2つの感想が特に嬉しかったです。ありがとうございました。 スライドめっちゃすてきだしリントやテストの大事さがすごくわかりやすい… #jsfes— nao (@naoi109) October 15, 2016 これまでの人生で一番簡潔に型検査やリントやテストの重要性
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
ロギングにおける十戒 | Yakst
どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。アプリケーションのログを拡張する手助けとなるのがこの「十戒」だ。 新年の私のブログにようこそ。監視とログのモニタリングについてのParisのdevopsメーリングリストでのスレッドに返信を書いた後、長らく心に留めていたブログ記事を思い出した。 このブログ記事は、私のOpsとしての顔をもって、主に開発者向けに書いた。 どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。多くの場合、これは予言をするのと同じようなことだからだ。トラブルシューティング中にどんな情報が必要かを知るのはとても難しい。それが、Opsエンジニアの大きな助けとなるよう、あなたのアプリケーションのログを拡張する手助けとなるこの「十戒」を望んだ理由だ。 1. 自分でログを書くべ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://lab.iisec.ac.jp/~harada_lab/lab/2015/IPSJ-EIP15068010.pdf