Rustのaxumでデバッグを困難にする不適切なログ記録のアンチパターンと改善の鉄則

Webアプリケーション開発において、ロギングは単なる動作記録ではなく、システムの状態をトレースし障害の根本原因を特定するための必須の観測機構です。

特にRustの非同期Webフレームワークであるaxumを利用している場合、Tokioランタイム上でのタスクスケジューリングやトレイトの境界という言語固有の性質により、不適切なログ設計がデバッグの解像度を著しく低下させます。

本記事では、コンパイラの恩恵を受けられるRust環境下において、どのようなログ記録がデバッグを困難にするアンチパターンとなるのかを論理的に分析します。

そして、トレースIDの伝播や構造化ロギングなど、 observabilityを担保するための改善の鉄則を明確に示します。

Rustとaxumにおけるロギングの重要性とデバッグの課題
非同期環境下におけるログの断片化とトレーサビリティの欠如
1. Tokioランタイムとタスクスケジューリングの複雑性
2. コンテキスト情報の不在によるデッドロックの特定困難
Rustの所有権システムが引き起こすログ記録のアンチパターン
1. 所有権と借用制約によるログ出力の省略
2. エラー型の変換過程でのコンテキスト消失
axumのエラーハンドリングと不適切なログ出力の罠
1. IntoResponseトレイト実装時のログ欠落
2. 多重エラーハンドリングによる重複ログの発生
構造化ロギングによるログの質的向上とトラブルシューティング
1. JSON形式でのログ出力と機械的可読性の向上
tracingクレートを活用した分散トレーシングの実装
1. スパンとコンテキストの適切な伝播
ミドルウェアを活用したリクエストスコープのログ記録
ログレベルの最適化と本番環境でのパフォーマンス担保
観測可能性を高めるRustとaxumのログ設計まとめ

Rustとaxumにおけるロギングの重要性とデバッグの課題

Rust言語とaxumフレームワークを用いたWebアプリケーション開発におけるロギングの重要性とデバッグ課題を示す画像

Webアプリケーション開発において、ロギングは単なる動作記録ではなく、システムの内部状態を外部から観測するための唯一の手段です。

特にRustの非同期Webフレームワークであるaxumを採用した環境では、その特異な実行モデルと強力な型システムの影響で、不適切なログ設計がデバッグの解像度を著しく低下させます。

コンパイラの厳密なチェックを通過したコードであっても、実行時の非同期タスクの複雑な挙動までは保証できません。

ここでは、axumの特性がロギングに与える影響と、開発者が直面するデバッグの課題を論理的に整理します。

まず、axumが基盤とするTokioランタイムは、多数の非同期タスクを軽量スレッド上で細断的に実行します。

この環境下では、従来の同期的なロギングの感覚が通用しません。

例えば、単一のHTTPリクエストを処理する過程で、実行コンテキストが何度も切り替わるため、ログの出力順序がコードの記述順と一致しないことが日常的に発生します。

これにより、原因追跡が困難になります。

次に、Rustの所有権とライフタイムという概念が、ログ出力の実装に直接的な制約を与えます。

他の言語のように、エラーオブジェクトを安易に文字列化して出力しようとすると、所有権の移動や借用の衝突というコンパイルエラーに直面します。

その結果、開発者はログ出力を簡略化するか、あるいは省略するという消極的な選択を迫られることがあります。

これがデバッグの際に致命的な情報不足を招きます。

これらの課題に対処するためには、構造化ロギングの導入が必須です。

以下は、axumのハンドラ内で非同期処理を行う際に、コンテキストを欠いた単純なログ出力をしてしまう典型例です。

async fn process_data(State(state): State<AppState>) -> impl IntoResponse {
    // 非同期タスク内での単純なログ出力
    tracing::info!("Data processing started");
    let result = state.db.fetch_user().await;
    if result.is_err() {
        // エラーの詳細なコンテキストが欠落している
        tracing::error!("Failed to fetch user");
    }
    "OK"
}

上記の実装では、どのリクエストが失敗したのか、どのユーザーIDが対象だったのかという重要な情報が抜け落ちています。

非同期環境下で複数のリクエストが同時に処理されている場合、このログはデバッグにおいて無価値に等しいです。

さらに、axumのエラーハンドリングにおいては、IntoResponseトレイトを実装した独自エラー型への変換過程で、元のエラースタックトレースが消失するアンチパターンが頻発します。

