Docker 컨테이너가 자꾸 재시작된다면? 로그부터 확인하는 순서

 

 

※ 이 글은 운영자가 직접 Intel N100 홈서버에서 Docker 기반 서비스를 운영하고 문제를 점검하는 과정을 바탕으로 작성했습니다. 글의 문장 정리와 구성에는 AI 도구의 도움을 약간 받았지만, 최종 내용은 운영자가 직접 검토하고 확인했습니다.

Docker 컨테이너가 자꾸 재시작된다면? 로그부터 확인하는 순서

도입

지난 글에서는 Uptime Kuma를 이용해 홈서버에서 운영하는 WordPress와 n8n 같은 서비스의 상태를 한곳에서 확인하는 방법을 살펴보았습니다.

정상적으로 응답하면 Up, 문제가 발생하면 Down 상태를 확인할 수 있었습니다.

그런데 모니터링 화면에서 서비스가 Down으로 표시되었다고 가정해 보겠습니다.

브라우저에서 직접 접속해 봐도 서비스가 열리지 않습니다.

SSH로 홈서버에 접속한 뒤 Docker 컨테이너 상태를 확인했더니 컨테이너가 보이지 않거나, 실행과 종료를 반복하고 있습니다.

이런 상황이 생기면 가장 먼저 떠오르는 행동은 대개 비슷합니다.

일단 다시 시작해 볼까?

다시 시작해도 해결되지 않으면 다음 생각이 떠오릅니다.

지우고 다시 설치하면 되지 않을까?

저도 처음에는 문제가 생기면 다시 시작하는 것부터 시도했습니다. 그래도 안 되면 Docker Compose를 다시 실행하고, 마지막에는 컨테이너를 지우고 처음부터 다시 설치하고 싶어졌습니다.

물론 재시작이나 재설치로 문제가 해결되는 경우도 있습니다.

하지만 여기에는 한 가지 문제가 있습니다.

왜 문제가 발생했는지 알지 못한 채 다시 정상으로 돌아올 수 있다는 것입니다.

같은 문제가 다시 발생하면 또 처음부터 시작해야 합니다.

그래서 이번에는 바로 재설치하지 않겠습니다.

먼저 질문해 보겠습니다.

컨테이너는 왜 멈췄을까?

이번 글에서는 Docker 컨테이너가 멈추거나 반복적으로 재시작될 때 상태를 확인하고, 로그에서 단서를 찾고, 원인의 범위를 하나씩 좁혀가는 과정을 살펴보겠습니다.

Intel N100 홈서버에서 MariaDB를 Docker Compose로 구축하는 과정을 정리한 다이어그램입니다.

※ 다이어그램은 실제 홈서버 Docker 트러블슈팅 과정을 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감

본문

① 가장 먼저 컨테이너 상태부터 확인한다

서비스에 접속되지 않는다고 해서 곧바로 컨테이너가 삭제되었다고 판단할 수는 없습니다.

먼저 현재 실행 중인 컨테이너를 확인합니다.

docker ps

이 명령어는 현재 실행 중인 컨테이너를 보여줍니다.

그런데 문제가 발생한 컨테이너가 이미 종료된 상태라면 목록에서 보이지 않을 수 있습니다.

이럴 때는 종료된 컨테이너까지 포함해서 확인합니다.

docker ps -a

두 명령어의 차이는 간단합니다.

명령어	확인 범위
docker ps	현재 실행 중인 컨테이너
docker ps -a	실행·중지·종료된 컨테이너 전체

여기에서 첫 번째로 해야 할 일은 원인을 추측하는 것이 아닙니다.

현재 어떤 상태인지 구분하는 것이 먼저입니다.

컨테이너 자체가 존재하지 않는 것인지, 컨테이너는 있지만 종료된 것인지, 아니면 실행과 종료를 반복하고 있는지 먼저 확인해야 합니다.

비슷해 보이는 장애라도 현재 상태에 따라 다음에 확인할 내용은 달라질 수 있습니다.

② Restarting 상태는 무엇을 의미할까?

docker ps -a를 실행하면 컨테이너의 상태를 확인할 수 있습니다.

문제를 추적하는 과정에서는 다음과 같은 상태를 접할 수 있습니다.

• Up
• Exited
• Restarting
• Created

이 가운데 이번 글에서 주목할 상태는 Restarting입니다.

