Honeycomb、未知の本番障害を高カーディナリティで探索するobservability

Honeycombの現在地は、障害が起きた後に用意されたdashboardを眺めるだけでは足りない、という問題意識から始まった。

分散システムが複雑になるほど、未知の切り口で本番データを掘る必要がある。出典

創業のきっかけ

共同創業者のChristine YenとCharity Majorsは、software engineeringとproduction運用の現場からobservabilityを考えてきた。

Honeycombは開発者が自分で問いを立て、システムの挙動を調べる道具として設計された。出典

転機・苦労

従来の監視は、想定した指標を先に決めることが前提だった。

高カーディナリティの属性を扱うHoneycombは、データを集めるだけでなく、調査のためのquery体験を成立させる必要があった。出典

observability is about understanding the internal state of a system by examining its outputs

この考え方は、単なるalertingとの違いを明確にする一方、データ量と利用方法を学ぶ負荷も生む。

pricingとdocsを含めて導入の文脈を説明することが重要になる。出典

成長・成功

OpenTelemetryとの接続は、vendor-neutralな計装を求める開発チームにとって入口になった。

Honeycomb固有の分析体験を保ちながら、標準化されたtelemetryを受け入れられる。出典

結び

Honeycombの示唆は、observabilityを「異常を知らせる画面」から「未知の問題を調べるための作業環境」へ広げたことにある。

Honeycombは、既知のメトリクスを監視するだけでなく、未知の障害を本番データから探索したい開発チームに刺さる。

高カーディナリティの属性を保ったままイベントを検索できる設計は、複雑な分散システムのdebuggingと相性がよい。出典

OpenTelemetry対応によって計装の入口を中立化し、既存のstackを捨てずに探索性を上げられる点が採用理由になる。出典

蓄積されたquery設計、instrumentationの知見、OpenTelemetryを含む開発者向け教育が複合したmoatになる。

単なる保存先ではなく、問いの立て方まで製品に組み込む。出典

ネットワーク効果は中程度。

利用者が増えるほど直接的にデータが共有される製品ではないが、OpenTelemetryやコミュニティの標準化が採用判断を補強する。出典

分散システムを運用するsoftware engineers、SRE、platform teamが中心。

単純なアクセス解析や固定dashboardだけを求めるチームには過剰になり得る。出典

第一に、observabilityをdashboardの閲覧ではなくdebuggingの探索として位置付けたこと。出典

第二に、OpenTelemetryとdeveloper educationを組み合わせ、技術選定の不安を下げたこと。出典

高カーディナリティのイベントを扱うほど、データ量と料金の理解が導入障壁になる。

既存の監視製品をすべて置き換えるのではなく、どの調査経路に使うかを設計しないと価値が伝わりにくい。出典

developer向けcontent、docs、OpenTelemetryとの接続を入口にし、productionでのdebugging成功体験から組織へ拡張する戦略が見える。出典

セルフサーブの理解とenterpriseの支援を分けることで、技術者起点と営業起点を両立しやすい。出典

主要チャネル: content, developer-community, events, sales

複雑な問題に対して、最初から答えを表示するのではなく探索できる道具を提供する発想が重要だ。

標準規格への対応と独自のworkflowを両立すると、導入の摩擦を抑えながら差別化できる。出典

日本企業では運用担当者が固定dashboardを守るだけになりやすい。

Honeycomb型の探索を導入するなら、OpenTelemetryで計装を共通化し、障害対応の問いと権限設計を先に決める必要がある。

これは製品導入より運用文化の変化が先行する領域だ。