모니터링 및 알림

무언가를 바꾸게만 해 주는 제어판은 절반짜리 도구입니다. 나머지 절반은 문제가 생겼을 때, 가능하면 장애로 번지기 전에 그 사실을 아는 것입니다. FrontierStack은 감시하도록 지정한 모든 대상에 대해 모니터 점검을 계속 실행하고, 문제의 첫 징후를 원하는 채널의 메시지로 알려 줍니다. 이 장에서는 모든 것을 요약하는 로컬 상태 보드, 경고를 발생시키고 전달하는 알림 패널, 이를 전달하는 메시징 게이트웨이, 그리고 클라우드 서비스, 프로젝트 도구, 전원, 스토리지를 위한 전용 모니터를 다룹니다.

11.1로컬 상태 보드

Overview ▸ Local Health를 열면 “지금 고장 난 게 있는가?”라는 질문에 답하는 단일 화면이 나타납니다. 모니터링되는 모든 서비스, 기기, 하위 시스템이 UP 또는 DOWN으로 표시된 행으로 나타나며, 웹 및 데이터베이스 서비스, 플릿, 사이트 및 인증서, 디스크, UPS 및 SNMP 기기, 연결된 클라우드 계정 등 영역별로 묶입니다. 맨 위에는 X up / Y down 형식의 한 줄 요약이 있어서, 모든 행을 읽지 않고도 플릿 전체 상태를 한눈에 파악할 수 있습니다.

그룹은 접을 수 있지만, 실패한 항목이 있는 그룹은 자동으로 펼쳐집니다. 행의 기록 버튼을 선택하면 최근 30회 점검, 측정된 응답 시간 스파크라인, 24시간, 7일, 30일 동안 실제로 관측된 정확한 이동 가동 시간, 최근 상태 전환을 볼 수 있습니다. 각 가동 시간 값 옆에는 관측 범위가 표시됩니다. 앱이 꺼져 있던 시간, 일시 중지된 시간, 네트워크 밖에 있던 시간은 알 수 없음으로 처리되며, 정상으로 추정하지 않습니다. Fleet-wide Events는 최초 관측, 장애, 복구를 최대 1,000건까지 31일간 보존하며, 엔드포인트, 자격 증명, 응답 본문은 저장하지 않습니다.

이 보드는 AI 관리자가 get_server_health 도구로 읽는 것과 같은 데이터입니다. “무엇이 다운됐어?”라고 물으면 AI 관리자는 이 화면에 표시된 내용을 그대로 보고하고, 수정안을 제안하기 전에 조사를 제안합니다(13장 참조). 점검은 약 60초마다 실행되며, 각 DOWN 항목은 해당 항목을 소유한 패널에도 귀속됩니다. 그래서 사이드바 행과 Dock 아이콘에 빨간색 개수 배지가 나타날 수 있습니다. 문제가 있다는 사실뿐 아니라 문제가 어디에 있는지도 알 수 있습니다.

11.2알림 패널: 감시 대상

로컬 상태 보드는 상태를 보여 주고, 알림 패널(Overview ▸ Alerts)은 무엇을 메시지로 보낼 가치가 있는지 판단하고 전송합니다. “Monitor critical services and alert me”를 켜면 점검에서 알림이 발생하기 시작합니다. 감시 대상은 다음과 같습니다.

• 사이트 및 서비스 상태 — HTTP/루프백 점검, TCP 포트, 더 깊은 프로토콜 검사(SMTP/IMAP 로그인, 데이터베이스 SELECT 1, LDAP 바인드)를 수행하므로, 수신 대기 중이지만 실제로는 고장 난 서비스도 감지됩니다. MySQL 검사는 추가로 연결 풀(현재 사용량 대 max_connections, 그리고 “too many connections” 거부 카운터)을 읽습니다. 풀이 90%를 넘거나 점검 사이에 클라이언트가 거부되면 알림을 보내며, 모든 점검 결과는 데이터베이스 상태 패널에 Connection Health History로 차트화됩니다. 시간에 따른 풀 사용률(%)과 함께 거부 급증 및 장애가 빨간 선으로 표시됩니다.
• 연결된 서버 — 점검할 때마다 모든 플릿 호스트의 SSH 엔드포인트에 대한 연결 가능성을 확인하므로(로그인 시도 없이 TCP 연결만 수행), 완전히 꺼진 서버는 간단한 “Server down” 알림을 발생시키고, 복구되면 “Server recovered”를 보냅니다. 이는 호스트가 켜져 있지만 연결 속도를 제한하고 있을 때만 발생하는 SSH 쿨다운 알림과는 별개입니다.
• 인증서 및 도메인 — 플릿 전체의 TLS 만료와 함께 등록 기관/DNS/SSL 점검을 수행하여, 도메인이 만료되는 당일 아침이 아니라 며칠 전에 경고합니다(7장).
• 디스크 용량 부족 — 볼륨의 여유 공간이 임곗값 아래로 내려가면 아래의 디스크 상태 모니터를 통해 알립니다.
• 보안 노출 — 새로 열린 포트나 예상치 못한 수신 대기 프로세스, VPN 터널 끊김, 또는 SSH가 네트워크에서 접근 가능한 상태에서의 심각한 SSH 보안 강화 실패.
• 결제 실패 및 청구 — 연결된 유료 서비스(OpenAI, Anthropic, Cloudflare, Google Cloud)가 할당량 부족, 잔액 부족, 인증 오류를 반환하는 경우로, 카드가 만료되었다는 징후입니다.
• 연결된 클라우드 서비스 — Stripe, Shopify, Freshdesk, SendGrid 등의 실시간 모니터로, 선택한 지표가 임곗값을 넘으면 알림이 발생합니다.

대부분의 점검은 임곗값 기반이므로 무엇을 “문제”로 볼지 직접 정할 수 있습니다. 인증서 만료가 N일 이내로 다가왔을 때, 미해결 티켓이 특정 수를 넘었을 때, 디스크 사용률이 특정 비율을 넘었을 때 알리도록 설정할 수 있습니다. 보수적인 임곗값을 쓰면 사후 분석 대신 사전 경고를 받을 수 있습니다. 이 패널에는 “Alert on intrusions”도 있습니다. 새로운 fail2ban/CrowdSec 차단, 심각도 높은 Suricata 시그니처, 주목할 만한 Wazuh 알림(레벨 ≥ 7)이 발생하는 즉시 메시지로 전송되며, 기존 기록에 대해서는 다시 알리지 않습니다.

SwitchBot 기기. SwitchBot 기기를 고정하면 SwitchBot 클라우드를 통해 감시합니다. 플러그는 2분마다 읽으며 Wi-Fi 불안정 경고를 받습니다. 잠금장치, 센서, 커튼, Bot, 조명, Hub 2/3 등 상태를 보고하는 기기는 10분마다 읽으며, SwitchBot이 해당 기기나 연결된 허브가 오프라인이라고 보고하면 알림을 보냅니다. 카메라와 Hub Mini는 상태를 보고하지 않으므로 오프라인으로 표시되지 않습니다. SwitchBot의 하루 10,000회 호출 할당량을 넘지 않도록, 고정된 기기가 많으면 간격이 자동으로 늘어납니다. 할당량은 계정별이므로 각 계정의 예산은 따로 계산됩니다. 고정된 SwitchBot 기기의 점은 자체 상태 점검에 응답한 후에만 초록색이 되며, 아직 점검되지 않았거나 상태가 없으면 회색으로 남습니다. SwitchBot 패널에서 Receive SwitchBot webhooks를 켜고 인터넷 접근(Cloudflare Tunnel, Tailscale Funnel 또는 라우터 포워딩)을 설정하면, Indoor Cam과 Pan/Tilt Cam이 모션을 감지할 때마다 보고하며 이는 last active로 표시됩니다. Pan/Tilt Cam 2K와 Plus 모델은 웹훅을 보내지 않습니다. 조용한 카메라는 오프라인으로 보고되지 않습니다.

여러 SwitchBot 계정. 토큰은 자체 계정에 추가된 기기만 나열하므로, 다른 사람이 소유하고 공유해 준 집의 기기에는 그 사람의 토큰으로 접근합니다. SwitchBot 패널의 Other Accounts에서 추가하십시오. 각 기기에 대한 명령과 점검은 그 기기를 나열하는 계정을 사용합니다. SwitchBot API에는 방 개념이 없으므로, Group by는 기기를 연결된 허브별, 고정한 장소별, 또는 계정별로 정렬합니다.

11.3메시징 게이트웨이

알림은 받는 사람에게 도달해야 비로소 쓸모가 있습니다. 알림 패널에서는 여러 게이트웨이를 동시에 활성화하고 채널마다 여러 수신자를 지정할 수 있으므로, 담당자가 이미 열어 두고 있는 앱으로 알림을 보낼 수 있습니다. 봇 토큰이나 웹훅 URL을 붙여넣고 테스트를 보내면 바로 사용할 수 있습니다. AI 관리자는 get_messaging_channels로 활성화된 게이트웨이 목록을 확인하고 send_notification으로 이를 통해 메시지를 보낼 수 있습니다(13장).

11.17.1온콜 담당자 호출(PagerDuty, Opsgenie, 긴급 ntfy)

위의 메시지 게이트웨이는 보내고 끝나는 텍스트입니다. 호출 채널은 성격이 다릅니다. 상태를 유지합니다. 모니터링 중인 항목이 다운되면 FrontierStack은 해당 항목을 키로 하는 인시던트를 트리거합니다. 그러면 PagerDuty(Events API v2 라우팅 키) 또는 Opsgenie(GenieKey)가 에스컬레이션 정책을 실행하여, 누군가 확인할 때까지 온콜 담당자에게 푸시, 문자 또는 전화를 보냅니다. 항목이 복구되면 FrontierStack이 같은 인시던트를 자동으로 해결합니다. 인시던트가 항목별로 키가 지정되므로 상태가 계속 바뀌는 서비스는 순번 담당자를 반복해서 호출하는 대신 하나의 인시던트만 업데이트하며, 이미 끝난 장애 때문에 누군가를 깨우는 일도 없습니다. 온콜 서비스가 없다면 ntfy 게이트웨이의 Page on down 토글을 켜면 “다운” 알림을 ntfy 최고 우선순위로 보냅니다 — 많은 휴대폰의 무음 설정을 무시하는 더 크고 반복되는 알림음입니다 — 복구 알림과 보고서는 일반 우선순위로 유지됩니다. 각 호출 채널에는 Send Test Page 버튼이 있어 실제 인시던트를 트리거하고 약 10초 후 자동으로 해결하므로, 에스컬레이션 경로 전체가 처음부터 끝까지 동작하는지 확인할 수 있습니다.

11.17.2다른 사람에게 알리기: 연락처, 프리셋, 에스컬레이션

위의 채널은 사용자 본인에게 알립니다. 하지만 많은 인시던트는 다른 사람에게도 알려야 합니다. 이메일을 원하는 관리자, 두 번째 지원 담당자, 또는 현장에 가야 하는 기술자 등입니다. 알림 ▸ Contacts & Escalation은 이를 세 부분으로 처리합니다.

예를 들어 Email the supervisor, page the on-site tech 프리셋은 관리자에게 이메일을 보내고, 기술자에게는 문자와 함께 알림 내용을 소리 내어 읽어 주는 전화를 겁니다. Tech now, supervisor if not fixed in 30 min은 에스컬레이션입니다. 관리자 단계는 30분 후에도 항목이 여전히 다운 상태이고 아무도 Acknowledge를 누르지 않은 경우에만 실행됩니다. 대기 중인 에스컬레이션은 이 섹션과 알림 팔레트(Ack)에 표시되며, 항목이 복구되면 각각 자동으로 취소됩니다. 고장 소식을 받은 사람에게는 복구 소식도 전달됩니다. 좋은 소식으로 전화를 받는 사람은 없으므로 복구 알림은 문자로 보냅니다. 미리 만들어진 프리셋을 사용하려면 New Preset ▸ Start from a template을 선택하십시오. 아직 없는 역할마다 빈 연락처가 추가됩니다. 테스트는 지연 시간을 무시하고 모든 단계를 TEST 표시와 함께 한꺼번에 보냅니다. 고정된 카메라, 라우터 또는 기타 기기의 오프라인 알림 스위치에는 Who else gets this alert… 버튼이 있습니다. 본인 외에 누가 알림을 받는지 보여 주고, 해당 기기에 대한 규칙이 미리 채워진 상태로 이 섹션을 열어 주므로 프리셋만 고르면 됩니다.

연락처는 이미 설정한 게이트웨이를 사용하되, 본인 주소 대신 해당 연락처의 주소로 보냅니다. 관리자에게 보내는 이메일은 사용자의 SMTP 계정을 사용하고, 문자와 전화는 사용자의 Twilio 번호를 사용하며 이 번호는 음성 통화가 가능해야 합니다. 이러한 게이트웨이는 본인 알림용으로는 꺼 둔 상태로 두어도 됩니다. 각 메시지에는 연락처의 역할, 위치, 프리셋의 지시 사항이 포함되므로 받는 사람이 왜 받았는지 알 수 있습니다. 주소가 없거나 게이트웨이가 구성되지 않은 경우 Delivery Errors에 예를 들어 SMS → Alex (On-site technician)와 같이 표시됩니다. 네트워크 오류는 보고하기 전에 2분 간격으로 두 번 다시 시도합니다.

IFTTT. Messaging Channels에서 IFTTT (Webhooks)를 켜면 모든 알림마다 IFTTT 애플릿을 실행합니다. value1은 제목, value2는 메시지이며, value3은 다운 알림이면 critical, 그 밖에는 info입니다. 다운 알림에 별도의 이벤트 이름을 지정하면 복구 때보다 더 눈에 띄는 동작(예: 조명 깜박이기)을 트리거할 수 있습니다. 연락처마다 자체 Webhooks 키를 지정할 수도 있으므로, 프리셋 단계에서 그 사람의 계정에 있는 애플릿을 실행할 수 있습니다. IFTTT의 Webhooks 서비스를 사용하려면 IFTTT Pro 플랜이 필요합니다.

토큰과 웹훅은 macOS 키체인에 저장되며 Mac 밖으로 나가지 않습니다. 예약된 AI 평가 보고서를 보낼 수도 있습니다. AI 관리자가 실시간 모니터링 상태를 바탕으로(읽기 전용 진단 실행) 요약을 작성하여 매일 또는 매주 이메일로 보내거나 활성화된 모든 채널로 푸시합니다 — 중요 항목이 두 개 이상 동시에 다운되면 더 자세한 보고서를 보내도록 선택할 수도 있습니다.

11.4전달 오류와 해결 방법

알림이 조용히 전송에 실패한다면 모니터는 쓸모가 없습니다. FrontierStack은 모든 전송을 확인합니다. 게이트웨이가 실패하면 알림 패널의 Delivery Errors 섹션에 기록되며, 알기 쉬운 해결 안내와 그 아래의 원본 오류, 그리고 잘못 구성된 채널의 설정으로 바로 스크롤하는 Fix 버튼이 함께 표시됩니다. 사이드바의 알림 행과 Dock 아이콘에 빨간 배지가 나타나 확실히 눈에 띄며, 지울 때까지 남아 있습니다. AI 관리자도 get_alert_errors로 같은 목록을 읽으므로 “알림이 왜 오지 않지?”라고 물어보기만 하면 됩니다.

흔한 원인은 대개 사소하고 빠르게 고칠 수 있습니다.

11.5호스트 내 서비스 워치독 및 데이터베이스 상태

위의 모니터는 사용자의 Mac에서 실행됩니다. 중요한 서버라면 서버 자체에 상주하는 워치독도 있어야 Mac이 잠자기 상태이거나 오프라인이거나, 애초에 장애가 난 기기가 Mac이 아닐 때도 계속 동작합니다. FrontierStack의 서비스 워치독은 호스트 모니터와 함께 배포됩니다(8장). 짧은 간격으로 서비스 상태를 검사하고, 실패하면 재시작하며, — 최후의 수단으로, 그리고 사용자가 허용한 경우에만 — 기기를 재부팅합니다. 최소 간격 보호 장치가 있어 계속 고장 난 서비스가 부팅 루프를 일으킬 수 없습니다. 각 감시 항목에는 검사 유형이 있습니다. 프로세스 검사, HTTP 또는 TCP 프로브, 또는 전용 MySQL·PostgreSQL 검사입니다.

11.17.3고정된 서버의 복구 단계

고정된 서버의 서비스 워치독 패널에서는 일반적인 호스트 내 서비스 복구 이후에 선택적으로 두 단계를 추가할 수 있습니다. Reboot from FrontierStack을 켜면 새 Recovery exhausted 이벤트가 발생한 후 Mac이 검증된 재부팅을 한 번 실행합니다. 지연 시간은 사용자가 정합니다. 전원 제어에 제어 가능한 콘센트가 연결되어 있으면, 다음 단계로 서버가 지정한 시간 동안 완전히 응답하지 않을 때 전원을 껐다 켤 수 있습니다. FrontierStack은 재부팅을 시도한 후 90초를 기다린 다음 호스트 상태를 판단하며, 전원 타이머의 최솟값은 5분입니다.

강제 전원 차단 판정은 의도적으로 SSH 로그인 실패보다 엄격합니다. Mac의 네트워크 경로가 정상이어야 하고, 서버에서 SSH 응답, 정상적인 모니터 보고, ping 또는 ARP 흔적, 일반 서비스 포트의 응답이 모두 없어야 합니다. 조금이라도 살아 있다는 신호가 있으면 해당 인시던트는 취소됩니다. 전원 재투입은 한 번만 실행되고 그 후 복구 단계가 멈춥니다. 정책을 활성화하면 이전 워치독 이벤트는 처리됨으로 표시되며, watchdog_reboot_suppressed는 최종 상태로 유지되므로 앱이 헬퍼의 부팅 루프 보호를 무력화할 수 없습니다.

11.17.4Mac을 닫아도 계속 감시하기

먹통이 된 서버는 자신의 스마트 플러그를 안정적으로 조작할 수 없습니다. Recovery observer에서 등록된 다른 서버를 선택하면 마지막 단계를 그 기기의 헬퍼가 맡습니다. 옵저버는 FrontierStack이 닫혀 있어도 사설 IP, ping, 여러 TCP 포트로 대상을 계속 프로브합니다. 먼저 사설 전원 컨트롤러가 상태 요청에 응답하는지 확인하고, 루프 방지 영수증을 영구 저장한 다음, 설정된 유지 시간 동안 전원을 차단했다가 복원하며, 대상이 다시 살아난 것을 확인할 때까지 두 번째 전원 재투입은 하지 않습니다. 영구 저장되는 30분 쿨다운은 옵저버가 재시작되어도 유지됩니다.

데이터베이스 Heartbeat는 프로세스/포트 검사로는 놓치는 장애를 잡아냅니다. MySQL Heartbeat는 암호 없이 SELECT 1을 요청합니다. 성공하거나 “access denied”가 반환되면 MySQL이 응답했다는 증거이며, 연결이 거부되거나 시간 초과되거나 포화 상태이면 비정상입니다. MySQL 암호는 저장되지 않으며 어떤 테이블도 읽지 않습니다. 프로브 이름을 비워 두면 root가 아닌 fs_watchdog가 사용되며, 실제 계정일 필요는 없습니다. PostgreSQL Heartbeat는 데이터베이스 사용자 이름이나 암호 없이 pg_isready를 사용합니다. error-log early-warning을 켜면 워치독이 데이터베이스 자체의 오류 로그도 추적하여, 손상 징후를 처음 발견하는 즉시 심각 이벤트를 발생시킵니다. 이 모든 것이 서버에서 실행되므로 Mac이 꺼져 있어도 ntfy나 웹훅으로 자율적으로 알림을 보낼 수 있습니다. 호스트의 서비스 워치독 패널에서 Alert me directly from this server로 켜십시오.

검사 전용 계정을 만들려면 your_database와 예시 암호를 바꾸십시오.

CREATE USER 'frontierstack_health'@'localhost' IDENTIFIED BY 'use-a-unique-random-password';
GRANT SELECT ON `your_database`.* TO 'frontierstack_health'@'localhost';

이 로그인 정보를 데이터베이스 상태에 저장하십시오. 수동 검사와 검증된 백업이 모두 성공할 때까지 자동 복구는 꺼 두십시오. 완전한 백업이나 복구에 다른 권한이 필요하면 MySQL이 지정하는 스키마 범위의 권한만 추가하고, *.*는 절대 사용하지 마십시오. 다른 기기에서 연결하는 모니터의 경우 localhost를 그 기기의 정확한 사설 주소 하나로 바꾸십시오.

고정된 서버의 Services 행에는 예약된 테이블 검사나 서버 자가 복구가 활성화되어 있으면 녹색 DB checker: On 점이, 대상은 있지만 둘 다 실행되고 있지 않으면 Paused가 표시되며, 선택한 MySQL 검사에 데이터베이스 암호가 없으면 녹색 대신 주황색 Needs login이 표시됩니다. 데이터베이스 상태와 Heartbeat는 서로 보완합니다. 전자는 더 느린 일정으로 테이블을 검사하고, 후자는 장애를 빠르게 감지하여 서버에서 MySQL을 재시작할 수 있습니다.

데이터베이스가 다운되지는 않았지만 느리거나 멈춘 경우에는 데이터베이스 상태 패널의 각 대상에 있는 Why slow/stuck? 버튼이 필요할 때 원인을 알려 줍니다. 서버의 실시간 활동(MySQL에서는 SHOW FULL PROCESSLIST, PostgreSQL에서는 pg_stat_activity)을 읽고, 실행 중인 쿼리를 형태별로 묶어 같은 쿼리가 몰려 들어오면 개수와 함께 한 줄로 합친 다음, 판정을 제시합니다 — 단일 쿼리가 집중적으로 호출됨, 오래 실행되는 쿼리가 다른 쿼리를 차단함, 연결이 잠금을 기다림, 지나치게 큰 결과 집합이 클라이언트로 스트리밍됨(대역폭 비용), 또는 연결 수가 상한에 가까움 등입니다. 유용한 세부 사항이 하나 있습니다. 부하가 간헐적으로 몰리는 경우 급증 사이에는 유휴 상태로 보일 수 있는데, 이때 도구는 문제없음이라고 잘못 보고하지 않고 그 사실을 밝히며 급증 중에 다시 실행하라고 안내합니다. 원격 대상은 SSH로 프로브하므로 데이터베이스 포트를 노출할 필요가 없습니다.

11.17.5유지 보수를 위한 검사 일시 중지

서비스를 의도적으로 내리는 중에 이것저것 재시작하는 워치독은 가장 원치 않는 존재입니다. 보호 기능을 끄고 — 다시 켜는 것을 스스로 기억해야 하는 — 대신, Guardian 헤더의 Pause Checks… 또는 개별 서비스 행의 일시 중지 버튼을 사용하십시오. 15분에서 하루까지 기간을 선택할 수 있습니다.

일시 중지 중에는 Guardian이 일시 중지한 대상의 상태 검사와 재시작을 멈추므로 작업이 방해받지 않습니다. 아무것도 비활성화되지 않으며 설정도 사라지지 않습니다. Keep Alive, Auto Recover, 임계값, 간격은 모두 그대로 유지되며, 기간이 끝나면 — 또는 Resume Now를 누르면 즉시 — 검사가 자동으로 재개됩니다. 앱을 종료했다가 다시 열더라도 일시 중지가 정해진 기간을 넘어 유지되는 일은 없습니다.

11.6사례 연구: High Sierra Server.app의 serviceproxy 먹통 현상

High Sierra에서 macOS Server(Server.app)를 아직 실행 중인 오래된 Mac에는 잘 알려진 장애가 있습니다. 실제 백엔드 앞에서 포트 80/443을 바인딩하는 웹 프런트 프록시 — launchd 작업 com.apple.serviceproxy — 가 가끔 먹통이 됩니다. TCP 연결은 계속 받아들이지만 응답하지 않으므로, 프로세스 검사는 모두 정상으로 보이는데도 그 뒤의 모든 웹 사이트가 먹통이 됩니다. Apple의 수정은 없으며 이 스택은 지원이 종료되었습니다. 서비스 워치독은 바로 이 사례를 염두에 두고 만들어졌습니다.

감시 설정 방법. 서버 패널에서 서비스 이름 serviceproxy에 대한 워치독 항목을 추가하고 — 이것이 중요합니다 — 프로세스 검사가 아니라 대상이 http://127.0.0.1/인 HTTP 검사를 지정하십시오. 실제 장애(연결은 수락되지만 응답 없음)를 감지하는 것은 HTTP 프로브뿐입니다. 실패하면 워치독이 launchctl kickstart로 복구하는데, 이는 관리자가 직접 입력하는 수동 해결책과 정확히 같습니다. 500 미만의 HTTP 상태는 모두 살아 있는 것으로 간주합니다(프록시가 반환하는 403/404도 응답하고 있다는 증거입니다). 각 프로브는 6초 후 시간 초과되므로 먹통이 된 프록시는 시간 초과로 검사에 실패합니다. 프록시 뒤의 백엔드도 같은 방식으로 server-httpd로 감시할 수 있습니다.

잘 동작하는 타이밍. 30초마다 검사하고, 3회 연속 실패하면 재시작하며, 재시작은 최대 3회까지 시도하고, 재시작 후 유예 시간은 기본값(약 20 초, 오래된 하드웨어의 Apache에도 충분한 여유)으로 두십시오. 이렇게 하면 조치하기 전에 약 90 초 동안 먹통 상태를 확인합니다 — 한 번의 느린 응답이나 순간적인 부하 급증으로 kickstart가 실행되지 않을 만큼 길고, 실제로 먹통이 된 후 약 2분이면 손대지 않아도 사이트가 복구될 만큼 짧습니다. 사이트가 매우 중요하다면 15–20 초 간격에 2회 실패(확인까지 ≈40 초)로 줄이십시오 — 그보다 더 줄이면 대부분 잘못된 재시작만 늘어납니다. 실제로 느린 오래된 기기는 부하가 걸리면 응답하는 데 몇 초가 걸릴 수 있기 때문입니다. 기기가 정말로 무인 상태가 아니라면 “Reboot the server if recovery still fails”는 끈 상태로 두십시오. 실제로는 kickstart로 먹통 현상이 해결되며, 이런 기기에서 최후 수단으로 재부팅하면 대부분 다운타임만 늘어납니다(어떤 경우든 부팅 루프 방지 장치가 워치독 재부팅 사이에 최소 30 분 간격을 강제합니다).

프로세스 검사를 쓰지 않는 이유는? serviceproxy라는 이름의 프로세스는 없습니다 — 이 작업은 특수한 구성의 httpd로 실행됩니다 — 그래서 v1.6.1 이전의 모니터는 정상적인 프록시를 계속 “다운”으로 판단하여 반복해서 재시작했고, 재부팅 에스컬레이션이 허용된 경우에는 정상적인 기기를 주기적으로 재부팅했습니다. v1.6.1부터는 모니터가 대신 launchd에 작업의 실제 상태를 묻기 때문에 이제 프로세스 검사도 정확한 결과를 알려 주지만, 실제 먹통 현상을 잡아내는 것은 여전히 HTTP 검사입니다. 오래된 서버가 뚜렷한 원인 없이 재부팅되고 있었다면 먼저 모니터 버전을 확인하십시오 — 또한 “Why did it reboot?”는 워치독이 시작한 재부팅을 명시적으로 구분해 알려 줍니다(v1.6+ 모니터에서는 이유와 함께 표시되며, 이전 모니터는 기록을 남기므로 그것도 보고됩니다).

전달 측면에서 한 가지 보장으로 마무리합니다. 알림은 절대 조용히 사라지지 않습니다. 메시징 게이트웨이와 별개로, 모든 상태 변경 알림은 게이트웨이와 무관하게 macOS 네이티브 알림 및 푸시도 발생시킵니다 — 따라서 이메일을 끄고 모든 채널을 비활성화해도 서비스가 다운되면 Mac에서 여전히 알 수 있습니다. 데이터베이스 복구 — mysqlcheck/pg_amcheck 실행과 AI 안내에 따른 재구축 — 는 5장에서 다룹니다.

11.7인시던트, 온콜 및 상태 페이지

이미 정식 인시던트 대응 체계를 운영하는 팀이라면 FrontierStack은 사용 중인 도구를 대체하지 않고 그 도구와 연결됩니다. 각 도구에는 카탈로그 항목에서 열 수 있는 라이브 패널이 있으며, 읽기 전용 API 키를 붙여넣으면 현재 상태가 표시됩니다.

• 인시던트 관리 & 온콜 — PagerDuty(열린 인시던트와 긴급도 높은 인시던트, 현재 온콜 담당자, 서비스), Opsgenie(열린 알림/확인되지 않은 알림, US/EU 리전 전환 포함), incident.io 및 Rootly(진행 중인 인시던트).
• 상태 페이지 — Statuspage(해결되지 않은 인시던트와 다운된 구성 요소) 및 Better Stack(모니터 업 / 다운 / 일시 정지).

각 패널에서 키를 설정하면(예: PagerDuty ▸ Integrations ▸ API Access Keys) 패널이 연결을 확인합니다. 이 정보는 같은 모니터링 화면에 반영되므로 열려 있는 PagerDuty 인시던트나 다운된 상태 페이지 구성 요소가 자체 상태 정보와 나란히 표시됩니다.

11.8SaaS 라이브 모니터 & 프로젝트 관리 패널

FrontierStack은 인프라에서 멈추지 않습니다. 설정 기반 SaaS 라이브 모니터는 연결된 클라우드 계정을 감시하며 몇 분마다 새로 고칩니다. 각 서비스에는 자격 증명 양식, 라이브 지표 타일, "Alert me" 토글과 임계값이 있습니다. 알림을 발생시킬 수 있는 서비스는 지표가 임계값을 넘으면 DOWN 알림을 발생시키고, 나머지 서비스는 연결 가능 여부를 감시합니다. 라이브 모니터 대상으로는 Stripe(응답이 필요한 분쟁, 잔액), Shopify 및 WooCommerce(미처리 주문), Freshdesk 및 Zammad(열린/보류 중/기한 초과 티켓), SendGrid, Mailgun 및 Postmark(반송 및 차단), GitHub Copilot(비활성 시트), 그리고 ID 제공업체 Okta와 Microsoft Entra ID가 있습니다. 서비스를 고정하면 알림 설정과 관계없이 항상 로컬 상태에 표시됩니다.

엔지니어링 및 컴플라이언스 서비스도 같은 방식으로 다룹니다. Sentry(최근 24 시간 동안 새로 발생한 미해결 이슈), Grafana 및 Grafana Cloud(발동 중인 알림 규칙), Honeycomb(발동된 트리거), New Relic(활성 이슈), Make(유효하지 않은 시나리오와 완료되지 않은 실행), MongoDB Atlas(열린 알림), Vanta 및 Drata(실패한 컴플라이언스 테스트), CircleCI 및 Buildkite(최근 24 시간 동안 실패한 빌드), Netlify 및 Render(최신 배포가 실패한 사이트 또는 서비스)입니다. 각각 읽기 키만 있으면 되며, 어떤 권한을 부여해야 하는지는 패널에 표시됩니다.

Ahrefs(API v3, Lite 플랜 이상)는 할당량을 소비하지 않고 감시합니다. 모니터는 무료 사용량 엔드포인트만 읽고 이번 달 API 유닛이 90%를 넘으면 알림을 보내며, 도메인을 지정하면 하루에 한 번 Domain Rating을 가져옵니다.

GMO 그룹의 서비스에도 전용 모니터가 있습니다. Color Me Shop(カラーミーショップ)은 developer.shop-pro.jp에서 등록한 앱의 OAuth 토큰으로 오늘, 이번 주, 이번 달의 매출을 읽어 판매 채널 대시보드에 반영하고, 발송 대기 주문이 쌓이면 알림을 보냅니다. GMO Trust Login은 SCIM 엔드포인트로 확인합니다. Entra ID가 이미 사용하는 항목에서 자격 증명을 생성하면 그 동기화가 끊기므로 모니터 전용 SCIM IDP 항목을 만드십시오. GMO Aozora Net Bank는 계좌 잔액을 보여 주고 엔화 잔액이 하한 아래로 내려가면 알림을 보낼 수 있습니다. OAuth 클라이언트 ID, 시크릿, 갱신 토큰이 있으면 30일짜리 액세스 토큰을 스스로 갱신하며, 무료 sunabar 샌드박스에서 먼저 시험해 볼 수 있습니다. GlobalSign은 키가 필요 없으며 Atlas ACME 디렉터리, GlobalSign 상태 페이지, 도메인의 실제 인증서를 감시합니다.

전용 GitHub 패널에는 계정 및 저장소 합계, Actions 관련 작업, PR, 요청된 리뷰, 할당된 이슈, 읽지 않은 알림, 남은 API 요청 수, 그리고 가장 최근에 업데이트된 저장소 5개의 릴리스 애셋 다운로드 수가 추가로 표시됩니다. Installed app permissions 섹션은 지정한 GitHub App을 감시하며(GitHub은 토큰으로 이 목록을 조회할 수 없게 합니다), 앱이 마지막으로 검토한 것보다 많은 접근 권한을 요청하면 — 새 권한, 읽기 전용에서 읽기 & 쓰기로의 상향, 새 소유자 — 보안 알림을 발생시킵니다. 이 섹션은 읽기 전용이며, 수락 또는 거절은 github.com에서 해야 합니다. Anthropic 계정/모델 모니터링과 GitHub Copilot 시트 사용량에는 해당 API 자격 증명만 필요하며, 클라우드 전용 서비스에 임의의 호스트나 포트를 만들어 내지 않습니다.

AppSignal에는 전용 읽기 전용 라이브 연결이 있습니다. 애플리케이션 ID와 개인 API 토큰을 입력하십시오. 토큰은 키체인에 저장되며, FrontierStack은 AppSignal의 GraphQL API를 사용해 열린 오류 인시던트, 활성 가동 시간 알림, 최신 배포, 그리고 제공되는 최근 1시간의 오류/지연 시간 지표를 표시합니다. 알림 임계값은 열린 인시던트와 가동 시간 알림을 합산합니다. AppSignal은 API 토큰을 GraphQL URL에 포함하도록 요구하므로 FrontierStack은 이 URL을 비공개로 구성하며 인증 정보가 포함된 URL을 로그에 기록하지 않습니다. 더 깊이 조사하려면 MCP Servers에서 AppSignal 프리셋을 추가하십시오. 이 프리셋은 버전이 고정된 OAuth 브리지를 통해 AppSignal의 호스팅 MCP를 열며, 모니터링 토큰을 AI 클라이언트로 복사하지 않습니다. 쓰기 가능한 도구를 검토하기 전까지는 AppSignal 접근을 읽기 전용으로 유지하십시오.

Paessler PRTG에는 자체 호스팅 PRTG 코어와 PRTG Hosted Monitor 모두를 위한 전용 라이브 연결이 있습니다. PRTG 서비스를 열고 HTTPS 기본 URL을 입력한 다음, Setup ▸ Account Settings ▸ API Keys에서 Read access 스크립팅 키를 생성하십시오. FrontierStack은 키를 키체인에 저장하고, 크기가 제한된 센서 상태 표를 읽어 Up, Down, Warning, Paused 및 기타 센서 합계를 표시합니다. Alert me when this needs attention을 켜면 Down 센서와 연결된 프로브가 없는 센서가 알림으로 전달됩니다. 이 통합은 알람을 확인 처리하거나 기기, 센서, 프로브를 변경하지 않습니다. PRTG Network Monitor와 Enterprise Monitor는 코어 서비스를 Windows에서 실행하므로 연결된 Windows 서버와 제공업체 설치 프로그램을 사용하거나 Hosted Monitor를 사용하십시오. 원격 Windows 프로브와 멀티 플랫폼 프로브를 사용하면 플릿의 나머지 부분까지 수집 범위를 넓힐 수 있습니다.

NinjaOne, Atera, Site24x7에도 전용 읽기 전용 라이브 연결이 있습니다. NinjaOne은 Monitoring 범위를 가진 Client Credentials 애플리케이션을 사용해 기기, 오프라인 엔드포인트, 활성 알림, 실행 중인 작업을 요약합니다. Atera는 Agents와 Alerts로 제한된 대상 API 키를 사용합니다. Site24x7은 계정이 속한 리전 데이터 센터에서 읽기 범위의 Zoho 갱신 토큰을 교환하고 현재 모니터 상태를 읽습니다. 이들의 비밀 값은 키체인에 보관되고 응답 크기는 제한되며, 어떤 연결도 엔드포인트에 패치를 적용하거나, 작업을 실행하거나, 알림을 닫거나, 유지 관리를 시작하거나, 제공업체 설정을 변경하지 않습니다.

같은 패턴으로 프로젝트 관리 도구에도 토큰 로그인 방식의 라이브 패널이 제공됩니다. Jira(열린 / 미할당 / 차단됨 / 스프린트 내 건수), Linear, monday.com, OpenProject, Plane, Taiga입니다. 이들은 알림 소스라기보다는 대시보드이지만, 팀의 작업량을 그 작업을 실행하는 서버와 같은 윈도우에서 보여 줍니다. 이메일 전송에는 트랜잭션 메일 제공업체 지표와 SPF/DKIM/DMARC 검사를 결합한 별도의 통합 Email Delivery 패널이 있습니다(7장).

11.9큐 운영

Queue Operations는 RabbitMQ, Kafka, NATS/JetStream, Redpanda, AWS SQS, Azure Service Bus, Google Pub/Sub, Celery/Flower, Redis Streams, Apache Pulsar, Apache RocketMQ를 위한 읽기 전용 대시보드입니다. 브로커, 네임스페이스 또는 클라우드 계정마다 모니터를 하나씩 추가하십시오. FrontierStack은 제공업체가 노출하는 경우 큐 또는 컨슈머 그룹 이름, 대기 및 처리 중 메시지 수, 컨슈머 수, 지연(lag), 데드 레터 수, 가장 오래된 메시지의 경과 시간을 표시합니다. 메시지 본문은 절대 읽거나 저장하지 않습니다.

클라이언트 포트와 관리 포트는 구분됩니다. 예를 들어 RabbitMQ 클라이언트는 5672에서 AMQP를 사용하고 관리 API는 보통 15672를 사용합니다. NATS 클라이언트는 4222를 사용하고 모니터링은 보통 8222를 사용합니다. Pulsar 클라이언트는 6650을 사용하고 HTTP 관리 API는 8080을 사용합니다. 모니터링 엔드포인트는 비공개로 유지하십시오. 호스트에 설치된 FrontierStack 모니터를 통하지 않고 대시보드에 접근하는 경우에는 항상 TLS와 모니터링 전용 계정을 사용하십시오.

연결된 서버의 경우 설치된 모니터를 선택하면 FrontierStack이 서명된 연결을 통해 자격 증명이 없는 헬퍼에게 크기가 제한된 요약을 요청합니다. 클라우드 제공업체는 일반적인 로컬 CLI 프로필 또는 키체인에 저장된 범위 제한 자격 증명을 사용합니다. 위험 임계값은 알림 점검에 포함되고, 동일하게 정리된 요약을 iPhone/iPad 앱에서도 볼 수 있으며, AI 관리자는 읽기 전용 get_server_health 도구를 통해 큐 상태에 관한 질문에 답할 수 있습니다. 대시보드에는 퍼지, 삭제, 게시, 확인 처리, 재생 작업이 없습니다.

11.10UPS 모니터링 및 SNMP 기기

배터리 백업 모니터링에는 전원 제어를 열고 UPS 섹션을 사용하십시오. FrontierStack은 USB UPS 기기를 macOS 전원 소스에서 직접 읽고, upsc로 NUT를 조회하며, apcaccess로 apcupsd를 통해 APC 기기를 조회합니다. 이 경로들은 Liebert 모델을 포함한 APC, Eaton, CyberPower, Vertiv는 물론 macOS 또는 NUT가 지원하는 기타 기기를 포괄합니다. NUT는 시리얼 및 네트워크 UPS 기기도 노출할 수 있습니다.

NUT는 무료 오픈 소스 소프트웨어이며 구독이 필요하지 않습니다. 상태 읽기에는 API 키가 필요하지 않으므로 NUT 서비스 패널에는 의도적으로 API 자격 증명 카드나 플랜 & 비용 카드가 없습니다. 전용 NUT 명령 로그인은 검토된 UPS 제어를 사용하기로 선택한 경우에만 필요하며, 유료 지원이나 호스팅 대시보드는 별도의 제품입니다.

같은 패널에서 전원 전환이 가능한 Raritan / Legrand Xerus PDU도 지원합니다. 사설 HTTPS 주소, 콘센트에 인쇄된 번호, 그리고 콘센트 제어로 권한이 제한된 전용 계정을 추가하십시오. 암호는 키체인에 보관됩니다. FrontierStack은 정확한 콘센트 상태와, 있는 경우 실제 유효 전력 센서 값을 읽고, On과 Off를 지원하며, Cycle에는 Xerus의 원자적 cyclePowerState 메서드를 사용합니다. 공인 주소, 내장된 자격 증명, 리디렉션, 임의의 JSON-RPC 메서드는 거부합니다. Off와 Cycle은 매번 새로운 파괴적 작업 확인을 표시하며, AI 하네스에도 같은 확인 게이트가 적용됩니다.

각 행에는 해당 모델이 제공하는 측정값이 표시됩니다. 충전량, 예상 배터리 런타임, 부하, 와트 단위의 유효 전력, 입력 및 출력 전압, 배터리 전압, 주파수, 온도입니다. UPS가 보고하는 와트 값은 그대로 표시됩니다. 기기가 정격 유효 전력과 부하율은 보고하지만 현재 와트 값은 보고하지 않는 경우, FrontierStack은 추정으로 표시된 값을 보여 줍니다. 볼트암페어를 와트로 취급하지 않습니다.

알림을 켠 다음 충전량, 런타임, 부하 임계값을 설정하십시오. 상용 전원 상실, 런타임 부족, 충전량 부족, 높은 부하, 배터리 서비스 경고, 강제 종료, 통신 두절은 각각 따로 추적됩니다. 따라서 런타임 감소 알림이 기존 정전 알림에 가려지지 않고 첫 번째 배터리 전환 알림 이후에도 도착할 수 있습니다. 연결이 끊긴 장치는 Comms lost로 계속 표시됩니다. UPS를 고정하면 전체 상태가 로컬 상태와 장소 지도에 유지됩니다. NUT 및 apcupsd 설치 버튼으로 필요할 때 이러한 선택적 도구를 추가할 수 있습니다.

이제 배터리 종료 규칙으로 질서 있는 종료 절차 전체를 수행할 수 있습니다. UPS가 지정한 시간 동안 배터리로 동작하거나 충전량이 임계값 아래로 떨어질 때까지 기다린 다음, 지정한 관리 서비스와 VM 서비스를 순서대로 중지하고, 각 중지를 확인한 뒤, 마지막으로 보호 대상 호스트를 종료합니다. 확인에 실패하면 호스트가 계속 실행 중인 상태로 단계 진행이 멈추고, 상용 전원이 돌아오면 완료되지 않은 단계는 취소됩니다. 호스트에서 PowerChute Network Shutdown이 실행되어야 하는 경우, FrontierStack은 일반적인 서비스 이름을 감지하거나 수동 선언을 받아들일 수 있으며, 그것이 사라지면 별도로 알림을 보내고 설정된 대체 동작을 중지하거나 계속할 수 있습니다.

스캔은 NUT와 apcupsd의 응답을 기다립니다. 스캔이 진행되는 동안 중지를 누르면 대기를 포기하고, 이미 찾은 측정값은 유지하며, 새로 고침을 누를 때까지 자동 새로 고침을 일시 정지합니다.