처음 이 상태를 보면 Docker가 문제를 해결하기 위해 열심히 컨테이너를 복구하고 있다고 생각할 수도 있습니다.

하지만 실제로는 조금 다르게 볼 필요가 있습니다.

컨테이너 시작

↓

애플리케이션 실행

↓

설정이나 연결 문제로 오류 발생

↓

프로세스와 컨테이너 종료

↓

재시작 정책에 따라 다시 시작

↓

같은 원인이 해결되지 않아 다시 종료

이 과정이 반복되면 컨테이너는 Restarting 상태를 반복할 수 있습니다.

재시작은 원인이 아니라 현재 나타나고 있는 현상입니다.

컨테이너가 반복해서 다시 시작된다는 사실만으로는 왜 문제가 생겼는지 알 수 없습니다.

환경 변수에 문제가 있을 수도 있고, 데이터베이스에 연결하지 못하고 있을 수도 있습니다.

볼륨으로 연결한 디렉터리에 접근하지 못하고 있거나, 필요한 포트를 다른 서비스가 이미 사용하고 있을 수도 있습니다.

따라서 다음 단계는 컨테이너를 계속 다시 시작하는 것이 아니라 왜 종료되고 있는지 단서를 찾는 것입니다.

③ 로그부터 확인해 보자

Docker 컨테이너에서 문제가 발생했을 때 가장 먼저 확인할 수 있는 자료 가운데 하나가 로그입니다.

기본적인 확인 방법은 다음과 같습니다.

docker logs 컨테이너이름

예를 들어 컨테이너 이름이 uptime-kuma라면 다음과 같이 확인할 수 있습니다.

docker logs uptime-kuma

하지만 오랫동안 실행된 컨테이너는 로그의 양이 많을 수 있습니다.

처음부터 모든 내용을 읽으려고 하면 오히려 중요한 부분을 찾기 어려울 수 있습니다.

그래서 최근 로그부터 확인하는 편이 더 이해하기 쉽습니다.

docker logs --tail=100 컨테이너이름

이 명령은 최근 100줄의 로그를 확인하는 방식입니다.

실시간으로 새로운 로그가 추가되는 모습을 보고 싶다면 다음과 같이 확인할 수 있습니다.

docker logs -f 컨테이너이름

확인을 끝내려면 Ctrl + C를 누릅니다.

Docker Compose로 운영하는 서비스라면 프로젝트 디렉터리에서 다음과 같이 확인할 수도 있습니다.

docker compose logs --tail=100

여러 서비스 가운데 특정 서비스의 로그만 확인하려면 다음과 같은 형식으로 사용할 수 있습니다.

docker compose logs --tail=100 서비스이름

docker logs에서는 컨테이너 이름이나 ID를 사용하고, docker compose logs에서 특정 대상을 지정할 때는 일반적으로 Compose 파일에 정의한 서비스 이름을 사용합니다.

이 둘을 혼동하면 이름을 입력했는데도 대상을 찾지 못하는 상황이 생길 수 있습니다.

④ 영어 로그를 전부 이해해야 할까?

처음 로그 화면을 열었을 때 가장 부담스러운 부분은 영어 문장이 빠르게 지나간다는 것이었습니다.

서버 운영 경험이 많지 않다면 화면을 보는 순간 이런 생각이 들 수도 있습니다.

이걸 전부 해석해야 하나?

하지만 처음부터 로그 전체를 완벽하게 이해할 필요는 없습니다.

우선 오류가 발생한 시점과 가까운 부분부터 살펴봅니다.

그리고 반복되는 표현이나 눈에 띄는 오류 메시지를 찾습니다.

• error
• failed
• denied
• refused
• timeout
• permission
• address already in use
• connection

다만 여기에서 주의할 점이 있습니다.

특정 단어 하나만 보고 원인을 바로 단정해서는 안 됩니다.

예를 들어 connection refused라는 메시지를 발견했다고 가정해 보겠습니다.

이 메시지만으로 원인을 하나로 확정할 수는 없습니다.

연결하려는 대상 서비스가 실행되지 않았을 수도 있고, 주소나 포트가 잘못되었을 수도 있습니다.

컨테이너 간 네트워크 경로에 문제가 있을 수도 있습니다.

로그는 정답을 바로 알려주는 문서라기보다 어디를 조사해야 하는지 알려주는 단서로 보는 편이 좋습니다.

⑤ 원인을 네 가지 범위로 나눠보자

로그를 확인했지만 여전히 원인이 명확하지 않을 수 있습니다.

