앱이 중지되었습니다. 첫 번째 유용한 단서를 찾으세요.

하나의 관찰 가능한 실패 정의

“중지됨”은 HTTP 오류, 타임아웃, 완료되지 않은 작업 또는 종료된 프로세스를 의미할 수 있습니다. 하나의 URL 또는 작업, 마지막으로 정상 작동한 시간, 첫 실패 시간, 그리고 당신의 시간대를 기록하세요. 모든 사용자가 영향을 받는지, 한 클라이언트만 영향을 받는지도 포함하세요. 조사하는 동안 현재 SSH 세션을 열어 두세요. 애플리케이션 오류에 대한 첫 대응으로 접근 규칙을 변경하는 것은 필수적이지 않습니다.

이 가이드는 systemd를 사용하는 Linux 호스트, 다음과 같은 이름의 애플리케이션 서비스를 가정합니다 first-api.service, 그리고 다음의 로컬 상태 확인 엔드포인트를 가정합니다 127.0.0.1:3000/healthz. 이 기본값은 첫 번째 API 배포 가이드와 일치합니다. 실제 이름으로 바꾸세요. 다른 사용자의 프로세스나 로그를 보려면 관리자 권한이 필요할 수 있습니다. 아래 명령과 출력은 예시이며, 이 가이드를 위해 어떤 제공자 인스턴스도 테스트되지 않았습니다.

메모는 문제가 발생한 앱의 자체 디렉터리 밖에 보관하세요. 해석보다 관찰을 먼저 기록하세요. “09:18 UTC에서 연결 거부됨”은 사실이고, “VPS에 더 많은 CPU가 필요하다”는 여전히 가설입니다. 서버 자체에 연결할 수 없다면, 기존에 마련한 복구 접근을 사용하고 앱 재시작이 가능하다고 가정하지 말고 연결 세부 정보를 수집하세요.

프로세스 상태 및 최근 기록 읽기

systemctl status first-api.service --no-pager --full
systemctl show first-api.service -p ActiveState -p SubState -p Result -p ExecMainStatus -p NRestarts

상태 보기는 현재 또는 가장 최근의 호출을 설명하며 최근 저널 메시지를 포함합니다. 선택한 속성은 나중에 비교할 수 있는 간결한 기록을 제공합니다. 실패 상태나 증가하는 재시작 횟수는 조사할 가치가 있습니다. 활성 프로세스라도 여전히 요청 테스트가 필요합니다. 이는 서로 다른 점검이며, 다음 문서에 설명된 대로입니다: 업스트림 systemctl 참조.

유닛이 없으면 먼저 이름과 배포 방식을 확인하세요. 대화형 터미널에서 시작된 앱, 컨테이너, systemd 서비스는 소유자와 로그가 다릅니다. 즉시 새 서비스를 만들면 동일한 포트를 두고 두 복사본이 경쟁할 수 있습니다. 변경하기 전에 기존 구성을 파악하세요.

리스너 확인 및 로컬 요청 수행

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

예상 주소와 포트를 찾은 다음 소유 프로세스를 식별하세요. 다른 포트에서 수신하는 프로세스는 정상일 수 있지만 구성된 프록시에서 도달할 수 없습니다. 다른 프로세스가 예상 포트를 점유했을 수 있습니다. ss 매뉴얼 는 리스너와 프로세스 옵션을 정의합니다.

로컬 요청은 작동하고 공용 HTTPS 요청은 실패하면 다음을 계속 진행하세요: DNS, TLS 및 프록시 점검. 리스너가 없으면 시작 실패를 조사하세요. 연결은 성공하지만 앱이 오류를 반환하면 해당 경로와 종속성을 조사하세요. --fail 가 없으면 HTTP 오류 응답에 대해서도 성공적으로 완료될 수 있으므로 종료 코드에만 의존하지 말고 응답을 읽으세요. 참조: curl의 응답 및 실패 옵션.

