The Humans OpenTelemetry - KubeCon EU 2024

今回は Humans of OpenTelemetry の第2弾として、パリで開催された KubeCon EU からお届けします。 前回に引き続き、Reese Lee と私は OpenTelemetry のコントリビューターやエンドユーザーにインタビューし、OTel に関わるようになった経緯を聞きました。

• Iris Dyrmishi (Miro)
• Severin Neumann (Cisco)
• Kayla Reopelle (New Relic)
• Morgan McLean (Splunk)
• Henrik Rexed (Dynatrace)
• Vijay Samuel (eBay)
• Daniel Gomez Blanco (Skyscanner)
• Doug Odegaard (ServiceNow)
• Adnan Rahić (Tracetest)
• Rynn Mancuso (Honeycomb)

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

• Reese Lee：共同インタビュアー
• Henrik Rexed：音声・映像の録画機器の提供と、未編集映像の初期編集
• Zhu Jiekun：自身のカメラでの撮影協力

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

これまで OpenTelemetry に貢献してくださったすべての方々に感謝するとともに、2024年以降も引き続きご貢献いただけることを楽しみにしています！🎉

トランスクリプト

読む方がお好みなら、以下のインタビューのトランスクリプトをご覧ください。

1- OTel の人々に会おう

IRIS DYRMISHI: 私は Iris Dyrmishi です。 Miro のシニアオブザーバビリティエンジニアをしていて、私の仕事はオブザーバビリティがすべてです。 Miro のエンジニアリングチームがアプリケーションを監視・観測し、最大限に活用できるツールを提供するオブザーバビリティプラットフォームを構築しています。

SEVERIN NEUMANN: 私は Severin Neumann です。 Cisco のオープンソースプログラムオフィスで働いていて、OpenTelemetry のガバナンス委員会のメンバーであり、OpenTelemetry ドキュメントの共同メンテナーの一人です。

KAYLA REOPELLE: 私は Kayla Reopelle です。 New Relic で働いていて、OpenTelemetry の Ruby プロジェクトに貢献しています。

MORGAN MCLEAN: 私は Morgan McLean です。 Splunk のプロダクトマネジメントのディレクターをしています。 OpenTelemetry には初日から関わっています。 プロジェクトの共同創設者の一人で、ガバナンス委員会にも参加しています。 OTel で何をしているかって？少しずつ全部やっていますね。 初期は文字通りすべてをやっていました。 私と Ted やその他のメンバーが、たくさんの仕事をこなしていました。 最近ではトレース、メトリクス 1.0 のリリースに関わりました。 昨年はログ 1.0 も。 今はプロファイリングと、OpenTelemetry のメインフレームコンピューティングへの拡張に取り組んでいます。

HENRIK REXED: 私は Henrik Rexed です。 Dynatrace のクラウドネイティブアドボケイトをしていて、オブザーバビリティとパフォーマンスに情熱を持っています。 コミュニティの皆さんが様々なソリューションを使い始められるよう、コンテンツを提供して支援しています。

VIJAY SAMUEL: 私は Vijay Samuel です。 eBay のオブザーバビリティプラットフォームのアーキテクチャを担当しています。

DANIEL GOMEZ BLANCO: 私は Daniel Gomez Blanco です。 Skyscanner のプリンシパルエンジニアであり、OpenTelemetry のガバナンス委員会のメンバーでもあります。

DOUG ODEGAARD: 私は Doug Odegaard です。 ServiceNow Cloud Observability（旧 Lightstep）のシニアソリューションアーキテクトです。 それ以前は数年間、OpenTelemetry のユーザーとして利用していました。

ADNAN RAHIĆ: やあ、Adnan です。 Tracetest でデベロッパーアドボケイトをしています。 何をしているかは…皆さんの方が私より上手く説明できるかもしれません。 基本的に OpenTelemetry に関するあらゆることをやっています。 ドキュメント、ブログ、デモのコントリビューターの一人です。

RYNN MANCUSO: 私は Rynn Mancuso です。 Honeycomb.io で働いていて、End User SIG のメンテナーの一人です。

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

IRIS DYRMISHI: オブザーバビリティが私にとって何を意味するか？ オブザーバビリティは私の人生における最大の情熱であり、プロフェッショナルとしてのキャリアでもあります。 キャリアを始めた頃はあまり興味を持たない分野の一つです。 何も知らないし、学校で教わることもなく、テックコミュニティでもあまり語られません。 でも発見した時に「すごい！」となるんです。 私たちは実際に変化を起こしていて、チームが製品を最大限に活用できるよう支援しているんです。

SEVERIN NEUMANN: オブザーバビリティは大きなゲームチェンジャーだと思います。 特にAPMにおいて、ここ数年私たちがやってきたことの進化形です。 私は AppDynamics で長く働いていて、APM エージェントをお客様に販売し、今日オブザーバビリティが約束していることの多くを提供していました。 しかしオブザーバビリティで見られる大きな変化は、それがすべての人に届くようになっているということです。 私たちがそこで行っていたことを、すべての人が利用できるようにしているのです。 さらに、「アプリケーションにコンパイル後のエージェントを追加しましょう」というアプローチから、「ネイティブなオブザーバビリティを実現しましょう」という方向に移行しています。 開発者や運用チームが組織全体で使うものにしようとしているんです。

KAYLA REOPELLE: 私にとってオブザーバビリティとは、安心感を得られるものです。 何が起きたか、何が問題だったかを確認するために頼れるものがあるということです。 オブザーバビリティはまた、お客様やユーザーとの技術的なつながりをより深く感じる方法でもあります。 自分がソフトウェアとどう対話するかだけでなく、ユーザーがどのように対話しているかを見ることができるからです。

MORGAN MCLEAN: 私にとってオブザーバビリティは、コンピューティング業界だけに留まるものではありません。 何かの中を覗き込み、それがどう動いているか、今何をしているかを理解する能力であり、壊れた場合にはより速く修復できるようにするものです。 この業界でテレメトリーについて考えるとき、オブザーバビリティが伝統的に意味してきたのは、バックエンドのインフラストラクチャやアプリケーションへの可視性です。 エキサイティングなことに、今まさに拡大していると思います。 OpenTelemetry を通じて、クライアントアプリケーションやメインフレームにも進出しています。 つまり、ビジネスに影響を与えるあらゆる技術システムへの可視性、それがオブザーバビリティです。

HENRIK REXED: オブザーバビリティと言えば、通常は「モニタリングの古い名前の置き換え」だと言われます。 しかし私にとってはモニタリング以上のものです。 モニタリングは何かを見るだけですが、オブザーバビリティは状況を理解するのに十分な情報を持つことです。 メトリクスだけを見ていると、何かが起きているという推測はできますが、理解はできません。 ログ、イベント、例外、トレース、プロファイリングといった追加の情報を得て、それらすべての次元（ディメンション）を組み合わせることで、「わかった、これが問題で、解決できる」と言えるようになるのです。

VIJAY SAMUEL: オブザーバビリティが私にとって何を意味するか？ 私は eBay のサイトエンジニアリング組織に所属していて、サイトで起きていることすべてを観測し、高い可用性を確保することが私たちの目標です。 つまり基本的に、オブザーバビリティとはサイトが正常に動いているかどうかを知ることです。 それが私がここにいる理由ですから。

DANIEL GOMEZ BLANCO: オブザーバビリティが私にとって何を意味するか？ それはシステム内で何が起きているかを理解する手段です。 かなり複雑なシステムを運用しているので、エンドユーザーに良い体験を提供するために、システムの内部で何が起きているかを理解する必要があるのです。

DOUG ODEGAARD: オブザーバビリティとは、私にとって…私は長年フルスタック開発者をやってきました。 実は、インシデント対応チームでインシデントの追跡をしていたのですが、何が問題なのかを突き止めようともしていました。 そこで、これがいかに必要か、いかに多くの異なる画面を見なければならないかが分かったんです。

ADNAN RAHIĆ: オブザーバビリティとは、私にとって…私は長年フルスタック開発者をやってきました。 実は、インシデント対応チームでインシデントの追跡をしていたのですが、何が問題なのかを突き止めようともしていました。 そこで、これがいかに必要か、いかに多くの異なる画面を見なければならないかが分かったんです。 オブザーバビリティとは、私にとってシステムで何が起きているかを実際に見る方法です。 一晩中起きて何が問題だったか考え続けなくて済むようになる究極の手段です。 OpenTelemetry とここ数年のトレーシングの台頭によって、私たちが今持っている可能性は史上最高になりました。 このプロジェクトの一員であることを本当に嬉しく思っています。 今のペースで成長していることも嬉しいですし、これからの数年間でどう進化していくか楽しみです。

RYNN MANCUSO: 私にとってオブザーバビリティとは、システムに対してより深い質問ができるようになることです。 単に以前見たことのある緊急事態にアラートを出すだけでなく、未知の領域に踏み出して複雑なシステムがどのように動作しているかを実際に理解できるようになることです。

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

IRIS DYRMISHI: OpenTelemetry は、オブザーバビリティを再び素晴らしいものにしているツールです。 OpenTelemetry が普及するにつれてオブザーバビリティが盛り上がりを見せていて、テレメトリーシグナルの一元化やセマンティック規約を可能にし、オブザーバビリティチームとエンジニアリングチームがオブザーバビリティにもっと注目し、構築し、改善していくことを全般的に支援しています。

SEVERIN NEUMANN: OpenTelemetry が私にとって何を意味するか？ オブザーバビリティの推進力だと思います。 それを実現するものです。 数年前に OpenTelemetry コミュニティに参加したのは、オブザーバビリティをすべての人に届けるというアイデアに興味を持ったからです。 そして、私たちは本当に良い仕事をしていると思います。 今の私にとってもう一つ意味があるのは、素晴らしいコミュニティだということです。 ここ KubeCon で、チャットでしか知らなかった多くの人に直接会えます。 OpenTelemetry についてたくさん話しますが、OpenTelemetry 以外のこともたくさん話します。 もちろんオブザーバビリティについて、これからの数年間で何が起こると思うかなど。 それが私にとっての OpenTelemetry です。

KAYLA REOPELLE: OpenTelemetry は、計装に関してすでに存在していた最良のものを集め、一つのグループにまとめて皆が恩恵を受けられるようにするコミュニティの取り組みだと思います。 異なるエージェントエンジニアとして多くのことを学んできましたが、製品自体のユーザーからも学べることがたくさんあります。 OpenTelemetry は、オブザーバビリティの専門家と言語の専門家の両方を結び付けて、すべての人にとって素晴らしく意義のあるものを作り上げる、素晴らしい仕事をしています。

MORGAN MCLEAN: OpenTelemetry は私の子どものようなものです。 このプロジェクトの創設に多大な労力を注ぎました。 私にとって何を意味するか？ つまらない答えを言えば、インフラストラクチャ、サービス、クライアントからメトリクス、トレース、ログ、プロファイル、その他すべてのシグナルを抽出し、バックエンドで観測・処理可能にするものです。 しかし、このコミュニティに長く関わってきた多くの人にとって、そして Henrik やあなたのようにコミュニティに積極的に参加している人にとって、OTel は参加するのがとても楽しいオープンソースコミュニティでもあります。 取り組むのが楽しいものです。 抽象的で感傷的に聞こえるかもしれませんが、OTel は私にとって多くの意味を持っています。 すべてとてもポジティブなものです。

HENRIK REXED: OpenTelemetry は私にとって未来を意味します。 オープンスタンダードを持つことで、市場のすべてのソリューションに共通の標準、共通のフォーマットを持つという贅沢が得られます。 業界全体、すべてのベンダー、すべてのソリューションに共通のフォーマットがあることで、ユースケースが広がるのです。 テストはかつてユーザーからのフィードバックに頼っていたと思います。 しかしオブザーバビリティデータがあれば、テストの効率は格段に上がり、マーケティングツールやビジネスアナリティクスツールの代替としてもはるかに効率的になれます。 未来だと思います。 多くの人が話題にする AI、機械学習についても同じことが言えます。 Tesla のようなものです。 Tesla を運転するとき、車はセンサーが計測したデータに基づいて判断を下します。 そのセンサーと計測がなければ、いくら賢いシステムがあってもデータなしでは正しい判断ができません。 モダンアプリケーションの将来の実装を可能にするものでもあると思います。