この問題を整理するため、axum開発における典型的なロギングの課題とその影響を表にまとめます。

課題の分類	具体的な症状	デバッグへの影響
非同期タスクの交錯	ログの時系列が前後する	因果関係の追跡が不可能になる
所有権による制約	エラー詳細の出力が省略される	障害の根本原因が特定できない
エラー変換の損失	スタックトレースが消滅する	障害発生箇所の特定が困難になる

このような状況下では、ログは単なるテキスト出力ではなく、システムの状態遷移をトレースするための構造化されたデータとして設計しなければなりません。

本記事では、これらの課題を解決し、axumアプリケーションの観測可能性を飛躍的に向上させるためのアンチパターンの排除と、改善の鉄則を解説します。

非同期環境下におけるログの断片化とトレーサビリティの欠如

Rustのaxumが基盤とするTokioのような非同期ランタイムは、極めて高いスループットを実現する反面、デバッグ時のログ解析に特有の困難をもたらします。

複数の非同期タスクが単一のスレッド上で時分割で実行されるため、従来の同期的なロギングの感覚で出力されたログは、容易に断片化します。

この断片化は、システム全体の挙動を追跡するトレーサビリティを著しく低下させ、根本原因の特定を困難にします。

Tokioランタイムとタスクスケジューリングの複雑性

Tokioランタイムは、非同期タスクを軽量なFutureとして扱い、ワークスティーリングアルゴリズムを用いて複数のワーカースレッド間で動的に分配します。

このアーキテクチャにより、単一のHTTPリクエストを処理する過程であっても、実行コンテキストが頻繁に切り替わります。

そのため、標準のログ出力では、どの出力がどのリクエストに属するものかを区別できなくなります。

以下は、リクエストのコンテキストを考慮せずにログを出力してしまうアンチパターンです。

async fn handle_request() {
    log::info!("Request received");
    tokio::time::sleep(Duration::from_millis(50)).await;
    log::info!("Request completed");
}

上記のコードでは、複数のリクエストが同時に処理されると、ログの時系列が入り乱れ、Aリクエストの開始ログの直後にBリクエストの完了ログが出力されるといった現象が発生します。

これでは、一連の処理フローを正しく追跡することは不可能です。

コンテキスト情報の不在によるデッドロックの特定困難

非同期処理におけるデッドロックやパフォーマンスのボトルネックを特定するには、タスクがどのようなリソースをロックし、どのような状態で待機しているかというコンテキスト情報が不可欠です。

しかし、ログが断片化していると、この重要なコンテキストが欠落します。

例えば、データベースのトランザクションロックの競合が発生した際、対象となるリソースの識別子やトランザクションIDがログに含まれていなければ、どのタスクが競合を引き起こしているのかを特定することはできません。

このようなコンテキストの不在は、デッドロックの原因究明を絶望的なものにします。

これらの問題を解決するためには、トレースIDやスパンといった分散トレーシングの概念をログに導入し、各ログエントリが属する実行コンテキストを明示する必要があります。

Rustの所有権システムが引き起こすログ記録のアンチパターン

Rustの強力な型システムと所有権モデルは、メモリ安全性を保証する反面、ロギングの実装において直感に反する制約を課すことがあります。

開発者はコンパイルを通すことに意識が向きすぎるあまり、本来出力すべき重要な情報を意図的に削減するというアンチパターンに陥りがちです。

この問題は、システムの観測可能性を著しく損なう原因となります。

所有権と借用制約によるログ出力の省略

Rustにおいて、ある変数の所有権が別の関数にムーブされた後、その変数を参照してログ出力を行うことはコンパイルエラーとなります。

また、ミュータブルな借用とイミュータブルな借用が衝突する場合も同様です。

開発者はこの制約に直面した際、ログ出力を諦めるか、不十分な情報で妥協してしまいます。

以下の例は、所有権の移動によって詳細なログ出力が省略される典型的なアンチパターンです。

fn process_payload(payload: Payload) -> Result<(), Error> {
    // 所有権がムーブする前であれば詳細を出力できるが、
    // 処理後の状態をログに残そうとすると所有権の衝突が発生する。
    database::save(payload)?;
    // ここで `payload` の内容をログに出力することは不可能。
    log::info!("Payload processed successfully");
    Ok(())
}

