構造化ログのフォーマット logfmt vs JSON lines - methaneのブログ
構造化ログのプラクティスをあちこちで調べていたら、logfmtを推奨する記事を見つけたので調べてみました。 先に結論を言うと、JSON linesを使っておくのが良さそうです。 logfmt について logfmtとはスペース区切りで key=value を並べたフォーマットです。文字列にはクォートとエスケープによってスペースや改行を含められます。 at=info method=GET path=/ host=mutelight.org fwd="124.133.52.161" dyno=web.2 connect=4ms service=8ms status=200 bytes=1653 (logfmt から引用) あちこちで logfmt のリファレンスとして紹介されているのはこの記事です。 https://brandur.org/logfmt 発明されたのはどこか分かりませんが、流行
フロントエンド監視の全体像と実現方法
必要性 フロントエンドの監視はバックエンドやインフラのそれらと比べ、優先度が低くなりがちです。 バックエンドやインフラでの障害はサービス継続に直結するため、これは当然と言えば当然なのですが、別の理由もあると考えています。 それは計算リソースをサービス提供側が管理していないことです。 例えばアプリケーションがインフラとして AWS を利用しているなら、AWS のリソースを管理するのはサービス提供側です。 これは AWS 以外のクラウドサービスプロバイダやオンプレであっても同様です。 一方でフロントエンドはエンドユーザのブラウザ上で動作し、これを管理しているのはエンドユーザです。 フロントエンドはその性質上、監視の「盲点」になりがちです。 しかしフロントエンドはエンドユーザが直接触れるものであるため、そこで何が起きているかサービス提供側は正確に把握する必要があります。 マイルストーン フロント
フロントエンドで収集するべきテレメトリは何か
先日『フロントエンド監視の全体像と実現方法』という記事を投稿しましたが、その中でテレメトリについては触れませんでした（※本記事は上記記事の内容を知らなくても読み進められるようになっています）。 というのは、テレメトリは可観測性を実現するための重要な概念ではあるものの、テレメトリを軸に監視を考えるのは手段の目的化になってしまうと考えているからです。 重要なのはサービスにとって何を観測するべきかを考えることであり、テレメトリはそれを設計や実装に落とし込む際に現れるものです。 一方で監視に対する理解を深める上では、テレメトリを軸に考えることも重要でしょう。 そこで本記事ではフロントエンド監視においてどのようなテレメトリを収集するべきか述べていきます。 監視 SaaS と OpenTelemetry (OTel) Datadog, New Relic, Sentry のいずれかを利用することを考え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
