The Humans of OpenTelemetry - KubeCon EU 2025

Blog posts are not updated after publication. This post is more than a year old, so its content may be outdated, and some links may be invalid. Cross-verify any information before relying on it.

Humans of OpenTelemetry の第4弾をお届けします。 今回の舞台は、イギリス・ロンドンで開催された KubeCon EU です。 Reese Lee と私は、再び OpenTelemetry のコントリビューターやエンドユーザーにインタビューし、彼らが OTel にどのように関わるようになったかを聞きました。

また、以下の方々に特別な感謝を捧げます。

  • Reese Lee:共同インタビュアー
  • Henrik Rexed:音声・映像収録機材の提供と、撮影素材の初期編集

録画の全編はこちらからご覧いただけます。


これまで OpenTelemetry に貢献してくださったすべての方々に感謝します。 2025年以降も皆さんの継続的な貢献を楽しみにしています!🎉

書き起こし

読む方がお好みの方のために、インタビューの書き起こしを以下に掲載します。

1- OTel の人々を紹介

MARYLIA GUTIERREZ: 私の名前は Marylia Gutierrez です。 Grafana Labs のスタッフソフトウェアエンジニアをしています。 また、OpenTelemetry のいくつかの異なるグループでも活動しています。

ADRIEL PERKINS: 私の名前は Adriel Perkins です。 アメリカのコンサルティング会社 Liatrio でプリンシパルエンジニアをしています。 エンドユーザーでもありますが、OpenTelemetry プロジェクトのコントリビューターでもあります。 CNCF アンバサダーの Dotan Horvitz と共に CI/CD SIG の共同リーダーを務めています。 Collector や仕様のリポジトリでも活動しています。

HANSON HO: 私の名前は Hanson Ho で、Android 関連の仕事をしています。 具体的には、Embrace でオブザーバビリティに関する Android の仕事をしています。

JAMIE DANIELSON: 私の名前は Jamie Danielson です。 Honeycomb のエンジニアで、計装ライブラリと OpenTelemetry に取り組んでいます。

MIKKO VIITANEN: 私は Mikko Viitanen です。 Dynatrace でプロダクトマネージャーをしています。 また、OTel Demo App のメンテナーでもあります。

DAMIEN MATHIEU: 私は Damien Mathieu です。OpenTelemetry ではさまざまなことをしています。 OpenTelemetry Go のメンテナーであり、Collector のプロファイリング関連すべてのコードオーナーでもあります。 また、eBPF プロファイラーの承認者でもあります。

JACOB ARONOFF: 私の名前は Jacob Aronoff です。 Omelet の CTO をしています。 私たちはオブザーバビリティ、テレメトリーパイプライン、そして OpenTelemetry を幅広く手がける新しいスタートアップです。

ALOLITA SHARMA: 皆さん、こんにちは。 Alolita Sharma です。 Apple でオブザーバビリティエンジニアリングとオブザーバビリティインフラストラクチャのための AIML をリードしています。

2- OpenTelemetry にどのように関わるようになりましたか?

MARYLIA GUTIERREZ: OpenTelemetry を始めたきっかけは、実はしばらくオブザーバビリティの世界で仕事をしていたことです。 そうしているうちに、いずれ OpenTelemetry のことを知ることになり、これは本当にクールな働き方で、依存関係を持たずに済むということがわかりました。

ADRIEL PERKINS: 私が OpenTelemetry に最初に関わったのは、オブザーバビリティのエンタープライズソリューションを調査するよう頼まれた時でした。 その時に OpenTelemetry、特に Collector を発見しました。 さまざまな場所からの異なるデータソースがたくさんあり、それらを一元化して全体像を把握したかったのです。 それが OpenTelemetry と Collector を見つけた最初のきっかけでした。 そして「これは本当にすごい」と思いました。

HANSON HO: Embrace はコミュニティにどうすればより良く貢献できるかを検討しました。 OpenTelemetry は、人々が共通の標準に貢献するオープンフレームワークとして、注目すべき明らかな選択肢でした。 見た時に「これは素晴らしい。まさに必要なものだ」と思いました。 私たちには独自の SDK があり、独自のシグナルを収集して自社サーバーに送信していました。 OpenTelemetry を使うことで、SDK の中身を大幅に変更することなく、データの送信先をオープンソースの Collector に広げることができました。 調べ始めた時に「モバイルを見てみよう。モバイルは素晴らしい」と思いました。 当時、モバイルの世界で OpenTelemetry に注目している人は少数の例外を除いてあまりいませんでした。 でも関わり始めてから1年ほどで、状況は大きく成長し、関心もずっと高まっています。 関われてとても嬉しいです。

