메시지 모니터링

이 가이드에서는 Manufacturing Data Engine (MDE)으로 전송된 메시지를 모니터링하고, 처리 파이프라인을 통해 메시지가 흐르는 방식을 확인하며, 구성 또는 잠재적인 시스템 문제로 인해 발생할 수 있는 문제를 진단하는 방법을 설명합니다.

MDE를 통해 흐르는 메시지를 모니터링하려면 operations-log BigQuery 테이블을 사용해야 합니다. MDE 파이프라인의 단계에서 메시지 처리에 실패할 때마다 단계와 실패 이유를 나타내는 operations-log 테이블로 메시지를 전송합니다.

실패한 메시지는 모두 이 테이블에 작성되지만 성공한 메시지도 operations-log 테이블에 작성되도록 MDE를 구성할 수 있습니다. 이는 문제를 디버깅할 때 유용하지만 시스템에서 많은 추가 트래픽을 생성할 수 있고 프로덕션에서 성능이 저하될 수 있으므로 사용 설정된 상태로 두어서는 안 됩니다.

REST

다음 REST API 요청을 실행하여 operations-log 테이블을 구성합니다.

POST /configuration/v1/environment

{
  "operationsLogLevel": "ALL"
}

각 항목의 의미는 다음과 같습니다.

ALL: 모든 메시지는 처리 파이프라인의 각 단계에 대해 operations-log 테이블로 전송됩니다.
ERROR: 처리 단계 중 하나라도 실패한 메시지만 operations-log 테이블로 전송됩니다.

처리 단계

처리 파이프라인을 통과할 때 메시지가 거부되는 이유를 진단하려면 다양한 처리 단계를 알고 각 단계에서 수행하는 작업을 이해하는 것이 유용합니다. 자세한 내용은 MDE 아키텍처를 참고하세요.

message-mapper: 원본 JSON을 읽고, 해당 메시지 클래스와 일치시키고, Whistle을 사용하여 처리하여 하나 이상의 레코드를 내보냅니다.
configuration-manager: 아직 없는 경우 시스템에 새 태그를 만들고 적절한 유형 (메타데이터 버킷, 싱크 ,변환)의 정의된 모든 속성을 레코드에 추가합니다.
metadata-manager: 이 레코드의 모든 메타데이터 참조를 해결하고, 새 메타데이터가 수신되면 시스템 메타데이터 인스턴스를 업데이트하고, 메타데이터가 구체화되도록 구성된 경우 구체화된 메타데이터를 레코드에 추가합니다.
bigquery-sink: 레코드를 적절한 유형 구조에 매핑하고 BigQuery에 기록되도록 해당 PubSub 주제에 전송합니다.
pubsub-sink: 레코드를 Pub/Sub Proto 또는 JSON 구조에 매핑하고 해당 주제로 전송합니다.
GCSWriter: input-messages 주제에서 수신된 원시 데이터와 메타데이터 관리자를 거친 후 처리된 데이터를 모두 작성합니다.
BigtableWriter: Bigtable에 데이터를 씁니다.
GCSReader: Cloud Storage에서 파일을 읽고 input-messages에 메시지를 전송합니다.

구성된 싱크에 메시지가 표시되지 않는 문제 진단

MDE에 메시지를 전송했는데 구성된 싱크에 없는 경우 먼저 유형이 싱크를 올바르게 구성했는지 (유형 섹션에 설명됨)와 BigQuery에서 올바른 테이블을 쿼리하고 있는지 확인합니다. 표 이름은 유형을 따릅니다.

이것이 올바르게 구성된 경우 operations-log 표를 사용하여 문제를 진단해야 합니다. 다음 예와 같이 event_timestamp로 정렬하거나 메시지가 전송된 시점으로 필터링하여 일반적인 쿼리로 시작할 수 있습니다.

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
ORDER BY
  event_timestamp desc
LIMIT 100;

source_message_id을 사용하여 특정 메시지를 필터링할 수도 있습니다. 이 ID는 메시지를 게시할 때 Pub/Sub에 의해 할당됩니다. gcloud CLI를 사용하여 명령줄에서 메시지를 게시하면 게시된 메시지의 messageId가 반환됩니다.

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) <= CURRENT_DATE()
  AND source_message_id = 'PubSubMessageId';

메시지를 찾을 수 없거나 메시지가 너무 많은 경우 원본 메시지의 속성을 기준으로 필터링할 수 있습니다. 메시지는 항상 마지막 단계에서 남은 상태로 payload 필드에 로깅되며 JSON 필드에 저장되므로 TO_JSON_STRING를 사용하고 %를 사용하여 원하는 텍스트가 포함된 메시지를 쉽게 찾을 수 있습니다.

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
  AND TO_JSON_STRING(payload) LIKE "%TEXT-TO-FIND%"
ORDER BY
  event_timestamp DESC;

operations-log 표에서 메시지를 찾은 후 error-message 열을 확인하여 메시지가 거부된 이유를 확인합니다. 가장 일반적인 오류는 다음과 같습니다.

구성 관리자에 등록된 메시지 클래스와 수신 메시지가 일치하지 않습니다.
메시지 클래스 <MESSAGE_CLASS_NAME>의 파서를 찾을 수 없습니다.
메시지를 역직렬화할 수 없으므로 (메시지가 유효한 JSON이 아님) 메시지 처리를 건너뜁니다.
파서 <PARSER_NAME>로 유효한 메시지를 구성할 수 없습니다. 메시지에 타임스탬프 필드가 누락되었습니다.
파서 <PARSER_NAME>로 유효한 메시지를 구성할 수 없습니다. 메시지에 tagName 필드가 누락되었거나 비어 있습니다.
파서 <PARSER_NAME>로 유효한 메시지를 구성할 수 없습니다. 메시지 타임스탬프가 지원되는 범위를 벗어납니다.

메시지 실패의 원인이 되는 오류를 찾아 수정하면 메시지가 각 싱크에 도착하기 시작합니다.