와치독을 구현하는 중에
예전에 배포관련 문서를 본적이 있는데
감시대상프로젝트들 과 와치독프로그램(프로젝트) 관계에서
와치족은 윈도우 서비스를 SC … 로 등록하고
감시대상프로갬은 실행
이렇게 되있습니다.
그렇다면 감시대상 프로젝트(들)은 dotnet run 으로 만 실행한다는 얘기인가요?
아니면 와치독이 자동으로 Exe 파일을 실행하는 건가요?
와치독이 DB에서 감시대상 프로그램 path + exe파일 경로롤 바로보고 있습니다. (당연한 얘기를 ㅠㅠ)
즉 와치독만 실행 (혹은 윈도우 서비스 자동 시작) 될 경우 감시대상이 알아서 각 Exe 파일을 Start 하는 것인지
질문드린겁니다.
그건 구현에 따라 다릅니다. 와치독 서비스가 그렇게 구현되었다면 그렇게 동작할 것이고 아니면 그렇게 동작하지 않습니다.
일반적으로 와치독 서비스가 감시 프로그램들을 올려주기도 해요.
보통 와치독 구현에 여러 방법이 있긴 한데,
말 그대로 프로세스만 감시하는 게 가장 흔한 방법이고, 그래서 프로세스가 내려간 것이 확인되면 해당 프로세스를 다시 실행시키는 형태로 구현을 합니다.
근데 말씀하신 윈도우 서비스를 감시 대상으로 삼는 건 흔하지 않은 거 같습니다.
왜냐하면 서비스 자체가 복구 기능이 있기 때문이죠.
와치독을 윈도우 서비스로 만드는 것도 같은 맥락이죠.
(와치독이 내려가면 스스로 복구해 항상 동작하도록 하기 위함이죠.)
그럼 당연히 와치독뿐만 아니라 다른 윈도우 서비스도 마찬가지겠죠?
그렇기 때문에, 윈도우 서비스를 감시대상으로 삼는 게 일반적인 게 아니라고 얘기한 겁니다.
윈도우 서비스의 복구 설정에는 서비스 실패 시 각 횟수에 따라 특정 동작을 할 수 있게 설정할 수 있습니다.
첫째 실패 → 둘째 실패 → 후속 실패 이렇게 각 실패 단계가 있고, 그 단계마다 복구 동작을 설정할 수 있어요.
(각 단계에서 서비스 재시작, 프로그램 실행, 컴터 재시작 등의 동작을 설정할 수 있지요.)
서비스 실행 이후 특정 시간이 지나면 실패 횟수를 초기화하는 설정도 있어서,
매우 빠르게 연속적으로 실패하지 않는 한, 윈도우 서비스 그 자체로 지속 실행이 가능한 구조입니다.
(만약 빠르게 연속적으로 실패할 경우, 감시가 아니라 디버깅이 필요한 상황이겠죠.)
그게 아니라면,
프로세스가 유지된 상태에서 hang 발생하는 것이나,
서비스 후속 실패까지 일어난 후 연속된 실패로 더 이상 프로세스 시작이 불가능한 경우를 체크하기 위한 서비스 감시는 충분히 의미가 있습니다.
하지만 그럴 경우 당연히 구현이 달라지겠죠?
hang을 체크할 경우, 와치독과 감시 대상 모두에게 keep alive 구현이 필요할 거구요.
최종 실패를 감지하는 경우, 최종 실패를 확인하는 절차와 알림 절차가 필요할 거예요.
(이 상황에서는 감시 대상을 다시 시작시키는 건 의미가 없겠죠? 바로 다시 죽을 테니까요.)