私たちが知っているように、それは観察可能性の終わりです（そして私は元気です）

非常に広い意味で、過去数十年にわたる観察可能性ツールの歴史は、非常に単純な概念についてでした。 New RelicはRails Revolutionのためにこれを行い、DatadogはAWSの台頭のためにそれをしました、そしてHoneycombが先導しました Opentelemetry。

ループはそれぞれの場合に同じです。ソフトウェア開発と展開のための新しい抽象化と手法は牽引力を獲得します。これらの抽象化により、複雑さを隠すことでソフトウェアがよりアクセスしやすくなり、その複雑さには何が起こっているかを監視および測定する新しい方法が必要です。ダッシュボード、アダプティブアラート、動的サンプリングなどのツールを構築します。これらはすべて、私たちが膨大な量を圧縮するのに役立ちます もの 私たちの人間の知性に理解できる何かに起こります。

AIでは、このパラダイムの死が見えます。それはすでに現実的であり、すでにここにあり、将来のシステム設計と操作へのアプローチ方法を根本的に変えるつもりです。

LLMSは普遍的な関数近似ですが、それらは本当に便利であることがわかります

私はあなたに話をするつもりです。それはこの写真についてです：

ハニカムデモを見たことがあるなら、おそらくこの画像を見たでしょう。私たちはそれを愛しています。なぜなら、それは現実世界の問題を示す素晴らしい方法であるだけでなく、調査ループを可能にするという私たちの核となる強みにうまく機能するものだからです。ヒートマップに表示される小さなピークは、の遅いリクエストを表しています フロントエンド 突然リセットする前に時間とともに上昇するサービス。彼らはパフォーマンスの低下を経験しているユーザーのごく一部を表しており、私たちは皆、これが現実の世界で何を意味するのかを知っています。

ハニカムデモでは、UIを使用してそれらのスパイクが実際に何を意味するかを理解するのがどれほど簡単かを示します。あなたは彼らの周りに箱を描き、私たちは走ります バブルアップ この視覚化を支持しているトレースデータを分析し、スパイクとベースラインの間で何が違いますかを示します。最終的には、特定のサービスにドリルダウンしたり、問題を引き起こしているメソッドコールもできます。それは素晴らしいデモであり、実際に私たちのプラットフォームの力を示しています。

先週の金曜日、私は毎週の内部デモの日にデモを見せました。それは私があなたに見せたものから始まり、それから私は次のように読むAIエージェントを介して単一のプロンプトを実行しました：

4時間ごとに発生するフロントエンドサービスの奇妙なレイテンシースパイクを調査し、なぜそれらが起こっているのか教えてください。

ここのスクリーンショットは、LLMからの残りの応答を排除します（この投稿の最後にテキスト全体を見つけてください）が、呼び出したいことがいくつかあります。第一に、これはあまりにも特別なものではありませんでした。エージェントは私が数日で自分自身を書いたものでした。これは、ループ内のLLM呼び出しツールです。モデル自体は既製です クロードソネット4。 Honeycombとの統合は私たちの新しいものです モデルコンテキストプロトコル（MCP） サーバ。 80秒かかり、8回のツールコールを作成しましたが、なぜそれらのスパイクが起こったのかを教えてくれただけでなく、Bubbleupでそれをするように言う方法とかなり似た方法でそれを理解しました。

これは不自然な例ではありません。私は基本的に、エージェントにデモで尋ねるのと同じ質問を尋ねましたが、エージェントは追加のプロンプト、トレーニング、またはガイダンスなしでそれを理解しました。実際のシナリオを効果的にゼロショットします。

そして、それはそれをしました 60セント。

私がこれを行うことができれば、あなたもそうすることができます。誰でもできます。

私は明確になりたい、これはおそらくだった 少しでも このワークフローの最適化バージョン。推論コストは削減されているだけであり、MCPサーバーをより効率的にすることができます。入力トークンの量をさらに減らす方法があります。 LLMが最適化されたクエリの結果を返す、よりカスタマイズされた集約と関数呼び出しで遊ぶことができます。エキサイティングな新しい時代です！

また、業界全体へのウェイクアップコールとしても機能するはずです。これは、観察可能性ツールを概念化する方法の地震の変化です。 あなたの製品の価値提案が素晴らしいグラフと簡単な計装であるなら、あなたは ルック。 LLMは分析ピースをコモディティ化し、Opentelemetryが計装作品をコモディティ化します。 堀は空になっています。

私はここに座って、これがの考えを破壊すると言うつもりはありません プロセスに関与している人間、 けれど。それは本当ではないと思います。クラウドの台頭は、その考えを破壊しませんでした。レールの存在は、サーバープログラマーを必要としないという意味ではありません。生産性が向上します マップを展開します。あらゆる形状とサイズのソフトウェアが増えます。必要になります もっと すべての。

問題は、これが私たちに何を必要とするのかということです。コードが安く、リファクタルが安く、分析が一定の要因である世界の観測可能性はどこにありますか？

高速フィードバックは唯一のフィードバックです

私はそこにマーカーを置くつもりです：本当に重要な唯一のことは、開発と運用のあらゆる段階での高速でタイトなフィードバックループです。 AIはスピードで繁栄します。毎回あなたを追い越します。成功するには、AIの速度でも移動するツールが必要です。分析エンジンが遅いほど、結果が悪化します。 LLMSは、これまで以上に速く仮説を生成、テスト、および破棄します。彼らはそれを正しくする前に何十回も間違っているかもしれませんが、再び、 私たちはここで断片的なペニーについて話している。

