우리의 소규모 Incident Support 팀 (단지 6 명의 전문가)에게는 두 가지 측정 요소가 절대적으로 중요합니다. 그리고 . speed of detection accuracy of diagnosis 우리는 전 세계 수백만 명의 사용자로부터 사례를 받습니다. 사용자 사례가 들어올 때, 우리가 의존하는 핵심 도구 중 하나는 - 다른 것들과 함께 - . 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 그리고 예 - 이것은 하지만 오히려 A . not a replacement for an engineer 생각의 가속기 이 아이디어 나는 자동화를 만들었다 이것은 몇 가지 도구를 결합합니다 : n8n 
 
 
 
 슬라크 키바나 (Clearvoyance를 통해) 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은 실제로 무엇에 대답합니까? 대답은 항상 구조화되어 있으며 매우 구체적인 질문에 답합니다 : 
 
 
 
 
 
 어떤 오류가 발견되었습니까? 긍정적 인 (정상적인) 사건의 요약 오류가 사용자 작업 흐름에 영향을 미칠 수있는 방법 정확히 문제가 발생했을 때 (타임스탬프) 전문가가 다음에 취해야 할 행동 결과적으로, 우리는 단지 볼 수 없습니다 하지만 실제 : 사용자가 무엇을하고 있었는지, 어디에서 문제가 발생했는지, 그리고 얼마나 중요한지. “Endpoint X에서 HTTP 400” context 그리고 예 - . no sensitive data is ever sent to the LLM 자동화의 핵심 목표 1) 인류의 글 읽기 키바나는 강력한 도구이지만 눈으로 로그를 읽는 것은 지루하고인지적으로 비니다.특히 이벤트가 시간과 여러 서비스에 걸쳐 퍼지면. 나는 수출이 A처럼 보이기를 원했다. 기술적인 쓰레기가 아닙니다. clear explanation 2) 분석 시간을 줄이는 방법 Before automation: 
 
 사용자 사례당 15분 이상 After automation: 
 
 1 ~ 2 분 (UID 보내기 → 요약 얻기) 이것은 특히 피크로드 또는 대량 사건 중에 중요합니다. 더 깊은 분석을 가능하게 하기 자동화는 시간을 절약 할뿐만 아니라 우리가 할 수 있습니다 : 
 
 
 
 
 체계적인 문제를 더 빨리 파악하고, 사용자들 사이에서 반복되는 오류 패턴을 식별하고, 새로운 문제 영역을 강조함으로써 전문가의 기술을 향상시키고, 응용 프로그램이 실제 사용에서 어떻게 행동하는지 더 잘 이해할 수 있습니다. 궁극적으로,이 접근 방식은 개발자가 사용자 경험을 통해서만 설명된 문제를 조사하는 데 소비되는 시간을 크게 줄여줍니다.Each case comes with a structured analysis backed by concrete log events. 이 도구는 누구를 위한 것일까? 주로 : 
 
 
 
 전문가들의 지원, 사용자에 직면한 사건을 다루는 엔지니어, 즉시 키바나에 뛰어들지 않고도 "무슨 일이 잘못 됐는지"를 빨리 이해해야 하는 팀. 이것이 최종 버전인가요? No. 이것은 A 현재 A , 일찍 계획된 완전한 롤로우와 함께 . living tool 조용한 테스트 단계 2026 테스트 중에 : 
 
 
 
 신속하게 정리되며, 다양한 LLM 및 모델 버전이 비교되며, 필터링 논리와 응답 템플릿이 개선됩니다. 심지어 지금, 자동화는 이미 주요 목표를 성취합니다 : . making logs understandable and saving time 파이프라인 구조 트리거 파이프라인은 전용 Slack 채널의 이벤트에서 시작됩니다 ( ) : Slack Trigger 
 
 
 이벤트 유형: 채널에 게시된 새로운 메시지 입력: 간단한 텍스트로 보낸 사용자 UID 데이터 준비 메시지 데이터는 추출되고 사용하여 변환됩니다. 필요한 JSON 형식으로 : Set nodes 
 
 
 Upper Branch: UID (As a Number) Thread Context (Channel ID 및 Thread Timestamp) 로고 Retrieval 히브리카는 히브리카에 갔다 ( )를 사용하여 인덱스에 대한 자세한 내용 Elasticsearch / Get Many traces-main 로고가 검색되었습니다 정해진 시간 창 안에 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(을 통해 사용할 수 있음)가 필요합니다.Requires preconfigured Slack credentials and the channel ID (available via Slack 에서) 오픈 채널 자세한 정보 노드 세트 입력 데이터를 추출하고 정상화하는 데 사용됩니다: Used to extract and normalize input data: 
 
 
 uid → 번호로 메시지 텍스트에서 파세 thread data:
 
 
 
 
 channel  → original message timestamp thread_ts Elasticsearch 노드 Kibana 자격 증명서 및 인덱스 ID가 필요합니다 (found in ) 인덱스 관리 핵심 설정 : 
 
 
 제한: 1000 개의 항목(더 높은 값은 종종 게이트웨이 타임 아웃을 일으켰습니다.) Query:
 
 
 
 
 
 
 time range:  now-6h filter by  user_id limited source fields last 1000 events 코드 노드 (Minimizer) LLM 분석을위한 로그를 준비합니다 : 
 
 
 
 
 
 
 
 
 필드를 정상화합니다 (시간, 콘텐츠) 잠재적 인 PII (전화 / 이메일 - 존재하지 않더라도 추가 보호로), 오래된 가치관을 세우고, 빈 필드를 제거하고, 시간에 따라 일어나는 일들, 비슷한 이벤트를 펼치고, 가벼운 통계를 계산합니다 (HTTP 코드, 엔드포인트), builds a compact prompt with the   and a strict length limit. top 500 aggregated events 이것은 LLM에 대규모, 토큰 비싼 비용 부하를 보내지 않도록하는 것이 중요합니다. OpenAI 노드 (Message a Model) OpenAI 인증서 및 모델 선택이 필요합니다 (현재 시험할 때) GPT-4.1-Mini 프롬프트는 A의 관점에서 설계되었습니다. : second-line technical support specialist 
 
 
 
 
 
 
 먼저 사용자를 분류하십시오 (운전자 / 승객 / 코리어), 기술적 오류에 대한 관심, 오류가 없으면 비즈니스 상태 (문서, 금지, 프로필 상태)를 분석합니다. 문자 한계가 있는 엄격한 응답 템플릿을 따르고, 구체적인 끝점과 타임스탬프에 대한 결론을 묶고, 사용자 중심의 워크플로의 영향으로부터 기술적 분석을 분리합니다. 이 구조는 raw logs를 . clear, actionable insights 아래에서 사용할 수 있는 예제 출력: Example output available below: 최종 생각 이 자동화는 엔지니어를 대체하지 않으며, 신속하게 생각할 수 있도록 도와줍니다.그리고 원시 로그를 짧고 구조화된 스토리로 변환함으로써 팀은 인지 부담을 줄이고 상황을 잃지 않고도 사건 분석을 가속화합니다. n8n 및 현대 LLM과 같은 도구를 사용하면 소규모 팀조차도 실용적이고 인간 친화적 인 관찰성 계층을 구축 할 수 있습니다.The key is not more data - it is making systems explain themselves.

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

inDrive.Tech

이 오디오는 이야기의 원래 언어로 제작되었습니다!

n8n 자동화를 구축하여 Kibana 로그를 읽고 LLM을 사용하여 분석하는 방법

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

HackerNoon 글쓰기 대회에서 우승하고 싶으신가요? #crypto-api 대회 우승자들이 추천하는 내용은 다음과 같습니다.

AI의 힘을 발휘하세요. 최첨단 기술의 체계적 검토: 개요 및 소개

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

HackerNoon 글쓰기 대회에서 우승하고 싶으신가요? #crypto-api 대회 우승자들이 추천하는 내용은 다음과 같습니다.

AI의 힘을 발휘하세요. 최첨단 기술의 체계적 검토: 개요 및 소개

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps