The Humans of OpenTelemetry - KubeCon NA 2024

By Adriana Villela (Dynatrace) |

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 の第3弾をお届けします。 今回の舞台は、アメリカ・ユタ州ソルトレイクシティで開催された KubeCon NA です。 Reese Lee と私は、再び OpenTelemetry のコントリビューターやエンドユーザーにインタビューし（そしてお互いにも！）、彼らが OTel にどのように関わるようになったかを聞きました。

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

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

動画

フルバージョンの録画はこちらからご覧いただけます。


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

書き起こし

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

1- OTel の人々を紹介

Hazel Weakly: こんにちは。 私の名前は Hazel Weakly で、いつもたくさん考えています。 考えることが止まりません。 本当に止まらないんです。

Eromosele Akhigbe: 私の名前は Eromosele Akhigbe で、現在 Sematext でソフトウェアエンジニアをしています。 皆さん、こんにちは。

Budha Bhattacharya: 私は Budha です。 Tyk でデベロッパーアドボケイトをしています。 それ以外にも、オープン標準と深い関わりがあり、OpenAPI Initiative の理事長であり、GraphQL Foundation の理事も務めています。

Miguel Luna: 私の名前は Miguel Luna で、Elastic のプロダクトマネージャーです。 会社全体の OpenTelemetry への取り組みとコミュニティへの貢献をリードしています。

Adriana Villela: 私の名前は Adriana Villela で、Dynatrace のプリンシパルデベロッパーアドボケイトです。

David Gohberg: 私の名前は David で、Monday.com で働いています。 ソフトウェアエンジニアとして、CRM プロダクトの開発に携わっています。

Endre Sara: 私の名前は Endre Sara で、Causely という会社の共同創業者です。 2年前に Causely を立ち上げました。

Braydon Kains: 私の名前は Braydon Kains です。 Google の Google Cloud Org でソフトウェアデベロッパーをしています。 Cloud Observability サービスに所属し、主にお客様の環境にインストールしてテレメトリーシグナルを収集し Google Cloud に送信するエージェントの開発に携わっています。

Christos Markou: 私の名前は Christos です。 Elastic でソフトウェアエンジニアをしています。 過去5年間、主にオブザーバビリティの分野で働いてきました。 昨年からは OpenTelemetry のエコシステムへの貢献が中心になっています。

Reese Lee: こんにちは、私の名前は Reese Lee で、New Relic のシニアデベロッパーリレーションズエンジニアです。

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

Hazel Weakly: OpenTelemetry ですね。 このプロジェクトには、ある意味偶然関わることになりました。 ただ、今ではどんなことに対しても「偶然」と答えている気がします。 偶然というのは、自分が持っていた疑問への答えを探していたということです。 それ以上に重要だったのは、他の人がより良い答えを見つけられるようにどう教えるか、そして一緒に働いているチームや組織をどうレベルアップさせていくかということでした。 人々がより良い質問をし、答えを得て、そこから学ぶ方法を見つけ出す過程で、最終的に OpenTelemetry にたどり着いたのです。

Eromosele Akhigbe: 3月に、Outreachy というインターンシップに参加しました。 Outreachy では OpenTelemetry に関わる機会をいただき、Golang でロギングブリッジの構築に取り組みました。 インターンシップの終わりまでに、OTel zerolog を使ったロギングブリッジを構築することができました。

Budha Bhattacharya: OpenTelemetry にどう関わるようになったか？ これは複数の要因がある質問、いえ、回答ですね。 注目するようになったきっかけはいくつかあります。 まず、新しく入ったグループプロダクトマネージャーのアドボカシーから始まりました。 彼女はオブザーバビリティ、特に OpenTelemetry の強力な支持者でした。 私は OpenTracing や OpenCensus を少しいじったことはありましたが、OpenTelemetry についてはあまり調べていませんでした。 でも彼女が来てからは私も大いに賛同し、注目するようになりました。 それがきっかけの1つ目です。 2つ目は、オープン標準であるという事実です。 私にとって、オープン標準に関わることは当然の選択です。

生活を楽にするオープン標準には、いくらでも時間を投資できます。 柔軟性の観点からも、これが正しい方向だと思います。 それが2つ目のきっかけです。 3つ目のきっかけは、実際に OpenTelemetry を使い始めた時です。 Tyk は API 管理プラットフォームです。 私たちにとって、OpenTelemetry は社内外で使われていました。 社内では、問題のトラブルシューティングがどれだけ迅速かつ効率的にできるか、問題の核心にたどり着けるかという点で、すでに成果が見え始めていました。 REST API だけでなく、GraphQL API でもその効果がありました。 ユースケースとしては考えられなかったかもしれませんが、抱えていた問題の一部を解決することができました。 それが3つ目のきっかけです。 これらすべてが合わさって、OpenTelemetry は注目に値するという結論に至りました。

Miguel Luna: 最初はプロダクトマネージャーとして始めました。 直接貢献するというよりも、コーディネーションが中心の役割だったので、とても興味深い経験でした。 しかし最近は、ドキュメントのローカリゼーションに関わっています。 つまり、ドキュメントの翻訳です。 私の場合は特にスペイン語話者向けです。 つまり、la traducción de la telemetría abierta。 つまり、OpenTelemetry ドキュメントのスペイン語への翻訳です。

Adriana Villela: 以前の職場で、当時のマネージャーが OpenTelemetry コミュニティに参加するよう勧めてくれました。 実は、オープンソースに貢献するのは初めてでした。 テック業界に20年以上いましたが、一度もオープンソースに貢献したことがなかったのです。 マネージャーが「まずはいくつかのミーティングに参加してみて」と言ってくれました。 最初に参加したミーティングは OTel comms のものでした。 それが私の OpenTelemetry への入り口となりました。

David Gohberg: 私のキャリアは組み込みアプリケーションから始まりました。 eBPF トレーシングがまだ広く知られる前から、それに取り組んでいました。 その後 Dropbox に移り、そこでは OpenTelemetry がメインストリームになる前に、すべてのテレメトリーが社内独自のものでした。 現在の Monday では、トレースベースのテスティングを続けています。

Endre Sara: OpenTelemetry について学び始めて、これが業界全体にとって計装の方法を標準化し、共通のセマンティック規約を使って人々がシステムの状態を理解できるようにする大きな機会であることに気づきました。 すぐに興味を持ち、取り組み始めました。 最初はいくつかのテストアプリケーションでしたが、その後、計装のやり方を人々にデモしました。 しかし、現在の会社を立ち上げてからは、初日からソフトウェアを適切に計装し、より多くのお客様を獲得した際にログ、メトリクス、テスティングでシステムを運用できるようにしなければならないと決めました。 OpenTelemetry は大いに役立っています。

Braydon Kains: OpenTelemetry に関わるようになったのは、私たちのチームが OpenTelemetry、特に OpenTelemetry Collector を使って、お客様の環境からデータを収集するのをサポートしているからです。 過去に OpenTelemetry でバグや問題があった際、チームからの関与は限定的で、Issue を作成して対応されるのを待つだけでした。 私はチーム内でその状況を変えたいと強く思っていましたし、同じ思いのチームメンバーもいました。 そこで、PR 付きの Issue を作成するという、より本格的な取り組みを始めました。 これにより、チーム全体が OTel への関与を深めることになりました。 私自身はさらに深く関わるようになり、今では Host Metrics Receiver のコードオーナーになっています。 これは私たちにとって重要なレシーバーですが、自分たちの問題を修正するだけでなく、すべての人にとって良いものにするために時間を費やせるようになりました。

Christos Markou: 最初は、Elastic Common Schema の OpenTelemetry への寄贈を支援するよう依頼されたのがきっかけです。 具体的には仕様とセマンティック規約への貢献でした。 それ以来、Collector など他のプロジェクトにもますます関与するようになりました。 現在は主にセマンティック規約と OpenTelemetry Collector、特に Collector contrib プロジェクトに注力しています。

Reese Lee: OpenTelemetry に関わるようになったきっかけは New Relic での仕事でした。 最初の体験は、OpenTelemetry を採用したお客様に関するサポートチケットでした。 その後、当時の専任 OpenTelemetry チームにデベロッパーリレーションズエンジニアとして参加する素晴らしい機会がありました。 2021年11月のことでした。 その後すぐに OpenTelemetry コミュニティに溶け込むことができました。 実は、前のマネージャーの Sharr Creeden が End User Working Group（現在は End User SIG）の立ち上げを主導しました。

3- OpenTelemetry はどのように役立ちましたか？

Hazel Weakly: OpenTelemetry は、私がこれまで働いてきた組織でとても役に立ちました。 さまざまなベンダーやツール、その他の中間的な手段と連携できるようになったからです。 私にとっての大きなメリットは、エンジニアリングに限らず、会社のさまざまな部門からの異なるコンテキストをすべて結びつけて、人々の質問に対する答えを示せることです。 これは新しい機能です。 以前はエンジニアリングが独自の世界にいましたが、もはやそれを続けることはできません。 OpenTelemetry は、エンジニアリングの知識を外に持ち出し、外部の知識をエンジニアリングに取り込む上で、非常に大きなインパクトをもたらしてくれました。

Budha Bhattacharya: 社内では物事がずっと効率的になりました。 SRE チームや DevOps チームと話すと、プラットフォームスタックのさまざまな要素を扱う際にずっと満足しています。 管理やハンドリングがずっと楽になったのです。 エンドユーザーについて言えば、彼らはその価値を実感しています。 個人的には、アドボカシーの面が本当に充実しています。 コミュニティにさまざまな形で関わることで、多くを学べました。 今年の初めには、LEAP という API オブザーバビリティカンファレンスのミニカンファレンスを開催する機会がありました。 コミュニティの多くの方々が、エンジニアリングの側面だけでなく、意思決定者が組織内で OpenTelemetry のような技術を導入する価値をどう認識できるかについても発表してくださいました。

Miguel Luna: すべては Elastic が Elastic Common Schema を寄贈することを決めた時に始まりました。 これは OpenTelemetry の目標、つまりオブザーバビリティを標準化し、テレメトリーデータを単一の標準に集約することで効率を高めるという目標に自然にフィットするものでした。

David Gohberg: キャリアを始めた頃には OpenTelemetry はまだなかったので、トレースの方法、メトリクスとの相関の取り方、ログの扱い方を自分で考え出す必要がありました。 しかし今では、これらの取り組みはすべてコミュニティによって標準化されているので、OpenTelemetry に初めて触れるエンジニアは私の時よりもずっと楽に始められます。

Endre Sara: 全般的に言えば、アプリケーションからシグナルを取得し、それを使って環境を運用しシステムの動作を理解する能力は、以前のプロプライエタリな計装と比べて、OpenTelemetry を使うことで格段に容易になったと思います。 より興味深いのは、そのデータで何をするかということです。 これらの情報のほとんどは、セマンティック規約に基づいて美しくコンテキスト化されたダッシュボードで人々に提示されています。 しかし最大の利点は、ソフトウェアを使ってデータを合理的に活用できることだと思います。

Braydon Kains: OpenTelemetry が個人的に一番役立ったのは、大規模なコミュニティとの関わり方を学んだことです。 オープンソースコミュニティの経験はすでにありましたし、「仕事をすればプロジェクトに発言権を持てる」という一般的な文化もあります。 オープンソースの世界ではそれは普通のことで、良いことだと思います。 しかし、OpenTelemetry には変更を反映させるための非常に大きな仕組みがあります。

Christos Markou: OpenTelemetry のエコシステム全体で働くのがとても好きです。 他の会社や他のチームの人々と一緒に働くことは、エンジニアとして個人的にとても成長につながります。 他の人々がどのようにオブザーバビリティに取り組んでいるかを知ることができるからです。 常に多くのことを学べます。 これは私がとても気に入っている点で、チーム全体にとっても非常に有益だと思います。 仕事の面でも素晴らしいです。 オープンソースが本当に好きで、オープンソースプロジェクトに取り組むのが大好きです。 個人的なレベルでも本当に助けになっています。

Reese Lee: OpenTelemetry は、正直に言って個人的にとても大きな形で役立っています。 OpenTelemetry のデベロッパーリレーションズの仕事を通じて、先ほど話したように、多くの素晴らしい人々と出会うことができました。 私の役割の一環として、さまざまなイベントにトピックを提出する機会があり、そのために自分自身もこれらのトピックについて学び、本番環境で使っている人や自分で試している人と話せることは、本当に素晴らしい経験でした。

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

Hazel Weakly: 私にとってのオブザーバビリティの定義は、意味のある質問をし、有用な答えを得て、学んだことに基づいて効果的に行動する能力を身につけるプロセスです。 つまり、答えを見つけるだけでは十分ではないということです。 何度も何度も繰り返し取り組むプロセスがあり、個人レベルだけでなく、組織レベル、グループレベル、さらには業界レベルでスキルを磨いていきます。 それを続けることで、本当に有用な答えと本当に意味のある質問が得られるようになります。 そしてグループ全体の学びのプロセスが、私たちが自分自身に引いた境界線を超えていくのです。 その境界線が制限ではなく、力を与えるものに変わるのです。

