[Alert] 원본 Measurement의 불필요한 Tag가 Alert에 포함되는 문제 개선

[kim-jinhyeong]

개요

현재 TICKscript에서 원본 Measurement를 조회한 후 alert()를 실행하면, 원본 데이터에 포함된 Tag가 Alert 이벤트에 그대로 전달됩니다.

이로 인해 Alert 처리에 필요하지 않은 원본 Measurement의 Tag까지 cloudhub_alerts Measurement와 httpOut 결과에 포함되고 있습니다.

Alert에 필요한 Tag만 유지하도록 delete() 노드를 적용하는 개선이 필요합니다.

---

현재 동작

현재 TICKscript는 다음과 같이 원본 cpu Measurement를 조회하고 있습니다.

var data = stream
    |from()
        .database(db)
        .retentionPolicy(rp)
        .measurement(measurement)
        .groupBy(groupBy)
        .where(whereFilter)
    |eval(lambda: "usage_idle")
        .as('value')

조회된 데이터가 별도의 Tag 정제 과정 없이 alert() 노드로 전달됩니다.

var trigger = data
    |alert()
        .crit(lambda: "value" > crit)
        .stateChangesOnly()
        .message(message)
        .id(idVar)
        .idTag(idTag)
        .levelTag(levelTag)
        .messageField(messageField)
        .durationField(durationField)
        .details(details)

이에 따라 Alert에서 생성한 Tag뿐만 아니라 원본 Measurement에 존재하는 Tag도 함께 전달됩니다.

Alert에서 생성하는 Tag

• alertID
• level
• alertName
• triggerType

원본 Measurement에서 전달되는 Tag 예시

• host
• cpu
• hw_type
• 기타 Measurement별 Tag

---

문제점

• Alert 처리에 필요하지 않은 Tag가 결과에 노출됩니다.
• Measurement마다 Tag 구성이 달라 Alert 데이터 구조가 일관되지 않습니다.
• 불필요한 Tag 저장으로 cloudhub_alerts Measurement의 Cardinality가 증가할 수 있습니다.
• 원본 모니터링 데이터와 Alert 메타데이터의 역할이 명확하게 분리되지 않습니다.
• httpOut 응답에도 불필요한 Tag가 포함됩니다.
• Alert 조회 및 필터링 시 사용하지 않는 Tag까지 관리해야 합니다.

---

개선 방향

alert() 노드가 실행되기 전에 delete() 노드를 추가하여 Alert 처리에 필요하지 않은 원본 Tag를 제거합니다.

var alertData = data
    |delete()
        .tag('cpu')
        .tag('hw_type')

정제된 데이터를 기준으로 Alert를 생성합니다.

var trigger = alertData
    |alert()
        .crit(lambda: "value" > crit)
        .stateChangesOnly()
        .message(message)
        .id(idVar)
        .idTag(idTag)
        .levelTag(levelTag)
        .messageField(messageField)
        .durationField(durationField)
        .details(details)
        .email()
        .to('jinhyeong.kim@snetsystems.co.kr')

단, groupBy()와 Alert ID 생성에 사용하는 Tag는 삭제 대상에서 제외해야 합니다.

현재 스크립트에서는 host가 그룹 식별에 사용되고 있습니다.

var groupBy = ['host']

var idVar = name + '-{{.Group}}'

따라서 host Tag를 삭제할 경우 다음 기능에 영향이 없는지 검토해야 합니다.

• Alert 그룹 구분
• Alert ID 생성
• stateChangesOnly()의 상태 관리 기준
• Host별 Alert 조회 및 식별

---

적용 예시

var data = stream
    |from()
        .database(db)
        .retentionPolicy(rp)
        .measurement(measurement)
        .groupBy(groupBy)
        .where(whereFilter)
    |eval(lambda: "usage_idle")
        .as('value')
    |delete()
        .tag('cpu')
        .tag('hw_type')

var trigger = data
    |alert()
        .crit(lambda: "value" > crit)
        .stateChangesOnly()
        .message(message)
        .id(idVar)
        .idTag(idTag)
        .levelTag(levelTag)
        .messageField(messageField)
        .durationField(durationField)
        .details(details)
        .email()
        .to('jinhyeong.kim@snetsystems.co.kr')

trigger
    |eval(lambda: float("value"))
        .as('value')
        .keep()
    |influxDBOut()
        .create()
        .database(outputDB)
        .retentionPolicy(outputRP)
        .measurement(outputMeasurement)
        .tag('alertName', name)
        .tag('triggerType', triggerType)

trigger
    |httpOut('output')

---

기대 결과

cloudhub_alerts Measurement와 httpOut 결과에는 Alert 처리에 필요한 Tag만 포함되어야 합니다.

유지 대상 Tag

• alertID
• level
• alertName
• triggerType
• host
  • 그룹 식별 또는 Alert 조회에 필요한 경우에만 유지

제거 대상 Tag

• cpu
• hw_type
• Alert 검색 및 식별에 사용하지 않는 원본 Measurement Tag
• Measurement별로 자동 전달되는 불필요한 Tag

---

작업 범위

• Alert Rule 생성 로직에 삭제 대상 Tag 처리 추가
• alert() 실행 전에 delete() 노드 추가
• groupBy 대상 Tag 삭제 방지
• Alert ID 생성에 사용하는 Tag 삭제 방지
• Measurement별 삭제 대상 Tag 정의 방식 검토
• influxDBOut() 저장 결과 확인
• httpOut() 응답 결과 확인
• Email Alert 발송 결과 확인
• 기존 Alert Rule에 대한 영향도 검토

---

완료 조건

• 원본 Measurement의 불필요한 Tag가 Alert 결과에 포함되지 않는다.
• Alert 처리에 필요한 시스템 Tag가 정상적으로 유지된다.
• groupBy에 사용하는 Tag가 정상적으로 유지된다.
• Alert ID 생성 결과가 기존과 동일하게 유지된다.
• stateChangesOnly()의 상태 변경 감지가 정상적으로 동작한다.
• cloudhub_alerts Measurement에 필요한 Tag만 저장된다.
• httpOut('output') 결과에 필요한 Tag만 포함된다.
• Threshold 판정 결과가 기존과 동일하다.
• Email Alert가 기존과 동일하게 발송된다.
• 기존 Alert Rule 실행에 오류가 발생하지 않는다.