私たちの小さな Incident Support チーム(わずか 6 人の専門家)にとって、2 つのメトリクスは絶対に重要です。 そして . speed of detection accuracy of diagnosis 私たちは、世界中の何百万ものユーザーからケースを受け取っています。 私たちのビジネスがどこで運営されているか。ユーザーケースが登場するとき、私たちが頼っているコアツールの1つは、他のツールとともに、 . 48 countries Kibana 私たちのシステムの多要素性質(マイクロサービス、現地の規制の特性、A/B実験など)のために、私たちはしばしば検索に終わります。 ログ内のユーザー関連のイベントを分析することによって。 アイドル in a Haystack 経験豊富な専門家でさえ、これには時間がかかります: 
 
 
 
 実際に起こったことを理解し、 現実の問題から騒音を分ける、 テクニカルイベントと実際のユーザー体験を結びつける。 平均的に、このような分析は、 そして、曖昧な状況では、より長くかかることがあります。 at least 15 minutes per case I wanted logs to read like a まるで Raw Event Dump みたいなものではありません。 story And yes - this is むしろA . not a replacement for an engineer 思考加速器 アイデア I built an automation in オートメーション これらは、いくつかのツールを組み合わせています: n8n 
 
 
 
 Slack キバナ(Clarvoyance) LLM(Large Language Model) そして、サポート専門家のためのシンプルで実用的なワークフローに変えました。 どのように機能する 
 
 
 
 
 
 
 
 
 
 専用のSlackチャンネルが作成されます。 専門家はユーザーのUIDをチャンネルに送信します - 番号だけです。 自動化は UID をキャプチャし、事前定義されたフィルターを使用して Clairvoyance Kibana にリクエストを送信します。 過去6時間のすべてのユーザーアクティビティログが収集されます。 ログが見つからない場合は、「活動が見つかりませんでした」という明確なメッセージが Slack トレードに掲載されます。 If logs exist, they are processed:
 
 
 
 
 
 
 empty entries are removed, duplicates are eliminated, data is structured and normalized, everything is bundled into a single dataset. 完全なログパッケージは、私たちのチームのニーズに合わせてカスタマイズされたプロンプトと一緒にLLMに送信されます。 LLMはイベントを分析し、人間が読める概要(最大600文字)を返します。 答えは、リクエストの約2分後に元の Slack トレードに戻ります。 このパイプラインの初期開発は、 その大半が正しく設定された認証情報(特にSlackでは、後で説明します)。 30 hours 私たちは、アクティブな使用で、この自動化がチームを救うことを期待しています。 . up to 60 hours per month LLMは実際に何を答えますか? 答えは常に構造化され、非常に具体的な質問に答えます: 
 
 
 
 
 
 どのようなエラーが検出されましたか? ポジティブな(正常な)出来事の概要 エラーがユーザーのワークフローにどのような影響を与えるか 問題が発生した時点(タイムスタンプ) 専門家が次に取るべき行動 結果として、私たちは見るだけでなく、 しかし、リアル : ユーザーが何をしていたか、どこで問題に遭遇し、それがどれほど重要だったか。 「HTTP 400 on Endpoint X」 context 「YES」 - . no sensitive data is ever sent to the LLM 自動化の核心目標 1.読書記録の人間化 キバナは強力なツールですが、目でログを読み取ることは疲れるし、特にイベントが時間と複数のサービスに広がる場合、認知的に費用がかかります。 I wanted the output to look like a 技術的なゴミではありません。 clear explanation 2.分析時間の短縮 Before automation: 
 
 ユーザーケースあたり15分以上 After automation: 
 
 1～2分(UIDを送る→概要を得る) これは、ピーク負荷や大規模な事故の際に特に重要です。 3.より深い分析を可能にする 自動化は時間を節約するだけでなく、私たちに以下のことを可能にします。 
 
 
 
 
 システムの問題をより迅速に検出し、 ユーザー間の繰り返しのエラーパターンを識別し、 新たな問題分野を強調することによって、専門家のスキルを向上させ、 アプリケーションが現実世界でどのように動くかをよりよく理解します。 最終的に、このアプローチは、ユーザー体験を通じてのみ説明された問題を調査するのに費やした開発者の時間を大幅に削減します. Each case comes with a structured analysis backed by concrete log events. このツールは誰のため? 主に: 
 
 
 
 専門家のサポート、 ユーザー面の事故に取り組むエンジニアは、 すぐにキバナに潜り込むことなく「何が間違ったのか」を理解する必要があるチーム。 これが最終版でしょうか。 No. This is a 現在A , with a full roll-out planned for early . living tool 静かなテスト段階 2026 テスト中: 
 
 
 
 早速、精製され、 さまざまなLLMとモデルバージョンが比較され、 フィルタリングロジックと応答テンプレートが改善されています。 今でも、自動化はすでに主な目標を達成しています: . making logs understandable and saving time パイプライン構造 トリガー Slackチャンネルでのイベントから始まるパイプライン( ) : Slack Trigger 
 
 
 イベントタイプ:チャンネルに投稿された新しいメッセージ Input: a user UID sent as plain text (単純テキストとして送信されたユーザのUID) データ準備 メッセージデータは抽出され、変換されます。 必要な JSON 形式: Set nodes 
 
 
 Upper Branch: UID(ナンバーとして) Lower branch: thread context(チャンネルIDとトレードタイムスタンプ) レトリバルレトリバル キッズはキッズ( )の使用 「Clarvoyance」のインデックス Elasticsearch / Get Many traces-main logs are searched by 定められた時間のウィンドウ user_id 条件論理 アン イベントが見つかったかどうかを確認する: IF node 
 
 
 
 
 No events: 
 
 
 Data is merged with the thread context A predefined “NO EVENTS” message is posted to Slack 
 
 Events found: 
 
 
 Logs are aggregated, minimized, and normalized Data is sent to the LLM for analysis 返信 配達 LLM 出力は、Slack トレード コンテキストと合併し、元のトレードに回答として投稿されます。 ノード詳細 Slack トリガー 事前設定された Slack 認証情報とチャンネル ID (可用) が必要です。 スレイクで) チャンネル詳細 ノードセット 入力データの抽出および正常化に使用される: 
 
 
 uid → 番号としてのメッセージテキストからパース thread data:
 
 
 
 
 channel  → original message timestamp thread_ts Elasticsearch ノード Kibana 認証情報とインデックス ID (Index ID) が必要 ( ) インデックス管理 キー設定: 
 
 
 : 1000 items (Higher values often caused gateway timeouts.) limit Query:
 
 
 
 
 
 
 time range:  now-6h filter by  user_id limited source fields last 1000 events コードノード(Minimizer) LLM分析のためのログを準備する: 
 
 
 
 
 
 
 
 
 フィールドの正常化(時間、コンテンツ) 潜在的なPII(電話/メール - 存在しない場合でも、追加の保護として)をマスクします。 長い価値観を持ち、 空のフィールドを削除し、 イベントの種類は時間によって、 似たような出来事を繰り返し、 軽量統計(HTTPコード、エンドポイント)を計算します。 トップ500の合計イベントと厳格な長さ制限を含むコンパクトなプロンプトを構築します。 これは、LLMに大きな、トークン高価なパイロットを送るのを避けるために重要です。 OpenAI Node(メッセージモデル) OpenAI 認証とモデル選択(現時点で必要) テスト中)。 GPT-4.1-Mini The prompt is designed from the perspective of an : second-line technical support specialist 
 
 
 
 
 
 
 まず、ユーザー(ドライバー/乗客/クーリーター)を分類します。 テクニカルエラーに注意し、 エラーが存在しない場合は、事業状況(文書、禁止、プロフィールの状態)を分析します。 文字制限のある厳格な回答テンプレートに従って、 具体的なターゲットとタイムスタンプに結論を結びつけ、 ユーザー向けのワークフローの影響から技術分析を分離する。 この構造は、 raw logs を . clear, actionable insights 出力例は以下の通りです。 最終思考 この自動化はエンジニアを置き換えるものではなく、彼らがより速く考えるのに役立ちます。原始ログを短い、構造化された物語に変えることで、チームは認識負荷を減らし、文脈を失うことなく事件分析を加速させます。 n8nや近代的なLLMのようなツールで、小さなチームでさえ、実用的な、人間に優しい観測可能な層を構築することができます。

This story contains new, firsthand information uncovered by the writer.

inDrive.Tech

このオーディオは、ストーリーの元の言語で制作されています。

n8n 自動化を構築して Kibana ログを読み、LLM でそれらを分析する方法

About Author

コメント

ラベル

この記事は

Related Stories

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

Telegram: クリプト島と本土を結ぶ橋

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

Telegram: クリプト島と本土を結ぶ橋

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps