웹앱을 배포하는 시스템의 상태 점검 범위는 무엇입니까?

오늘 저는 웹 응용 프로그램을 배포하기위한 오케스트레이션 시스템 인 장기 실행 서비스에 대한 "상태 점검"작업을 수행했습니다.

나는 그러한 건강 검진의 범위가 무엇인지 결정하려고 노력하고 건강 검진의 범위와 관련된 이러한 질문을 생각해 냈습니다.

1. 오케스트레이션 시스템에서 작업이 실행되고 있다고보고하는 경우 서비스를 정상으로 간주하는 것으로 충분합니까?
2. 아니면 각 서비스를 수동으로 핑해야합니까?
3. 아니면 더 나아가 웹 페이지를 표시하는 것과 같이 웹 앱이해야 할 일을 수행하도록해야합니까?
4. 상태 확인에서 일부 종속 서비스도 실행 중인지 확인해야합니까? 데이터베이스 또는 오케스트레이션 시스템 자체와 같습니다. 아니면 다른 건강 검진의 책임입니까?
5. 그리고 마지막으로 종속 서비스 중 하나가 종료되고 웹앱이 실패하는 경우 웹앱이 웹앱 결함이 아니기 때문에 건강 상태가 좋지 않은지 또는 양호합니까?

나는 이것이 5 가지 별도의 질문이라는 것을 알고 있지만 웹 응용 프로그램을 배포하는 장기 실행 서비스의 상태 확인 범위와 관련이 있으므로 단일 질문으로 그룹화하는 것이 더 합리적이라고 생각했습니다.

건강에 대한 정의 또는 이와 같은 표준 건강 검사의 모양을 확실하지 않기 때문에 구현하기가 어렵습니다.

이 특정 서비스에 대한 건강 검진에는 무엇이 포함됩니까?

건강에 대한 정의로 인해 구현하기가 어렵습니다.

당신은 여기에 당신의 자신의 질문에 대답했습니다. 건강 검진의 정의는 다양 할 수 있습니다. 또한 건강 검진을 발행하는 대상에 따라 다릅니다.

"질문자의 관점에서, 확인 된 서비스가 예상대로 작동합니까?" 이것이 당신이라면, 그것을 정의하게됩니다. 다른 팀 / 서비스 인 경우 상태 점검에 대한 표준 / 사양이 무엇인지 식별해야합니다.

대규모 조직에서 건강 검진이 수행해야 할 작업에 대한 일종의 표준이있을 것입니다. 알아 내세요.

특히 여기에서 웹앱 예제는 웹앱이 건강하지 않기 때문에 상태가 양호하지 않아야 함을 의미합니다. 그러나 "건강한"에 대한 귀하의 정의에는 "ok"가 포함됩니다. 이것은 위에서 언급 한 요구 사항 중 일부입니다 (다시 자신의 코드 일지라도).

다른 곳에서 지정하지 않았다고 가정하면 다른 오류와 관련된 일종의 상태 코드가 있어야합니다. 웹앱을 쿼리하면 "종속 서비스가 종료되었습니다"라는 오류가 표시되어 클라이언트 (또는 상태 확인을 수행하는 모든 사람)가 클라이언트가 종료 된 이유를 알 수 있습니다 .

편집 된 질문의 경우 :

오케스트레이션 시스템에서 작업이 실행되고 있다고보고하는 경우 서비스를 정상으로 간주하는 것으로 충분합니까?

아니요, 프로세스가 실행되고 있다고해서 중단되지 않거나 완전히 작동하지 않거나 다른 다양한 가능성이있는 것은 아닙니다.

아니면 각 서비스를 수동으로 핑해야합니까?

응용 프로그램 기능의 범위에 따라 작동 할 수 있습니다. 서비스를 확인하는 것이 "살아 있습니까?" 핑 다음이 모든 것이 필요할 수 있습니다. 그러나 서비스가 쉽게 "살아 있고 반응 적이지만 실제로 작동하지 않을 수"있는 경우 다른 사항도 확인해야합니다.

아니면 더 나아가 웹 페이지를 표시하는 것과 같이 웹 앱이해야 할 일을 수행하도록해야합니까?

건강 검진은 필요한 필수 기능이 예상대로 작동하는지 확인해야합니다.

당신은뿐만 아니라 그것이 잘못된 반응을 줄 것으로 전체 상태 검사 제거 수, 앱 반환 "건강한"그것은 할 필요가 무엇을 할 수없는 경우합니다 (혼동 말할 것도없고 도대체 문제를 디버깅하는 노력 명 중 - '헤이 웹 서버에 문제가 없는데 왜 페이지를 볼 수 없습니까? ').