VIJAY SAMUEL: OpenTelemetry は将来のオブザーバビリティの標準です。 過去数年間のオブザーバビリティの旅を通じて、Prometheus などのオープンスタンダードを探し続けてきたので、これは非常に重要です。 少なくとも取り込みと収集については、誰もが採用できる単一の標準になりました。 長期的に見て、これは非常に強力だと思います。

DANIEL GOMEZ BLANCO: OpenTelemetry が私にとって何を意味するか？ 人々をまとめることだと思います。 テレメトリーについての一つの共通言語と一つの考え方のもとに、皆を結び付けるものです。 人間の言語ですらお互いを理解するのは十分に難しいと思います。 OpenTelemetry はテクノロジーをまとめ、テレメトリーについての一つの考え方、システムの観測についての一つの考え方を提供しているのです。

DOUG ODEGAARD: 私にとって OpenTelemetry は、プロダクトチームやインフラチームの仕事を楽にし、カスタマーエクスペリエンスを改善し、全体的に私たちの仕事をより良い体験にしてくれるものです。

ADNAN RAHIĆ: OpenTelemetry は、オブザーバビリティの未来だと言いたいです。 多くの企業やベンダーが OpenTelemetry ファーストのマインドセットに移行しているのを見てきました。 OpenTelemetry を使って、一つのライブラリセット、一つのツールですべてのテレメトリーシグナルを生成・収集できるのです。 こうあるべき姿そのものです。 一つのツール、一つのベンダー、一つのクラウドプロバイダーにロックインされることはもうありません。 基本的に何でもやりたいことができ、メトリクス、ログ、トレースを好きなように使えます。 それを見られて本当に嬉しいです。

RYNN MANCUSO: OpenTelemetry は、オブザーバビリティについてより詳細な質問をするための計装プロトコルです。 多種多様なシステムから複数のシグナルを収集するからです。 Kubernetes のコントロールプレーンから物理的なオンプレミスシステムまで、あらゆるものを監視している方がいます。 非常に柔軟な言語であり、パンデミックの最中に集まって本当に特別なものを作り上げた、美しいコミュニティです。

4- OpenTelemetry に関わるようになった経緯

IRIS DYRMISHI: ペースの速いオブザーバビリティチームで働いていて、多くのツールをメンテナンスしていましたが、規約もなく、一元化もされておらず、バックエンドについて柔軟性もなく、全般的にベンダー非依存ではありませんでした。 そこで OpenTelemetry という素晴らしいツールを発見しました。 試してみようということになり、私たちにとって素晴らしく機能しました。 そして今日、1年以上経った今、2つ目のプロジェクトで OpenTelemetry への移行を推進しています。

SEVERIN NEUMANN: OpenTelemetry にどう関わるようになったか？ 先ほど言いましたが…数年前に興味を持ったんです。 AppDynamics でいわゆるドメインアーキテクトとして働いていて、Node.js、Python などの言語の専門家でした。 「OpenTelemetry というものがあるけど、製品に統合すべきでは？」という会話が常にありました。 もっと学びたいと思いました。 オープンソース技術について新しいことを学ぶ良い方法は何か？そう、参加することです。 しばらく JavaScript に関わっていましたが、ある時、OpenTelemetry を本当に理解するにはドキュメントに取り組むのが良い方法だと気づきました。 こうしてドキュメントのメンテナーになったんです。