Eromosele Akhigbe: オブザーバビリティエンジニアは、システムの医者のようなものです。 システムに何か問題がある場合、私たちが正確にどこに、何が問題なのかを特定し、それを解決する必要があります。 それが私にとってのオブザーバビリティの意味です。

Budha Bhattacharya: オブザーバビリティとは何か？ 技術的な答えとしては、モニタリング、ロギング、トラブルシューティングの領域に入ります。 私にとっては、「理解」がすべてです。 自分が作ったプラットフォームの脈動を理解することです。 私は API をよく扱うので、すべてが API プラットフォームに関係しています。 API プラットフォームの脈動を理解し、さまざまなコンポーネントがどう組み合わさっているか、何が機能し何が機能していないか、その良い面も悪い面もすべてを知ること。 それが私にとってのオブザーバビリティです。 つまり、問題の核心にたどり着き、何がうまくいっていて何がうまくいっていないかを知り、より効果的に意思決定できるようにすることです。

Miguel Luna: モニタリングとは、聞くべきだとわかっている質問の答えを知ることです。 オブザーバビリティとは、聞くべきだと気づいていなかった質問の答えを知ることです。

Adriana Villela: 私にとってオブザーバビリティとは、システムの洞察を得る能力です。 これは私にとって非常に変革的でした。 人生の中で何度も、開発者として自分のコードや本番環境のコードをデバッグしていて、ログを見ても全体像とどう関係するのか理解できないことがありました。 本番環境の問題をトラブルシューティングした記憶がたくさんあります。 「システムが遅い」と言われ、アプリサーバーの管理者に「ログを確認してくれますか？」と聞くと「私の問題じゃない」。 DBA に聞いても「私の問題じゃない」。 他の人に聞いても同じで、全員に聞いても誰の問題でもない。 でもレイテンシーは依然として発生している。 オブザーバビリティはそのすべてを明らかにしてくれると感じています。 突然、実際の根本原因がどこにあるかが見えるようになる。 それがオブザーバビリティの魔法であり力だと思います。

David Gohberg: 今日のソフトウェアエンジニアリングで最も重要なのはユーザー体験です。 ソフトウェアはますます複雑になっているため、「ユーザーは私のプロダクトをどう体験しているか？」という問いに答えるのが難しくなっています。 OpenTelemetry は、こうした難しい問いに答え、ソフトウェアの可視性を提供してくれます。

Endre Sara: おそらく最も明白な答えは、シグナルを収集できることでしょう。 しかし、オブザーバビリティの本当のポイントは、システムの動作を理解し推論することだと思います。 単にデータを収集するだけでは、実はあまり成果につながりません。 データが意味を持ち価値あるものになり、人々がそれを使ってアクションや意思決定を推進できるようになることが重要です。 信頼性をどこで改善すべきか？ アプリケーションのパフォーマンスをどこで改善すべきか？ アーキテクチャをどこで変更すべきか？ オブザーバビリティはまさにそれに応えるものだと思います。 そうでなければ、ただのデータの湖です。

Braydon Kains: 私にとってオブザーバビリティとは、何が起こっているかわかるということです。 コンピューターは、1と0が何をするか理解するブラックボックスです。 人間として、コンピューターが猛スピードで処理している1と0が何をしているのかを、任意の時点で理解できること。 そのスピードでどうやってそれが何を意味するかを把握できるでしょうか？ つまり、私にとってオブザーバビリティとは、コンピューターが何をしているかを人間が理解するためのものです。

Christos Markou: 私にとってオブザーバビリティは、大学時代から取り組んできたもので、非常に重要な分野です。 システムを運用する上で本当に重要なのは、システムを観測し、システムが正常に動作しているかどうかを知る方法だと思います。 特に、私はインフラストラクチャのバックグラウンドから来ています。 インフラストラクチャにおいては、コスト削減の観点でも非常に重要です。 システム全体がどのように動作しているかは、見逃すことのできない重要な要素です。

Reese Lee: 私にとってオブザーバビリティとは、さまざまなアプリケーションやソフトウェアプログラムのエンドユーザーとして、より良い体験ができるということです。 これらのプロダクトを構築している企業がオブザーバビリティを活用し、コードで発生している問題を把握できていれば、エンドユーザーとしてより良い体験を得られるからです。