이럴 때 모든 가능성을 한꺼번에 생각하면 더 복잡해집니다.

이번에는 초보자 입장에서 자주 확인하게 되는 범위를 네 가지로 나눠보겠습니다.

⑥ 첫 번째 범위 : 포트 문제

Docker 서비스를 구성할 때 호스트의 특정 포트를 컨테이너 포트와 연결하는 경우가 많습니다.

예를 들어 다음과 같은 설정입니다.

ports:
  - "3001:3001"

그런데 호스트의 3001번 포트를 다른 컨테이너나 프로세스가 이미 사용하고 있다면 충돌이 발생할 수 있습니다.

이때는 먼저 Compose 설정을 확인합니다.

그리고 현재 포트 사용 상태를 확인해 볼 수 있습니다.

ss -tuln

특정 포트를 중심으로 확인하고 싶다면 다음처럼 필터링할 수도 있습니다.

ss -tuln | grep ':3001'

여기서 중요한 것은 단순히 포트 번호를 다른 숫자로 바꾸는 것이 아닙니다.

먼저 누가 해당 포트를 사용하고 있는지, 그리고 현재 구성에서 어떤 포트가 필요한지 확인해야 합니다.

⑦ 두 번째 범위 : 볼륨과 권한 문제

Docker 컨테이너는 데이터를 유지하기 위해 호스트의 디렉터리나 Docker 볼륨을 연결해서 사용하는 경우가 많습니다.

예를 들어 다음과 같은 구성입니다.

volumes:
  - ./data:/app/data

그런데 호스트의 디렉터리가 예상한 위치와 다르거나, 애플리케이션이 필요한 파일을 읽고 쓰지 못하면 문제가 발생할 수 있습니다.

로그에서 permission denied와 같은 표현이 보인다면 권한 문제를 확인할 필요가 있습니다.

하지만 여기에서도 곧바로 무리한 권한 변경부터 하는 것은 피하는 것이 좋습니다.

먼저 확인할 것은 다음과 같습니다.

• Compose 파일의 볼륨 경로가 맞는가?
• 호스트 디렉터리가 실제로 존재하는가?
• 컨테이너가 어떤 사용자 권한으로 실행되는가?
• 애플리케이션이 해당 경로에 읽기 또는 쓰기를 요구하는가?

권한 문제라고 해서 무조건 넓은 권한을 부여하는 것이 해결책은 아닙니다.

서비스가 요구하는 권한과 현재 디렉터리 상태를 확인한 뒤 필요한 범위에서 수정하는 것이 좋습니다.

⑧ 세 번째 범위 : 환경 변수와 설정값 문제

WordPress, 데이터베이스, n8n과 같은 서비스는 환경 변수와 설정값의 영향을 많이 받습니다.

예를 들어 데이터베이스 연결 정보가 잘못되어 있다면 애플리케이션 컨테이너 자체는 시작되더라도 정상적으로 서비스를 제공하지 못할 수 있습니다.

이때 확인할 부분은 다음과 같습니다.

• 환경 변수 이름에 오타가 없는가?
• 필요한 값이 빠지지 않았는가?
• 데이터베이스 주소가 맞는가?
• 사용자 이름과 비밀번호 설정이 서로 일치하는가?
• 컨테이너 내부에서 사용하는 서비스 이름과 호스트의 주소를 혼동하지 않았는가?

설정 파일을 수정한 직후 문제가 생겼다면 최근 변경 내용을 먼저 확인하는 것도 좋은 방법입니다.

문제가 발생한 시점과 설정 변경 시점이 가까울수록 조사 범위를 줄이는 데 도움이 될 수 있습니다.

⑨ 네 번째 범위 : 의존 서비스 문제

문제가 보이는 컨테이너 자체에는 이상이 없을 수도 있습니다.

예를 들어 WordPress가 정상적으로 시작되려면 데이터베이스와의 연결이 필요합니다.

WordPress 로그에서 데이터베이스 연결 오류가 나타난다고 해서 반드시 WordPress 자체가 원인이라고 단정할 수는 없습니다.

데이터베이스 컨테이너가 멈췄을 수도 있습니다.

접속 정보가 잘못되었거나 컨테이너 간 네트워크 연결에 문제가 있을 수도 있습니다.

문제가 보이는 컨테이너와 실제 원인이 있는 서비스는 다를 수 있습니다.