JAMIE DANIELSON: 2021年に Honeycomb に入社した時、所属チームが OpenTelemetry にもっと取り組み始め、オブザーバビリティや計装ライブラリに取り組むようになりました。 Collector や少し Java にも取り組んだ後、最終的に OpenTelemetry JavaScript に落ち着きました。 それ以来3年間、承認者になり、最近ではプロジェクトのメンテナーにもなりました。

MIKKO VIITANEN: 約3年前に OpenTelemetry を始めました。 OTel Demo App への小さな貢献から始めました。 Demo App は計装の基本や Collector の設定を学ぶのに最適な場所だと気づきました。 Demo App はコードやハンズオンに関するあらゆることを少しずつ提供してくれるので、とても良いと思いました。

DAMIEN MATHIEU: 以前、別の会社のオブザーバビリティチームで働いていました。 かなりフラストレーションを感じていました。 ログだけでなくトレーシングも行うべきだと確信していたので、OpenTelemetry を使うべきだと考えていました。 しかし、当時のエンジニアリングメンバーを説得するのはとても難しかったのです。 そこで2022年の新年の抱負として、OpenTelemetry Go のリポジトリをウォッチして貢献を始めることにしました。 そして一つのことがきっかけで次々と進み、1年後にはフルタイムで OpenTelemetry に取り組む仕事に就きました。

JACOB ARONOFF: 私の OTel の旅は、前職の Lightstep から始まりました。 テレメトリーパイプラインチームに所属し、OTel エコシステムへの素晴らしいコントリビューターたちと一緒に働きました。 Kubernetes 側の仕事として OpenTelemetry Operator に取り組み、ターゲットアロケーターのアップグレードを担当しました。 ターゲットアロケーターは、Collector 用の Prometheus スクレイプターゲットを水平にシャーディングするものです。 非常に技術的ですが、エコシステムにとって非常に重要な部分です。

ALOLITA SHARMA: 私が OpenTelemetry に関わり始めたのは6年以上前のことです。 当時は AWS にいました。 Linux の最初の頃からずっとオープンソースプロジェクトに積極的に関わってきました。 クラウドネイティブの世界での旅の中で、AWS でプラットフォームサービスを構築していた時、Kubernetes ネイティブの新世代サービスを構築することにしました。 チームとして、オープンソースオブザーバビリティのすべての新しいプロジェクトに関わる機会を得られたのは本当にエキサイティングでした。 もちろん、OpenTelemetry はその最前線にありました。 これは OpenTracing と OpenCensus が統合されて OpenTelemetry が誕生した直後のことです。 2つのプロジェクトのすべてのコントリビューターが合流し、私のような新しいコントリビューターも参加するという、この素晴らしい新しいプロジェクトを目にするのはエキサイティングな変化でした。

3- あなたにとってオブザーバビリティとは?

MARYLIA GUTIERREZ: 私にとってオブザーバビリティとは、大量の情報があるからこそ、自分が知りたいとすら思っていなかったことを見つけられるということです。 しかし、情報があるだけでは意味がありません。解釈の仕方を知らなければ。 元々は機械工学から来ているとも言われていますが、要はシステムを理解しようとすることであり、それをあらゆるものに拡張できます。 システムのすべてを理解する方法を見つけることは、生活にもオブザーバビリティをもたらし、何が起こっているかを理解することにつながります。

ADRIEL PERKINS: 個人的にオブザーバビリティが何を意味するか? 知らなかったことを発見し、改善できるようにしてくれるものです。 私はずっと継続的な学習と改善が好きな人間で、オブザーバビリティはそれを助けてくれます。 知らないことがたくさんあるからです。 知れば知るほど、知らないことがもっとあると気づきます。 オブザーバビリティは、それを発見する助けになりました。 さまざまなアプリケーションやサービスの技術的なレベルでもそうですし、社会技術的な面でも助けになりました。 ソフトウェア開発ライフサイクルの一環として発見できたテレメトリーのおかげで、より良いエンジニアになれました。 全般的に、発見を助けてくれるものです。