서버나 일반 고정 기기의 Power 섹션에는 별도의 설정 대화상자가 두 개 있습니다. Add power control…은 전원 전환 경로용입니다. SwitchBot Plug, 설정된 Home Assistant, Shelly, Tasmota, 사설 HTTP, Raritan PDU, Anker SOLIX, TP-Link Tapo / Kasa 또는 Smart Life / Tuya 콘센트, 명령 기반 PDU, 또는 전원 제어가 가능한 Remote KVM이 여기에 해당합니다. 이 대화상자에서 SwitchBot, Home Assistant, Anker SOLIX, TP-Link Kasa/Tapo 제공업체 패널로 바로 이동할 수도 있으며, 전원 제어에서 기본 설정되는 제공업체는 전원 제어에서 열립니다. Add backup power…는 고정된 모니터링 대상 UPS, Mini DC UPS, 또는 Unmanaged / dumb UPS용입니다. PDU는 컨트롤러로 취급하십시오. 전원 제어에서 모든 물리적 콘센트에 인쇄된 번호를 지정한 다음, 서버나 기기에 대해 이름과 번호가 붙은 해당 콘센트를 선택하십시오. 고정된 PDU는 명령 기반 제어용으로도 제공되며, 이 경우 정확한 콘센트 번호와 명령을 서버의 Power 섹션에 직접 입력합니다. SwitchBot 리모컨과 센서는 제외됩니다. 보호 대상 기기에는 스마트 플러그와 일반(dumb) UPS가 모두 있을 수 있습니다. Smart Plug로 표시된 기기는 그 자체가 전원 컨트롤러이므로, 해당 패널에서는 다른 컨트롤러를 제안하지 않고 Power 섹션 전체를 생략합니다. 연결된 모니터링 대상 UPS는 실제 배터리, 런타임, 경고 상태를 제공합니다. 관리되지 않는 선택 항목은 제조사와 모델 메모만 받고 인벤토리 전용으로 남으므로, FrontierStack과 AI 하네스는 지어낸 측정값이나 제어를 노출하지 않습니다. TREEDIX는 5 V Raspberry Pi UPS 컨트롤러용 Mini DC UPS로 사용할 수 있습니다.

스마트 플러그 브랜드. TP-Link Tapo 및 Kasa 플러그와 멀티탭은 전원 제어에서 TP-Link Tapo / Kasa로 추가하며 로컬 네트워크에서 전환됩니다. 플러그의 주소와 설정에 사용한 TP-Link ID를 입력한 다음 Find outlets를 선택하십시오. 멀티탭의 각 콘센트는 별도의 항목이 됩니다. TESSAN, BN-LINK, Edison Smart, OHMAX, MEAPUXIN 플러그와 멀티탭은 화이트 라벨 Tuya 기기입니다. Smart Life 패널을 연결한 다음 Smart Life / Tuya 콘센트를 추가하고 기기와 콘센트를 선택하십시오(브랜드 자체 앱에서 설정한 플러그는 먼저 Smart Life에 다시 추가해야 합니다). Smart Life 전원 사이클은 콘센트 자체의 카운트다운도 시작하므로, 해당 콘센트가 라우터에 전원을 공급하더라도 다시 켜집니다. Onvis 및 Matter Amazon Basics 플러그는 Home Assistant의 Matter 통합에 공유한 뒤 Home Assistant 스위치를 추가하여 제어합니다. 모든 세대의 Shelly 플러그(Gen 1 릴레이 API 및 Gen 2/3/4 RPC)는 직접 전환됩니다.

콘센트 연결 가능 여부. 전원 제어에서 콘센트를 편집하고 Alert when this outlet is unreachable을 켜십시오. FrontierStack은 읽기 전용 프로브로 2분마다 콘센트를 확인하고, 2회 연속으로 응답이 없으면 알림을 보냅니다. 이 확인은 이 Mac이 콘센트가 마지막으로 응답했던 것과 같은 물리적 네트워크(라우터의 하드웨어 주소로 식별)에 있을 때만 수행됩니다. 집 밖에 있는 노트북이나 같은 주소를 재사용하는 네트워크에 있는 Mac이 플러그가 죽었다는 잘못된 알림을 받는 일은 없습니다. 이 Mac에서 접근할 수 없는 플러그에는 Shelly Cloud 패널(IoT)을 사용하십시오. Shelly 앱에서 인증 클라우드 키와 서버 주소를 붙여넣고, 각 기기 ID를 추가한 다음, 오프라인 알림을 받으려면 벨을 켜십시오. Shelly를 두 가지 방식으로 모두 감시하는 경우, 해당 네트워크에 있는 동안에는 로컬 확인이 우선합니다.

11.17.6번호가 매겨진 PDU 콘센트에 기기 연결하기

1. 전원 제어에서 사용할 물리적 PDU 소켓마다 콘센트 레코드를 하나씩 추가하십시오. 알아보기 쉬운 이름을 지정하고 해당 소켓 옆에 인쇄된 번호를 입력하십시오. 예: Rack server · Outlet 4.
2. 고정된 서버나 기기를 열고 Power를 펼친 다음 Add power control…을 선택하십시오. 설정된 콘센트가 이름과 물리적 번호로 표시됩니다. 해당 기기에 전원을 공급하는 정확한 콘센트를 선택하십시오.
3. 설정된 콘센트가 없으면 Add a smart plug or PDU in Power Control…을 선택하십시오. FrontierStack이 설정 패널을 열어 컨트롤러의 사설 IP 주소나 URL을 입력하고 콘센트를 추가할 수 있게 합니다. 빈 PDU 연결은 만들지 않습니다.
4. 주소가 있는 PDU가 이미 고정되어 있지만 FrontierStack 기본 콘센트 통합이 없는 경우, Command-based PDU / powerboard에서 해당 PDU를 선택하십시오. 서버의 Power 섹션에 해당 기기의 콘센트 번호와 검토된 On 및 Off 명령을 입력하십시오. 명령은 선택 메뉴가 아니라 그곳에서 설정합니다.
5. UPS에 대해서는 별도로 Add backup power…를 선택하십시오. 고정된 UPS는 기기의 백업 전원을 나타내므로 그곳에 표시되며, 전원 전환이 가능한 PDU 콘센트가 아닙니다.

개별 콘센트를 식별할 수 있는 경우에는 서버를 PDU 전체에 연결하지 마십시오. FrontierStack은 행 레이블과 파괴적 작업 확인에 콘센트 번호를 포함하므로, 운영자는 Off 또는 Cycle 작업 전에 물리적 소켓을 확인할 수 있습니다.

11.11원격 KVM 플랫폼과 전원

Remote KVM 패널은 여러 대의 PiKVM, JetKVM, TinyPilot, NanoKVM, Raritan Dominion, ATEN, Vertiv Avocent, Lantronix Spider/SpiderDuo, Adder, GL.iNet, AWERAY 및 일반 KVM-over-IP 장비를 기록합니다. 각 레코드는 정확한 모델이나 펌웨어를 보관하고, 고정할 수 있으며, 비공개 브라우저 콘솔을 엽니다. AWERAY 레코드는 선택한 컴패니언 앱을 실행합니다.

전원 제어는 검토된 경로가 설정된 경우에만 제공됩니다. PiKVM은 문서화된 로컬 ATX API를 사용하며, 하드 작업을 보내기 전에 ATX가 활성화되어 있고 유휴 상태이며 예상한 현재 상태인지 확인합니다. JetKVM은 정확한 기본 토픽 하나로 공유 MQTT 연결을 사용합니다. 짧게 또는 길게 누르기 전에 보존된 ATX 상태를 읽고, DC 확장은 명시적인 ON 및 OFF 메시지를 사용합니다. 명령은 QoS 1을 사용하며 보존되지 않습니다. TinyPilot과 NanoKVM의 전원 하드웨어, 그리고 엔터프라이즈 제공업체의 PDU 통합은 모델과 펌웨어마다 다르므로, 명시적인 사설 엔드포인트가 제공되지 않는 한 해당 레코드는 콘솔/인벤토리 전용으로 남습니다. Dominion 대상과 연결된 Raritan PDU는 전원 제어의 검토된 Xerus 항목을 사용해야 합니다. KVM Off와 Cycle은 패널과 AI 하네스 모두에서 매번 새로운 확인이 필요합니다.

11.12Home Assistant 엔티티 모니터 (Beta)

이미 Home Assistant로 건물을 관리하고 있다면 FrontierStack이 Home Assistant가 보는 것을 감시할 수 있습니다. Home Assistant 서비스 패널을 열고 URL과 장기 액세스 토큰을 입력하면 Entity Monitors 섹션이 나타납니다. Load Entities from HA를 누르고 엔티티를 선택한 다음 규칙을 지정하십시오. 온도, 습도, 전력 측정값에는 숫자 규칙(is above / is below)을, 바이너리 센서의 on/off, wet/dry, home/not_home 상태에는 텍스트 규칙(equals / is not)을 사용합니다. 각 감시 항목은 일반 알림이 되어 평소의 점검 주기에 확인됩니다.

기기로 고정할 수 없는 센서에 적합한 곳이 바로 여기입니다. 서버실 바닥 아래의 Zigbee 누수 센서, 랙의 Z-Wave 도어 접점, Bluetooth 온도계 — 이들 중 어느 것도 IP 주소가 없으므로 ping을 보낼 수 없습니다. Home Assistant는 이미 이들의 프로토콜을 지원하므로 측정값은 Home Assistant를 통해 들어옵니다. Home Assistant 2026.9의 공유 Modbus 버스 접근은 같은 개념을 태양광 인버터, PDU, 전력량계로 확장합니다. 두 제품이 하나의 시리얼 연결을 놓고 다투는 대신 HA가 버스를 폴링하고 FrontierStack은 이름이 지정된 값을 읽습니다.

