2016-10-04 8 views
1

최근에 여러 클러스터에서 Apache Kafka 중개인을위한 GC 로깅을 활성화하기로 결정했습니다 (정확한 버전은 다양합니다). Kafka 관련 메모리 및 가비지 수집 문제. 우리는 브로커를 운영하기 위해 이것을하고 싶습니다 ("kafka-topics.sh"와 같은 카프카 운영을위한 것이 아닙니다). 어떤 이유로 로그 파일 덮어 쓰기 및 디스크 공간 사용 제한을 방지하면서 Apache Kafka 브로커에 GC 로깅을 활성화하는 방법

  • 디스크로 이어지는, 너무 많은 디스크 공간을 사용하여 로그 브로커가 다시 시작될가 작성하기 때 유지하는 경우 (로그 파일의

    • 덮어 쓰기를 : 우리는 또한 우리가 발생할 수 알고이 문제를 방지하려면 클러스터가 충분히 오래 실행되면 관리하지 않는 한 로그 파일이 가득 찰 것입니다.)

    프로세스에 대해 Java GC 로깅이 시작될 때 동일한 이름을 가진 파일의 내용을 대체하는 것처럼 보입니다. 즉, 조심하지 않으면 GC 로깅이 손실 될 수 있습니다. 아마도 필요할 가능성이 클 경우입니다.

    kafka-server-start.sh를 실행하기 전에 환경 변수 GC_LOG_ENABLED을 "true"로 설정하면 GC 로깅이 가능하지만 위의 두 가지 문제는 해결되지 않습니다. 그러면 고정 된 매개 변수 집합 인 -Xloggc:<gc-log-file-loc> -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps이 추가됩니다. 여기서 gc-log-file-loc은 ".out"대신 "-gc.log"를 넣은 .out 파일과 동일한 디렉토리 및 이름에 있습니다.

  • 답변

    7

    kafka-server-start.sh를 실행하기 전에 KAFKA_GC_LOG_OPTS을 아래의 특정 JVM 매개 변수로 설정할 수 있습니다. 이것은 kafka-run-class.sh가 JVM 옵션에서 환경 변수의 내용을 포함하기 때문에 작동하지만, 명령 행에 -loggc이 전달 된 경우에만 가능합니다. kafka-server-start.sh가 이것을 전달합니다.

    Apache Ambari를 통해 카프카를 시작하는 경우 카프카 서비스> 구성> 고급 kafka-env> kafka-env 템플릿에서 KAFKA_GC_LOG_OPTS을 설정합니다. 여기에 설정하면 kafka-server-start.sh에서만 사용됩니다. 다른 스크립트는 현재 -loggc을 kafka-run-class.sh에 전달하지 않습니다.

    이제는 KAFKA_GC_LOG_OPTS에 포함되도록 JVM 매개 변수에 대해 설명합니다.

    파일에 GC 로깅을 사용하려면 -verbose:gc -Xloggc:<log-file-location>을 추가해야합니다.

    브로커를 다시 시작할 때마다 덮어 쓰기를 방지하려면 로그 파일 이름을 특별히 고려해야합니다. 모든 호출에 대해 고유 한 이름이 있어야 타임 스탬프를 추가하는 것이 가장 좋은 옵션 인 것처럼 보입니다. 'date +'% Y % m % d % H % M ''과 같은 것을 추가하여 타임 스탬프를 추가 할 수 있습니다. 이 예에서는 YYYYMMDDHHMM 형식입니다. 일부 Java 버전에서는 "% t"를 로그 파일 위치에 넣을 수 있으며 YYYY-MM-DD_HH-MM-SS 형식의 브로커 시작 시간 소인으로 대체됩니다.

    이제 디스크 공간 사용을 관리하십시오. 내가 가지고있는 것보다 더 간단한 방법이 있다면 나는 행복 할 것이다.

    먼저 Java의 내장 GC 로그 파일 순환을 이용하십시오. -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M은 JVM에서 최대 10 개의 GC 로그 파일을 가지며이 크기가 100MB를 넘지 않는이 순환 게재를 사용하는 예입니다. 10 x 100MB는 최대 사용량이 1000MB입니다.

    GC 로그 파일을 최대 10 개까지 회전 시키면 Xloggc에서 지정한 파일 이름에 '.0', '.1', ... '.9'이 추가됩니다. .0이 먼저 나오고 .9에 도달하면 .0을 대체하고 라운드 로빈 방식으로 계속 진행합니다. Java의 일부 버전에서는 .current가 현재 쓰여지고있는 로그 파일의 이름 끝에 더 추가됩니다.

    인해 우리는 분명히 덮어 쓰기를 방지해야 할 필요가 명명 고유 한 파일에, 당신은 브로커 프로세스 호출 당 1,000메가바이트 을 가질 수있다, 그래서 이것은 카프카 브로커 GC 로그에 의해 사용되는 디스크 공간을 관리하는 토탈 솔루션이 아닙니다. 각 브로커에 대해 최대 10 개의 GC 로그 파일 세트로 끝날 것입니다. 이는 시간이 지남에 따라 늘어날 수 있습니다. 가장 좋은 해결책은 (* nix 아래) logrotate 유틸리티 (또는 다른 유틸리티)를 사용하여 마지막 N 일 동안 수정되지 않은 브로커 GC 로그를 정기적으로 정리하는 것입니다.

    수학을 수행하고 충분한 디스크 공간이 있는지 확인하십시오.

    사람들은 GC 로그에서 기본값보다 세부 정보와 컨텍스트를 자주 원하므로 GC_LOG_ENABLED=true과 같이 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps을 추가하는 것을 고려하십시오. 당신의 카프카 로그 디렉터리의 위치 또는 어디든지 사용하여 명령 줄에서

    Putting all end parameters together into KAFKA_GC_LOG_OPTS and starting a broker you might have: 
    TIMESTAMP=`date +'%Y%m%d%H%M'` 
    # GC log location/name prior to .n addition by log rotation 
    GC_LOG_NAME="{{kafka_log_dir}}/kafka-broker-gc.log-$TIMESTAMP" 
    
    GC_LOG_ENABLE_OPTS="-verbose:gc -Xloggc:$GC_LOG_NAME" 
    GC_LOG_ROTATION_OPTS="-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M" 
    GC_LOG_FORMAT_OPTS="-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps" 
    
    export KAFKA_GC_LOG_OPTS="$GC_LOG_ENABLE_OPTS $GC_LOG_ROTATION_OPTS $GC_LOG_FORMAT_OPTS" 
    ./kafka-server-start.sh server.properties 
    

    , 대체 {{kafka_log_dir}}는 GC 로그로 가고 싶어. 로그 파일 이름을 변경할 수도 있습니다.

    Ambari에서는 Ambari UI의 "kafka-env template"필드에 kafka-server-start.sh를 실행하지 않고 해당 행을 추가합니다. {{kafka_log_dir}}은 자동으로 필드 바로 위에 정의 된 Kafka 로그 디렉토리로 바뀝니다. 브로커 로깅을 시작하려면 브로커를 다시 시작해야합니다 (롤링 업그레이드를 고려하십시오).