2017-12-19 11 views
0

발생합니다.Elasticsearch 고산 고정 표시기는 내가 최근 봄 부팅 자동 주입을 사용하는 JDK 8 <code>java.time.Instant</code></p> <p>로그 문서에 <code>java.util.Date</code>에서 변화 2.4.6 고산을 시도 epochSecond 오류

import java.time.Instant; 

@Document(indexName = "log") 
public class Log { 

    @Id 
    private String id; 

    @Field(type = FieldType.Date, store = true) 
    private Instant timestamp = null; 
... 

이전 로그 문서는 다음과 같습니다. ES java.util.Date와 2.4.6 고산과 java.time.Instant와 ES 2.4.6에

import java.util.Date; 
@Document(indexName = "log") 
public class Log { 

    @Id 
    private String id; 

    @Field(type = FieldType.Date, store = true) 
    private Date timestamp = null; 

, 나는 어떤 문제가 발생하지 않습니다.

그러나 ES 2.4.6-alpine에서 java.time.Instant을 사용하는 경우 다음 오류가 표시됩니다. alpine linux 및 java.time 형식화에 문제가있는 것으로 보입니다.

SEVERE: Servlet.service() for servlet [dispatcherServlet] in context with path [/v1] threw exception [Request processing failed; nested exception is MapperParsingException[failed to parse [timestamp]]; nested: IllegalArgumentException[unknown property [epochSecond]];] with root cause 
java.lang.IllegalArgumentException: unknown property [epochSecond] 
     at org.elasticsearch.index.mapper.core.DateFieldMapper.innerParseCreateField(DateFieldMapper.java:520) 
     at org.elasticsearch.index.mapper.core.NumberFieldMapper.parseCreateField(NumberFieldMapper.java:241) 
     at org.elasticsearch.index.mapper.FieldMapper.parse(FieldMapper.java:321) 
     at org.elasticsearch.index.mapper.DocumentParser.parseObjectOrField(DocumentParser.java:311) 
     at org.elasticsearch.index.mapper.DocumentParser.parseObject(DocumentParser.java:328) 
     at org.elasticsearch.index.mapper.DocumentParser.parseObject(DocumentParser.java:254) 
     at org.elasticsearch.index.mapper.DocumentParser.parseDocument(DocumentParser.java:124) 
     at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:309) 
     at org.elasticsearch.index.shard.IndexShard.prepareCreate(IndexShard.java:533) 
     at org.elasticsearch.index.shard.IndexShard.prepareCreateOnPrimary(IndexShard.java:510) 
     at org.elasticsearch.action.index.TransportIndexAction.prepareIndexOperationOnPrimary(TransportIndexAction.java:214) 
     at org.elasticsearch.action.index.TransportIndexAction.executeIndexRequestOnPrimary(TransportIndexAction.java:223) 
     at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:157) 
     at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:66) 
     at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryPhase.doRun(TransportReplicationAction.java:657) 
     at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) 
     at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryOperationTransportHandler.messageReceived(TransportReplicationAction.java:287) 
     at org.elasticsearch.action.support.replication.TransportReplicationAction$PrimaryOperationTransportHandler.messageReceived(TransportReplicationAction.java:279) 
     at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:77) 
     at org.elasticsearch.transport.TransportService$4.doRun(TransportService.java:378) 
     at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) 
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
     at java.lang.Thread.run(Thread.java:748) 

alpine elasticsearch에서 java.time. *을 사용하는 데 필요한 조언이 있습니까?