의도적으로 설계된 동작이 두 가지 있습니다. unavailable 또는 unknown을 보고하는 엔티티는 건너뛰지 않고 알림을 발생시킵니다 — 조용해진 누수 센서야말로 반드시 알아야 할 대상이기 때문입니다. 그리고 모니터는 구조적으로 읽기 전용입니다. Home Assistant의 서비스 API를 호출하지 않으므로 건물 상태를 읽을 수는 있지만 조명을 켜고 끄거나, 문을 열거나, 밸브를 열 수는 없습니다. 전환은 모든 작업이 명시적이고 확인을 거치는 전원 제어에서만 이루어집니다.

사용할 수 없는 기기. 엔티티를 하나씩 감시하는 대신 Alert when any device becomes unavailable을 켜십시오. FrontierStack은 1분마다 선택한 도메인의 모든 엔티티를 읽고 Home Assistant가 unavailable로 표시한 엔티티가 있으면 알림을 보냅니다. 단순히 unknown(아직 값이 없음)인 엔티티는 포함되지 않으며, Home Assistant 자체에 접근할 수 없는 동안에는 어떤 것도 오프라인으로 보고되지 않습니다. Alert after(기본값 10분)는 짧은 순단과 HA 재시작으로 인한 알림을 억제합니다. 많은 엔티티가 한꺼번에 실패하면(30% 초과 또는 50개 초과) 수십 개의 알림 대신 "Home Assistant: N devices unavailable"이라는 알림 하나를 받게 됩니다. 원인은 보통 HA 재시작, Zigbee/Z-Wave 브리지 다운, 또는 네트워크 문제로 같기 때문입니다. HA에서 아직 삭제하지 않은 퇴역 기기에는 Exclude(또는 각 행의 버튼)를 사용하십시오.

같은 연결이 기기 검색의 Import from Home Assistant 기능도 지원합니다. HA가 추적하는 네트워크 기기가 HA에서 지정한 이름으로 나열되며, 개별적으로 또는 한꺼번에 클릭 한 번으로 고정할 수 있습니다. 가져온 기기는 스캔 결과와 똑같이 동작하여 상태 확인, 장소, 라이선스 제한이 평소대로 적용되며, 이미 고정된 기기는 걸러집니다. Home Assistant 2026.9의 기기 레지스트리 API가 안정화될 때까지 두 기능 모두 Beta로 표시되며, 레지스트리 세부 정보 전체(영역, 모델)를 가져오는 기능은 그 이후로 미뤄집니다.

그 밖에 SNMP를 지원하는 모든 장비 — 관리형 스위치, 프린터, 네트워크 UPS, NAS 장치 — 는 기기 세부 정보 패널의 SNMP / OIDs 섹션에서 직접 조회합니다. 레거시 SNMPv2c 또는 SNMPv3를 선택하십시오. 권장되는 v3 프로필은 SHA 인증과 AES 암호화를 사용합니다. 암호구는 키체인에 보관되며 명령 인수가 아니라 소유자 전용 임시 설정 파일을 통해 net-snmp에 전달됩니다. 기본 제공 템플릿(System, Host Resources, Interfaces, Printer RFC 3805, UPS RFC 1628, Synology, QNAP, APC PowerNet)을 선택하고 Query를 누르면 레이블과 값 목록이 표시되며, 사용자 지정 OID 하나를 직접 가져올 수도 있습니다. OID를 감시할 수도 있습니다. 비교 조건과 임계값을 설정하면 FrontierStack이 해당 OID를 폴링하고 조건이 충족되면 알림을 발생시킵니다.

11.13Zigbee 및 Z-Wave 기기

오프라인 알림. Zigbee 패널에서 기기의 벨(또는 Alert on All)을 클릭하면 기기가 메시에서 이탈할 때 알림을 받습니다. Zigbee2MQTT에서는 Zigbee2MQTT 설정에서 availability를 켜야 합니다. 이 설정이 없으면 FrontierStack은 조용한 기기와 죽은 기기를 구분할 수 없으므로 패널에 주황색 안내가 표시되며, 절대 추측하지 않습니다. deCONZ는 조명의 연결 가능 여부를 보고합니다. 감시 중인 기기는 패널이 닫혀 있어도 1분마다 확인됩니다.

Zigbee 패널은 Z-Wave JS UI가 구동하는 Z-Wave 노드도 감시합니다. Z-Wave JS UI에서 Zigbee2MQTT가 사용하는 것과 같은 브로커에 MQTT 게이트웨이(Settings ▸ MQTT)를 활성화하고 Retain을 켜 두십시오. 그런 다음 패널의 Z-Wave 섹션에서 Z-Wave JS UI via MQTT를 켜고 같은 접두사(기본값 zwave)를 입력하십시오. 각 노드는 alive, awake, asleep 또는 dead로 표시되며, 벨을 켜면 노드가 dead가 될 때 알림을 받습니다. 절전 중인 배터리 노드는 정상이며 업 상태로 간주됩니다. 게이트웨이가 오프라인이거나, 보고한 적이 없거나, 마지막 읽기가 5분보다 오래된 경우 모든 노드가 unknown으로 표시되고 알림은 발생하지 않습니다 — FrontierStack은 알 수 없는 상태를 오프라인으로 보고하지 않습니다.

같은 SNMP 프로필은 기기 검색, Network Path, PoE 모니터링에서도 사용됩니다. PoE 쓰기는 설정된 사용자에게 쓰기 권한이 있으면 SNMPv3를 사용하고, SNMPv2c는 스위치별 쓰기 커뮤니티를 별도로 유지합니다. AI 하네스는 비밀 값이 아닌 프로필을 검사하고, 고정된 기기에서 숫자 OID를 읽고, PoE 상태를 나열할 수 있습니다. 쓰기 도구에는 임의의 OID 작업이 없으며, 검토된 PoE 켜기/끄기/사이클 작업으로 제한되고, 변경이 활성화되어 있어야 하며, 매번 새로 표시되는 수동 확인을 기다립니다.

11.14Music Assistant

Music Assistant는 Home Assistant 팀이 만든 음악 서버로, 스트리밍 서비스와 로컬 파일을 하나의 라이브러리로 묶어 AirPlay, Google Cast, Sonos, Squeezebox, Snapcast, DLNA 스피커에서 재생합니다. 문제가 생겨도 무언가가 멈추지는 않습니다 — 스트리밍 로그인이 만료되거나, 업그레이드로 스피커 통합이 깨지거나, 스피커가 네트워크에서 사라질 뿐입니다 — 그래서 음악이 재생되지 않을 때까지 아무도 알아채지 못합니다. Music Assistant 서비스 패널(홈 자동화)을 열고 서버 URL(보통 포트 8095)과 Music Assistant ▸ Settings ▸ Profile에서 발급한 장기 액세스 토큰을 입력하십시오.

모니터는 알림 점검이 돌 때마다 세 가지를 확인합니다. 서버가 응답하고 토큰을 받아들이는지, 로드에 실패했거나 다시 로그인해야 하는 음악 또는 플레이어 제공업체가 없는지, 그리고 오프라인 시 알림으로 전환해 둔 스피커가 여전히 사용 가능한지입니다. 휴대폰과 노트북은 하루 종일 연결되었다 끊기기를 반복하므로 스피커는 직접 선택한 경우에만 감시합니다. 모니터는 목록 조회 명령만 보내므로 재생을 시작하거나 음량을 바꾸거나 설정을 편집하는 일은 결코 없습니다.

서비스 스캔과 서비스 검색은 포트만 보고 추측하지 않고 /info 응답으로 포트 8095의 Music Assistant 서버를 인식하며, 그 버전을 표시합니다.

11.15디스크, RAID 및 SMART 상태

드라이브는 귀 기울이고 있으면 고장 전에 경고를 보냅니다. 디스크 상태 패널(기본 제공 모니터링 도구)은 여러 계층을 결합합니다. 볼륨 공간과 Time Machine 상태는 항상 표시됩니다. smartmontools를 설치하면(원클릭 설치 버튼) 각 물리 드라이브에 심층 SMART 속성이 추가됩니다 — 상태, 온도, 전원 켜짐 시간, 재할당 섹터와 보류 섹터, 고장 예측 플래그 — 드라이브별로 확인 버튼과 원본 보고서를 보여 주는 세부 정보 시트가 있습니다. 드라이브는 완전히 고장 났을 때만이 아니라 SMART 실패 또는 우려되는 속성(재할당/보류 섹터 또는 고장 예측)이 있을 때도 알림을 발생시킵니다.

소프트웨어 AppleRAID 세트(미러, 스트라이프, 연결)는 별도 섹션에 레벨, 상태, 구성원별 상태와 함께 표시되며, 세트가 저하되거나 구성원이 오프라인이 되면 알림이 발생합니다. 알림 및 임계값에서 디스크 알림을 켜면 다른 모든 모니터와 똑같이 사용자의 채널로 전달됩니다.