HANSON HO: オブザーバビリティ。 Hazel Weakly の定義を要約すると、質問をして答えを得ること、特に最初は聞く必要があるとは思わなかった質問について、そしてそれに基づいて行動することです。 データから行動し学ぶことができること。 単なるテレメトリーではなく、データを通じてシステムを理解することです。

JAMIE DANIELSON: オブザーバビリティとは、システムに対するインサイトを持つことです。 アプリケーションがどう動いているか、システムがどう機能しているかを理解し、何かが起きるまで必ずしも重要だとわからなかったものへの可視性を持つことです。 サービスにおける未知の未知を見つけ、そうでなければ意味をなさないかもしれないことを理解できるようにすることです。

MIKKO VIITANEN: 実は何年も前から関わっていました。 テレコムネットワークで働いていた時、オブザーバビリティは本当に重要でした。 たとえば、ここからアメリカに電話をかけるとします。 その通話はいくつものノードを通り、複数の通信事業者を経由します。 オブザーバビリティがなければ問題を特定できません。 お客様が「なぜ通話が切れるのか?」と問い合わせてきた時、何が起こっているかを把握し問題を特定するためには、本当に強力なオブザーバビリティが必要です。

DAMIEN MATHIEU: オブザーバビリティに取り組む前は、いわゆる SRE やそれに相当する役割で何年も働いていました。 インシデント管理もやっていて、インシデントコマンダーも務めました。 多くのインシデントで根本原因を突き止めようとしました。 日曜日の朝だったりするので、原因の特定はとても難しいです。 もうあんな経験はしたくありません。 オブザーバビリティに取り組むことで、もし SRE やオペレーションの役割に戻った場合、状況がもっと良くなるはずです。 そして、もし […] であれば、他の人にとっても良くなるはずです。

JACOB ARONOFF: 個人的には、任意の時点でシステムで何が起こっているかを理解することです。 オブザーバビリティとは一般的に、稼働中のサーバーの状態を知ることだと考えています。 私が使うたとえ話は、車を運転する時に目の前にダッシュボードがあり、車を効果的に操作しているかどうかを示す多くの計器や計測値があるということです。 オブザーバビリティも同じですが、1台の車よりもはるかに大きな規模のサーバーに対するものです。

ALOLITA SHARMA: オブザーバビリティは私にとって大きな意味があります。 特にクラウドネイティブのインフラストラクチャとアプリケーションにおいて、オブザーバビリティという分野は、アプリケーションとインフラストラクチャが可観測であること、つまり動作することを保証するために非常に重要な部分だと考えています。 ソフトウェアエンジニアとして、特に分散システムエンジニアとして、アプリケーションを構築し、パブリッククラウドであれオンプレミスの Kubernetes ベースのインフラストラクチャであれ、クラウドネイティブインフラストラクチャを使用している場合、必然的に多くの複雑なマイクロサービスと向き合うことになります。 アプリケーションにもインフラストラクチャにも、初日からオブザーバビリティを組み込むことが絶対に不可欠です。 そして、今日のオブザーバビリティの状況として、テレメトリーの収集だけではありません。 アプリケーションだけでなく、モデルやインフラストラクチャからも、文字通り数兆ペタバイトのデータが生成されています。 ストレージ、パフォーマンス、分析、そして可視化を含むソリューション全体がどう機能するかについても考える必要があります。

4- あなたにとって OpenTelemetry とは?

MARYLIA GUTIERREZ: 私にとって OpenTelemetry とは、誰にも依存する必要がないこと、そしてコミュニティでもあります。 みんなが一緒に働く方法であり、通常は競合相手と見なす人とも実際には協力します。 ミーティングに参加したりペアプログラミングをしたりして、コミュニティが成長するのを見たい。 みんなが一緒に取り組むことで問題を解決できるようにしたいのです。

ADRIEL PERKINS: OpenTelemetry が何を意味するか? とても多くのことです。多くのことができるからです。 さまざまな部分に触れることができたおかげで、非常に大きな意味を持つようになりました。 本質的には、あらゆるオブザーバビリティスタックの中心にあるものだということです。 OpenTelemetry があれば、どのバックエンドベンダーを使っていても、必要なことを正確に把握できます。