KAYLA REOPELLE: 昨年の春、New Relic から OpenTelemetry Ruby プロジェクトの現状を調査するよう依頼されたのがきっかけです。 New Relic の Ruby エージェントチームのエンジニアとしても働いていて、それがプロジェクトへの貢献を始めるきっかけになりました。 Ruby の多くのシグナルがまだ安定版ではないことに気づいたので、これまでの私の作業の多くは Ruby のログとメトリクスを安定版にすることに注力してきました。

MORGAN MCLEAN: Google で、トレーシング、プロファイリング、デバッグなどのオブザーバビリティ製品に携わっていました。 トレーシングでの課題の一つは、ユーザーのアプリケーションからデータを取得することでした。 これは本当に難しいんです。 何十万ものソフトウェアとのインテグレーションが必要です。 一つのチームや一つの企業がそれをメンテナンスするのは不可能です。 そこでオープンソースで何かしたいと考えました。 他のオープンソース標準もありました。 ほぼ同時期に始まった OpenTracing というものがありました。 私たちは OpenCensus を始めました。

ある時点で、特にソーシャルメディアに精通したメンバーの間で（私はその一人ではありませんが）、データベースや言語ランタイムのメンテナーがどちらのプロジェクトに統合作業を費やすべきかについて、両プロジェクト間で対立がありました。 それが両プロジェクトの成功を妨げていました。 私は OpenCensus をリードし、Ted や Dan たちは OpenTracing をリードしていました。 2018年末から2019年初頭にかけて、ついに決着をつけ、統合して今の OpenTelemetry にすることを決めたのです。 それ以来ずっと関わっていて、今は Splunk で働いています。 会社は違いますが、同じようなことに取り組んでいます。 こうして関わりが始まり、どんどん成長し、雪だるま式に広がっていったのです。

HENRIK REXED: オブザーバビリティの冒険を始めた時、もちろん Dynatrace に入社しました。 Dynatrace には独自のベンダーエージェント OneAgent があります。 OpenTelemetry のムーブメントを見て、パフォーマンスのバックグラウンドから来た私は「オープンスタンダードだ、とてもエキサイティングだ」と思いました。 あるお客様向けにログの収集・処理と機械学習の適用を実装した経験があり、その時「一つの共通標準があれば素晴らしいのに」と思ったんです。 カスタム実装のかわりに、すべての人のための何かがあれば。 プロジェクトの定義とその背景にあるものを見て、とてもワクワクしました。 「参加したい！」と思い、コミュニティが始められるようコンテンツを作り始めたのです。

以前は開発者でしたが、間違いなく良い開発者ではありません。 だからこそ、他の方法であらゆる方向からプロジェクトを支援しようとしています。 私の目標はオープンスタンダードの採用を増やし、あらゆる場所で採用されるようにすること。 そうすれば、さらにエキサイティングな実装を進められるのです。

VIJAY SAMUEL: 数年前に2つの理由で始めました。 一つは、社内にトレーシングを導入しようとしていたこと。 当時、OpenTracing と OpenCensus が OpenTelemetry に統合されつつありました。 そのために OpenTelemetry の評価を始めました。 トレーシングのために OpenTelemetry に移行したので、メトリクスの収集も OpenTelemetry に移行する旅を経験しました。 こうして関わるようになったんです。

DANIEL GOMEZ BLANCO: OpenTelemetry にどう関わるようになったか？ Skyscanner での仕事を通じて、エンドユーザーとして関わるようになりました。 テレメトリーのオープンスタンダードの採用を推進していました。 COVID の間、インフラストラクチャへのアプローチ、テレメトリーデータの収集・処理・エクスポート方法の簡素化が求められました。 オープンスタンダードの採用と簡素化の取り組みをリードするために、オブザーバビリティリードとして OpenTelemetry のコミュニティにより深く関わるようになりました。 同じ問題を解決し、誰にとっても機能する解決策を見つけたいと考えるエンドユーザーたちと交流することにしました。

DOUG ODEGAARD: OpenTelemetry について言えば、実は以前の職場で数年間、オブザーバビリティソフトウェアを開発するために雇われていました。 独自のものを書いていて、アラート管理など多くのことに取り組んでいました。 とても大変な作業で、もっと簡単にできるはずだと思いました。 さらに、将来にわたって使えるもの（あえてそう言いますが）で、拡張可能であることも確認したかったんです。