이 모니터들을 함께 사용하면, 한눈에 볼 수 있는 보드 하나, 조정할 패널 하나, 알림을 받을 채널 집합 하나를 갖게 됩니다 — 그리고 같은 상태 정보를 읽고 사용자를 대신해 같은 알림을 보내는 AI 관리자(13장)도 있습니다. 플릿 전체의 CPU, 메모리, GPU 지표를 이 그림에 공급하는 호스트 모니터는 8장에서 다룹니다.

11.16문제를 일으키는 패키지 및 컨테이너

패키지 관리자는 설치 후 스스로 실행되는 것들을 설치합니다 — Homebrew 서비스, 전역 npm 도구, pip로 설치한 서버, Docker 컨테이너 등 — 그리고 그중 하나가 코어 하나를 다 잡아먹거나 계속 쓰러져도 아무것도 알려 주지 않습니다. FrontierStack은 이 Mac에서 30 초마다 이들을 감시합니다. 바쁜 프로세스마다 프로그램이 있는 위치(Homebrew의 Cellar, node_modules, site-packages, gem, ~/.cargo/bin)로 어느 패키지에 속하는지 파악하고, docker stats와 각 컨테이너의 마지막 종료 상태를 읽고, macOS 충돌 보고서와 brew services를 확인한 다음, 다음을 표시합니다.

• 과도한 CPU 또는 메모리 — 임계값 초과(CPU는 활성 상태 보기와 같은 방식으로 계산하며 100% = 코어 하나, 패키지의 모든 프로세스 합계), 또는 메모리 한도의 90%에 이른 컨테이너
• 최근 24시간 동안 기록된 충돌, 그리고 메모리 부족으로 종료된 컨테이너나 오류와 함께 종료된 컨테이너
• 재시작 루프, 실패하는 상태 확인, 그리고 error 상태에 갇힌 brew 서비스

문제는 Docker, Homebrew, Node.js, Python, Ruby, Rust 패널 상단의 주의 필요 섹션에 표시되고 해당 패키지 행에 배지가 붙으며, 서버 활동 윈도우의 이 Mac 개요에도 나타나고 타일 색도 바뀝니다. 활동 윈도우의 프로세스 탭은 각 프로세스가 속한 패키지 이름을 보여 주며, Docker 탭은 이 Mac뿐 아니라 모든 서버에서 문제가 있는 컨테이너를 표시합니다. 무시를 누르면 해당 패키지 하나의 감시를 중지합니다.

직접 확인하지 않고 알림을 받으려면 알림 ▸ 패키지 및 컨테이너를 켜십시오. CPU와 메모리 임계값, 높은 사용량이 몇 분 동안 지속되어야 호출할지(빌드가 1분 동안 코어 하나를 꽉 채우는 것은 정상입니다), 그리고 리소스 사용, 실패, 또는 둘 다에 대해 알릴지를 선택하십시오. 그러면 알림은 다른 알림과 마찬가지로 채널, 연락처, 에스컬레이션 규칙을 거쳐 전달되고, 로컬 상태의 패키지 및 컨테이너 아래에 나타나며, 해당 패키지를 담당하는 패널에 배지를 표시합니다.

11.17서버 활동 윈도우

하나를 설정하는 것이 아니라 모든 기기를 한꺼번에 지켜보고 싶을 때는 모니터 ▸ 서버 활동 윈도우(⇧⌘A, 또는 도구 막대의 게이지 버튼)를 여십시오. 이것은 고정된 서버와 실시간 상태를 보고할 수 있는 고정된 기기 — 라우터와 방화벽, UPS 장치, PoE 스위치, 채굴 장비, KVM 콘솔, 스마트 플러그 — 만 담은 별도의 윈도우이며, 앱의 나머지 부분은 들어 있지 않습니다. 각 타일은 요청한 지표를 스파크라인과 상태 점으로 보여 주고, 주의가 필요하면 주황색이나 빨간색으로 바뀝니다.

레이아웃은 보드에 무엇을 올릴지 결정합니다. 기본 제공 레이아웃은 모든 서버, Mac, CPU 순으로 정렬된 간결한 클러스터 격자, 채굴 장비 및 GPU, 네트워크 및 전원, AI 에이전트, 전체입니다. 사본을 사용자화하거나 직접 만들 수 있습니다 — 대상 종류, 서버 필터, 개별 구성원, 지표와 그 순서, 타일 크기, 그룹화, 정렬, 샘플링 간격을 정할 수 있습니다. 측정값은 FrontierStack 모니터가 설치된 곳에서는 모니터에서, 그 외에는 SSH 왕복 한 번으로 가져오며, 샘플링은 윈도우가 열려 있는 동안에만 실행됩니다.

이 윈도우는 키보드로 조작하도록 만들어졌습니다. 화살표 키는 보드나 목록에서 선택 항목을 옮기며, 위아래 화살표는 타일 한 줄씩 이동합니다. ⌘↑와 ⌘↓는 첫 번째 또는 마지막 대상으로 이동하고, ⇧⌘0은 보드로 돌아가며, esc는 한 단계씩 빠져나옵니다 — 세부 정보, 보드, 그리고 윈도우 닫기 순입니다. ⌘1부터 ⌘9까지는 레이아웃으로 바로 전환하고, ⌥⌘←와 ⌥⌘→는 레이아웃을 순환하며, ⌘E는 현재 레이아웃을 편집하고 ⌘⌫는 선택한 대상을 레이아웃에서 숨깁니다. ⌘F는 필터에 초점을 맞추고, ⌘R은 즉시 샘플링하며, ⌥⇥는 서버의 탭 사이를 이동하고, ⌘T는 터미널 윈도우를 열고, ⇧⌘O는 선택 항목을 메인 윈도우에서 열고, ⇧⌘K는 모든 서버에서 명령 하나를 실행하며, ⌃⌘S는 목록을 보이거나 숨깁니다. 언제든지 ⌘/를 누르면 전체 단축키 목록이 표시됩니다.

모두에서 실행…은 레이아웃의 모든 서버에서 명령 하나를 실행합니다. 기기에는 각자의 세부 정보가 있습니다. 라우터는 게이트웨이와 IDS 알림, UPS는 배터리와 전압, PoE 스위치는 포트별 제어, 채굴 장비는 해시레이트와 셰어, KVM은 콘솔과 전원, 플러그는 상태와 와트를 보여 줍니다.

서버의 개요 옆에 있는 웹 트래픽 탭은 해당 서버 하나에 대한 웹 트래픽 패널입니다. FrontierStack은 SSH로 서버의 Apache 또는 Nginx 액세스 로그를 찾아, 선택한 기간의 요청, 방문자, 오류율, 상위 페이지, 리퍼러, 봇을 보여 줍니다. 같은 보기가 메인 윈도우에도 있습니다 — 웹 트래픽 패널의 호스트 선택기에서 서버를 고르거나, 서버의 서비스에서 Apache 또는 Nginx 행의 트래픽을 누르십시오. root 전용 로그를 읽으려면 서버의 암호가 SSH 및 root 접근에 저장되어 있어야 합니다.

AI 에이전트 레이아웃은 설정해 둔 에이전트 런타임 중 상태 API가 있는 모든 것 — T3 Code, OpenClaw, Hermes, Paperclip, Octop, LangGraph 등 — 을 보드에 올리며, 작업 중인 에이전트와 오늘의 토큰 및 비용을 보여 줍니다. T3 Code는 읽기 전용으로 연결하면 사용자를 기다리는 스레드(답할 때까지 타일이 주황색으로 바뀝니다)와 전체 프로세스 트리의 CPU 및 메모리를 이 Mac 대비 비율로 추가합니다. 세부 정보에는 대기 중, 작업 중, 실패한 스레드, 모델별 사용량, 가장 바쁜 에이전트 프로세스가 나열됩니다. 플릿 점검에서 서버상에 발견된 T3 Code 워커는 존재만 표시하는 타일로 나타납니다.

연결된 Proxmox VE 클러스터는 모든 서버, 클러스터, 전체 레이아웃에 노드마다 타일 하나를 추가하며, CPU, 메모리, 디스크, 가동 시간 스파크라인과 실행 중인 VM 및 컨테이너 수를 보여 줍니다. 세부 정보에는 모든 게스트가 시작, 종료, 재부팅, 중지, 리셋 컨트롤과 함께 나열되고, 노드의 스토리지와 클러스터의 쿼럼이 표시되며, 부트 미디어 패널로 이어지는 ISO로 부팅…을 제공합니다. 클러스터 연결은 8장에서 다룹니다.

윈도우 자체의 제목 막대에는 세 가지 컨트롤이 있습니다. 모양은 이 윈도우만 다크 또는 라이트로 만듭니다 — 앱의 나머지 부분은 라이트로 두고 모니터링 보드만 다크로 쓰고 싶을 때 유용합니다 — 앱 따르기, 다크, 라이트 순으로 순환합니다. 탭 레이아웃은 선택한 서버의 탭을 콘텐츠 위의 띠와 옆의 세로 목록 사이에서 전환합니다. 세로 목록은 세로로 긴 윈도우에 어울리며 모든 탭을 한 번에 보여 줍니다. 키보드는 단축키 목록을 엽니다. 두 토글은 레이아웃 편집기와 ⇧⌘D, ⇧⌘L에도 있습니다.