HANSON HO: OpenTelemetry は、少しずつ異なるゴールを持ちながらも、全員にとって達成できる同じものに取り組むことで、みんなが協力する機会だと思います。 オープンスタンダードがあることで、同じ言語を話せることが重要です。 オブザーバビリティのための共通語(リンガフランカ)が必要です。 実際にあまり価値を加えないプロプライエタリなものを使うのではなく。 […] 同じ言語を話しましょう。 物事をまとめる方法は違うかもしれませんが、ボキャブラリーについて合意しましょう。 文字について合意しましょう。 OpenTelemetry は、文字通り同じプラットフォームの壁の向こうにいなくても、お互いを理解できる機会を与えてくれると信じています。

JAMIE DANIELSON: OpenTelemetry は私にとって特別なものです。 数年間 OpenTelemetry に関わってきましたが、ベンダーニュートラルなスタンダードで、みんなが使えて、スタンダードがあることで全員が恩恵を受け、さまざまな場所から貢献があるというアイデアが大好きです。 ベンダーから、エンドユーザーから、情熱を持つコミュニティのさまざまな人々から。 一生懸命に働き、お互いに責任を持ち合い、このプロジェクトを最高のものにしようとする友人や仲間に囲まれているような感覚です。 ベンダーは自分たちのバゲットやプロダクトの機能で競争し、エンドユーザーがアプリケーションを計装してシステムの可視性を得るのがより簡単になる。 別のベンダーに切り替えたい時に別のエージェントに対処する必要がない。 非常にオープンで、みんなにとって使いやすいものです。

MIKKO VIITANEN: OpenTelemetry は、オープンソースプロジェクトの素晴らしい事例だと個人的に感じています。 競争的な業界にいながら、100社以上の企業が OTel に貢献し、共通の課題を解決し、毎日協力しています。 コミュニティと協力がすべてだと感じています。

DAMIEN MATHIEU: 私にとっては、単にエンジニアリングの問題を解決するだけでなく、グローバルコミュニティが非常にフレンドリーで歓迎的だということだと思います。 15以上の言語にわたって、非常に異なるニーズや問題、問題の解決方法を持つ中で、物事がどう機能すべきかについて共通の理解を持つことに成功したのは、極めて印象的だと思います。 人間としてそれを解決できたことは、非常に励みになります。 また、現在の環境で、複数の企業、競合他社が、それぞれの小さな領域に留まるのではなく、一緒により良い価値を提供できるように何かを構築するために手を組んでいるのは、非常にまれなことだと思います。 それが OpenTelemetry の偉大な点だと思います。

JACOB ARONOFF: 私にとって OpenTelemetry は、すべてのデータを取得する方法です。 一つのことを行うための標準的な方法があるべきだと合意した、非常に広大なエコシステムです。 車のたとえに戻ると、日産やボルボの運転を学ぶのではなく、車の運転を学びますよね。 同じように、エンジニアリングを学ぶ時に、別の会社に移るたびにすべてを学び直す必要がないように、スタンダードがあることが重要です。 それが私にとっての OpenTelemetry の意味です。

ALOLITA SHARMA: OpenTelemetry は今日、約80のリポジトリを持つプロジェクトです。 ご存知の方も多いかもしれませんが、OpenTelemetry は非常に大きなプロジェクトです。 コンポーネントの集合体であるだけでなく、ベンダーとエンドユーザーが技術的な課題を解決し、OpenTelemetry の最高のコンポーネントを構築するために協力するパートナーシップとコラボレーションという点で、素晴らしいコミュニティでもあります。 私にとって OpenTelemetry は、クラウドネイティブアプリケーションのコレクションアーキテクチャを構築するための不可欠な部分であるだけでなく、プロジェクト内のさまざまなコンポーネント間の相互運用性が実際に活用され、OpenTelemetry Protocol のようなオープンスタンダードがエンドツーエンドで実装されている素晴らしいコミュニティでもあります。 これは業界にとってのゲームチェンジャーです。 OpenTelemetry Protocol について特に言及するのは、エンドユーザーがオブザーバビリティのためのソリューションをエンドツーエンドで構築し、メトリクスやログやトレースやプロファイルなど収集するすべてのデータのプロトコルについて考える必要なく、すぐに使えるオブザーバビリティを利用できるようにするものだからです。 私はプロジェクトとしてもコミュニティとしても OpenTelemetry が大好きで、さまざまな部分に取り組むのが大好きです。 Collector に注力し、Collector contrib コンポーネントではインテグレーションを追加し、OpenTelemetry Collector の Operator を改善し、Operator にターゲットアロケーターの改善などのメトリクスやパフォーマンス機能を追加し、トレーシングやロギングの改善にも取り組んできました。