상태 확인에서 일부 종속 서비스도 실행 중인지 확인해야합니까? 데이터베이스 또는 오케스트레이션 시스템 자체와 같습니다. 아니면 다른 건강 검진의 책임입니까?

이것은 다소 다릅니다. 서비스가 다른 서비스에 의존하는 경우 해당 상호 작용의 특성은 앱에서 전송 된 API / 네트워크 호출에 반영되어 상태 확인에 포함되어야합니다.

예를 들어 데이터베이스에서 읽는 웹 서버에는 데이터베이스에 대한 상태 정보가 내장되어 있어야합니다. 그렇지 않으면 API 호출이 실패하면 웹 앱이 중단됩니다. 건강 검진에 포함되도록 이러한 전화를 간단하게 수정할 수 있습니다.

그러나 서비스가 유효성 검사없이 수신 대기하는 이벤트를 소비자에게 보내는 경우 소비자가 살아있는 것이 앱 의 기능 에 덜 중요합니다 . 앱에 "건강"한 메시지는 실제로는받지 않고 메시지를 보내는 것입니다.

기본적으로 서비스가 다른 서비스와 대화하고 건강 상태를 확인해야하는 경우 최소한 서비스의 건강 상태 점검을위한 기본 수준의 점검이 필요합니다. 응용 프로그램에서 이미 이것을 처리 할 것이므로 무작위로 충돌한다고 생각합니다.

그리고 마지막으로 종속 서비스 중 하나가 종료되고 웹앱이 실패하는 경우 웹앱이 웹앱 결함이 아니기 때문에 건강 상태가 좋지 않은지 또는 양호합니까?

이것은 기본적으로 위의 답변입니다. 본인의 건강 검진이이 정보를 제공하는 코드 / 메시지 / 무엇을 반환하도록하는 것이 좋습니다. 두 가지 정보 모두 중요합니다. 서비스에 필요한 종속 서비스가 종료 되었고 결과적으로 서비스가 예상대로 작동하지 않는다는 것입니다.

일반적으로 건강 검진은 "생존하고 반응하고 있는지"를 의미합니다. 그 이상의 점검은 고도로 전문화되어 있으며 시스템 사용에 전적으로 달려 있습니다. 시스템이 요청을 올바르게 처리하고 있는지 확인하기 위해 여분의 마일을 사용하든간에 기본 사항을 먼저 수행해야합니다. 시스템이 있는지 확인하고 요청을받을 수 있는지 확인하고 응답을 리턴합니다.

상태 확인을 구현하는 가장 쉬운 방법은 다른 명령이 사용하는 것과 동일한 메커니즘을 사용하여 서비스가 처리하는 명령을 작성하는 것입니다. 그것은 생생함을 나타내고 시스템이 응답을 받고 처리하고 있음을 보여줍니다.

종속 시스템 점검은 상태 점검의 일부가 아니므로 간단하고 독립적으로 유지해야합니다. 각 종속 서비스에 차례로 상태 점검을 추가하십시오. 이렇게하면 실행중인 건강한 시스템 목록을 얻을 수 있으며 어느 시스템이 잘못되었는지 쉽게 알 수 있습니다!

내 경험상 중요한 서비스에는 다음과 같은 기능이 있습니다.

하트 비트

서비스가 정기적으로 실행되는 경우 서비스 본문이 지정된 시간에 시작되었음을 나타내는 타임 스탬프와 함께 로그 파일 또는 이와 유사한 행을 작성합니다.

빵 부스러기

위와 마찬가지로, 이동 경로는 일반적으로 서비스가 서비스 본문을 예상대로 처리하고 흐름의 위치를 ​​나타내는 방법 이름 (및 때로는 매개 변수)의 덤프입니다. 이들은 더 많은 출력을 생성 할 수 있기 때문에 일반적으로 구성 파일 또는 이와 유사한 것으로 제어되므로 서비스가 잠기면 끌 수 있습니다.

다양한 서버, 서비스 및 데이터베이스의 상태 등과 같은 다른 많은 것들을 추가하려는 유혹이 될 수 있습니다. 이것이 귀중한 것은 아니지만, 너무 광범위한 것을 쓰지 말 것을 권합니다. 이것들은 당신 자신의 마음의 평화에 유용 할 수 있지만, 그러한 보호 수단은 다양한 접점을 담당하는 당사자들이 그들이 있다는 것을 알게되면 남용되는 경향이 있습니다. 알기 전에 회사 전체에 대한 진단 앱을 작성할 수 있습니다.