OpenTelemetry を発見した時、「ありがたい」と思いました。 会社が継続して使えるものであり、データの保存についても心配しなくて済みました。 本当に優れたプラットフォームを提供してくれたので、仕事のやり方ではなく、目の前のタスクに集中できるようになりました。 プロジェクトに関わったのは、まず顧客としてでした。 約3年から4年前、OpenTelemetry の草創期のことです。 オンラインでドキュメントを読んだり、コードを見たりしていましたが、もっと学びたかったんです。 SIG のミーティングに参加すると、Google や Microsoft などの企業の人がいて、それに加えてアメリカの小さなフィンテック企業の私がいました。 最初は少し気まずかったのですが、彼らはエンドユーザーである私が参加してくれたことをとても喜んでくれました。 単なる消費者ではなく、貢献できるのだと気づけた素晴らしい体験でした。 その後、ベンダー企業にキャリアを転向し、今ではかつての自分のようなお客様向けにこれらのシステムを導入しています。 恩返しのようなものですね。

ADNAN RAHIĆ: OpenTelemetry プロジェクトにどう関わるようになったか？ 皆さんと一緒にブログへの投稿を増やし、ドキュメントにも少し貢献し始めました。 チーム全体で、毎日数分を OpenTelemetry プロジェクトのチェックと貢献の方法を探すことに充てるという、心からの取り組みを続けています。

RYNN MANCUSO: OpenTelemetry プロジェクトに関わるようになったのは…正直に言うと、あるオブザーバビリティ企業のマーケティング部門で働いていて、その会社は OpenTelemetry に関わる意味がないと考えていました。 関わらせてもらえなかったんです。 でも私はオープンソースを本当に信じていました。 Mozilla や Wikimedia で働いた経験から、戦略的な観点からこれが正しい道だと確信していました。 関わらせてくれる会社に移れるチャンスが来た瞬間、そうしました。 今は Honeycomb にいます。 入社して3ヶ月以内にプロジェクトメンバーになり、End User Working Group で活動を始め、それを SIG に成長させ、他のメンバーと一緒に今日のプログラムを作り上げてきました。

5- お気に入りのテレメトリーシグナルは？

IRIS DYRMISHI: トレーシングがお気に入りのシグナルです。

SEVERIN NEUMANN: 今のお気に入りのシグナルはプロファイリングです。 オブザーバビリティに欠けていた大きなギャップを埋めるものだと思うからです。 先ほど言ったように、私は APM の世界から来ています。 APM、オブザーバビリティ、その違いを明確にするのは難しいです。 しかし、APM 製品を使っている人と話すと、「OpenTelemetry でのコードレベルの可視性はどこにあるの？」と言われます。 商用エージェントは問題の原因となるコード行を教えてくれます。 プロファイリングはまさにそれを提供するものです。 だからとてもワクワクしています。

KAYLA REOPELLE: お気に入りのシグナルを決めるのは難しいです。 トレースの力が大好きです。 トレースは非常に意味のある方法でストーリーを語ることができると思います。 一方で、ログにずっと没頭していて、ログがスパンやトレースとのつながりをより持てるようにしようとしてきたので、ログにも思い入れがあります。

MORGAN MCLEAN: 分散トレースに思い入れがあります。 このプロジェクトが始まったのがそこだからです。 初期の頃、多くの価値がそこにあったと思います。 標準化された分散トレース収集を本格的にやっていた人は他にいませんでした。 Zipkin や Jaeger に関連したオープンソースの例はいくつかありましたが、OpenTelemetry がこれほど早く勢いを得た理由は、まさにそれを提供していたからだと思います。

ログにも思い入れがあります。 昨年リリースしたものです。 OTel の多くの部分に関わってきましたが、ログは初期の段階でコア仕様の多くを推進した分野の一つです。 それがリリースされるのを見るのは本当にエキサイティングでした。 また、ログはキャリアを通じて以前から不満を感じていたものです。 標準化されていない、処理が遅い、コストが高い。 OTel がログを使うすべての人にとって、多くの良い変化をもたらすでしょう。

