KubeCon China 2025、オブザーバビリティの失敗例を解説するセッションを紹介

連載 [第7回] :

KubeCon＋CloudNativeCon China 2025レポート

2025年10月16日(木)

KubeCon China 2025、Cisco/Splunkのシニアディレクターがオブザーバビリティの失敗例を解説したセッションを紹介する。

KubeCon＋CloudNativeCon China 2025から、Splunkのエンジニアリングチームのシニアディレクターがオブザーバビリティにおける失敗例を解説したセッションを紹介する。セッションを担当したのはSteve Flanders氏だ。この稿ではセッションの内容に加えて、セッション後に行ったインタビューの内容も合わせて紹介する。タイトルは「Antipattern in O11y：Lessons Learned and How OTel Solves Them」、オブザーバビリティ（O11y）におけるやってはいけないパターンを紹介し、それをどうやってOpenTelemetry（OTel）が解決するのか？という内容だ。

プレゼンテーションを行うSteve Flanders氏

Flanders氏はOpenTelemetryのコントリビューターであり、過去にもThinkITに登場している。2019年に上海で行われたKubeCon China 2019では現地でインタビューを行い、その後、Flanders氏が登場する動画を解説した記事も公開されている。

●参考：KubeCon Chinaで訊いたOpenTelemetryのマージ裏話

●参考：ベンダーニュートラルな可視化ツールOpenTelemetryの最新情報を紹介

ThinkITには過去2回登場していることになるが、CNCFがカンファレンスに使っているSchedというアプリで筆者がセッションを登録したことを感知して、セッション前には挨拶に応えてくれた。セッションの動画は以下から参照可能だ。

●動画：Antipatterns in Observability: Lessons Learned and How OpenTelemetry Solves Them

12のアンチパターンを紹介するセッション

Flanders氏は「Mastering OpenTelemetry and Observability」という書籍の筆者でもあり、OpenTelemetryの前身であるOpenCensusのコントリビューターであったことからOpenTelemetryにも関わるようになった。SplunkがCiscoに買収された経緯から、今ではCiscoのオブザーバビリティプロダクトのエンジニアリングチームにおけるリーダーでもある。

過去の経歴を簡単に紹介

ここから12の例を挙げてオブザーバビリティにおいてやってはいけないパターン、つまり「アンチパターン」を紹介していく内容になった。

12の例を挙げてオブザーバビリティにおけるアンチパターンを解説

アンチパターンの一つとして紹介されたのが「不完全なインストゥルメンテーション」というものだ。ここでは稼働するすべてのコンポーネントをカバーできないことで、障害時の原因解明が難しくなってしまうことを説明。対策として、Javaのコマンドラインや環境変数の設定を説明している。

不完全なインストゥルメンテーションの例を説明

分散トレーシングについてはダイアグラムを使って説明。多くのコンポーネントが関連することでオブザーバビリティは難しくなる。

分散トレーシングの例をダイアグラム図を使って説明

実際にどの処理にどれだけ時間がかかっているのか？についても例を使って説明。ここではECサイトなどでは一般的な購入時のチェックアウトのプロセスを示して説明。この例ではカートのアイテムの取得、通貨の処理、送付先住所の取得などに続いて、確認用e-mailの送信などに細分化されていることがわかる。

チェックアウトのプロセスに多くの細かな段階が積み重なっていることを表示

次のスライドではコンポーネントの相関図を使って処理がどうやって接続されているのかを解説した。

ネットワーク図を使ってプロセスの接続状況を解説

アンチパターンの解説だけではなく、OpenTelemetryについても基本的な内容を説明。ここではOpenTelemetryが取得した情報を仲介するCollectorについて解説を行っている。

OpenTelemetry Collectorについて解説

実際に設定ファイルの記述例についても解説を行った。

設定ファイルの例を使って説明

