Watcher — 검색 결과를 조건에 따라 액션으로 연결한다
Elasticsearch Index Sorting 및 Watcher 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(index-settings/sorting), 공식 블로그(optimizing-sort-queries), Watcher 공식 문서(how-watcher-works) Elastic 공식문서 How Watcher works
이 모듈을 다 읽으면
- Watch의 4단계 파이프라인(trigger→input→condition→action)을 순서대로 설명할 수 있다
- condition이 false면 나머지 파이프라인이 어떻게 되는지 설명할 수 있다
elasticsearch-learn-05에서 다룬 Query DSL을 전제로, 그 쿼리 결과를 사람이 매번 확인하는 대신 조건을 만족할 때 자동으로 알림 같은 액션을 실행하게 만드는 Watcher의 4단계 파이프라인을 정리한다.
4단계 파이프라인 — trigger → input → condition → action
Watch는 trigger(언제 체크할지, 보통 스케줄 기반 — 예: 5분마다), input(elasticsearch-learn-05의 Query DSL 등으로 실제 데이터를 가져와 watch payload에 담는 단계, Elasticsearch뿐 아니라 외부 HTTP 서비스에서도 가져올 수 있음), condition(그 payload가 알림을 낼 조건을 만족하는지 평가), action(조건을 만족했을 때 실제로 할 일 — 이메일 발송, 웹훅 호출 등) 네 단계로 구성된 파이프라인이다.
핵심 포인트
- trigger(스케줄, 예: 5분마다)→input(쿼리 실행 결과를 watch payload에 적재 — ES뿐 아니라 외부 HTTP도 가능)→condition(payload가 조건을 만족하는지 평가)→action(이메일·웹훅 등 실제 실행)
condition이 실행 여부를 결정하는 게이트다
condition은 단순한 로그 기록이 아니라 파이프라인의 진행 여부를 결정하는 게이트다 — 예를 들어 '에러 이벤트가 5건 넘게 있는가'를 평가해, 그 조건이 참이면 다음 단계(action)로 진행하고, 거짓이면 그 시점에서 watch 실행 자체가 그냥 종료된다(액션은 전혀 실행되지 않음). 즉 input 단계에서 데이터를 매번 가져오더라도, condition을 통과하지 못하면 알림·웹훅 같은 실제 액션 비용은 전혀 발생하지 않는다는 게 이 구조의 핵심이다.
핵심 포인트
- condition이 참이어야 action으로 진행 — 거짓이면 그 시점에서 watch 실행이 종료되고 action은 전혀 실행 안 됨
- input 단계는 매번 실행되지만, condition을 통과 못 하면 실제 알림·웹훅 비용은 발생하지 않음