このようなケースでは、payloadの識別子などをログに残すために、処理の前に必要な情報だけを抽出しておく設計が求められます。

しかし、開発中の手間からこのプロセスが省略され、後々のデバッグで「どのデータが処理されたのか」が全く分からないという事態を招きます。

エラー型の変換過程でのコンテキスト消失

axumアプリケーションでは、複数のレイヤーにまたがってエラーを伝播させるため、?演算子を用いたFromトレイトの実装によるエラー型の変換が頻繁に行われます。

この変換過程で、元のエラーが持っていた具体的なコンテキストが失われるアンチパターンが多発します。

例えば、データベースのエラーをアプリケーション全体のエラー型に変換する際、単にエラーの種別だけをマッピングし、発生時のクエリ内容や対象レコードのIDなどの付加情報を破棄してしまうのです。

以下の表は、エラー変換時の情報の欠損パターンを整理したものです。

変換前の状態	変換後の状態	デバッグへの影響
SQLエラーと対象テーブル名	汎用的なDBエラー	どのテーブルで失敗したか不明
認証トークンの無効化理由	汎用的な認証エラー	期限切れか不正かの区別が不能

エラーハンドリングの責務を持つミドルウェア層でログを記録する場合、このように変換されてしまったエラー型からは、原因究明に必要な情報を取得できません。

エラーをラップする際には、map_errなどを使用してコンテキストを付与しながら伝播させる設計が不可欠です。

axumのエラーハンドリングと不適切なログ出力の罠

Webアプリケーションにおけるエラーハンドリングは、ユーザー体験の担保と障害調査の要です。

しかし、Rustのaxumフレームワークを採用した環境では、その独特のアーキテクチャに起因して、エラー時のログ出力に深刻な罠が潜んでいます。

エラーを適切にレスポンスに変換する過程で、ログの記録漏れやノイズの増大が発生すると、システムの観測可能性は著しく低下します。

IntoResponseトレイト実装時のログ欠落

axumでは、ハンドラが返す任意のエラー型をHTTPレスポンスに変換するために、IntoResponseトレイトの実装が必須となります。

この実装箇所において、開発者はステータスコードやエラーメッセージの生成に集中するあまり、エラーのログ出力を忘却するアンチパターンに陥りがちです。

以下は、IntoResponseの実装でログ記録が欠落している典型例です。

impl IntoResponse for AppError {
    fn into_response(self) -> Response {
        // エラー内容をログに出力せずにレスポンスを構築してしまう
        let status = match &self {
            AppError::NotFound => StatusCode::NOT_FOUND,
            AppError::Database(_) => StatusCode::INTERNAL_SERVER_ERROR,
        };
        (status, "Something went wrong").into_response()
    }
}

この実装では、データベース接続の致命的なエラーが発生しても、サーバーのログには何の痕跡も残りません。

エラーレスポンスを返却する直前に、必ずtracing::error!マクロなどで詳細を記録する設計が必要です。

多重エラーハンドリングによる重複ログの発生

前項の教訓に従い、IntoResponseの実装でログを出力するよう設計したとします。

しかし、今度は多重エラーハンドリングによる重複ログという新たな罠に直面します。

axumアプリケーションでは、ルーターのミドルウェア層やカスタムエラーハンドラ層など、複数の階層でエラーをインターセプトすることがあります。

各階層で同じエラーに対してログ出力を行うと、単一の障害に対して同じ内容のログが複数回出力されてしまいます。

この問題の構造を整理するため、典型的なエラー伝播の経路とログ出力のタイミングを表にまとめます。

処理階層	エラーの処理内容	ログ出力の状態
ハンドラ層	リポジトリからのエラーを抽出	`warn!`で出力される
ミドルウェア層	エラーをインターセプトして付加情報を追加	`error!`で出力される
レスポンス変換層	`IntoResponse`でステータスコードへ変換	`error!`で出力される

このように、1つのリクエストで3回のエラーログが出力されると、ログのノイズが増大し、真に重要な障害箇所の特定が困難になります。

重複ログを防ぐための鉄則は、エラーの分類とログ出力の責務を明確に分離することです。

例えば、内部ロジックではエラーのコンテキストを構築するのみに留め、最も外側のIntoResponse実装においてのみログ出力を行う設計が有効です。

構造化ロギングによるログの質的向上とトラブルシューティング

