Logstash + ElasticSearch : 초기 유형 매핑으로 인해 로그 행이 누락 됨

Question

로그 집계를위한 고전적인 logstash + elasticsearch + kibana 설정이 있습니다. 모든 서버와 응용 프로그램에서 로그를 집계하는 데 사용하고 다음과 같은 문제를 발견했습니다. ES가 처음으로 로그 행 (이 경우 JSON 문서)을 받으면 해당 문서에 대한 매핑이 만들어집니다 (http://bit.ly/1h3qwC9 참조) . 대부분의 경우 속성은 문자열로 매핑되지만 경우에 따라 날짜 또는 숫자로 매핑됩니다. 후자의 경우 다른 응용 프로그램의 다른 로그 행에 동일한 필드가 있지만 문자열 값이있는 경우 ES는이 필드의 색인을 생성하지 못하고 로그에 예외를 던지고 평소와 같이 계속 진행합니다. 이 문제를 해결하기 위해 ES가 잘못된 형식의 문서 (index.mapping.ignore_malformed : true)를 무시하도록 구성했지만 해킹이 더 많이 발생했습니다.

어떤 아이디어라도 우아한 방법으로이 문제를 해결하려면 어떻게해야합니까?

Answer 1

날짜 유형이나 유형에 상관하지 않는 것 같습니다. 내가 가장 좋은 방법은 문자열로 모든 유형을 정의하는 동적 템플릿을 정의하는 것입니다 생각 : here에서

{ 
    "_default_" : { 
     "dynamic_templates" : [ 
      { 
       "long_to_string" : { 
        "match" : "*", 
        "match_mapping_type": "long", 
        "mapping" : { 
         "type" : "string", 
         "index" : "analyzed" 
        } 
       } 
      }, 
      { 
       "double_to_string" : { 
        "match" : "*", 
        "match_mapping_type": "double", 
        "mapping" : { 
         "type" : "string", 
         "index" : "analyzed" 
        } 
       } 
      }, 
      { 
       "float_to_string" : { 
        "match" : "*", 
        "match_mapping_type": "float", 
        "mapping" : { 
         "type" : "string", 
         "index" : "analyzed" 
        } 
       } 
      }, 
      { 
       "integer_to_string" : { 
        "match" : "*", 
        "match_mapping_type": "integer", 
        "mapping" : { 
         "type" : "string", 
         "index" : "analyzed" 
        } 
       } 
      }, 
      { 
       "date_to_string" : { 
        "match" : "*", 
        "match_mapping_type": "date", 
        "mapping" : { 
         "type" : "string", 
         "index" : "analyzed" 
        } 
       } 
      }, 
      { 
       "boolean_to_string" : { 
        "match" : "*", 
        "match_mapping_type": "boolean", 
        "mapping" : { 
         "type" : "string", 
         "index" : "analyzed" 
        } 
       } 
      } 
     ] 
    } 
} 

.

Answer 2

많은 연구 끝에, 저는이 슬픈 해결책이 현재 존재하지 않는다고 슬프게 선언 할 수 있습니다. 필드를 분석해서는 안된다는 것을 선언 할 수는 있지만 동적으로 유형을 변경하도록 말하거나 유형을 자동으로 무시할 수는 없습니다.

실질적으로 당신이 먼저 보내는 유형이 그 필드에 색인을 생성 할 수있는 유일한 유형이라는 것을 의미합니다. 유형으로 필드를 미리 선언 한 경우 해당 유형 이외의 다른 항목을 색인 할 수 없습니다. 두 경우 모두 일치하지 않는 유형이 모두 삭제됩니다. 또한, 이는 종종 elasticsearch의 로그 파일을 넘치게하고 로그 로테이션을 설정하거나 로깅 yaml에서 해당 오류를 로깅하지 않도록 elasticsearch를 구성해야합니다.

귀하의 솔루션은 잠재적으로 해킹 될 수 있습니다 (색인 해제 된 데이터가 관련이 없다는 것을 확신하지 않는 한). try와 매우 흡사합니다 : python을 전달하십시오.

일반적으로 (경험적으로 말하면) 다른 유형의 데이터 (서로 다른 탄성 검색 유형이 아님)를 같은 이름의 입력란에 색인하지 않는 것이 좋습니다. 그러면 시도 할 때 키바나에서 분석하기가 매우 어려워집니다. 숫자/문자열 기반 쿼리를 사용할 수 있습니다. 특정 필드에 히스토그램이나 파이 차트를 정렬하거나 표시 할 수 없습니다. 분명히 코드 (또는 다른 응용 프로그램의 코드)를 변경하여 같은 경우에는 원래 앱을 식별하고 logstash의 grok를 사용하고 (이미 json을 보내지 않는 한) 필터를 변경하여 필드의 이름을 대체합니다.

Answer 3

왜 ignore_malformed가 해킹으로 간주됩니까? 그들은 정확하게 같은 이유로 필드를 선언 된 데이터 유형으로 평가하지 못할 수도 있습니다. 정말 아무것도 망가 뜨 렸니?

편집/업데이트 : 로그 섭취/처리/인덱싱
, 내 경험을 직접 ES와 같은 저장소에 로그를 섭취하는 것은 여러 가지 이유로 나쁜 생각이다 (그리고 만약 사람들을 무엇인지 물어 주시기 바랍니다 호기심있다).

요약하면 ElasticSearch 또는 HDFS와 같은 데이터 저장소에 데이터를 보내기 전에 항상 인제 스트/파싱 엔진을 사용합니다. logStash 또는 flume과 같은 에이전트를 사용하여 grok를 사용하여 데이터를 처리/구문 분석 할 수 있습니다. 또는 맞춤형 Spark 앱을 작성하여 데이터를 ES에 공급하기 전에 데이터를 수집, 검증 및 구조화하십시오.

일반적으로 나는 다음과 같은 로그 파이프 라인을 만듭니다. 생산자 (syslog 등) -> Kafka/Kinesis (topic-1) -> Spark Streaming App (구문 분석/구조 규칙 적용) -> Kafka/Kinesis) -> 여러 에이전트 (데이터 저장소 당 하나의 에이전트 그룹). 그래서 예를 들어, 주제 -2에 가입하고 HDFS에 쓸 flume agent를 배치 할 것입니다. 병행하여 많은 수의 logStash 에이전트를 배치하고 ES에 작성하십시오.

다소 복잡해 보일 수도 있지만 청소기/일관성있는 데이터의 이점은 여러 가지입니다. 캐주얼 데이터 탐색기에서 데이터 과학자까지 모두 감사합니다 :)