Montray — systemd 서비스 상태를 알림 영역에서 확인하는 도구

AI 요약

systemd 서비스가 멈춰도 사용자가 알아차리지 못하는 문제를 알림 영역 아이콘으로 해결하려는 프로젝트입니다. 개발자는 Syncthing 서비스가 몇 주 동안 고장 난 채 방치돼 파일 동기화가 어긋난 경험과 Certbot이 인증서를 갱신하지 못한 사례를 들었습니다. 별도의 대규모 모니터링 시스템 대신, 정상일 때는 초록색이고 문제가 생기면 노란색이나 빨간색으로 깜박이는 간단한 표시를 원했습니다. 이후 디스크 여유 공간이나 RAID 상태처럼 명령행에서 확인할 수 있는 항목도 감시 범위에 넣었습니다.

서버와 데스크톱 앱

Montray는 두 구성 요소로 나뉩니다. montray-server는 Go로 작성한 백그라운드 서비스입니다. 머신에서 systemd 서비스와 사용자 지정 명령행 점검을 실행하고, 발생한 인시던트를 읽기 전용 WebSocket API로 제공합니다. montray-ui는 Rust와 Slint로 만든 데스크톱 앱입니다. 하나 이상의 서버에 연결해 상태를 모으고, 시스템 트레이 아이콘과 데스크톱 알림으로 보여줍니다.

각 인시던트에는 systemd.my-service, free-space.exec-result 같은 키와 warning 또는 error 상태가 붙습니다. UI는 서버 설정에서 지정한 ID를 키 앞에 추가해 여러 서버의 인시던트를 구분합니다. 문제가 생겼지만 나중에 확인하고 싶다면 UI에서 해당 항목을 잠시 숨기는 스누즈 기능을 이용합니다.

아이콘은 스누즈하지 않은 항목 가운데 가장 심각한 상태를 나타냅니다. 상태를 아직 받지 못했으면 회색, 모두 정상이라면 초록색입니다. 경고는 노란색 깜박임, 오류는 빨간색 깜박임으로 표시합니다. UI의 연결이나 터널에 내부 오류가 생기면 자주색으로 깜박입니다.

로컬·원격 머신 연결

로컬 머신에서 쓰려면 GitHub 릴리스의 사전 빌드 바이너리를 내려받아 montray-server setup으로 서버 서비스를 설정합니다. UI를 설치한 뒤 montray-ui setup을 실행하면 기본 설정과 자동 시작 항목을 만들고, 앱을 시작하면 트레이 아이콘이 나타납니다. 재부팅 뒤에도 자동으로 시작합니다.

원격 Linux 서버에는 montray-server만 설치하면 됩니다. 기본 설정은 서버가 127.0.0.1에서만 요청을 받으므로, 노트북의 UI에서 접속하려면 SSH 터널이나 TLS와 bearer token 인증을 설정해야 합니다. 문서에서는 SSH 공개키 인증을 전제로 한 터널 설정을 안내합니다. UI 설정에 원격 호스트, 사용자, SSH 포트와 서버 주소를 추가하면 UI가 사용 가능한 로컬 포트를 할당해 터널을 연결합니다.

점검 설정과 지원 범위

기본 설정에서는 systemd 서비스가 실패하면 경고로 표시하고, 루트 파티션의 여유 공간이 100 MiB 미만이면 오류로 처리합니다. 설정 파일에서 특정 서비스의 상태 기준을 더 엄격하게 바꾸거나 사용자 지정 명령행 점검을 추가할 수 있습니다. 설정 변경 뒤에는 montray-server.service를 재시작해야 적용됩니다.

프로젝트는 현재 Linux에서만 테스트했습니다. UI는 Windows와 macOS에서도 실행해 원격 Linux 서버를 감시할 수 있도록 설계했지만, 해당 운영체제의 로컬 서비스 상태를 기본 제공하지는 않습니다. 서버 프로그램도 비Linux 환경에서 실행할 수는 있지만, systemd 점검은 사용할 수 없고 주기적으로 스크립트를 실행하는 점검만 유효합니다. 빌드에는 Go 1.26 이상과 Rust 1.92 이상이 필요하며, UI는 Slint 실행에 필요한 시스템 라이브러리도 요구합니다.

Lobsters 반응

• @weaksauce — 이 프로젝트는 멋지고 유용해 보입니다. 하지만 분위기 코딩으로 만든 것들과 인위적인 봇 신호가 늘면서 이런 것들을 믿기 어려워졌습니다. 이 특정 소프트웨어와 직접 관련된 이야기는 아니지만, 새 프로젝트를 볼 때마다 마음 한구석에 걸립니다. 겉보기에는 괜찮고 유용한 소프트웨어에 백도어를 넣기는 어렵지 않습니다. 이제 코드를 생성하기가 쉬워졌으니까요. 소프트웨어를 쓰는 사람이 책임져야 하는 건 늘 그랬지만, 전보다 부담이 커진 것 같습니다. 이제 코드를 직접 감사해야 하는데 큰일입니다. 그래도 확실히 멋진 소프트웨어입니다!
  • @nelson — 저는 백도어보다 제품 품질이 걱정됩니다. 새 도구를 배우고 설치할 만큼 가치가 있는지 어떻게 알 수 있을까요? 세심하고 제대로 작동할까요? 1년 뒤에도 업데이트될까요? 예전에는 새 도구를 프로그래밍하는 데 걸림돌이 많아서 제품을 설계한 사람이 어느 정도 공을 들였습니다. 이제는 한 시간쯤 생각하면 이런 걸 만들 수 있습니다. 그렇게 나온 제품 가운데 상당수는 별로입니다. Montray가 어떤지는 모르겠습니다. 유용한 아이디어 같지만, 저에게도 이런 도구가 필요한데 평가하는 데 시간을 쓸 가치가 있는지 모르겠습니다.
  • @dimonomid — 앞으로 개발이 계속될지는 장담할 수 없습니다. 제 여가 시간을 쓰는 일이고, 앞으로 얼마나 시간이 날지도 모르니까요. 그래도 5년간의 Git 이력을 보면 제가 얼마나 공을 들였는지 어느 정도 알 수 있습니다. 핵심 기능은 LLM이 나오기 전에 처음 구현했고, 몇 년 동안 개인적으로 사용했습니다. 이 도구를 팔려는 건 전혀 아닙니다. 직접 관심이 생기지 않는다면 시간을 들이지 마세요!
  • @dimonomid — 솔직히 제 생각은 오히려 반대입니다. LLM이 소프트웨어에 백도어를 몰래 넣는 일을 특별히 쉽게 만들지는 않습니다. LLM 없이도 충분히 쉬운 일이었습니다. 하지만 LLM은 큰 소프트웨어 제품에서 백도어를 찾거나, 백도어가 없다고 상당한 확신을 얻는 일을 훨씬 쉽게 만듭니다. LLM에게 Montray나 다른 프로젝트에 백도어가 있는지 확인해 달라고 요청한 뒤 안심하고 쓸 수도 있습니다.

원문: GitHub / 번역·요약: Trawling