また採取する情報についての命名ルールが確立していないというアンチパターンについても説明し、この例は特にログにおいては起こりがちであると語った。対策としてOpenTelemetryの機能であるSemantic Conventionsを使うことを推奨した。Semantic Conversionsについては以下の公式ドキュメントを参照されたい。

●参考：Semantic Conventions

オブザーバビリティで取得する情報の命名ルールが決まっていないアンチパターン

ここからはオブザーバビリティにおける設定などのアンチパターンではなく、プラットフォーム選択におけるアンチパターンを説明する内容に移った。

プラットフォーム選択におけるアンチパターン

最初に挙げたアンチパターンはベンダーロックインだ。ここではプロプライエタリーなベンダーのソリューションに依存することでベンダーの支配から脱却することが難しくなり、選択肢が狭められてしまうことを問題点として挙げた。

ベンダーロックインが最初に挙げたアンチパターン

またオブザーバビリティのためのツールが社内に乱立してしまう問題については、OpenTelemetryがほぼデファクトスタンダードになっていることから、ベンダーを替えてもOpenTelemetry Collectorに準拠した仕様になっているツールを選ぶことが重要だというのが要点だろう。

ツールが乱立してしまうアンチパターンを説明

また社内の組織がサイロ化して協調することが難しいというアンチパターンやオブザーバビリティについて誰がオーナーシップを持つべきか？というアンチパターンについても解説。この辺りになるとテクノロジーの話ではなく組織や責任の在り方まで考えておかないと、ビジネスにマイナスの影響を与えてしまうということが趣旨だろう。インターネットやソフトウェアがビジネスに与えるインパクトが重要になった現状を映し出していると言える。

サイロ化した組織もオーナーシップの欠如もオブザーバビリティのアンチパターン

全体として成功例を解説するのではなく、アンチパターンから改善する方法を解説するという発想のセッションとなっていた。あまり失敗を語りたがらない中国のエンジニアにはどう映ったのだろうか。Flanders氏は最後に最新の著書である「Mastering OpenTelemetry and Observability」を紹介してセッションを終えた。

OpenTelemetryのブースで質問に答えるSteve Flanders氏

セッション後のFlanders氏に訊いた

セッションの後にOpenTelemetryのブースでFlanders氏にインタビューを行った。ここではその中からいくつかの回答を紹介する。

簡単に経歴を紹介してください。

Flanders：最初に逢った時からすでに数年が経過していますので、いろいろなことがありましたね。ステルスだったOmnitionからSplunkによる買収、さらにCiscoがSplunkを買収したことで今はCiscoのオブザーバビリティのチームになっています。私はAPMであるAppDynamicsのプロダクトも含むエンジニアリングチームのディレクターをやっています。ここにはOpenTelemetryベースのデータを取得するためのソリューション、GDI（Getting Data In）というソリューションも含まれています。つまり、主にOpenTelemetryに関連した仕事をしていると言っても良いと思いますね。

多くのオブザーバビリティベンダーがそれぞれの強みを出して市場が乱立しているように見えます。これについては？

Flanders：多くのベンダーがこの領域に進出してきているのは、それだけ市場が求めているからだと思います。新興のプレイヤーであればある一点に集中して開発リソースを投下し、差別化できるニッチなポイントソリューションを提供しますが、多くのエンタープライズ企業が求めているのは信頼できるパートナーであり、プロダクトポートフォリオだと思いますね。そういう意味ではCiscoは良いポジションにいると思います。AIについても今や多くのオブザーバビリティベンダーが生成AIを使ったアシスタントを提供していますが、その多くが、エラーの内容を説明したり設定ファイルを書くアシスタントとして使ったりすることなどに留まっていると思います。

しかしエンタープライズ企業にとっては、すでに多くのツールを使ってシステムの運用をやっているわけで、AIだけが単独のツールとして存在するというのではなくJiraやWebExといったツールと連携する必要が出てきていると思います。すでに「SREをサポートするためのAI」という謳い文句のベンダーも出てきているようですから。