TL;박사이상 부하를 검출하거나 대량의 작업을 한 번에 완성할 수 있도록 클라우드 작업 대기열과 작업 지속 시간을 정확하게 감시해야 한다.GCP 모니터링과 로그 기반의 사용자 정의 GCP 지표를 결합하여 사용하면 많은 필요한 견해를 제공할 수 있습니다.
모니터링은 생산 시스템을 유지하는 중요한 구성 부분이다.계기판에 정확한 사용 가능한 지표가 있는지 확인하면 문제가 발생하거나 의외의 부하가 발생할 때 더욱 주동적일 수 있습니다.
특히 백그라운드 작업에 적합하며 백그라운드 작업에서 직접적인 서버 오류보다 문제가 더 미묘하다.백그라운드 작업 문제는 대열에 재시도나 시간 초과 작업이 가득한 것을 발견할 때까지 천천히 퍼진다.
GCP에서 제공하는 기존 지표를 사용하여 상황을 신속하게 파악하고 로그 기반 지표를 사용하여 깊이 있게 발굴할 수 있습니다.
본고에서 저는 클라우드 임무와Cloudtasker에 어떻게 모니터링 지표를 배치하는지 소개하겠습니다.
다음은 내가 추적하는 배경 작업에 대한 표준 지표 목록이다.

클라우드 작업 대기열 크기

감시할 첫 번째 지표는 대기열 크기다.만약 당신의 대기열이 제어를 잃게 된다면, 이것은 백엔드 용량을 늘려야 하거나, 작업에 문제가 생기면, 계속해서 다시 줄을 서야 한다는 것을 의미한다.
metrics explorer를 다음 구성과 함께 사용합니다.

지표: 클라우드 퀘스트.고그리피스.com/대기열/깊이

그룹화 기준: 대기열 Id

집계기: 합계

시간: 1분

이렇게 하면 다음 차트가 생성됩니다.

이 도표를 자동으로 생성할 수도 있습니다.

여기를 클릭하십시오. 클라우드 Chargeback 실행 시

기본적으로 작업이 실행되는 백엔드 서비스에 대해 비용을 계산하고 있는 용기의 수량을 감시하면 (1) 귀하의 서비스가 무거운 작업 부하에서 어떻게 나타나는지, (2) 작업이 월말의 전체 계산서에 어떻게 영향을 미치는지 잘 알 수 있습니다.
이것은 백그라운드 업무 모니터링에 독립하는 좋은 지표다.
를 다음 구성과 함께 사용합니다.

미터법:달리기.고그리피스.com/container/bilable 인스턴스 time

그룹화 기준: 구성 이름

집계기: 합계

시간: 1분

이렇게 하면 다음 차트가 생성됩니다.
metrics explorer
이 도표를 자동으로 생성할 수도 있습니다.
이 도표는 초당 비용을 계산하는 실례수를 보여 줍니다.만약 당신이 500밀리초/초를 보았다면, 이것은 당신의 서비스가 50% 의 시간 동안 적극적으로 운행되고 있다는 것을 의미한다.8s/s를 보면 8개의 용기가 실행 중임을 나타냅니다.
Cloud Run은 활성 실행 중인 컨테이너(빈 컨테이너) 위에 다른 컨테이너를 구성할 수 있지만 이러한 컨테이너는 콜드 부팅을 피하기 위해 유지되며 유료로 제공되지 않습니다.

작업 기간(Cloudtasker에만 해당)

측정 작업의 지속 시간은 분해 작업이 필요한지 확인하고 다운스트림 서비스(데이터베이스, 캐시 저장소, 제3자 API)의 속도가 느린지 확인하는 데 매우 중요하다.
클라우드 작업 지속 시간은 본 기기의 GCP 지표가 아니다.로그 기반 데이터로 이 도량을 만들어야 합니다.
click heregem는 모든 작업 완료 로그 항목에 지속 시간 필드를 자동으로 추가합니다.이 값은 작업 지속 시간을 작성하는 메트릭에 사용할 수 있습니다.
GCP Logging > Logs based metric에서 먼저 생성 합니다.
Distribution을 측정 유형으로 선택하고 cloudtasker/job duration 으로 이름 지정하고 단위로 s(초)를 입력합니다.
필터의 경우 다음 질의를 사용합니다.

resource.type="cloud_run_revision"
jsonPayload.name="Cloudtasker"
jsonPayload.payload.duration >= 0

마지막으로 jsonPayload를 입력합니다.유효 하중.필드 이름의 지속 시간과 도량을 저장합니다.
Cloudtasker
이 지표는 트레이스 효과가 없습니다. 데이터를 얻기 위해 몇 분을 기다려야 합니다. (작업량에 따라)
현재 이 맞춤형 지표가 있습니다. 모든 서비스의 로그 지속 시간을 표시하는 그래프를 만듭니다.
new GCP Log-based metric를 다음 구성과 함께 사용합니다.

지표: 로깅.고그리피스.com/user/cloudtasker/job_duration

팀원: 서비스 이름

집선기: 99퍼센트

시간: 1분

이렇게 하면 다음 차트가 생성됩니다.

이 도표를 자동으로 생성할 수도 있습니다.

메트릭 리소스 매니저 Redis 메모리(Cloudtasker에만 해당)

또는 click here를 사용하는 경우 Redis 메모리 사용을 모니터링하는 것이 좋습니다.
Redis에서 최대 메모리에 도달하면 메모리가 부족하거나 키가 자동으로 회수됩니다. (Redis의 maxmemory 정책에 따라) 작업이 실패합니다.
를 다음 구성과 함께 사용합니다.

지표:redis.고그리피스.com/stats/memory/usage

집계기: 없음

시간: 1분

이렇게 하면 다음 차트가 생성됩니다.
Cloudtasker Batch
이 도표를 자동으로 생성할 수도 있습니다.
Rails 캐시 Redis 인스턴스를 Cloudtasker Redis 인스턴스와 분리하는 것이 일반적으로 좋습니다.
Rails의 일반 캐시는 일반적으로 중요하지 않으며, 실행할 때 다시 채울 수 있다.
한편, 클라우드 타일러는 Redis를 일괄 처리 작업과 유효 부하 저장의 지속적인 저장으로 사용하기 때문에 저장이 매우 중요하다. 레드스가 클라우드 타일러 키를 회수하면 작업에 실패할 수 있다.

Redis의 페이로드 저장소 마무리

상기 네 가지 지표는 플랫폼이 작업 처리 부하를 어떻게 처리하는지 잘 설명할 수 있을 것이다.
더 자세한 지표가 필요하다면, 로그 기반 지표를 만들어서 특정한 로그 값을 추출하고 집합해야 합니다. 우리가 '작업 지속 시간' 지표에 대한 것처럼.
Cloudtasker logger를 사용하여 특정 값(예: API 호출 응답 시간)을 기록한 다음 GCP의 사용자 정의 로그 기반 메트릭에서 이러한 값을 캡처할 수도 있습니다.그 이후로 가능성은 무궁하다!