그래서 여러 서비스가 함께 구성된 Compose 환경에서는 문제가 발생한 서비스의 로그만 보는 것이 아니라, 연결되어 있는 다른 서비스의 상태와 로그도 함께 확인할 필요가 있습니다.

⑩ restart 정책이 문제를 해결해 주는 것은 아니다

Docker Compose 설정에서 다음과 같은 항목을 사용한 적이 있습니다.

restart: unless-stopped

이 설정은 컨테이너 운영에 유용합니다.

하지만 이것이 컨테이너 내부의 문제를 해결해 주는 기능은 아닙니다.

예를 들어 환경 변수에 잘못된 값이 들어 있다고 가정해 보겠습니다.

컨테이너 시작

↓

잘못된 설정으로 애플리케이션 오류

↓

컨테이너 종료

↓

재시작 정책에 따라 다시 시작

↓

잘못된 설정은 그대로 유지

↓

같은 오류 반복

자동 재시작은 복구 기회를 제공하는 기능이지, 잘못된 설정을 자동으로 고치는 기능은 아닙니다.

일시적인 오류로 프로세스가 종료된 경우에는 자동 재시작이 도움이 될 수 있습니다.

하지만 구조적인 설정 오류가 있다면 원인을 수정해야 반복 장애가 멈춥니다.

⑪ 재시작 횟수도 하나의 단서가 된다

컨테이너가 몇 번이나 재시작되었는지 확인하는 것도 도움이 될 수 있습니다.

docker inspect -f '{{ .RestartCount }}' 컨테이너이름

결과가 계속 증가하고 있다면 컨테이너가 반복적으로 종료되고 다시 시작되고 있을 가능성을 확인할 수 있습니다.

이 숫자 하나만으로 장애 원인을 알 수 있는 것은 아닙니다.

하지만 일회성 종료인지, 반복적인 문제가 이어지고 있는지를 판단하는 보조 단서로 사용할 수 있습니다.

RestartCount 증가 확인

↓

최근 로그 확인

↓

같은 오류 반복 여부 확인

↓

최근 변경 설정 확인

↓

연결된 서비스 상태 확인

이렇게 숫자와 로그를 함께 보면 문제의 반복 패턴을 이해하는 데 도움이 됩니다.

⑫ 무작정 재설치하기 전에 무엇을 남겨야 할까?

문제가 생겼을 때 컨테이너를 삭제하고 다시 설치하면 서비스가 살아날 수도 있습니다.

하지만 원인을 모른 채 복구되면 중요한 정보가 사라질 수 있습니다.

같은 문제가 다시 발생했을 때 처음부터 다시 조사해야 합니다.

그래서 거창한 장애 보고서가 아니더라도 최소한의 기록을 남기는 편이 좋습니다.

• 문제가 발생한 시간
• 문제가 발생한 서비스
• 당시 컨테이너 상태
• 마지막 주요 오류 메시지
• 직전에 변경한 설정
• 시도한 조치
• 실제로 해결된 방법

저는 이런 기록을 전문적인 장애 보고서라기보다 다음의 나를 위한 메모라고 생각합니다.

한 달 뒤 같은 오류가 발생했을 때 과거의 내가 남긴 한 줄이 문제 해결 시간을 줄여줄 수도 있습니다.

⑬ 문제 해결 순서를 하나로 정리해 보자

Docker 컨테이너에 문제가 생겼을 때 처음부터 원인을 정확하게 맞힐 필요는 없습니다.

다음과 같은 순서로 범위를 좁혀볼 수 있습니다.

1단계. 서비스가 실제로 응답하지 않는지 확인

↓

2단계. docker ps로 실행 상태 확인

↓

3단계. docker ps -a로 종료 상태까지 확인

↓

4단계. 최근 로그 확인

↓

5단계. 반복되는 오류 메시지 찾기

↓

6단계. 포트·볼륨·권한·설정값 확인

↓

7단계. 연결된 의존 서비스 상태 확인

↓

8단계. 최근 변경 사항과 비교

↓

9단계. 필요한 수정 후 재실행

↓

10단계. 해결 과정 기록

이 순서가 모든 Docker 장애에 동일한 정답이 되는 것은 아닙니다.

하지만 아무런 기준 없이 재시작과 재설치를 반복하는 것보다, 현재 상태를 관찰하고 범위를 줄여가는 출발점으로 사용할 수 있습니다.

운영 철학