これまで解説してきた非同期環境下での断片化や所有権に伴う情報欠落は、ログを単なるテキスト文字列として扱うアプローチの限界を示しています。

システムの規模が拡大し、マイクロサービスアーキテクチャが一般化する現代において、人間が目視でログを追跡する手法は限界を迎えています。

ここで重要となるのが、ログをデータとして扱う構造化ロギングの導入です。

構造化ロギングは、ログメッセージをキーとバリューのペアとして記録し、システム全体の観測可能性を飛躍的に向上させます。

Rustのエコシステムにおいては、tracingクレートとserde_jsonを組み合わせることで、堅牢な構造化ロギングを実現できます。

JSON形式でのログ出力と機械的可読性の向上

構造化ロギングの最も代表的な実装形態が、JSON形式でのログ出力です。

JSON形式を採用することで、ログ収集ツール（DatadogやLokiなど）がログを自動的にパースし、インデックス化できるようになります。

これにより、特定のエラーコードの発生頻度をグラフ化したり、ユーザーIDごとにフィルタリングしたりする高度なトラブルシューティングが可能となります。

以下は、Rustのtracingクレートを用いてJSON形式のログを出力する初期化コードの例です。

use tracing_subscriber::fmt::format::FmtContext;
use tracing_subscriber::fmt::{self, FormatFn};
use tracing_subscriber::prelude::*;

fn init_logging() {
    let json_format: FormatFn<FmtContext> = |ctx, writer, fields| {
        // JSONフォーマットでログを出力する設定
        let _ = fmt::format::json().format_fields(writer, fields);
        Ok(())
    };

    tracing_subscriber::registry()
        .with(fmt::layer().event_format(json_format))
        .init();
}

この初期化を行うことで、以降の出力は構造化されたJSONオブジェクトとして記録されます。

しかし、フォーマットをJSONに変更しただけでは不十分です。

ログに含まれるフィールドが統一されていなければ、解析ツールでの集計効率は悪化します。

効果的な構造化ロギングを実現するためには、プロジェクト全体で共通のフィールドを定義する必要があります。

以下の表は、ログに含めるべき標準的なフィールドとその役割を整理したものです。

フィールド名	データ型	役割と解析における重要性
`timestamp`	ISO 8601文字列	ログの正確な発生時刻を示し、時系列ソートの基準となる
`level`	文字列	エラーの重大度を示し、アラートの発火条件として利用される
`trace_id`	UUID文字列	非同期タスク間で同一リクエストのログを紐付ける唯一の識別子
`user_id`	数値または文字列	障害の影響範囲を特定し、特定ユーザーの操作トレースを可能にする
`error_type`	文字列	エラーの分類名であり、エラーの集計と頻度分析に不可欠

これらのフィールドを意識してログを設計することで、ログは単なる記録から、高度に検索可能なデータベースへと進化します。

機械による可読性が向上すれば、障害発生時の初動遅延を防ぎ、MTTR（平均復旧時間）を大幅に短縮することが可能です。

tracingクレートを活用した分散トレーシングの実装

Rustの非同期アプリケーションにおいて、ログの断片化を防ぎ、システム全体の挙動を連続して追跡するための強力な手段がtracingクレートです。

標準的なロギングクレートが出力時点の静的なメッセージ記録に特化しているのに対し、tracingはタスクの開始から終了までの期間をスパンとして捉え、その間に発生するイベントを文脈付きで記録します。

この分散トレーシングの仕組みをaxumに導入することで、非同期タスクが切り替わってもコンテキストが維持され、どの処理がどのリクエストに属しているのかを正確に把握できるようになります。

コンピュータサイエンスの観点から見れば、これは実行トレースの時間計算量と空間的な関連性を視覚化する手法に他なりません。

スパンとコンテキストの適切な伝播

tracingの核心は、処理のスコープを定義するスパンと、そのスコープ内で共有されるコンテキストです。

ハンドラの冒頭でスパンを生成すれば、そのスパンがアクティブな間に発生するすべてのログイベントは、自動的にそのスパンのコンテキストを継承します。

以下は、axumのハンドラにおいて、リクエストごとにスパンを生成し、コンテキストを伝播させる実装例です。

use axum::extract::Path;
use tracing::instrument;

#[instrument]
async fn get_user(Path(user_id): Path<u32>) -> String {
    // このイベントは自動的に user_id を含むスパンの配下に記録される
    tracing::info!("Fetching user from database");
    // データベース処理のシミュレーション
    format!("User {}", user_id)
}