마지막 줄만이 아니라 첫 번째 실패 주변을 읽으세요

sudo journalctl -u first-api.service --since "30 minutes ago" --no-pager -n 100
sudo journalctl -k --since "30 minutes ago" --no-pager -n 100

첫 번째 쿼리는 서비스를 선택하고, 두 번째 쿼리는 커널 메시지를 선택합니다. 마지막으로 성공한 요청과 중단 전에 발생한 변경을 포함하도록 시간 범위를 조정하세요. 접근과 보존 기간에 따라 남아 있는 내용이 결정됩니다. 업스트림 journalctl 참조 는 유닛, 시간 및 커널 필터를 설명합니다. 발췌를 공유하기 전에 토큰, 고객 데이터 및 연결 문자열을 삭제하세요.

업로드 기능이 있는 별도 앱의 예시 발췌:

09:18:03 field-api: opening upload directory
09:18:03 field-api: EACCES: permission denied, open '/var/lib/field-api/uploads/index.json'
09:18:03 field-api: startup aborted

이는 서비스 사용자의 특정 경로에 대한 접근을 가리킵니다. 릴리스 지침에 따라 파일과 상위 디렉터리 소유권을 확인하세요. 전체 파일 시스템에 광범위한 쓰기 권한을 부여하지 마세요. 이후 프록시의 "업스트림 사용 불가" 메시지는 이 시나리오에서 결과이므로 프록시를 먼저 수리하면 원인을 놓치게 됩니다.

리소스를 가장 최근 릴리스와 비교

free -h
df -h / /opt/first-api
df -i / /opt/first-api

이 스냅샷은 메모리 압력, 파일 시스템 공간 또는 inode 고갈이 장애와 동시에 발생했는지 묻는 데 도움이 됩니다. 해석은 다음 문서에 속합니다: 메모리 및 디스크 가이드; 단일 사용량 수치가 원인을 입증하지는 않습니다. 서비스는 나머지 호스트에 용량이 있어도 자체 리소스 한도에 도달할 수 있습니다.

배포된 릴리스 식별자, 시작 명령, 필요한 환경 변수 이름 및 데이터 경로를 마지막으로 작동한 릴리스와 비교하세요. 비밀 환경 값을 보고서에 덤프하지 마세요. 이름이 변경된 디렉터리, 누락된 런타임 종속성, 포트 변경 또는 호환되지 않는 데이터베이스 마이그레이션을 찾으세요. 무엇이 변경되었고 오류가 무엇을 예측하는지 명시하세요.

하나의 정당한 수정을 수행하고 복구 확인

증거가 뒷받침하는 가장 작은 수정을 선택하세요. 예시 권한 실패의 경우, 서비스 계정의 의도된 접근을 복원한 다음 한 번의 통제된 시작 시도를 하세요. 대신 알려진 작동 코드 릴리스를 사용하는 경우, 먼저 해당 데이터베이스 스키마가 호환되는지 확인하세요. 코드 롤백은 데이터 마이그레이션을 자동으로 되돌릴 수 없습니다.

수정 후 동일한 서비스, 로컬 엔드포인트 및 공용 요청 점검을 반복하세요. 대표적인 애플리케이션 작업이 작동하고, 새 오류가 중단되었으며, 다음 정상 워크로드 동안 프로세스가 안정적으로 유지되는지 확인하세요. 재시작 정책은 프로세스 복구에 도움이 될 수 있지만 지속적으로 손상된 프로그램을 건강하게 만들지는 못합니다. 참조: systemd 서비스 참조 실제 정책은.

증상, 첫 번째 유용한 단서, 수행한 변경 및 검증 결과로 장애 노트를 마무리하세요. 원인이 불확실하면 임시 재시작을 영구 수정으로 표시하지 말고 수정된 증거와 함께 불확실성을 보고하세요. 다음을 개선하세요: 릴리스 체크리스트 이 실패를 더 일찍 잡았을 점검으로.