5- あなたにとって OpenTelemetry とは？

Hazel Weakly: 私にとって OpenTelemetry は、企業は利益を出す必要がある、企業はイノベーションを起こしたい、人々は競争したい、人々はさまざまなソリューションを開発したいという、ある種の資本主義的な概念を取り込み、その上で構築される興味深いアプローチの1つです。 それらすべてを、競争を許容し、アイデアの実現を可能にし、イノベーションを継続させつつも、可能性を制限せず、業界にその複雑さの進化や卓越性の追求の途中経過を負担として課さない、十分に柔軟なプロジェクトにまとめ上げるのはどうすればよいか。 それが OpenTelemetry なのです。

Eromosele Akhigbe: OpenTelemetry はオブザーバビリティの未来だと信じています。 3月に OpenTelemetry の調査を始めた時、これがどれほど大きな可能性を持つかを知り、OpenTelemetry に全力で取り組むことを決めました。 オブザーバビリティの未来であり、誰もが取り組むべきだと信じています。

Budha Bhattacharya: OpenTelemetry とは何を意味するか？ それは「理解」の延長です。 技術的な答えとしては、分散トレーシングを支えるオープン標準です。 それはその通りです。 私にとっては、プラットフォームスタックのさまざまなコンポーネントや要素が共通の言語やフレームワークを通じて結びつき、プラットフォーム全体の健全性を伝えることによる、理解の拡張です。 それはエンジニアリングの観点からビジネスの観点まで及びます。 両方に影響があります。 それが OpenTelemetry という技術がもたらすものですが、コミュニティについても同様です。 業界全体が集まって標準に合意することで、SRE、DevOps 組織、ツールプロバイダー、エンドユーザー、すべての人の生活がずっと楽になります。 オープン標準があることで、プラットフォームの柔軟性が高まり、進化や成熟の自由が増し、将来への準備ができます。 それが私にとっての OpenTelemetry が約束する柔軟性と自由です。

Miguel Luna: 私にとっては共通言語を意味します。 ユーザー全員が集まり、収集するものがすべて同じ方法、同じメカニズムで収集されることを理解できる場所です。 また、物事の呼び方もそうです。 セマンティック規約によって、物事を何と呼ぶかという共通の標準に合意しています。 テレメトリーが統一され、再利用可能になる。 それが私にとっての OpenTelemetry です。

Adriana Villela: OpenTelemetry は私にとって何を意味するか？ 実は、家のような存在です。 ここ2年半ほど、私の居場所になっているからです。 本当に人生を変える存在でした。 先ほど言ったように、オープンソースや CNCF コミュニティへの入り口でした。 だから、コードを計装するためのオープン標準という一般的な定義を超えて、とても個人的な意味を持っています。 私にとっては、さまざまなベンダーの人々が敵ではなく友人として、同じ目標に向かって協力している素敵なコミュニティです。

David Gohberg: OpenTelemetry は基本的に、ソフトウェアについて難しい質問をしたいすべてのエンジニアの取り組みを標準化する方法です。

Endre Sara: OpenTelemetry は、複数のベンダーが協力し合い、計装を競争の要素ではない所与のものとして捉え、この情報をアクショナブルなインサイトに変えるという価値の創出に本当に集中する方法を提供しています。 そこに人々、ベンダー、エンドユーザーがイノベーションを期待しているのだと思います。 つまり、OpenTelemetry は基本的に、ベンダーが本当の価値がある場所に集中するためのイネーブラーなのです。

Braydon Kains: 私にとって OpenTelemetry は、業界が一丸となって「本当に何について競争しているのか？」「企業として市場のどこに位置づけようとしているのか？」を理解することの表れです。 シグナル自体で差別化する価値はあまりなく、この分野で合意しないことは全員にとってマイナスだということを、私たちは集合的に理解していると思います。 シグナルの部分で合意できれば、すべての企業がデータの活用方法という、実際に差別化できる方法に、より多くの時間を費やせるようになります。

Christos Markou: この1年間 OpenTelemetry に関わってきて、OpenTelemetry はオブザーバビリティの分野に本当に情熱を持つ人々と出会い、学ぶための素晴らしい場所だと思います。 本当に好きなことをしていて、それに長けている人々で構成されています。 エンジニアが集まり、協力し、オブザーバビリティの分野を発展させていくための素晴らしい場所です。