最後にプロファイルです。 今取り組んでいるものだからです。 何年も前に Google にいた時、世界初の分散型継続的プロファイリング製品（少なくとも一般公開されたもの）をリリースしました。 Google Cloud Profiling、Stackdriver Profiling です。 まだサポートされていて、無料だったと思います。 非常に強力です。 しかし、プロファイリングは常にニッチなものでした。 Splunk や他の企業でもサポートしていますが、メトリクス、トレース、ログほど知られていません。 OTel で、今年後半にプロファイルの完全サポートをリリースする予定ですが、状況は大きく変わると思います。 Google 時代のお客様で、プロファイラーを1時間使って、非常に最適化されていないコードを素早く見つけ、計算リソースの20〜30%を節約した方もいました。 より多くの人がその能力を持ち、高速化でき、開発者が実際にものがどう動くかを理解できるようになる。 それはとてもエキサイティングです。 技術は長い間存在していて、OTel がそれをメインストリームに持ち込むのは画期的なことです。

HENRIK REXED: 「お気に入りの子どもは誰？」と聞かれると、いつも「お気に入りの子どもなんていない」と答えます。 みんな素晴らしいんです。 トレースは好きです。 どこで遅くなったかを理解するのに役立つから。 メトリクスも好きです。 パフォーマンスエンジニアとしてメトリクスをたくさん使っていたから。 ログも好きです。 ログにはサンプリングがないので、ログの分析をすれば非常に正確だからです。

だからお気に入りのシグナルはないと思います。 必要なものに応じて選ぶだけで、明らかに一つのシグナルが他より役に立つことがあります。 Valencia 以来とても楽しみにしているのが継続的プロファイリングです。 プロファイリングが大好きで、トレースは素晴らしいですが、どこかに問題がある場合、プロファイリングの方がはるかに役立つでしょう。 質問に答えていないかもしれませんが、OpenTelemetry が提供するすべてのシグナルが好きです。

VIJAY SAMUEL: 私はメトリクスに完全に偏っています。 メトリクスが最も強力なシグナルだと思います。 計装をしっかり考え、適切な粒度とカーディナリティをプラットフォームに送り込めば、異常検知、機械学習など、非常に強力なことができます。 メトリクスが大好きです。

DANIEL GOMEZ BLANCO: トレースと言わざるを得ません。 コンテキストを提供してくれるからです。 トレースは他のすべてのシグナルのバックボーンとなる相関を提供します。 しかし、現在のメトリクスの API 設計は非常に強力で、計装と計測を集約（アグリゲーション）から切り離す方法がとても強力なので、メトリクスにまた惹かれています。 システムを記述する豊かさを与えてくれるので、メトリクスに再び惹かれています。

DOUG ODEGAARD: お気に入りのシグナルは、やはりトレースです。 長年ソフトウェア開発をしてきたので、最初に惹かれたのはそれを見る能力でした。 特にデバッグがどういうものか知っているからです。 インシデント時に素早く焦点を合わせる必要があることも知っています。 はい、トレースがお気に入りですが、トレース ID とスパン ID をログに送るのも好きになってきました。 次のお気に入りになりつつあります。

ADNAN RAHIĆ: お気に入りのシグナルはトレースです。 間違いなくトレースです。 お気に入りの歌手は Ed Sheeran です。

RYNN MANCUSO: お気に入りのシグナルは何か？ Honeycomb で働いているので、トレースがお気に入りだと言う義務があります。

参加しませんか！

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

• CNCF Community Slack の #otel-sig-end-user チャンネルに参加する
• OTel in Practice セッションに参加する
• OpenTelemetry ブログでストーリーを共有する
• その他ご希望のセッションがあれば、CNCF Community Slack でお問い合わせください！

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

また、YouTube チャンネルも購読して、OpenTelemetry の素晴らしいコンテンツをお見逃しなく！

• ←前へ
• 次へ→