このコード例の#[instrument]属性は、関数の引数を自動的にスパンのフィールドとして抽出し、関数の実行全体を一つのスパンで囲みます。

これにより、ログを個別に出力する手間が省けるだけでなく、トレースIDやユーザーIDといった重要なコンテキストが確実に伝播されます。

しかし、この仕組みを最大限に活用するためには、プロセス境界を越えたコンテキストの伝播についても考慮しなければなりません。

マイクロサービスアーキテクチャのように、複数のサービスをまたぐ処理の場合、HTTPヘッダーを経由してトレースコンテキストを伝播させる必要があります。

axumのミドルウェアでこの伝播を処理する際に意識すべきポイントを整理します。

HTTPリクエストの受信時に、標準化されたトレースヘッダー（W3C Trace Contextなど）をパースする
抽出したトレースIDを元に、現在のリクエストのルートスパンを確立する
外部のAPIやデータベースへリクエストを送信する際は、現在のスパンコンテキストをヘッダーに注入する

これらのプロセスを経由することで、システム全体で一貫したトレースツリーが構築されます。

スパンとコンテキストが適切に伝播されているかを確認するための評価基準を表にまとめます。

評価基準	不適切な状態	適切な状態
トレースIDの一意性	リクエストごとにIDが断絶している	エンドツーエンドで同一のIDが維持される
スパンの階層構造	フラットなログの羅列となる	親子関係のあるツリー構造として記録される
コンテキストの完全性	引数や状態が欠落している	重要な変数の値が構造化フィールドとして保持される

このようにtracingクレートを活用し、スパンとコンテキストの伝播を厳密に設計することで、複雑な非同期処理のデバッグは不可能から可能へと転換します。

ミドルウェアを活用したリクエストスコープのログ記録

axumのアーキテクチャにおいて、ミドルウェアは全てのリクエストとレスポンスに対する共通の処理を担う強力なレイヤーです。

このレイヤーを活用することで、各ハンドラにロギングのロジックを散乱させるアンチパターンを排除し、システム全体の関心事を一元管理できます。

特にリクエストスコープのログ記録においては、ミドルウェアでのトレースコンテキストの初期化が必須となります。

ハンドラ内部で個別にトレースIDを生成しようとすると、エラーハンドリングの過程でコンテキストが欠落するリスクが高まります。

そこで、リクエストがアプリケーションに到達した直後に、ミドルウェアでトレースIDを生成し、それをtracingのスパンとして設定する設計が鉄則です。

以下は、axumのミドルウェアを実装してリクエストスコープを初期化する例です。

use axum::{
    extract::Request,
    http::header::HeaderName,
    middleware::Next,
    response::Response,
};
use tracing::Instrument;
use uuid::Uuid;

pub async fn trace_context_middleware(req: Request, next: Next) -> Response {
    let trace_id = req
        .headers()
        .get("x-trace-id")
        .and_then(|v| v.to_str().ok())
        .map(String::from)
        .unwrap_or_else(|| Uuid::new_v4().to_string());

    let span = tracing::info_span!("request", trace_id = %trace_id);

    next.run(req).instrument(span).await
}

この実装により、ミドルウェア配下の全てのハンドラと非同期タスクは、自動的にこのスパンを継承します。

結果として、どの深い階層で出力されたログであっても、必ずトレースIDが付与されるようになります。

しかし、ミドルウェアを用いたロギング設計においても、陥りやすい罠が存在します。

それは、パフォーマンスへの悪影響と不要なノイズの生成です。

リクエストボディのサイズが大きい場合や、ストリーミング転送を行っている場合に、不適切なタイミングでボディを読み込んでログに記録しようとすると、メモリ使用量の増大やレスポンス遅延の直接的な原因となります。

ミドルウェア層で記録すべき情報と、記録すべきでない情報を明確に分離する必要があります。

以下の表は、axumのミドルウェアにおけるロギング項目の妥当性を評価したものです。

ロギング項目	評価	理由と留意点
リクエストメソッドとパス	適切	ルーティング解析の基礎情報であり、軽量に取得可能
トレースID	必須	分散トレーシングの要であり、コンテキスト伝播の中核
レスポンスタイム	適切	ボトルネックの特定に不可欠だが、計測のオーバーヘッドに注意
リクエストヘッダー全量	不適切	認証トークンの漏洩リスクがあり、ノイズが多すぎる
リクエストボディ	原則不適切	ストリーミング処理を阻害し、メモリとCPUを著しく消費する

