スタックトレース始めてみた社内のLT会で使用した資料です。 URL p.8 比較・検討 https://pkg.go.dev/github.com/pkg/errors https://pkg.go.dev/golang.org/x/xerrors https://github.com/juju/errors h…
alpの使い方(発展編)
基本編はこちら。 主にISUCONで使われているアクセスログ集計ツール alp の使い方を、ISUCON10オンライン予選問題のアクセスログを例に、基本よりも少し発展した使い方を紹介します。 alpは、デフォルトで90,95,99パーセンタイルを出力しますが、それ以外のパーセンタイルを出力したいことがあるかもしれません。そのようなときは--percentilesを使用します。 $ cat /path/to/access.log | alp json -m '/api/estate/[0-9]+,/api/chair/[0-9]+,/api/recommended_estate/[0-9]+' --sort avg -r --show-footers -o count,1xx,2xx,3xx,4xx,5xx,min,max,avg,sum,p50,p75 --percentiles 50,7
Structured Logging with slog - The Go Programming Language
Jonathan Amsterdam 22 August 2023 The new log/slog package in Go 1.21 brings structured logging to the standard library. Structured logs use key-value pairs so they can be parsed, filtered, searched, and analyzed quickly and reliably. For servers, logging is an important way for developers to observe the detailed behavior of the system, and often the first place they go to debug it. Logs therefore
Go公式の構造化ロガー（予定）のslogで秘匿値をログから削除する
Go言語ではながらく公式のログ出力にlogパッケージが使われてきました。しかし昨今のクラウド環境などでのロギングでは構造化ログがほぼ必須であり、そのような流れを受けて公式の構造化ログパッケージ slog が提案されています。2023年8月にリリース見込みの Go 1.21 のリリースノートにはすでに掲載されており、1.21 で公式に取り込まれるのはほぼ確実かと考えられます。 背景：絶対にログに秘匿値を出力したくない オンラインサービスで出力されるログは様々な目的で利用されます。例えば、サービスの運用監視のためにログを集約してアラートを発生させたり、サービスの改善のためにログを集約して分析したり、サービスのセキュリティ監視のためにログを集約して不正アクセスを検知したり、などなど。また、ログは監査に利用されることもあり、原則として保管期間中は削除しない、できないということが前提として様々なログ
🪵 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パッケージには
Go 1.21 に入る予定の log/slog パッケージの話 - 誰かの役に立てばいいブログ
ログ出力をどうするかっていうのは、Go 書くときに常にちょっとした悩みの種でした。 標準の log パッケージはあるものの、実用には機能が不足していると見なす人が多いためです。 かくいう私もその一人で、近年は Kubernetes 界隈でよく使われている以下を組み合わせていました。 go-logr/logr uber-go/zap + go-logr/zapr logr は所謂 structured logging のための共通インタフェースを提供するパッケージで、uber-go/zap のような著名なログライブラリ向けにアダプタも提供してくれます。 debug, info, warn, error といったいわゆるログレベルも備えていますし、context 経由で logger を渡すこともできるので、便利に活用していました。 ただ、logr は結構使われているとはいえ標準パッケージでは
Goの新しい構造化ロガーを体験しよう | gihyo.jp
logパッケージ Goには標準ライブラリとしてlogパッケージが提供されています。logパッケージで行えることはそう多くはありません。たとえば、デフォルトではログは標準エラー出力に出力されますが、log.SetOutput関数で出力先を変更できます。また、利用する関数によってログを出力した後の挙動をコントロールできます。たとえば、log.Print関数はログを出力するだけですが、log.Fatal関数はログ出力後にos.Exit(1)を呼び出します。log.Panicはログ出力後に出力したログと同じ文言を引数としてパニックを発生させます。 logパッケージでは、ログとともに関連するデータを出力したい場合は、log.Printf関数を用います。次のように、書式を指定して出力します。 log.Printf("request_url=%s request_method=%s", r.URL, r
Go公式の構造化ロガー（として提案されている）slogを触ってみたメモ
Go言語ではながらく公式のロガーとして log パッケージがありました。これは非常にシンプルなもので構造データをうまく表現できなかったりログレベルを分けるということができません。CLIで使うシンプルなインタラクションであればこれで十分なのですが、クラウド上のバックエンドで動かすサービスにとっては構造化ロギングやログレベルの出し分けは事実上必須であり、そのための機能は十分と言えませんでした。 これに対して様々なロガーが3rd party packageとして公開されてきましたが、一方で公式に導入されようとしているロガーもあります。それがslogです。まだ提案の段階ではありますが、現状で使える実装を触ってみたところかなり実用的な段階だなと感じたので、自分用の備忘録を兼ねてメモを残してみます。 サンプルコードはここにも置いてあります。 基本的な使い方 まず基本的な使い方を見てみます。ログ出力用に
A Complete Guide to Logging in Go with Zerolog | Better Stack Community
Zerolog is a high-performance, zero-allocation Go logging library. It provides structured logging capabilities for latency-sensitive applications where garbage collection is undesirable. You can use in a completely zero-allocation manner such that after the logger object is initialized, no further objects will be allocated on the heap, thus preventing the garbage collector from being triggered. Th
Sentry で Go 製アプリケーションのエラーを楽に管理する - JX通信社エンジニアブログ
*1 こんにちは、サーバーサイドエンジニアの @kimihiro_n です。 今回はSentryというエラー集約管理システムをGo言語で扱う場合の知見を共有したいと思います。 Sentry とは Sentryはエラーの集約管理を行うためのシステムで、作成したアプリケーション内で発生したエラーを一括で収集して見やすく管理することができます。 sentry.io 類似のエラーをグルーピングして発生頻度を確認したり、エラーの発生状況をSlackのようなチャットツールに通知してくれたりします。 予期しないエラーが発生したとき、生のログを見なくてもSlackやWebのUIで確認出来るのはとても便利です。 バックエンドからフロントエンドまで幅広い言語に対応しているためシステムのエラーを一括で集約が可能です。 JX通信社ではエラー管理ツールとしてSentryを広く利用しており100を超えるシステムが登録
Goのロギングライブラリ 2021年冬 - moriyoshiの日記
この記事はPySpa Advent Calendar 2021の14日目のエントリーとして書かれました。昨日のエントリーは冷凍食品でウキウキ引きこもり生活 でした。ちなみに私も70ℓの冷凍庫を購入しましたが本当にライフチェンジングでした。 総論: なぜログが必要か 可観測性 たとえ目的は自明でも、その動作までが自明なアプリケーションというものはほぼ存在しません。現実の世界のアプリケーションというものは、動作パラメータだったり実行環境だったり、起動時点でのさまざまな要因によって挙動を変えるものだからです。そして、そうしたアプリケーションにはライフサイクルというものがあります。ここでいうライフサイクルは、アプリケーションの処理が実行されるにつれ、アプリケーションの内外との情報のやりとりで生じる大局的な状態の変化のことです。アプリケーションが並行処理を行うようなものであれば、個々の並行処理の単位
Goでセキュアにロギングするzlog
TL; DR Goで秘匿値をログに出力しないようにする zlog というロガーを作りました。 以下、経緯や使い方の説明です。 背景：サーバーサイドにおけるロギングと秘匿値の問題 Webサービスを含む多くのサーバーサイドのサービスでは、サービスの挙動に関するログを出力・記録しておくのが一般的です。継続的にログを出力しておくことで、トラブルシューティングやデバッグ、セキュリティインシデントの対応や監査、性能改善の手がかりなどに活用することができます。ログに含まれる情報が多いほど問題を解決するための手がかりが増えるため、（限度はあるものの）なるべく多くの情報を掲載する、あるいは設定によって情報量を増やせるようにしておくと便利です。 しかし一方で、サーバーサイドで出力するのは望ましくない情報もあります。 認証に利用される情報：パスワード、APIトークン、セッショントークンなど、それを使うことで別の
OpenTelemetryとgo-chiを繋げてみる | フューチャー技術ブログ
PHP/Rust/Swift/Erlangあたりはコミットチャンス？ 2年前からアップデートされていると感じたポイントOpenTelemtryと、その前身のOpenCensusについてはこのブログでも取り上げました。 OpenCensus(OpenTelemetry)とは | フューチャー技術ブログ 基本的な考え方は前回紹介したものと変わっていませんが、2年前からいくつか変わったかも？と思ったところをピックアップするとこんなところですかね。 OpenTelemetryはOpenTelemetry専用のエージェント（ログ中継サービス）の活用も最初から視野に入っており、エージェント向けのエクスポーターも提供されている（OpenCensusにもあったがバージョンが最終版でも0.1.11で安定版ではなかった）。 stdoutロガーが一級市民扱い？ トレース、メトリックスという2種類の機能のほかに、
GoのロギングライブラリzapのTips - Carpe Diem
概要 zapを使っていて 書き込み先をio.Writerで自由に設定したい テストで時刻を固定値にしたい ログレベルによって標準出力、標準エラー出力を分けたい GCP Cloud Loggingのフォーマットでログ出力したい 全ログに付けたいフィールドがある 独自logパッケージでラップしたらcallerがおかしい とちょっとカスタマイズしたいケースのTipsです。 環境 Go 1.17 go.uber.org/zap v1.19.1 Tips 書き込み先をio.Writerで自由に設定したい zapのデフォルトの出力先は標準エラー出力ですが、期待通りのフォーマットでログが出力されているか確認したい時にio.Writerを渡してそこに書き込んでほしい場合です。 そんなときはzapcore.AddSyncを使います。 func NewWithWriter(w io.Writer) *zap.
軽量な Go 製カラムナフォーマット変換ツール columnify を作った話 - Repro Tech Blog
こんにちは。業務委託として SRE チームのお手伝いをしている @syucream です。 本記事では Repro にて開発した、 Go 製のカラムナフォーマットへのデータ変換ツール columnify について、開発背景や技術的な取り組みを紹介します。 なぜカラムナフォーマットか？ ことのおこり 事業がスケールすると共に扱うログの量が増えることは、喜ばしい反面さまざまな悩みをもたらします。その中でも顕著なものの一つとしてコストの問題が挙げられます。 膨大なログデータはログに対するストレージ料金を増大させると共に、分析や可視化に際してクエリで求められるコンピュートのコストも無視できなくなっていきます。 近頃 Repro でもコンテナのログの管理においてこの問題が顕著になってきました。Repro のバックエンドシステムは ECS 上のコンテナで実現され、ログの閲覧・管理のため外部のログ収集サ
GitHub - nikoksr/simplog: A simple and opinionated library that lets you set up and use zap quickly.
マイクロサービスのロギングベストプラクティスとGoの実装の場合 - RareJob Tech Blog
こんにちは、プラットフォームチームの池田と申します。初投稿です。 プラットフォームチームではマイクロサービスアーキテクチャの構成を採用し開発を進めています。 どんな構成でも忘れてはいけないのがロギング。いわゆる非機能要件の1つで地味な存在ですが、サービス運用を支える上で非常に重要です。 直近でマイクロサービスにおけるロギングの構成を調査し、プラットフォームチームでメインで採用しているGo言語での実装を検証しました。 今回の記事ではそのまとめを紹介します。 目次 目次 ロギングベストプラクティス for マイクロサービス リクエストにユニークなIDを付与し紐付けができるようにする ログは一箇所に集める ログデータを構造化する ログに有益な情報を持たせる どのサービスでも共通で持つのが望ましいフィールド リクエストのエントリーポイントとなるサービスで持つのが望ましいフィールド Go言語での実装
Goの任意のLoggerをログローテート対応できるreplaceablewriter | おそらくはそれさえも平凡な日々
https://github.com/Songmu/replaceablewriter 表題の通りですが、io.Writer をラップして io.WriteCloser として振る舞い、その内部に保持した io.Writer を差し替え可能にするライブラリを書いた。 例えば、Goの標準logをログローテートしたい場合には以下のようにします。 f, _ := os.OpenFile("20191001.log", os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644) w := replaceablewriter.New(f) log.SetOutput(w) // 翌日になったら差し替える f2, _ := os.OpenFile("20191002.log", os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644) w.Repl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
もっと log/slog を使おう
PostgreSQL と ORM と Logging と
