2 人の Grafana エンジニアが述べたように、可観測性の焦点を左に移せば、CI/CD の問題がエスカレートする前に解決できます。
CI/CD Observability: A Rich New Opportunity for OpenTelemetry、著者 Dimitris Sotirakisより翻訳。
継続的インテグレーションと継続的デプロイ (CI/CD) は最新のソフトウェア配信のバックボーンですが、そのプロセスの可視性は依然として限られています。 OpenTelemetry (OTel) がこの状況をどのように変えていくのか、そしてこれらの変化がなぜそれほどエキサイティングなのかを説明します。
CI/CD の定義は人によって異なりますが、一貫しているのは、継続的であるということです。つまり、手動プロセスを削減し、デプロイ可能なソフトウェアを作成し、問題が発生したときにソフトウェアを提供することが目的の終わりのないフィードバック ループであり、運用環境の前に根絶する必要があります。
この実践は、手動プロセスを削減し、展開可能なソフトウェアを作成し、ソフトウェア配信プロセスの信頼性を高めるために必要になっていますが、ソフトウェア配信プロセスの不安定化を防ぐツールが不足しています。
CI システムの可観測性はまだ初期段階にありますが、現在、さまざまな要因の組み合わせにより、この機会が可能になっています。 CI/CD パイプラインの歴史的に観察できなかった側面、OpenTelemetry と関連作業によって CI の可観測性がどのように実現されるか、将来の開発者の生産性向上の上限について詳しく見てみましょう。
左に移動する余地はまだたくさんあります
CI とアラートは従来、共通の目標を持つソリューションとして使用されてきました。これらは、継続的な自動監視に不可欠なコンポーネントとして密接に連携します。継続的インテグレーションは、初期段階での保護機能です。変更を検出し、ビルドの健全性を維持し、システム信号を継続的に監視します。アラートは後の段階でよく使用されます。 CI で見逃された問題を特定します。したがって、CI が基盤を築き、アラートが脅威に対応することで、同じ問題を解決するための継続的なコラボレーションが可能になります。
しかし歴史的に、可観測性の焦点は物事の「実行」部分にあり、構築、テスト、デプロイメントなどの初期段階からの貴重な洞察や、CI パイプラインの初期段階にあるその他の重要な機会領域は無視されてきました。
私たちは物を配備し、物が発火するのを見て、それから火を消そうとします。
しかし、開発と導入サイクルの最終段階だけを見ていては手遅れになります。構築段階やテスト段階で何が起こったのかが分からなかったり、根本原因の分析が困難であったり、平均回復時間が長くなったりして、最適化の機会を逃してしまいます。 CI パイプラインの実行に時間がかかることはわかっていましたが、より速く実行したい場合、何を改善すればよいのかわかりませんでした。
可観測性の焦点を左に移すと、問題がエスカレートする前に解決でき、プロセス内の問題を減らして効率を高め、テストの堅牢性と完全性を高め、導入後および停止関連のコストと出費を最小限に抑えることができます。
OpenTelemetry が Cloud Native Computing Foundation (CNCF) で最も活発なプロジェクト (厳密には「2 番目に速いプロジェクト」) の 1 つであるのには理由があります。これは、セマンティック規約を定義し、ログ、メトリクス、トレース (可観測性の「3 つの柱」) だけでなく、分析やその他の新しい信号タイプの信号タイプを統一するための優れたプロトコルです。
私たちは、OTel が昨年、かつてはブラック ボックスだった領域にオープン スタンダードと共通基盤の広範なサポートを追加して波紋を起こすのを見てきました。データベース、クラウド プロバイダー、クエリ言語、ログ ファイル形式など、かつては可観測性の高度に独占的であった領域が、現代の多言語世界のプログラミング言語で普及しているほぼすべてのものを動作およびサポートする、明確に定義されたプロトコルによって解読されました。
CI/CD ベンダー ツールの世界には独自のブラック ボックスがあります。すべての開発チームは CI システムを使用しており、ほとんどのチームは複数の CI システムを使用しています。今日、「独自の CI データを所有する」という概念が注目を集めており、よく理解された独自のバックエンド アーキテクチャでそのデータを取得するための複雑な回避策にうんざりしているユーザーが増えていますが、コンテキストの切り替えや専用のバックエンドに苦労しています。
OTel CI/CD ワーキング グループが最初に CI/CD 可観測性のための新しいセマンティック規約の導入を提案し、その後 CI/CD 可観測性に特化した新しい Special Interest Group (SIG) を提案したとき、非常に興奮したのはこのためです。
可観測性データの将来はどのようになるのか
独自のデータを所有するということは、データの行き先と保存方法を自分で決めることを意味します。 CI システムと選択した宛先の間で OpenTelemetry を実行することにより、OpenTelemetry はそれを必要なデータベースとスキーマに変換します。これは、以前はサイロ化されていた CI データに基づいた多くのイノベーションが、可観測性ツール フィールドに導入されていることを意味します。
たとえば、OpenTelemetry Collector ディストリビューションを構築しました。これは、そのレシーバー、プロセッサ、およびエクスポーターが Drone から CI データを抽出し、必要な形式に変換して、そのデータをデータベースに送信するバイナリです。 Jenkins には、OpenTelemetry Protocol (OTLP) 経由でデータをエクスポートするプラグインがあります。
今は可観測性コミュニティにとって非常にエキサイティングな時期です。 CI からデータを取得し、可観測性システムと統合することで、ビルドからログをドリルバックして、最初の障害の時間など、CI から重要な情報を確認できます。そこから、エラーが発生した時期をより正確に特定する方法で、エラーの原因を突き止めることができます。
CI/CD スペースは、可観測性システム用に膨大な量の犯罪前のデータを解放します。ビルドからテレメトリ データを取得すると、デプロイメント ブランチのタイムラインを構築し、どのような障害が発生したかを洞察し、さまざまな不安定なテストの問題をトラブルシューティングし、問題の根本原因を簡単に見つけて再現し、CI/CD パイプラインのパフォーマンスと分析を行うことができます。トラブルシューティングを実行します。
可観測性が CI パイプラインでさらに左に進み続けるにつれて、問題がエスカレートする前に解決し、プロセスから問題を取り除くことで効率を向上させ、テストの堅牢性と完全性を向上させ、デプロイ後やダウンタイムに関連するコストと出費を最小限に抑えることができます。
OpenTelemetry によって推進される CI/CD スペースは、インフラストラクチャ監視やアプリケーション パフォーマンス監視などの他の主要な可観測性ユースケースに加わり、可観測性に関して最も注目を集めて進化する分野の 1 つになると予想されます。
CI/CD は、最新のすべての運用システムの基盤であり、多くの場合、前提条件であるため、運用サービスに使用するベスト プラクティスをそれに適用することで、その重要性を強調する必要があります。
1990 年代生まれのプログラマーがビデオ移植ソフトウェアを開発し、1 年足らずで 700 万以上の利益を上げました。結末は非常に懲罰的でした。 高校生が成人式にオープンソースプログラミング言語を自作―ネチズンの鋭いコメント： 詐欺横行でRustDesk依存、国内サービスの タオバオ（taobao.com）は国内サービスを一時停止、ウェブ版の最適化作業を再開 Java最も一般的に使用されている Java LTS バージョンは 17 、Windows 11 は減少し続ける Open Source Daily | Google がオープンソースの Rabbit R1 を支持、Microsoft の不安と野心; Electricがオープンプラットフォームを閉鎖 AppleがM4チップをリリース GoogleがAndroidユニバーサルカーネル(ACK)を削除 RISC-Vアーキテクチャのサポート Yunfengがアリババを辞任し、将来的にはWindowsプラットフォーム用の独立したゲームを制作する予定この記事はYunyunzhongsheng ( https://yylives.cc/ ) で最初に公開されたもので、どなたでもご覧いただけます。