私はこれを絶望する理由ではなく、祝うものと考えています。 AI-ASSISTEDの開発と運用が私たちを導くことができるものは物です 私たちはいつも行ってきました。 HoneycombのModus Operandi全体は、高速フィードバックループ、共同知識共有、およびすべてを実験として扱うことに基づいています。私たちは、今日ここにある未来のために、明日のための最高のツールになることができるプラットフォームで構築されています。

この業界が2、5、または10年でどのように見えるかの正確な輪郭は、私の見解から外れています。物事がどのように見えるかを信頼して伝えることができる人はいないと思います。私はまた、予測をするビジネスではありません。しかし、私が言えることは、私たちが全体にわたって開発と運用タスクのAI支援のスペクトルを見ると思うということです ソフトウェア開発ライフサイクル：

• AIエージェントは、コードを書いて展開するときに受動的に実行できます。これは、生産からの実際の観察に基づいてコード品質を向上させる修正を提案します。
• 緊急システムの動作は、AIによって検出および対処され、無人エージェントがユーザーへの影響を特定し、それらを調査し、レポートを編集し、変更を行う前に承認と調整のために人間のオペレーターに提示することができます。
• 出血組織は、ハニカムや友人などのツールを搭載した完全に無人のSWE/SREロールを採用し、ビジネスのニーズと目標を満たすためのソフトウェアを最適化および書き込むことができます。

これらのすべての場合、最も重要なのはそうです スピード。従来の監視および観察可能性ツールには、この世界で競争するために必要なものはありません。きれいなダッシュボード、事前に構築されたアラート、魔法の統合は、今日の将来には十分ではありません。サブ秒のクエリパフォーマンス、統一されたデータストレージ、および人間とAIの間の共同ワークフローは、観察可能性の将来の成功の鍵です。

クールなことをしましょう。

補遺： 以前の調査スクリーンショットからの完全な出力は次のとおりです。

完璧！今、私は何が起こっているのか明確な絵を持っています。私の調査に基づいて、フロントエンドサービスで見ているレイテンシスパイクを説明できます。

---

🔍調査結果：フロントエンドのレイテンシースパイク

---

特定された根本原因：チェックアウトサービスのパフォーマンスの問題

4時間ごとに経験しているレイテンシスパイクはあります 実際には周期的ではありません– これはaのように見えます 負荷テストまたは合成交通パターン スケジュールされたシステムの問題ではなく。これが私が見つけたものです：

---

📊重要な調査結果：

1. プライマリ犯人：チェックアウト操作
   
   • /カート/チェックアウトエンドポイント： P95 = 3.7秒 （vs通常〜500ms）
   • CheckoutService/placeOrder： P95 = 4.2秒
     
   • 観察された最大遅延：7.6秒
     
2. スパイクパターン分析：
   
   • スパイクは集中しています チェックアウト操作のみ
     
   • 他のエンドポイントは比較的安定したままです
   • 485スローチェックアウト操作 過去24時間で
   • パターンが示唆しています ロードテストまたはバッチチェックアウト処理
     
3. ダウンストリームサービスインパクト：
   
   • CheckoutService/placeOrder： P95 = 4.6秒
     
   • GetDiscounts操作： P95 = 4.2秒
     
   • Shippingservice/Shiporder： P95 = 4.0秒
     

---

trace分析からの証拠：

サンプルのトレースを見ると、私は見ることができます：

• ユーザーエージェントパターン： python-requests/2.28.2およびpython-requests/2.31.0
• 一貫したクライアントIPS： 52.45.250.5および内部IPS
• 高いカート値： 6,861ドル、7,036ドル、259ドル（テストシナリオを提案）
• 同じユーザーID： 同一のカート合計を備えたユーザー20109からの複数のリクエスト

---

💡なぜこれが起こっているのか：

ほとんどの場合、原因：荷重テストまたは合成監視

• パターンが示唆しています 自動テスト 実際のユーザートラフィックではなく
• Pythonリクエストライブラリが示しています スクリプト化されたトラフィック
  
• 高いカート値と繰り返されるシナリオが指しています テストデータ
  
• 「4時間ごと」パターンはおそらくあります ロードテストスケジュール
  

技術的な原因：

• チェックアウトサービスボトルネック 大量の操作中
• 割引計算の遅延 （4.2s p95）
• 配送サービスの遅延 注文処理中
• 可能 データベースの競合 または 外部APIタイムアウト
  

---

🎯推奨事項：

1. 即時の行動：
   
   • これが負荷テストであるかどうかを確認します– テストチームにチェックします
   • チェックアウトサービスリソースを監視します スパイク期間中
   • 割引サービスのパフォーマンスを確認してください および外部依存関係
2. パフォーマンスの最適化：
   
   • 割引計算ロジックを最適化します
     
   • キャッシングを追加します 出荷計算用
   • 回路ブレーカーを実装します 外部支払い/配送API用
   • スケールチェックアウトサービス これが実際のユーザーの負荷を表す場合
3. 監視改善：
   
   • 個別のアラート 合成と実際のユーザートラフィック用
   • SLIトラッキングを追加します 特にチェックアウト操作用
   • 下流の依存関係を監視します （支払い、配送、割引サービス）

---

🚨アクションアイテム：

1. 4時間パターンがロードテストスケジュールに一致するかどうかを確認します
2. 実際のトラフィックの場合は、チェックアウトサービス容量と依存関係を調査します
3. チェックアウト固有のパフォーマンス監視と警告の実装を検討してください

---

良いニュースは、他のサービスがうまく機能していることです。これは、ロードテストシナリオによって悪化する可能性が高いチェックアウトフローの孤立した問題のように見えます。

---