소스는 btop 설정 문제처럼 보이지만, 실제로는 서로 다른 두 실행 환경을 혼합하고 있습니다. ZimaOS에는 v1.3.3부터 내장 btop 성능 패널이 제공되었습니다. 이와 별도로 사용자는 App Store에서 btop 컨테이너를 설치할 수 있습니다. 컨테이너는 일반적으로 자체 네트워크 네임스페이스만 보는 반면, 호스트의 btop은 호스트에 노출된 인터페이스를 볼 수 있습니다.
이 차이로 인해 한 참여자는 다음 항목 사이를 전환할 수 있었던 이유가 설명됩니다. eth0, eth1, virbr0, docker0그리고 다음 몇 가지가 있었습니다. veth 인터페이스인 반면, 원 게시자의 btop에는 다음만 표시되었습니다. lo 및 eth0. 스레드는 여전히 해당 사용자의 정확한 설정에 대한 확인된 복구 방법 없이 끝났습니다.
ZimaOS 자체는 10GbE 인터페이스를 사용하고 있었음
btop은 ZimaOS의 내장 성능 패널로 추가됨
IceWhale은 ZimaOS 1.3.3에서 내장 btop 패널을 도입했습니다. 따라서 현재 사용자는 기본적인 시스템 모니터링을 위해 별도의 btop 컨테이너를 설치해야 한다고 단정해서는 안 됩니다.
공식 내장 btop 기능 범위를 참조하세요.
호스트 btop 예시에서는 여러 물리 및 가상 인터페이스가 표시됨
Docker btop은 할당된 네트워크 네임스페이스만 볼 수 있음
커뮤니티 답변에서는 App Store btop 컨테이너가 자체 컨테이너 네트워크만 볼 수 있다고 설명했습니다. 이는 정상적인 Docker 동작입니다. 애플리케이션은 네임스페이스에 노출되지 않은 호스트 인터페이스를 모니터링할 수 없습니다.
btop 인터페이스 선택기를 변경해도 누락된 인터페이스를 만들 수 없음
Docker 호스트 네트워크를 선택하자 소스 앱이 충돌하거나 중지됨
원 게시자는 App Store btop 컨테이너를 호스트 네트워킹으로 전환해도 문제가 해결되지 않았으며 btop이 작동을 멈췄다고 말했습니다. 또한 다음을 추가하는 방안도 고려했습니다. SYS_PTRACE 또는 SYS_ADMIN.
스레드에서는 이러한 권한 변경을 검증하지 않았으므로, 통계 패널 하나를 표시하기 위해서만 권장해서는 안 됩니다.
호스트 btop 바이너리는 존재했지만, 소스에서는 작동하지 않는다고 했습니다
스레드에는 확인된 최종 해결 방법이 없습니다
소스에는 해당 사용자의 내장 btop이 손상되었는지, 이전 수동 설치의 영향을 받았는지, 아니면 별도의 1.6.1 버그가 발생한 것인지 확인해 주는 IceWhale 직원의 답변이 없습니다.
현재 더 안전한 접근 방식
- 먼저 기본 제공 ZimaOS btop 패널을 사용하세요.
- 현재 호스트 네트워크 도구로 NIC가 존재하는지 확인하세요.
- 컨테이너화된 모니터를 사용하는 경우 해당 모니터의 네트워크 네임스페이스를 이해하세요.
- 메트릭만을 위해 privileged/SYS_ADMIN 권한으로 확대하지 마세요.
- 기본 제공 btop이 작동하지 않는다면 두 번째 btop 패키지를 반복해서 재설치하지 말고 현재 버전과 직접 실행한 CLI 오류를 수집하세요.
검은색 btop 페이지와 누락된 eth1은 서로 별개의 증상입니다
스레드 초반에 원 게시자는 기본 제공 대시보드 btop이 검은 화면으로 열렸다고 말했습니다. 이후에는 작동하지만 다음만 표시하는 App Store/컨테이너 btop에 주목했습니다. lo 및 eth0. 이 두 가지를 하나의 원인으로 뭉뚱그려서는 안 됩니다.
기본 제공 패널의 실패는 호스트 btop/ttyd 세션과 관련될 수 있지만, Docker 모니터 내부에 호스트 인터페이스가 없는 것은 네임스페이스 격리로 인해 예상되는 현상입니다.
높거나 변경되는 btop 포트가 자동으로 근본 원인인 것은 아닙니다
ZimaOS는 일부 터미널 방식 도구를 웹 세션을 통해 실행합니다. 브라우저에서 포트 또는 연결 오류가 보인다고 해서 물리적 NIC가 잘못 구성되었다는 뜻은 아닙니다. 먼저 호스트에서 명령을 직접 실행하고 정확한 오류를 기록하세요.
컨테이너 권한을 더 부여하는 것은 무료 모니터링 해결책이 아닙니다
추가 SYS_ADMIN, 광범위한 장치 접근 권한 또는 완전한 권한 모드는 btop에 필요한 범위를 훨씬 넘어 호스트의 더 많은 부분을 노출할 수 있습니다. 심지어 network_mode: host 컨테이너의 격리 모델을 변경합니다.
시스템 텔레메트리에는 모든 인터페이스를 열거할 수 있도록 App Store 컨테이너에 호스트에 가까운 권한을 부여하는 것보다 호스트에 통합된 모니터가 작동하는 편이 바람직합니다.
btop을 탓하기 전에 호스트에서 eth1 확인
현재 ZimaOS 네트워크 페이지 또는 호스트 네트워크 명령을 확인하여 10GbE 인터페이스가 활성 상태이고, 예상 주소를 가지며, 트래픽을 전달하는지 확인하세요. 소스에서는 이를 성공적으로 수행했습니다. ZimaOS 자체에서 해당 인터페이스를 표시하고 사용했습니다. eth1.
호스트 네트워킹에서 인터페이스가 보이지만 컨테이너에서만 보이지 않는다면, 문제의 경계는 NIC 드라이버가 아니라 모니터링 환경입니다.
현재 ZimaOS에서 기본 제공 btop이 작동하지 않는 문제는 새로운 회귀로 취급하세요
소스에서는 1.6.1을 사용했지만 현재 ZimaOS는 1.7.1입니다. 기본 제공 패널이 현재도 검은색이라면 현재 버전, CPU 아키텍처, 직접 btop 출력, 브라우저 콘솔/세션 오류 및 복구/재설치로 문제가 바뀌는지를 기록하세요. 2026년 4월 스레드가 현재 장애의 원인을 이미 설명한다고 가정하지 마세요.
btop 네트워크 FAQ
eth1이 해당 네임스페이스에 표시되지 않는 경우에도 btop에서 eth1을 선택할 수 있나요?
아니요. 선택기는 실행 중인 프로세스가 볼 수 있는 인터페이스 사이에서만 순환합니다.
다른 사용자가 기본 제공 btop에서 eth1을 볼 수 있다고 확인했나요?
예. James는 호스트 btop에서 eth0, eth1, libvirt, Docker 및 veth 인터페이스를 차례로 확인했다고 보고했습니다.
소스에서 안전한 Docker 권한 수정이 확인되었나요?
아니요. 호스트 네트워킹과 추가 기능에 대한 논의는 있었지만, 최종적으로 작동하는 구성은 검증되지 않았습니다.