5- お気に入りの OpenTelemetry シグナルは?

MARYLIA GUTIERREZ: お気に入りのテレメトリーシグナル…やはりメトリクスが好きです。 トレースについても少しずつ知るようになりますが、メトリクスはまだシグナルへの入り口のようなものだと思います。 人に説明するのがとても簡単だからです。 数字です。 そしてその数字の上に、たとえば属性を追加して、さらにデータを得ることができます。 こうすることで、最初から大きなトレースやスパンに人々が怖がることなく、少なくともこの分野にもっと多くの人を引き込むことができます。 そこからさらに発展させていけるのです。

ADRIEL PERKINS: お気に入りのテレメトリーシグナル。 1つを選ぶのはとても難しいです。非常にうまく組み合わせられるからです。 最初はメトリクスがお気に入りでした。SDLC で最初に見たものだったからです。 しかし、トレースやトレーシングパイプラインにもっと深く入るにつれ、その強力さを実感しました。 トレースからあらゆるシグナルを導出でき、直接埋め込むことができます。 今はトレーシングがお気に入りだと言わなければなりません。

HANSON HO: まあ、トレースが本当に一番パワフルです。 だから今はトレースを選びます。 スパンにしましょう。 スパンが大好きです。 スパンマンです。

JAMIE DANIELSON: 私のお気に入りの OpenTelemetry シグナルは、おそらくトレースです。 トレースが本当に好きです。 アプリケーションの1つの場所、1つのサービスから始まって、リクエストがサービスからサービスへとエンドツーエンドで流れるのを見て、そうでなければ可視性がなかったかもしれない流れを理解できるというアイデアが好きです。 完全に接続されたトレースだからです。 そう、トレースがお気に入りのシグナルだと思います。

MIKKO VIITANEN: お気に入りのテレメトリーシグナル。 すべて重要ですが、主に分散トレースを選びます。 特別だと思うのは、1つのビュー、1つのウォーターフォールビューで簡単に全体像を把握でき、問題を特定できるからです。 リクエストが拒否された場合、そのビューを見るだけで、どのサービスが拒否を引き起こしているか、すでにわかることが多いです。 リクエストが非常にゆっくり返される場合や、システムが遅い場合も、分散トレースから各サービスがどのように積み重なっているかを確認できます。 多くのインサイトが得られます。

DAMIEN MATHIEU: ああ、同僚に嫌われそうですが、トレーシングです。 プロファイリングにもたくさん取り組んでいて、一緒に働く人たちは本当にプロファイリングを中心に考えています。 どちらも非常に重要だと思います。 しかしプロファイリングは、すべてがうまくいっていて改善したい時のためのものです。 トレーシングは、壊れていてなぜかを解明する必要がある時のためのものです。 それが私が OpenTelemetry に入ったきっかけであり、私の仕事の経験でもあります。 だからお気に入りのシグナルはトレーシングです。

JACOB ARONOFF: 私のお気に入りのテレメトリーシグナルは圧倒的にトレーシングです。 トレーシングは、すべての中で最高のものだと思います。 メトリクスを導出でき、ログを導出でき、高レベルのオブザーバビリティ目標と低レベルのデバッグの両方を理解するのに役立つ、非常に重要な可視化ができます。 最も重要で、最も誤解されているものだと思います。

ALOLITA SHARMA: 今日の私のお気に入りのテレメトリーシグナルは、メトリクスとトレースです。 その理由は、特に AI アプリケーションのリアルタイムのオブザーバビリティを見る時、新世代のアプリケーションにおいて、トレーシングはプロファイリングと組み合わせることで、モデルの動作やソフトウェアアプリケーションの動作を理解するのに非常に価値があるからです。 メトリクスと組み合わせると、通常インフラストラクチャシステムのテレメトリーと理解を得るための標準的な方法であるメトリクスが、スタック全体にわたるオブザーバビリティとオブザーバブルなコンポーネントのエンドツーエンドのビューを提供する非常に素晴らしい方法になります。

ご参加ください!

あなたの組織で OpenTelemetry をどのように使っているかのストーリーがあれば、ぜひお聞かせください! 共有方法は以下の通りです。

OpenTelemetry を MastodonBlueskyLinkedIn でフォローし、#OpenTelemetry ハッシュタグを使ってストーリーを共有してください!

そして、YouTube チャンネルの登録もお忘れなく。 素晴らしい OpenTelemetry コンテンツがもっとあります!