systemd-report, 서버 상태를 모아 서명된 보고서로 전송합니다

AI 요약

systemd-report는 시스템의 정적 정보와 실행 중 변하는 지표를 모아 하나의 보고서로 만드는 systemd 도구입니다. Lennart Poettering은 서버 집단을 관리할 때 각 노드와 서비스의 상태를 파악하는 데 쓸 수 있도록, Amutable이 관련 기반 기능을 systemd에 기여했다고 설명합니다.

지표 수집과 보고서 구성

systemd-report는 여러 지표 제공 서비스와 Varlink IPC 인터페이스로 통신합니다. 기본 제공 수집기뿐 아니라 외부 서비스도 같은 인터페이스를 구현해 자료를 추가할 수 있습니다. 수집 정보는 자주 바뀌는 런타임 지표와 비교적 고정된 시스템 정보인 ‘facts’로 나뉩니다. Meta가 먼저 동적 지표 수집을 위한 서비스를 기여했고, Amutable은 같은 인터페이스로 운영체제 배포 관리 등에 쓸 정적 정보도 다룹니다.

기본 수집 항목에는 CPU 아키텍처, 가상화 기술, 운영체제 정보, 부팅 ID와 머신 ID, TPM2 제조사와 모델, 클라우드 인스턴스 메타데이터, 호스트 이름, 메모리와 CPU 수, 커널 버전이 포함됩니다. 네트워크 인터페이스별 주소와 상태, CPU·디스크 I/O·메모리 사용량, PSI(System Pressure Stall Information), 스왑, cgroup별 자원 사용량도 모읍니다. systemd 유닛별 상태와 오류, 작업 대기열, 재시작 횟수, 저널의 높은 우선순위 메시지도 항목에 들어갑니다. 수집 결과는 특정 시점의 지표를 담은 타임스탬프 포함 JSON 문서로 정리됩니다.

전송과 서명 검증

보고서는 HTTPS 서버에 PUT 방식으로 올릴 수 있습니다. 글에서는 .timer 유닛으로 정기 전송하고, 부팅이나 예약된 종료·재부팅 같은 이벤트에도 전송하는 방식을 제안합니다. 제어부가 보고서를 관리 작업에 활용하려면 내용의 진위를 확인해야 하므로, systemd-report는 서명 서비스와 통신하는 별도 Varlink 인터페이스도 제공합니다.

업스트림에는 서명 방식이 세 가지 있습니다. 소프트웨어 서명기는 처음 사용할 때 비대칭 키를 만들고 /var/ 아래 평문으로 저장합니다. TPM 서명기는 PCR과 NvPCR, 지표 데이터를 포함하는 TPM quote를 만들고 측정 로그를 덧붙입니다. CoCo 서명기는 CPU TSM quote로 보안 가상 머신의 초기 측정값과 지표 데이터를 다룹니다. 한 보고서에 여러 서명을 붙일 수도 있어, 하드웨어 기반 무결성 기능이 있는 환경에서는 그 방식을 함께 활용합니다. Amutable 제어부는 서명을 검증한 뒤 TPM 측정 로그에서 운영체제 관련 정보를 확인하고 보고서를 관리·분석 작업에 사용합니다.

Prometheus와의 차이, 확장 방식

글은 Prometheus와 node_exporter도 비슷한 정보를 제공하지만 구조가 다르다고 설명합니다. systemd 방식은 운영체제 하위 계층에서 정보를 직접 제공하고, 여러 지표를 일관된 시점의 서명된 보고서로 묶습니다. Prometheus의 개별 지표 스트림을 대체한다고 단정하지는 않습니다. 두 방식 사이의 연결은 가능성이 있는 작업이며, 새 기반이 그 다리를 놓는 데 쓰일 수 있다고 설명합니다.

외부 프로젝트는 지정된 디렉터리에 AF_UNIX/SOCK_STREAM Varlink 소켓을 열고 간단한 메서드 호출을 구현해 지표 제공자나 서명기를 추가할 수 있습니다. 구현 언어에는 제한이 없습니다.

Reddit 반응

• @u/aliendude5300 — 사실상 시스템 인벤토리 수집에 유용하겠네요. 대량으로 만드는 neofetch 같아요.
  • @u/noobjaish — 진짜 유용하겠네요.
• @u/jodkalemon — 괜찮아 보이네요. 저는 systemd를 좋아하고, 데비안 안정판에서도 별문제 없이 씁니다. 이 기능은 서버 집단 관리용이고 매뉴얼에도 언급되어 있네요. 사용 여부도 선택할 수 있습니다.
• @u/ExaHamza — systemd 같은 프로그램 묶음이라면 구성 요소를 쉽게 분리해 배포판이 필요한 것만 쓰도록 하는 방법이 있으면 좋겠습니다. 예전에 문서를 읽었을 때는 분리가 가능하긴 해도 systemd가 그런 방식으로 설계되지 않았다는 이유로 권장하지 않았고, 분리 절차도 복잡하다고 느꼈습니다.
  • @u/Business_Reindeer910 — 어떤 구성 요소를 말씀하시는 건가요? 분리할 수 없는 주 구성 요소는 journald 정도입니다.
• @u/nelmaloc — Varlink만 아니면 좋겠네요.
• @u/DissonantGuile — 그러니까 Telegraf 같은 건가요?
• @u/UAP44 — 선택 설치 패키지이고 기본 실행되지 않는다면 괜찮습니다. 그래도 흠, 스파이웨어인가요? 먼저 만들고 보편화한 다음 스위치를 켜서 기본값으로 넣으려는 건 아닌가 싶네요.
  • @u/AStolenGoose — 스파이웨어요? 기업에서 쓰는 서버 집단 관리용이잖아요.
  • @u/UAP44 — 음, 그래도 다른 용도로 쓸 수도 있잖아요. 수집되는 데이터가 꽤 많네요.
  • @u/Business_Reindeer910 — systemd는 관련 기능이 생긴 뒤로 이런 데이터를 알고 있었습니다. 시스템 전체를 제어하니 시스템에 관한 세부 정보를 아는 건 당연합니다. 다른 운영체제의 동급 구성 요소도 마찬가지입니다.
• @u/PigIronDave — 서버 집단을 관리한다면 서버와 서비스의 상태를 알아야 한다는 말이네요. 보통 PC 사용자가 필요로 하는 기능을 또 추가하는군요. 농담이지만 컴퓨터 한 대도 ‘집단’이라고 부를 수 있죠. systemd는 서버 유지보수와 시스템 관리자를 위한 것이고, 가정용 사용자는 runit이나 dinit, sysV를 쓰는 편이 낫습니다. 일반 사용자는 systemd 기능의 90%도 안 쓰니, 그 정의대로라면 덩치가 큰 셈입니다.
  • @u/crazy_penguin86 — 일반 사용자는 vim, emacs, LibreOffice, Blender, git, gcc 같은 중간 규모 이상 소프트웨어 기능의 90%도 안 씁니다. 그 정의를 따르면 이것들도 덩치가 크겠네요. 그리고 이 도구는 systemd에 기본 포함된 게 아니라 따로 설치해야 합니다.

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