Reese Lee: 私にとって OpenTelemetry は多くのことを意味します。 プロジェクトとしての側面や、さまざまな組織がスタック全体でオープンソースを採用し推進するのを助けてきた側面だけでなく、巨大で素晴らしいコミュニティでもあります。 メンテナーと出会い、エンドユーザーを知ることをとても楽しんでいます。 OpenTelemetry コミュニティの多くの方々と良い関係を築いています。 それが私にとっての OpenTelemetry の意味です。

6- お気に入りの OpenTelemetry シグナルは？

Hazel Weakly: お気に入りの OpenTelemetry シグナルですか。 少しズルをして、こう答えます。 私のお気に入りの OpenTelemetry シグナルは、人々が最も意味のあると感じる質問に対して、最も有用だと感じる答えを与えてくれるシグナルです。

Eromosele Akhigbe: トレースです。 トレースがお気に入りのシグナルです。 システム全体で何が起こっているかの全体像を把握でき、エラーを簡単に特定できるからです。

Budha Bhattacharya: お気に入りの OpenTelemetry シグナル。 これは難しい質問です。 現時点ではトレースが勝利を収めるべきだと思います。 物事がどのように結びついているかを考えると。 また、プロファイリングにも非常に注目しています。 次にこの会話をする時には、プロファイリングが勝者になるかもしれません。 パフォーマンスは多くの組織にとって大きなテーマだからです。 特に API ゲートウェイとして、さまざまなコンポーネントと連携する中で、API プラットフォームスタックの一部としてボトルネックの可能性を知る必要があります。 私たちがボトルネックなのか？ 他に潜在的なボトルネックはあるのか？ どうやってパフォーマンスを改善するか？ 数字に基づいて投資するにはどうすればよいか？ プロファイリングはある程度それを約束してくれるものです。

Miguel Luna: Elastic でのバックグラウンドから、ログと言わざるを得ません。 もちろん、ログは深いコンテキストのインサイトをもたらしますが、結局のところすべてが必要です。 メトリクスは問題があることを知らせてくれます。 トレーシングは問題がどこにあるかを理解するのに役立ちます。 ログは問題が何であるかを理解するのに役立ちます。

Adriana Villela: 私のお気に入りのシグナルはトレースです。 トレースがきっかけでオブザーバビリティと OpenTelemetry に恋に落ちたからです。

David Gohberg: トレーシングから最も多くの価値を得たと言わざるを得ません。 しかし最近、トレースとメトリクスの相関を取り始めて、これがゴールデンフローだと感じています。

Endre Sara: 分散トレーシング全般の大ファンでした。 大規模なサービスが互いにどのようにやり取りしているかの理解を与えてくれます。 しかし、プロファイリングも好きになってきました。 人々がシステムの動作をさらに深く理解するための興味深いエキサイティングな機会を提供してくれると思います。 特に、さまざまなフロー、さまざまな条件下でシステムがどう動作するかを理解し、将来の負荷に対応するためにアーキテクチャやスケールを調整・改善できるという点で。

Braydon Kains: 今のお気に入りの OpenTelemetry シグナルはログです。 OpenTelemetry にどっぷり浸かって3つのシグナルすべてが何を意味するか理解していても、最初はログから始めました。 ログは簡単だからです。 とても理にかなっていて、オブザーバビリティのセカンドウェーブからの考え方、つまりすべてをトレースやワイドイベントにすべきだという意見は理解できます。 その価値は理解していますが、ログはなくならないと感じています。

Christos Markou: インフラストラクチャとシステムのバックグラウンドからすると、私はメトリクスがとても好きです。 これは実は今後数ヶ月の個人的な目標でもあります。 セマンティック規約におけるシステムメトリクスや Kubernetes メトリクスの安定化に貢献し、Collector がユーザーにより多くの信頼性を提供できるようにすることです。 セマンティクスが安定すれば、それが助けになるでしょう。

Reese Lee: お気に入りのシグナルですか。 トレースと言いたいです。 オブザーバビリティの世界に入った時に最初に学んだものだからです。 それが私の理解に一番しっくりきました。 トレースのウォーターフォールがとても好きなので、トレースにします。

ご参加ください！

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

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

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

最終更新 June 11, 2026: [ja] add translation of content/en/blog/2024/humans-of-otel-na-2024.md (0556f103)