refactor: interface-layer OpenTelemetry runtime follow-ups deferred from #802
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 52/100
- issue の種類
- リファクタリング
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- python
調査の方向性
独立してスコープを設定できる項目を1つ選び、次に data_designer/integrations/opentelemetry.py と、そこから参照されている data_designer.py、observability.py、または async_scheduler.py のセクションを読みます。まず既存のランタイムとプロトコルの動作を確認してください。完了とは、選択した型付け、コントラクト、パフォーマンス、メトリクスのセマンティクス、またはライフサイクルの変更が、任意の設計項目に拡張せずに実装されていることを意味します。
索引モデルが issue の本文から書いたものです。
説明
Priority Level
Low
Task Summary
PR #802 added the default pull-based OpenTelemetry/Prometheus metrics exporter (data_designer.integrations.opentelemetry.OpenTelemetryRuntime). During review a set of non-blocking polish/design items were intentionally deferred rather than expanded that PR's scope. This issue tracks them so they aren't lost.
None of these are correctness blockers — the PR shipped as "Ship it (with nits)." They are hygiene, typing, perf, and design-consolidation items localized to the interface-layer OTel runtime (plus two small engine-seam items).
Line references are against head 9aee1dde of #802.
Technical Details & Implementation Plan
Small / low-risk
- Document the deliberate log-handler swallow.
_MetricLogHandler.emit(opentelemetry.py:69-73) is a silentexcept Exception: pass. This is defensible (logging from inside a failing log handler risks recursion), but it's now the lone silent swallow in the module. Add a short comment explaining the silence is intentional so nobody "fixes" it into re-entrant logging. - Tighten
Any-typed instrument attributes. ~11 runtime attributes (opentelemetry.py:87-99:_registry,_meter_provider,_server, the instruments, etc.) are typedAnybecause OTel types aren't imported at module scope. Import them underTYPE_CHECKINGand annotate precisely (Histogram,Counter,UpDownCounter,ObservableGauge,MeterProvider,CollectorRegistry,HTTPServer). - DRY the enablement rule.
self._open_telemetry if self._run_config.otel_metrics_port is not None else Noneis duplicated at three call sites indata_designer.py(:753,754,762) plus the port passed intoobserve_create. Extract aself._metrics_sink()accessor.
Protocol / contract
- Declare the
accepts_*filters on the sink Protocols.scheduler_event_sink_accepts/request_event_sink_acceptsprobegetattr(sink, "accepts_*_event", None)(observability.py:276,324) for methods that aren't declared onSchedulerAdmissionEventSink/RequestAdmissionEventSink. A rename/typo silently degrades a filter to "accept everything." Also, onlySchedulerAdmissionEventSinkis@runtime_checkable(:217) —RequestAdmissionEventSink(:313) is not. Declareaccepts_*on the Protocols (or aFiltering*sub-Protocol) and apply@runtime_checkableconsistently.
Perf
- Lock-free interest check.
accepts_scheduler_event/accepts_request_event(opentelemetry.py:145-151) acquire the process-wideRLockon every event, on the hottest paths (the scheduler emits many events per task). Since the check only readsbool(self._active_run_ids)plus a static membership test, consider a lock-free "any run active" flag (updated under the lock, read without it) so the cheap gate stays lock- and allocation-free. Measure first.
Metric semantics
- Progress gauge starts at 0 on resume.
data_designer.dataset.progressuses the full job total as the denominator (_start_dataset_progress,opentelemetry.py:422-427;row_group_total_rowsfromasync_scheduler.py:326,1091) but the numerator only accrues checkpoints observed in the current run. A resumed (already-partway) job reads near 0 climbing up. Seedinitial_completed_recordsinto the starting(scheduled, processed)tuple, or document the limitation in the metric description.
Larger / optional design consolidation
- Split
OpenTelemetryRuntime. Extract the dataset-progress math (_start_/_advance_/_finish_active_dataset,_active_dataset_progress) into a small OTel-agnostic, directly unit-testableDatasetProgressTracker, and consider a typed_MetricInstrumentscontainer; leave the runtime as orchestration + lifecycle. - Lazy-construct the singleton. Module import constructs
_RUNTIMEand registersatexitas a side effect (opentelemetry.py:520-521). Consider constructing lazily on firstget_open_telemetry_runtime()call and registeringatexitthere once. - Per-run progress-gauge label.
_dataset_progress_valueis a single process-wide float blended across concurrent creates, with the last finished value lingering. If overlapping creates become a supported dashboard scenario, add a per-run gauge label. (Metric-schema change — only if needed.)
Investigation / Context
- Deferred from PR #802 (feat: add OpenTelemetry metrics for create jobs).
- Related: #447 (introduce
AsyncRunControllerand explicit build/preview sinks) covers the adjacent scheduler-side "converge emission seams into one fan-out" direction — #802 already added_FanoutSchedulerEventSinkas a first step. The items here are scoped to the interface-layer OTel exporter, which #447 and the #645 observability epic do not cover.
Dependencies
None. Independent polish; can be picked up piecemeal.
- 主要言語
- Python
- スター
- 2.3k
- フォーク
- 227
- 平均マージ
- 1日 12時間
- マージ済み PR(30日)
- 52
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
NVIDIA-NeMo/DataDesigner のほかの issue
-
docs: required_columns description is incomplete for LLM and multimodal columns対応中かも @nightcityblade が 6 日前に担当しました。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
NVIDIA-NeMo/DataDesigner#1002 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
Python code validator reports syntactically invalid code as valid対応中かも @Bsgg1 が今日担当しました。 オープンbug triaged
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
NVIDIA-NeMo/DataDesigner#995 · コメント 4 件 ·
メンテナーはふだん 1 日以内に返信
-
enforce \from future import annotations` via ruff FA102 rule`対応中かも @chethanuk が 35 日前に担当しました。 オープンtask
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
NVIDIA-NeMo/DataDesigner#760 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 15/100
NVIDIA-NeMo/DataDesigner#1033 ·
メンテナーはふだん 1 日以内に返信
-
bug triaged
難易度 2/5 1〜3時間 初心者へのやさしさ 45/100
NVIDIA-NeMo/DataDesigner#1017 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
NVIDIA-NeMo/DataDesigner の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
jbacalso24/mimry#291 ·
メンテナーはふだん 1 日以内に返信
-
good first issue
難易度 2/5 1時間未満 初心者へのやさしさ 82/100
eli-alvarado/us-watchlist-alerts#14 ·
メンテナーはふだん 1 日以内に返信
-
from-review-extraction python severity:nit
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
LearningCircuit/local-deep-research#7462 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
cathrynlavery/diagram-design#441 ·
メンテナーはふだん 2 日以内に返信
-
[Cleanup] Include the public header in work_split.cpp対応中かも @blozano-tt が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
tenstorrent/tt-metal#60850 ·
メンテナーはふだん 1 日以内に返信