すべてのユースケース

APIパフォーマンスボトルネックの調査

ZeroがAxiomからTP95データを取得し、最も遅いエンドポイントを特定、パターンを分析してGitHub Issueを作成します。

Zeroの接続先:SlackAxiomGitHub

Zeroが出力する結果

課題

TP95のスパイクは常にページャーを鳴らすわけではありません。チームが出荷に集中している間、メトリクスダッシュボードに居座って静かにユーザー体験を悪化させます。Zeroを使えば、任意のエンドポイントのパフォーマンスをオンデマンドで確認できます——直近7日間のTP95データを引き出し、どのリクエストが遅いかを見て、GitHubイシューを自動作成して取りこぼしを防ぎます。

Zeroによる解決方法

ステップ1:ツールを接続する

Axiom
Axiom
必須
Axiomは必須です。Zeroはエンドポイントパスと時間ウィンドウでフィルタしたリクエストイベントについて、Axiomデータセットをクエリします。
接続
GitHub
GitHub
オプション
GitHubは任意です。依頼に応じて、Zeroは検出事項からイシューを作成し、本文にメトリクス表を埋め込みます。
接続

ステップ2:Zeroに聞く

@Zero check Axiom for the POST /api/zero/runs endpoint - show me the TP95 for the last 7 days and flag any events over 5s.
ZeroがAxiomでエンドポイントをクエリ
Zeroは指定された期間における該当エンドポイントのリクエストイベントをすべて取得し、日次でTP50・TP95・TP99を算出します。
Zeroが遅いイベントを抽出
Zeroは閾値(デフォルト: 5秒)を超えるイベントを抽出し、時間帯やエラーパターンでグループ化し、想定される根本原因を特定します。
検出事項を含むGitHubイシューを作成
Zeroはメトリクス表・遅いイベント一覧・根本原因分析を含む構造化されたGitHubイシューを起票し、エンジニアリングチームがすぐに対応できる状態にします。

ステップ3:さらに活用する

担当者割り当てと優先度設定
適切なエンジニアにイシューを振り分けます
@Zero assign the Axiom issue to Ethan and add the label performance, priority-high.
定期的なモニタリングをスケジュール
主要エンドポイントの週次TP95チェックを設定します
@Zero every Monday at 9am, pull the last 7 days of TP95 for /api/zero/runs and post to #dev. File a GitHub issue only if TP95 exceeds 3s.
特定の遅いイベントを調査
単一の外れ値イベントを深掘りします
@Zero pull the full trace for the 6,857ms event on Apr 12 from Axiom and tell me where the time is spent.

より良い結果のためのヒント

プロンプトで閾値を指定してください — 「3秒を超えるイベントをフラグ」と書けば、汎用的なカットオフではなく自社のSLOに沿った検出になります。
デプロイ直後にエンドポイントを確認するようZeroに依頼し、ユーザーに大規模に影響する前にリグレッションを捉えましょう。
Daily Error Triageと組み合わせれば、SentryのエラーとAxiomのパフォーマンスが一つのブリーフにまとまり、朝のヘルスチェックが完結します。