Agent Manager는 설치된 서버에서 "bootvisor"로 참조됩니다.
이 페이지에는 Agent 로그를 구성하는 방법에 대한 정보, Agent 구성과 관련된 일반적인 문제에 대한 설명이 포함되어 있으며 디버깅 지침을 제공합니다.
curl -s https://<your domain name>/magritte-coordinator/api/ping > /dev/null && echo pass || echo fail을 실행합니다.
pass가 표시됩니다. 이 경우 다음을 수행해야 합니다.
echo $http_proxy를 실행하여 프록시가 사용되는지 확인할 수 있습니다.curl: (6) Could not resolve host: ...와 같은 오류가 표시될 수 있습니다. 이 경우 연결을 차단하는 것이 있을 수 있습니다 (예: 방화벽 또는 프록시) Palantir 담당자에게 문의해야 합니다.<agent-manager-install-location>/var/log/startup.log 파일의 내용을 확인합니다.
다음 오류가 표시되는 경우: Caused by: java.net.BindException: {} Address already in use, 이는 Agent Manager가 바인딩하려는 포트에서 이미 프로세스가 실행 중이라는 것을 의미합니다.
<agent-manager-directory>/var/conf/install.yml 파일의 내용을 확인하고 port 매개변수를 찾음으로써 수행할 수 있습니다 (예: port: 1234 - 여기에서 1234는 포트). 포트 매개변수가 정의되지 않은 경우 Agent Manager는 기본 포트 7032를 사용합니다.ps aux | grep $(lsof -i:<PORT> |awk 'NR>1 {print $2}' |sort -n |uniq) 여기에서 <PORT>는 Agent Manager가 바인딩하려는 포트입니다.
com.palantir.magritte.bootvisor.BootvisorApplication이 포함된 경우 이미 다른 Agent Manager가 실행 중입니다.BindException 오류를 해결하려면 사용되지 않은 새로운 포트를 Agent Manager에 찾아야 합니다.
lsof -i :<PORT> 여기에서 <PORT>는 선택한 포트 번호입니다.사용 가능한 포트를 찾으면, <agent-manager-directory>/var/conf/install.yml에 저장된 구성에 port 매개변수를 추가(또는 업데이트)해야 합니다.
아래는 포트가 7032로 설정된 Agent Manager 구성 스니펫 예입니다.
Copied!1 2 3... port: 7032 auto-start-agent: true
위의 구성을 저장한 후, <agent-manager-root>/service/bin/init.sh stop && <agent-manager-root>/service/bin/init.sh start를 실행하여 Agent Manager를 다시 시작합니다.
<agent-manager-directory>/var/data/processes/<latest-bootstrapper-directory>/var/log/startup.log 파일의 내용을 확인합니다.
다음 오류가 표시되는 경우: Caused by: java.net.BindException: {} Address already in use, 이는 Bootstrapper가 바인딩하려는 포트에서 이미 프로세스가 실행 중이라는 것을 의미합니다.
port 매개변수 아래에 정의됩니다 (예: port: 1234 - 여기에서 1234는 포트). Bootstrapper의 기본 포트는 7002입니다.ps aux | grep $(lsof -i:$PORT |awk 'NR>1 {print $2}' |sort -n |uniq) 여기에서 $PORT는 Bootstrapper가 바인딩하려는 포트입니다.
com.palantir.magritte.bootstrapper.MagritteBootstrapperApplication이 포함된 경우 이미 다른 Bootstrapper가 실행 중입니다.BindException 오류를 해결하려면 사용되지 않은 새로운 포트를 Bootstrapper에 찾아야 합니다.
lsof -i :<PORT> 여기에서 <PORT>는 선택한 포트 번호입니다.사용 가능한 포트를 찾았으면 Bootstrapper의 구성에 port 매개변수를 설정해야 합니다. 이렇게 하려면 Data Connection 앱의 에이전트 개요 페이지로 이동해야 합니다. 그곳에서 고급 구성 버튼을 선택한 다음 "Bootstrapper" 탭으로 이동해야 합니다.
아래는 포트가 7002로 설정된 Bootstrapper 구성 스니펫 예입니다.
Copied!1 2 3 4server: adminConnectors: ... port: 7002 #This is the port value
구성을 업데이트한 후 변경 사항을 저장하고 에이전트를 다시 시작하여 변경 사항이 적용되도록 해야 합니다.
대부분 이러한 경우, 다른 "유령" 인스턴스의 Agent가 실행 중이므로 찾아서 종료해야 합니다.
이전 프로세스를 찾고 종료하려면 다음 단계를 수행하세요.
<agent-manager-install-location>/service/bin/init.sh stop을 실행하여 Agent Manager를 중지합니다.<agent-manager-install-location>/var/data/processes/index.json 파일을 삭제합니다.for folder in $(ls -d <agent-manager-root>/var/data/processes/*/); do $folder/service/bin/init.sh stop; done을 실행하여 이전 프로세스를 종료합니다.<agent-manager-install-location>/service/bin/init.sh start).Agent를 설치된 호스트에서 수동으로 시작하면 (Data Connection을 통해 시작하는 대신) "유령" 프로세스가 생성될 수 있습니다.
Agent 프로세스가 "불건전함"으로 표시되는 경우, 대부분 운영 체제 또는 다른 소프트웨어(예: 안티바이러스)에 의해 충돌하거나 종료되었습니다.
운영 체제가 프로세스를 종료한 이유는 여러 가지가 있지만, 가장 일반적인 이유는 운영 체제에 메모리가 충분하지 않아 실행할 수 없기 때문입니다. 이는 OOM(Out Of Memory) 죽임으로 알려져 있습니다.
운영 체제에서 에이전트 또는 Explorer 하위 프로세스 중 어느 것이 OOM 죽임을 받았는지 확인하려면 다음 명령을 실행할 수 있습니다: grep "exited with return code 137" -r <agent-manager-directory> --include=*.log. 이 명령은 에이전트 관리자 디렉토리 내의 모든 로그 파일을 검색하여 '종료 코드 137과 함께 종료됨'을 포함하는 항목을 찾습니다(종료 코드 137은 프로세스가 OOM 죽임을 의미합니다).
위 명령에 의해 생성된 다음 예제 출력은 Agent 하위 프로세스가 OOM 죽임을 받았음을 보여줍니다: ./var/data/processes/bootstrapper~<>/var/log/magritte-bootstrapper.log:ERROR [timestamp] com.palantir.magritte.bootstrapper.ProcessMonitor: magritte-agent exited with return code 137. 이와 같은 출력이 표시되면 힙 크기 조정 단계를 따라야 합니다.
또한 운영 체제 로그에서 OOM 죽임 항목을 확인하려면 다음 명령을 실행할 수 있습니다: dmesg -T | egrep -i 'killed process. 이 명령은 커널 링 버퍼에서 'killed process' 로그 항목을 검색하여 프로세스가 OOM 죽임을 나타냅니다.
실제 OOM 죽임 프로세스의 로그 항목은 다음과 같습니다:
[timestamp] Out of memory: Killed process 9423 (java) total-vm:2928192kB, anon-rss:108604kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:1232kB oom_score_adj:0(java)가 포함되지 않은 항목은 에이전트와 관련이 없으므로 무시할 수 있습니다.힙 크기 조정
힙 할당을 변경하기 전에 먼저 다음을 수행해야 합니다:
free -h를 실행할 수 있습니다. 6GB 시스템에서 출력 결과는 다음과 같습니다:Copied!1 2 3total used free shared buff/cache available Mem: 5.8Gi 961Mi 2.8Gi 9.0Mi 2.1Gi 4.6Gi # 메모리: 총 5.8기가, 사용 중 961메가, 여유 2.8기가, 공유 9.0메가, 버퍼/캐시 2.1기가, 사용 가능 4.6기가 Swap: 1.0Gi 0B 1.0Gi # 스왑: 총 1.0기가, 사용 중 0바이트, 여유 1.0기가
free 명령의 결과물에서 available 열은 새로운 애플리케이션을 시작하는 데 사용할 수 있는 메모리 양을 보여줍니다. 에이전트에 얼마나 많은 메모리를 할당할 수 있는지 결정하려면 에이전트를 중지한 다음 시스템이 정상적으로 높은 부하 상태에서 free -h를 실행하는 것이 좋습니다. 사용 가능한 값은 모든 에이전트 프로세스를 결합한 메모리의 최대 양을 알려줍니다. 가능한 경우 시스템의 다른 프로세스에 메모리가 필요하고 에이전트 프로세스의 오프힙 메모리 사용을 고려하여 약 2-4GB의 버퍼를 남겨 두는 것이 좋습니다. free의 모든 버전이 사용 가능한 열을 표시하지 않으므로 시스템의 버전에 대한 문서를 확인하여 동등한 정보를 찾아야 할 수도 있습니다. 도움이 필요하면 Palantir 담당자에게 문의하십시오.
다음 하위 프로세스에 각각 얼마나 많은 메모리가 할당되어 있는지 결정하십시오: Agent Manager, Bootstrapper, Agent 및 Explorer.
에이전트 및 탐색기 하위 프로세스에 할당된 메모리 양을 알아내려면 Data Connection 앱 내의 에이전트 구성 페이지로 이동한 다음 고급 구성 버튼을 클릭하고 "Bootstrapper" 탭을 선택해야 합니다. 이제 각 하위 프로세스가 자체 구성 블록을 가지고 있으며 각 블록에서 관련 프로세스에 할당된 메모리 양을 정의하는 jvmHeapSize 매개 변수를 볼 수 있습니다.
기본적으로 Bootstrapper 하위 프로세스에는 512mb의 메모리가 할당됩니다. 이를 확인하려면 먼저 <agent-manager-directory>/var/data/processes/ 디렉토리로 이동한 다음 가장 최근에 생성된 bootstrapper~<uuid> 디렉토리를 찾으려면 ls -lrt를 실행해야 합니다. 가장 최근에 생성된 bootstrapper~<uuid> 디렉토리에 있으면 ./var/conf/launcher-custom.yml 파일의 내용을 검사할 수 있습니다. 여기서 Xmx 값은 Bootstrapper에 할당된 메모리 양입니다.
기본적으로 Agent Manager 하위 프로세스에도 512mb의 메모리가 할당됩니다. 이는 파일 <agent-manager-directory>/var/conf/launcher-custom.yml의 내용을 검사하여 확인할 수 있습니다. 여기서 Xmx 값은 Agent Manager에 할당된 메모리 양입니다.
Windows 머신에 설치된 에이전트는 launcher-custom.yml 파일을 사용하지 않으며 따라서 기본적으로 Java는 에이전트 관리자와 부트스트래퍼 프로세스에 시스템에서 사용 가능한 총 메모리의 25%를 할당합니다. 이 문제를 해결하려면 에이전트 관리자와 부트스트래퍼 힙 크기를 수동으로 설정해야 하는데, 아래 단계를 따르면 됩니다.
setx -m JAVA_HOME "{BOOTVISOR_INSTALL_DIR}\jdk\{JDK_VERSION}-win_x64\"setx -m MAGRITTE_BOOTVISOR_WIN_OPTS "-Xmx512M -Xms512M"setx -m MAGRITTE_BOOTSTRAPPER_OPTS "-Xmx512M -Xms512M".\service\bin\magritte-bootvisor-win호스트에 사용 가능한 메모리 양과 위의 하위 프로세스에 할당된 메모리 양을 결정한 후 다음 중 하나를 결정해야 합니다. 위의 프로세스에 할당된 메모리 양을 줄이거나 호스트에 사용 가능한 메모리 양을 늘립니다.
에이전트 프로세스의 메모리 사용량을 안전하게 줄일 수 있는지 여부는 에이전트 설정(예: 동시 동기화 최대 수 및 파일 업로드 병렬 처리), 동기화되는 데이터 유형 및 에이전트에 대한 전형적인 로드에 따라 다릅니다. 힙 크기를 줄이면 OS가 프로세스를 종료하는 가능성이 줄어들지만 자바 프로세스가 힙 공간이 부족해질 가능성이 더 커집니다. 어떤 값이 작동하는지 테스트해야 할 수도 있습니다. 이 값을 조정하는 데 도움이 필요하면 Palantir 담당자에게 문의하십시오.
하위 프로세스 중 하나(또는 여러 개)에 할당된 메모리 양을 줄이려면 다음을 수행하십시오:
jvmHeapSize 매개 변수를 설정할 수 있습니다.Copied!1 2 3agent: .... jvmHeapSize: 3g #This is jvm heap size value
기본 힙 할당
기본적으로 에이전트는 약 3GB의 메모리가 필요하며 다음과 같이 할당됩니다:
Java 프로세스는 오프힙 메모리를 사용하므로, 이를 위해 최소한 ≥ 4GB를 남겨 두는 것이 좋습니다.
에이전트 다운로드에 실패하는 두 가지 주요 원인은 네트워크 연결과 만료된 링크입니다.
Foundry에 연결할 수 있지만 다운로드에서 tar.gz 파일이 유효하지 않거나 오류 메시지가 나타난다면 만료되거나 무효화된 링크가 있을 수 있습니다.
사용자는 프로젝트의 에디터여야 프로젝트에서 에이전트를 생성할 수 있지만 프로젝트의 소유자여야 프로젝트 내의 에이전트를 관리할 수 있습니다. 즉, 사용자가 에이전트를 생성한 다음 에이전트의 다운로드 링크를 생성하거나 에이전트에서 다른 관리 작업을 수행할 수 없을 수도 있습니다. 에이전트 권한에 대한 자세한 정보는 권한 참조를 참조하십시오.
TLSv.1.0 및 TLSv1.1은 구식이고 불안전한 프로토콜이므로 Foundry에서 지원되지 않습니다. Azul Zulu는 OpenJDK 11.0.14 빌드에서 기본적으로 jdk.tls.disabledAlgorithms 보안 속성에 있는 java.security 파일에서 TLSv1.0 및 TLSv1.1을 비활성화합니다.
TLSv1.0 및 TLSv1.1을 전용으로 지원하는 데이터 소스 시스템에 연결하려는 시도는 'Error: The server selected protocol version TLS10 is not accepted by client preferences'를 포함한 다양한 오류로 실패할 것입니다.
TLS의 더 이상 사용되지 않는 버전의 사용을 적극적으로 반대하며 Palantir은 그 사용과 관련된 보안 위험에 대해 책임지지 않습니다. 그렇다고 해도 TLSv1.0 및 TLSv1.1을 임시로 지원할 필요가 있는 경우 다음 단계를 수행할 수 있습니다:
java.security 파일을 찾으십시오. 이 파일은 다음 위치에 있어야 합니다: <bootvisor-directory>/jdk/<jdk-directory>/conf/security/java.security.java.security 파일을 부트비저 디렉토리 외부의 다른 위치로 복사하여 부트비저가 업그레이드될 때 덮어쓰거나 삭제되지 않도록 한 다음 /opt/palantir/tls-override/tls-overrides.java.security와 같은 이름으로 변경하십시오.tls-overrides.java.security 파일에서 jdk.tls.disabledAlgorithms 속성을 찾고 그 값을 TLSv1 및 TLSv1.1을 제거하십시오. 파일을 저장하십시오.jvmArguments 구성을 찾으십시오. 이는 Agent settings > Configuration > Advanced > Bootstrapper에서 찾을 수 있습니다. 에이전트 및 탐색기의 기존 jvmArguments에 다음 JVM 인수를 추가하십시오: -Djava.security.properties=/opt/palantir/tls-overrides/tls-overrides.java.security(생성된 오버라이드 파일에 적절한 경로를 채우십시오).이러한 단계를 수행하면 에이전트가 TLSv1.0 및 TLSv1.1을 계속 허용하며 에이전트가 업그레이드됩니다. 데이터 소스가 새로운 TLS 버전으로 이동하면 오버라이드 파일과 JVM 인수를 제거하십시오.
호스트 머신에서 에이전트의 로그 저장 설정을 조정하려면 다음 단계를 따르십시오:
새 구성이 이제 적용되어야 합니다.