장애가 발생했을 때 가장 빠른 행동이 항상 가장 좋은 해결 방법은 아닙니다. 현재 상태와 로그를 먼저 확인하면 단순한 복구를 넘어 같은 문제를 다시 만났을 때 사용할 수 있는 경험이 남습니다.

운영노트

처음 Docker를 사용할 때는 컨테이너가 멈추면 일단 다시 실행했습니다.

그래도 안 되면 Compose를 다시 올렸습니다.

그리고 몇 번을 반복해도 해결되지 않으면 삭제하고 처음부터 다시 설치하고 싶어졌습니다.

어쩌다 서비스가 다시 살아나면 안심했습니다.

하지만 나중에 생각해 보면 왜 멈췄는지는 알지 못했습니다.

같은 문제가 다시 생기면 또 검색하고, 또 명령어를 복사하고, 또 처음부터 시작했습니다.

로그를 보기 시작하면서 모든 오류를 이해하게 된 것은 아닙니다.

지금도 로그를 보면 모르는 내용이 많습니다.

다만 달라진 점은 있습니다.

어디부터 확인해야 하는지 조금씩 알게 되었다는 것입니다.

마지막 부분에 어떤 오류가 반복되는지 봅니다.

포트 문제인지 확인합니다.

권한과 볼륨 경로를 봅니다.

설정값을 다시 확인합니다.

연결된 다른 서비스가 살아 있는지도 살펴봅니다.

모든 것을 한 번에 이해하지 못해도 확인할 범위를 하나씩 줄여갈 수 있었습니다.

저에게 로그는 정답을 알려주는 화면이라기보다 다음에 어디를 봐야 할지 알려주는 흔적에 가까웠습니다.

에디터의 해석노트

문제 해결은 정답을 바로 맞히는 일이 아니라 가능성을 하나씩 지워가는 과정에 가깝다고 생각합니다.

처음 서비스가 멈추면 모든 것이 원인처럼 보입니다.

Docker 문제일 수도 있습니다.

포트 문제일 수도 있습니다.

권한 문제일 수도 있습니다.

환경 변수 문제일 수도 있습니다.

데이터베이스 문제일 수도 있습니다.

이때 처음부터 하나의 정답을 맞히려고 하면 오히려 더 어려워질 수 있습니다.

대신 현재 상태를 확인합니다.

로그를 읽습니다.

반복되는 메시지를 찾습니다.

포트인지, 권한인지, 설정인지, 연결 문제인지 범위를 나눕니다.

그리고 가능성이 낮은 것부터 하나씩 지워갑니다.

그러다 보면 처음에는 넓게 보였던 문제의 범위가 점점 좁아집니다.

홈서버 운영에서 로그를 읽는다는 것은 모든 메시지를 완벽하게 해석하는 일이 아닐지도 모릅니다.

남아 있는 흔적을 따라가며 다음 질문을 만드는 일.

저는 그것이 트러블슈팅의 시작이라고 생각합니다.

참고 링크 (References)

1. Docker Documentation : docker container ls
2. Docker Documentation : docker container logs
3. Docker Documentation : docker inspect
4. Docker Documentation : Start containers automatically
5. Docker Documentation : Docker Compose logs

트러블슈팅

이번 글에서 살펴본 문제 상황을 빠르게 다시 확인할 수 있도록 증상별 첫 확인 지점을 정리해 보겠습니다.

문제 1. 컨테이너가 목록에서 보이지 않는다

docker ps는 현재 실행 중인 컨테이너만 보여줍니다.

종료된 컨테이너까지 확인하려면 다음 명령어를 사용합니다.

docker ps -a

컨테이너가 존재하지만 Exited 상태라면 최근 로그를 확인합니다.

docker logs --tail=100 컨테이너이름

문제 2. 컨테이너가 계속 Restarting 상태다

반복 재시작 자체를 원인으로 보지 말고, 종료 직전의 로그를 확인합니다.

docker logs --tail=100 컨테이너이름

같은 오류가 반복되는지 확인한 뒤 설정값, 볼륨과 권한, 의존 서비스 상태를 점검합니다.

문제 3. 포트 충돌 메시지가 나타난다

Compose 파일의 포트 설정과 현재 호스트의 포트 사용 상태를 비교합니다.

ss -tuln

특정 포트만 확인하려면 다음처럼 사용할 수 있습니다.

ss -tuln | grep ':3001'

