Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[SDK] BatchLogRecordProcessor still drains the queue in a tight loop, inconsistent with BatchSpanProcessor fix

オープン
  • 何か問題がありますか？
#4,498 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
78/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
cpp
領域
observability

調査の方向性

sdk/src/logs/batch_log_record_processor.cc から始め、#4466 の BatchSpanProcessor の変更とその動作を比較します。issue で説明されているエクスポート呼び出しとバッチサイズの測定を再現し、その後、通常のウェイクアップでは 1 つのバッチがエクスポートされ、ForceFlush() と Shutdown() ではバッファが空になることを確認します。

索引モデルが issue の本文から書いたものです。

説明

bug help wanted triage/accepted

Describe your environment

  • Platform: macOS
  • opentelemetry-cpp version: main branch
  • Component: sdk/src/logs/batch_log_record_processor.cc
  • BatchLogRecordProcessor configuration:
    • max_queue_size = 8192
    • max_export_batch_size = 2048
    • schedule_delay_millis = 5000

Steps to reproduce

  1. Configure BatchLogRecordProcessor with a LogRecordExporter that counts export calls and records per call.
  2. Produce log records at a constant rate (e.g. 5,000 logs/s) for 10 seconds.
  3. Observe the number of export requests and the average number of logs per request.
  4. Produce 50,000 log records without calling ForceFlush().

What is the expected behavior?

With max_export_batch_size = 2048, exports should be close to 2048 records each. After #4466, BatchSpanProcessor behaves this way: on a normal wakeup it exports at most one batch, and only ForceFlush() / Shutdown() drain the entire buffer.

BatchLogRecordProcessor should follow the same semantics.

What is the actual behavior?

BatchLogRecordProcessor::Export() still drains the whole buffer in a tight loop:

void BatchLogRecordProcessor::Export()
{
  do {
    bool notify_force_flush =
        synchronization_data_->is_force_flush_pending.exchange(false, std::memory_order_acq_rel);
    if (notify_force_flush) {
      num_records_to_export = buffer_.size();
    } else {
      num_records_to_export =
          buffer_.size() >= max_export_batch_size_ ? max_export_batch_size_ : buffer_.size();
    }
    // ... consume & export ...
  } while (true);
}

And the worker wakes up as soon as the buffer is non-empty:

synchronization_data_->cv.wait_for(lk, timeout, [this] {
  ...
  return !buffer_.empty();
});
Measured result
Metric Value
Logs produced 50,000
Export calls 2,332
Average batch size 21.4
Full batches (>=2048) 1
Tiny batches (<100) 2,331

The first export is 2048 records; every subsequent export in the same wakeup is ~20–25 records because the worker keeps draining the buffer instead of waiting for the next full batch.

Additional context

  • #4449 reported the same problem for BatchSpanProcessor.
  • #4466 fixed the trace path by changing the worker wait predicate and making Export() drain the buffer only for ForceFlush() / Shutdown().
  • The logs path (sdk/src/logs/batch_log_record_processor.cc) still uses the old implementation and should be aligned with the trace path.
主要言語
C++
スター
1.4k
フォーク
656
平均マージ
1日 19時間
マージ済み PR（30日）
51

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

open-telemetry/opentelemetry-cpp のほかの issue

open-telemetry/opentelemetry-cpp の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。