Evaluate reuse of machinery's OpenTelemetry log export to complete native OTEL support (logs, metrics, traces)

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

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

@armru がすでに取り組んでいます。

2026年11月3日 から。

  • #562 @armru による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, grpc
領域
backend, observability

調査の方向性

Start by reading Klio's core/internal/opentelemetry and its logging setup that uses machinery's Flags.ConfigureLogging. Review the open machinery#343 PR to see the proposed WithOpenTelemetry API. The deliverable is a written conclusion in this issue and a comment on machinery#343 before merge; if reusable, a bump PR with unit tests and docs.

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

説明

enhancement

Context

Klio already exports metrics and traces via OpenTelemetry (core/internal/opentelemetry), enabled by the standard OTEL_* environment variables. Logs are the missing signal: they only go to stdout/stderr, so collecting them still requires a node-level DaemonSet or a sidecar.

CloudNativePG hit the same limitation and tracked it in cloudnative-pg/cloudnative-pg#11085 ("Support Otel Log streaming w/o daemonset"). The framework to address it landed in the shared logging library as cloudnative-pg/machinery#343 ("feat(log): export the log records via OpenTelemetry"). Klio already depends on github.com/cloudnative-pg/machinery (currently v0.6.1) for its logging, so it is a natural candidate for reuse.

Note that machinery#343 has not been merged yet, and it should not be merged until Klio confirms that the framework works for it too. Klio is therefore a gating consumer: this evaluation should run against the open PR, and any change Klio needs should be raised on the PR before it lands, not as a follow-up that would force an API change in a released machinery version.

What machinery#343 introduces

From the open PR (to be confirmed against the final code, as the API may still change):

  • An optional WithOpenTelemetry() argument to Flags.ConfigureLogging.
  • Activation via the standard OTEL_EXPORTER_OTLP_ENDPOINT / OTEL_EXPORTER_OTLP_LOGS_ENDPOINT variables. Protocol is http/protobuf unless grpc is requested.
  • A zap core teed with the existing core, inside the duplicate-message sampler, so stdout and OTLP receive the same records at the same level. The log destination is unchanged.
  • Structured fields are exported as attributes using the same keys as the JSON output. The custom debug and trace levels map to DEBUG severity.
  • Batched background export, dropping records rather than blocking when the collector falls behind.
  • ShutdownOpenTelemetry to flush queued records before exit.
  • ForwardToOpenTelemetry, which exports JSON records written by spawned processes while preserving their original time, level and logger name.

Goal

Verify whether this framework can be reused as is by Klio, so that logs, metrics and traces are all exported natively through OTEL, with no DaemonSet or sidecar needed for any of the three signals.

Out of scope

  • Redesigning the existing metrics catalogue or tracing spans.
  • Any change to the stdout log format.

Acceptance criteria

  • A written conclusion (in this issue or a short design note) on whether machinery's framework is reusable as is, or which upstream changes are needed.
  • An explicit confirmation (or list of blocking concerns) posted on cloudnative-pg/machinery#343 before it is merged.
  • If reusable: a follow-up PR bumping machinery to the release containing the change, enabling log export behind the existing OTEL_* configuration, with unit coverage and an e2e or manual verification against an OTel Collector.
  • Docs showing a single configuration that enables logs, metrics and traces together.

Related

  • cloudnative-pg/machinery#343 (open, not to be merged until Klio confirms compatibility)
  • cloudnative-pg/cloudnative-pg#11085
  • cloudnative-pg/cloudnative-pg#11783 (CloudNativePG side of the integration, as referenced by the machinery PR)
主要言語
Go
スター
39
フォーク
10
平均マージ
19時間 58分
マージ済み PR（30日）
175

環境構築

はじめの一歩

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

cloudnative-pg/klio のほかの issue

cloudnative-pg/klio の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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