무작정 포트를 변경하기보다 현재 어떤 서비스가 해당 포트를 사용하고 있는지 확인하는 것이 먼저입니다.

문제 4. Permission denied가 나타난다

먼저 Compose 파일의 볼륨 경로를 확인합니다.

호스트의 실제 디렉터리 존재 여부와 애플리케이션이 요구하는 읽기·쓰기 권한을 함께 확인합니다.

원인을 확인하지 않은 상태에서 과도하게 넓은 권한을 부여하는 방식은 피하는 것이 좋습니다.

문제 5. Connection refused가 반복된다

먼저 연결 대상 서비스가 실제로 실행 중인지 확인합니다.

그다음 주소, 포트, 컨테이너 네트워크 경로를 확인합니다.

connection refused라는 표현 하나만으로 원인을 단정하지 않고 연결 과정의 각 지점을 나눠서 확인합니다.

문제 6. 데이터베이스 연결 오류가 발생한다

애플리케이션 컨테이너뿐 아니라 데이터베이스 컨테이너의 상태도 확인합니다.

docker ps -a

데이터베이스 서비스의 로그와 애플리케이션의 환경 변수, 사용자 이름, 비밀번호, 데이터베이스 주소를 함께 확인합니다.

문제 7. 재시작 후 잠시 살아났다가 다시 멈춘다

재시작 횟수를 확인하고 같은 오류가 반복되는지 비교합니다.

docker inspect -f '{{ .RestartCount }}' 컨테이너이름

재시작 횟수가 계속 증가한다면 최근 로그와 최근 변경한 설정을 함께 비교해 봅니다.

증상	첫 번째 확인	다음 확인
컨테이너가 보이지 않음	docker ps -a	종료 상태와 로그
계속 Restarting	최근 로그	설정·권한·의존 서비스
포트 충돌 의심	Compose 포트 설정	현재 포트 사용 상태
Permission denied	볼륨 경로	디렉터리 권한과 실행 사용자
Connection refused	대상 서비스 상태	주소·포트·네트워크
DB 연결 실패	DB 컨테이너 상태	환경 변수와 접속 정보
재시작 후 다시 장애	RestartCount	반복 로그와 최근 변경 사항

핵심 체크포인트 10

1. docker ps는 실행 중인 컨테이너를 확인한다.
2. docker ps -a는 종료된 컨테이너까지 함께 확인한다.
3. Restarting은 원인이 아니라 현재 나타나는 상태다.
4. 문제가 발생하면 최근 로그부터 확인하는 것이 도움이 된다.
5. 로그의 오류 단어 하나만으로 원인을 확정하지 않는다.
6. 포트, 볼륨과 권한, 설정값, 의존 서비스로 조사 범위를 나눌 수 있다.
7. 재시작 정책은 잘못된 설정을 자동으로 수정하지 않는다.
8. RestartCount는 반복 장애 여부를 판단하는 보조 단서가 될 수 있다.
9. 문제가 보이는 컨테이너와 실제 원인이 있는 서비스가 다를 수 있다.
10. 문제 해결 과정은 짧게라도 기록으로 남기는 것이 좋다.

마무리

화요일 글에서는 Uptime Kuma를 이용해 서비스의 상태를 관찰하는 방법을 살펴보았습니다.

이번에는 그다음 단계로 넘어왔습니다.

서비스가 Down으로 표시되었을 때 바로 재설치하는 대신 현재 상태를 확인하고, 로그를 읽고, 원인의 범위를 하나씩 좁혀보았습니다.

Docker 컨테이너 문제를 해결할 때 모든 명령어를 외울 필요는 없습니다.

모든 로그를 완벽하게 해석할 필요도 없습니다.

중요한 것은 순서라고 생각합니다.

현재 상태를 확인합니다.

↓

최근 로그를 봅니다.

↓

반복되는 단서를 찾습니다.

↓

가능성을 하나씩 줄여갑니다.

그리고 해결되었다면 그 과정을 짧게라도 남깁니다.

이런 기록이 쌓이면 홈서버는 단순히 서비스를 실행하는 기계에서 조금씩 이해하면서 운영하는 시스템으로 바뀌기 시작합니다.

다음 글에서는 이번 주에 설치하고 확인한 모니터링 환경을 조금 더 안정적으로 운영하기 위해, 알림을 너무 많이 받지 않으면서도 중요한 장애를 놓치지 않도록 모니터링 기준을 어떻게 조정할지 살펴보겠습니다.