curl -xGET localhost:9200/* docker-compose up -d 명령 후 나는 초기 데이터가 있습니다. 이 데이터는 -XDELETEdocker-compose downdocker-compose up -d 명령 후에도 다시 나타납니다.

elasticsearch : 2.4.6 및 elasticsearch : 2.4.6-alpine dockers의 초기 데이터는 동일합니다.

{ 
    "log":{ 
    "aliases":{}, 
    "mappings":{ 
     "log":{ 
     "properties":{ 
      "timestamp":{ 
      "type":"date", 
      "store":true, 
      "format":"strict_date_optional_time||epoch_millis" 
      } 
     } 
     } 
    }, 
    "settings":{ 
     "index":{ 
     "refresh_interval":"1s", 
     "number_of_shards":"5", 
     "creation_date":"1513716676662", 
     "store":{ 
      "type":"fs" 
     }, 
     "number_of_replicas":"1", 
     "uuid":"qlj9xxxxxxxxxxxxxxoisA", 
     "version":{ 
      "created":"2040699" 
     } 
     } 
    }, 
    "warmers":{} 
    } 
} 

아. 초기 데이터는 Elasticsearch 구현에 사용 된 로그 문서 클래스의 스프링 부트 서비스 자동 삽입 시작시 채워집니다.

org.springframework.data.elasticsearch.annotation.DateFormat 클래스의 javadoc에서 날짜/시간 형식에 대한 좋은 참조를 찾았습니다. SOO 많은 시간 이름 형식과 없음은

http://nocf-www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html

+0

sidenote. docker.elastic.co/elasticsearch/elasticsearch:6.1.1은 최신 탄력성 검색입니다. 나는 그것으로 전환하려고 노력할 것이다. – dskow

답변

0

이 오류는 일반적으로 당신은 그 형식 이전에 색인 문서와 충돌 문서를 제출할 때의 결과 내 출력을 :(일치합니다. (에서 날짜 형식 변경과 같은 자바 인스턴트에 자바 날짜) 문서 형식을 변경하면

, 당신은 ElasticSearch에서 해당 인덱스를 삭제해야합니다.

당신은 인덱스를 지우려면 DELETE API를 사용할 수 있습니다 (모든 취소 * 사용할 수 있습니다 like
curl -XDELETE localhost:9200/*) 및 GET API를 사용하여 클린 색인을 확인하십시오.
(curl -XGET localhost:9200/*는, 또는 당신의 브라우저에서 http://localhost:9200/*로 이동합니다. {} 당신이 빈 인덱스 의미)

(이것은 또한에 테스트하는 새로운 ES 2.4.6 고산를 작성하지 않은 당신을 가정됩니다. I '를 '깔끔한'설정으로 되 돌리는 것이 실제로 모든 오래된 데이터를 제거하지 않은 다른 것들과 도커 셋업을 사용하여 다른 사람을 보았습니다.)

+0

감사합니다. 각 테스트에서 모든 고정 컨테이너, 네트워크, 볼륨 및 이미지를 삭제했습니다. 나는 커얼 옵션을 시도해야 할 것이다. "비 apline ES 도커에서 즉시 변경 날짜"테스트가 작동합니다. 그래서, 나는 그것이 오래된 데이터 문제라고 생각하지 않는다. – dskow

+0

'format = DateFormat.custom, pattern = "yyyy-MM-dd'T'HH : mm : ss.SSSZ"'@Field에 추가하려고 시도합니다. – dskow

+0

'curl -XGET' 명령은 모두 돌아옵니다 "timestamp": { "type": "date", "store": true, "format": "yyyy-MM-dd'T'HH : mm : ss.SSSZ"} 이제 로그에 오류가 발생했습니다. – dskow

0

탄성 찾기로 작업하려면 : 2.4.6- 알파인 도커와 내 스프링 -boot 1.5.9-RELEASE with auto-injection, @FIELD 주석에 format = DateFormat.custom, pattern = "yyyy-MM-dd'T'HH:mm:ss.SSSZ"을 추가해야했습니다. 기본적으로 org.springframework.data.elasticsearch.annotations.DateFormat.none은 알파인에서 실행되는 탄성 검색과 작동하지 않습니다.

Alpha 3.7 OS에서 CentOS OS보다 호환되지 않는 시간 형식을 사용해야합니다.