mcpField
O
otel-upgrade

otel-upgrade

github.com/ollygardenクラウド・DevOps11764 回インストール2 日前に更新
リポジトリ

otel-upgrade について

otel-upgradeは、リポジトリの証拠に基づいてOpenTelemetryのアップグレードを評価するスキルです。依存関係とCollectorの手順を使い分け、最新の安定版とプロジェクトで検証済みの候補を区別します。

主な機能

  1. 01依存関係またはCollectorの手順選択
  2. 02安定版と互換性の確認
  3. 03隔離環境での検証
  4. 04上流の変更とプロジェクトでの使用状況の照合
  5. 05調査結果と検証上の不足の報告

活用シーン

  1. 01OpenTelemetry SDKのアップグレード評価
  2. 02Collector設定変更の確認
  3. 03サードパーティ製Collectorモジュールの評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ollygarden/opentelemetry-agent-skills --skill otel-upgrade

インストール後、Claude Code で/otel-upgradeを入力して読み込まれたか確認します。

同梱ファイルreferences/collector-upgrade.mdreferences/dependency-upgrade.md

詳細

OpenTelemetry のアップグレード

利用可能なリポジトリ内の根拠に基づいて、サポートされる最も高い安定版の候補を特定し、ケースに即した簡潔なアップグレードのアドバイスを提供してください。ユーザーが実装を依頼していない限り、プロジェクトファイルを変更せずにアップグレードを評価してください。

ワークフローを選択する

リクエストまたはリポジトリ内の根拠参照先
パッケージマニフェスト、ロックファイル、API、SDK、計装ライブラリ、エクスポーター、プラグイン、依存関係の制約依存関係のアップグレード
Collector のバイナリ、イメージ、チャート、Operator、設定、機能ゲート、コンポーネント、OCB マニフェスト、ビルド、実行時の動作Collector のアップグレード
独立してバージョン管理されるモジュールまたはサードパーティ製モジュールを含むカスタム Collectorまず Collector のワークフローを参照し、次に関連するモジュールの制約について依存関係のワークフローを参照してください。

該当するリファレンスのみを参照してください。アップグレードが両方の対象領域にまたがる場合は、両方を参照してください。

共通の指示

  1. ワークフローを選択したり、エコシステムを推測したりする前に、リポジトリと実行環境の根拠を調査してください。
  2. 現在のバージョンと候補バージョンを正確に特定してください。ラッパー、ディストリビューション、成果物、組み込みの依存関係は、それぞれ別に記録し、いずれか一つのバージョンを別のものの証拠として扱わないでください。
  3. 現在の安定版リリースについて、信頼できるレジストリとタグ付きの主要な上流ソースを確認してください。確認日を記録してください。リリース候補版、ベータ/アルファ版パッケージ、ナイトリー成果物、タグのないソースは、そのパッケージ系列が意図的にプレリリース識別子付きで公開されている場合を除き、プレリリースとして扱ってください。プロジェクトが既に使用している実験的なパッケージ系列を、別系列の安定版パッケージで黙って置き換えないでください。明示された要件を満たす安定版リリースがない場合は、プレリリースを別途評価し、その旨を明確に示してください。
  4. 入手可能な最新の安定版リリースと、互換性が検証された最も高い候補を区別してください。関連するチェックを実行できなかった場合、その候補を検証済みと表現しないでください。
  5. 一時コピー、ワークツリー、または同等の隔離環境で検証し、ユーザーの作業ツリーを保持してください。まず最新の安定版候補を試してください。失敗した場合は原因を診断し、必要に応じて選択した下位バージョンもテストしてください。互換性が単調に変化すると想定しないでください。
  6. 上流の変更を、このリポジトリでの実際の使用状況と利用可能な下流の契約に関連付けてください。利用できない利用側、環境、正確なバージョンの適用範囲は、未検証として扱ってください。
  7. 利用可能な場合に限り、該当する専門スキルを使用してください。利用できない場合は、主要な上流ソースとリポジトリ内の根拠を使用し、それによって生じた検証上の不足を報告してください。

依存関係の解決、コンパイル、設定の受け入れ、テストの成功は、それぞれ異なる、限定的な種類の根拠を示します。各結果が具体的に何を示すのかを明記してください。

レポート

リポジトリに合わせて、レポートを簡潔にまとめてください。

## Recommendation

Recommend upgrading `<subject>` from `<current>` to `<target>`, remaining on `<current>`, or deferring the upgrade. Explain the evidence, effort, and risk.

## Relevant Findings

- `<Material finding>` — explain its effect on this repository and any required action.

## Proposed Upgrade Path

Give the smallest coordinated sequence of dependency, artifact, code, configuration, and rollout changes.

## Validation

State the exact candidates, artifacts, configurations, platforms, and checks covered, their results, and what those results demonstrate.

## Remaining Risk

Mention only material behavior, environments, integrations, consumers, or artifacts that could not be verified. Omit this section when no material unverified areas were identified.

上流の重要な主張には、信頼できるリリースノート、ドキュメント、またはソースへのリンクを付けてください。入手可能な最新バージョンが、互換性を検証できた最も高いバージョンでない場合は、両方を挙げ、その妨げとなった要因を説明してください。

コメント