このように、ミドルウェアでのロギングは「何を記録するか」という取捨選択が極めて重要です。

特にヘッダー情報を記録する際は、認証情報や個人情報を含むヘッダーを明示的にマスキングする処理を実装しなければなりません。

セキュリティと観測可能性のトレードオフを論理的に判断し、最適なバランスを見出すことが、ミドルウェア設計における真の役割です。

ミドルウェアによるリクエストスコープの確立は、個別のハンドラ実装に伴うロジックの重複を防ぐだけでなく、システム全体のログの一貫性を担保する強力なアプローチです。

この基盤を整えることで、後続の実装者は本来のビジネスロジックに集中でき、結果としてコードの保守性と品質が飛躍的に向上します。

ログレベルの最適化と本番環境でのパフォーマンス担保

Webアプリケーションの観測可能性を高めるためにロギングを強化すると、必然的にログのデータ量は増大します。

しかし、無秩序に出力される大量のログは、ストレージリソースを圧迫するだけでなく、アプリケーションのCPUサイクルを消費し、レスポンスタイムの低下を招く原因になります。

特にRustとaxumの組み合わせは極めて高速ですが、ログのシリアライズ処理やI/O同期待ちがボトルネックになれば、そのパフォーマンス優位性は失われます。

ここで重要となるのが、ログレベルの適切な設計と、本番環境におけるパフォーマンスを担保するための最適化です。

コンピュータサイエンスの観点から見れば、ログ出力はシステムの実行パスに挿入されるオーバーヘッドであり、そのコストを最小化するアルゴリズム的な工夫が不可欠です。

ログレベルの最適化において最初に考慮すべきは、各レベルの意味付けをプロジェクト全体で厳密に定義することです。

開発者が主観でinfoやdebugを選択すると、本番環境でノイズが増大し、真に重要なエラーが埋もれてしまいます。

以下の表は、ログレベルの運用方針を定義した一例です。

ログレベル	本番環境での出力可否	目的と主な記録内容
`error`	出力する	システムの継続が困難な障害やリクエストの完全な失敗
`warn`	出力する	想定外の状態だが復旧可能なエラーや、代替処理へのフォールバック
`info`	条件付き出力	主要なビジネスイベントやリクエストのライフサイクル
`debug`	出力しない	開発時のデバッグ情報や内部状態の詳細な変数

このように方針を定めた上で、本番環境ではinfo以下のレベルをフィルタリングすることが基本となります。

しかし、Rustのlogクレートをそのまま使用すると、出力がフィルタリングされた場合でも、ログメッセージの文字列フォーマット処理が実行されてしまうという深刻なパフォーマンス問題が発生します。

例えば、複雑な構造体をformat!マクロで文字列化してログに渡そうとした場合、ログレベルで弾かれても文字列構築のコストは支払われます。

これを防ぐためには、tracingクレートの遅延評価特性を活用する鉄則を守る必要があります。

以下のアンチパターンと改善案のコードを見比べてみてください。

// アンチパターン: 常に文字列構築が発生する
fn process_data(data: &ComplexData) {
    log::debug!("Processing data: {:?}", data.serialize()); // フィルタされてもserialize()が実行される
}

// 改善案: トレイトの遅延評価を活用する
fn process_data_optimized(data: &ComplexData) {
    // 引数として渡すだけで、レベルが有効な場合のみ評価される
    tracing::debug!(data = ?data, "Processing data");
}

改善案では、data.serialize()というメソッド呼び出しを記述せず、tracingマクロの構造化フィールド記法（?data）を利用しています。

これにより、debugレベルが無効化されている本番環境では、シリアライズ処理自体が実行されず、オーバーヘッドをゼロに抑えることができます。

さらに、本番環境でのパフォーマンスを担保するためには、I/Oの非同期化も重要な課題です。

ログの書き込み処理が同期的に行われると、ファイルシステムへの書き込み待ちで非同期タスクがブロックされ、Tokioランタイム全体のスループットが低下します。

この問題を解決するためには、tracing-subscriberの設定で、非同期ライター（non-blocking）を導入することが推奨されます。