메시지 프로세서 문제 해결 가이드

이 주제에서는 메시지 프로세서의 문제를 해결하는 단계를 설명하고 문제를 해결합니다. 메시지 프로세서는 apigee-runtime 구성요소의 일부입니다. 런타임 서비스 구성 개요도 참조하세요.

HTTP 상태 코드 500으로 준비 프로브 실패

증상

하나 이상의 apigee-runtime pod가 준비 상태가 아닙니다.

오류 메시지

kubectl을 사용하여 실패한 apigee-runtime pod를 설명하면 다음 오류가 표시됩니다.

Readiness probe failed: HTTP probe failed with statuscode: 500

예를 들면 다음과 같습니다.

kubectl describe pod -n hybrid \
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

...
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7  Readiness probe failed: HTTP probe
failed with statuscode: 500
...

가능한 원인

이 오류는 메시지 프로세서가 트래픽을 제공하는 데 사용할 수 있는 활성 계약이 없음을 의미합니다. 이 상태에서는 메시지 프로세서가 자체적으로 '준비'라고 할 수 없습니다.

원인 설명
Synchronizer에서 관리 영역으로의 연결 문제 Synchronizer에서 관리 영역으로 연결할 수 없습니다. 이 문제는 일반적으로 contractProvider URL을 재정의하고 잘못된 서비스 계정으로 연결하는 경우에 발생합니다. 예를 들어 프로덕션 서버를 가리키는 contractProvider URL로 스테이징 배포에 대한 서비스 계정을 구성하는 경우입니다.
메시지 프로세서에서 동기화 담당자로의 연결 문제 새 MP가 자동 확장 또는 pod 다시 시작의 일부로 나타나는 경우 이 오류가 표시될 수 있습니다. 일반적으로 이 문제는 synchronizer가 다운되고 MP가 계약을 로드할 수 없을 때 발생합니다.

진단: Synchronizer에서 관리 영역으로의 연결 문제

Synchronizer와 관리 영역 연결 문제를 진단하려면 다음 안내를 따르세요.

  1. 클러스터의 pod를 나열합니다. 
    kubectl get pods -n namespace
  2. apigee-synchronizer pod에서 셸을 엽니다. 
    kubectl exec -it -n namespace synchronizer-pod-name bash

    예를 들면 다음과 같습니다.

    kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x bash
  3. 다음 디렉터리로 이동합니다. 
    cd /opt/apigee/var/log/apigee-synchronizer
ls

  dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  drwxr-sr-x 2 apigee apigee  4096 Sep 12 16:52 cachedFiles
  -rw-r--r-- 1 apigee apigee 22295 Sep 12 16:52 config.log
  -rw-r--r-- 1 apigee apigee    76 Sep 12 16:52 versions.properties
  4. version.properties에서 활성 버전을 확인하세요. 예를 들면 다음과 같습니다. 
    cat versions.properties

  #active repository version
  #Sat Dec 14 19:45:00 GMT 2019
  active.version=749
  5. active.version 값이 계약 폴더 번호의 이름과 일치하는지 확인합니다. 위의 예시에서(아래에서도 표시됨) 폴더 이름은 750이므로 일치하지 않습니다. 
    dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  6. Pod 셸을 종료합니다.

해결 방법

version.properties가 없거나 위에 설명된 대로 버전 불일치가 발생한 경우 동기화 담당자 로그를 확인하여 가장 최신 계약이 다운로드되고 있지 않은 이유를 확인합니다. 예를 들면 다음과 같습니다.

kubectl logs -f -n namespace synchronizer-pod-name

동기화 담당자 로그 해석에 대한 자세한 내용은 동기화 담당자 로그를 참조하세요. Synchronizer가 다운되면 apigeectl을 사용하여 다시 시작해 봅니다. 예를 들면 다음과 같습니다. 

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

진단: 메시지 프로세서에서 Synchronizer로의 연결 문제

메시지 프로세서와 Synchronizer의 연결 문제를 진단하려면 다음을 수행하세요.

  1. 클러스터의 pod를 나열합니다. 
    kubectl get pods -n namespace
  2. 계약이 다운로드되지 않는 이유를 알아보려면 런타임 로그를 확인하세요.
    kubectl logs -f -n namespace pod-name

    예를 들면 다음과 같습니다.

    kubectl logs -f -n apigee apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

    새 MP가 자동 확장 또는 Pod 재시작의 일부로 나타나는 경우 MP가 계약을 로드하지 못할 수 있습니다. 일반적으로 Synchronizer가 다운되면 문제가 발생하고 MP가 계약을 로드하지 못하게 됩니다. 예를 들면 다음과 같습니다. 

    2019-09-13 16:59:24,331 podName:N/A ipAddress:N/A dpColor:N/A
HttpClient@331886186-301 DEBUG o.e.j.c.AbstractConnectionPool - AbstractConnectionPool$1.failed() :
Connection 1/64 creation failed
java.net.UnknownHostException: apigee-synchronizer-apigee-gcp-prod1-test.hybrid.svc.cluster.local
at java.net.InetAddress.getAllByName0(InetAddress.java:1281)
at java.net.InetAddress.getAllByName(InetAddress.java:1193)
at java.net.InetAddress.getAllByName(InetAddress.java:1127)
at org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:167)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
at java.lang.Thread.run(Thread.java:748)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
	at java.lang.Thread.run(Thread.java:748)

해결 방법

Synchronizer를 다시 시작해 보세요. 예를 들면 다음과 같습니다. 

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

잘못된 암호화 키에 대한 준비 프로브 실패

증상

apigee-runtime pod가 준비 상태가 아닙니다.

진단

kubectl을 사용하여 실패한 apigee-runtime pod를 설명하면 다음 오류가 표시됩니다. Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed. 예를 들면 다음과 같습니다. 

$ kubectl describe pod -n namespace apigee-runtime-pod-name

...
Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed due to
com.apigee.probe.model.ProbeFailedException{ code = hybrid.encryption.key.InvalidEncryptionKey,
message = Invalid encryption key. Please check the length of the encryption key, associated
contexts = []}
...

해결 방법

지원되는 암호화 키 길이는 16, 24 또는 32바이트이며 키 값은 base64로 인코딩되어야 합니다. 올바른 형식의 키 만들기에 대한 자세한 내용은 데이터 암호화를 참조하세요.

메시지 프로세서 로그 보기

메시지 프로세서 로그를 보고 해석하는 방법에 대한 자세한 내용은 런타임 로그를 참조하세요.

런타임 pod에서 API 프록시 호출

문제를 격리하기 위해 apigee-runtime pod 내에서 직접 API 프록시를 호출하여 인그레스 게이트웨이를 우회할 수 있는지 확인하는 것이 좋습니다.

  1. 다음 명령어를 실행하여 포트 8443으로 전달하세요. 그러면 pod에서 API를 호출할 수 있습니다. 
    kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
  2. 배포된 API 프록시를 호출합니다. 예를 들어 프록시 기본 경로가 ilove-apis인 경우 다음 명령어를 사용합니다. 
    curl -k -v https://0:8443//ilove-apis

    < HTTP/1.1 200 OK
    < X-Powered-By: Apigee
    < Access-Control-Allow-Origin: *
    < X-Frame-Options: ALLOW-FROM RESOURCE-URL
    < X-XSS-Protection: 1
    < X-Content-Type-Options: nosniff
    < Content-Type: text/html; charset=utf-8
    < Content-Length: 18
    < ETag: W/"12-Jb9QP1bUxNSmZkxQGt5KLQ"
    < Date: Fri, 13 Sep 2019 18:33:46 GMT
    < Via: 1.1 google
    < X-Apigee.Message-ID: 016f5f7f-c59e-404c-86e8-7b0737833f982
    < X-Apigee.dp.color: blue
    < X-Apigee.proxy: /organizations/my-org/environments/test/apiproxies/i-loveapis/revisions/1
    < X-Apigee.proxy.basepath: /ilove-apis
    < X-Apigee.target-latency: 9
    <
    * Connection #0 to host 0 left intact
    <H2>I <3 APIs

Management API 확인

아래에 설명된 API를 사용하여 Management API가 제대로 작동하는지 확인할 수 있습니다.

  1. 클러스터에 있는 pod의 이름을 가져옵니다. 
    kubectl get pods -n namespace
  2. 포트 전달을 사용하여 apigee-runtime pod에 액세스합니다. 포트 전달 구문은 다음과 같습니다. 
    kubectl port-forward -n namespace podname 8843:8843

    예를 들면 다음과 같습니다.

    kubectl port-forward -n apigee \
    apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843
  3. 그런 다음, 다음 예시와 같이 다른 터미널 창에서 curl와 같은 유틸리티를 사용하여 classification/tree API에 요청을 보냅니다.
    curl -k https://0:8843/v1/classification/tree

    다음은 '테스트' 환경에 배포된 프록시에 대한 정보를 나열하는 예시 응답입니다.

    [ {
  "condition" : "(always matches)",
  "virtualHost" : {
    "env" : "test",
    "name" : "default",
    "org" : "my-organization",
    "tree" : {
      "elements" : [ {
        "application" : "myproxy",
        "basePath" : "/myproxy",
        "name" : "default",
        "revision" : "1"
      } ],
      "name" : "IdentificationTree"
    }
  }
} ]

디버그 모드 사용

문제 해결에 도움이 되도록 디버그 모드를 사용 설정하면 apigee-runtime pod 로그에 더 자세한 정보가 포함됩니다.

  1. 네임스페이스에서 pod를 나열합니다.
    kubectl get pods -n namespace
  2. 나열된 apigee-runtime pod 중 하나를 선택하여 디버깅합니다.
  3. 해당 pod에 대해 포트 전달 명령어를 실행합니다. 예를 들면 다음과 같습니다. 
    kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843
  4. 다른 터미널을 열고 다음 API를 호출하여 디버깅을 사용 설정합니다. 
    curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
  5. kubectl logs 명령어를 실행하여 디버그 모드에 있는 로그를 확인합니다. 예를 들면 다음과 같습니다. 
    kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
  6. 디버그 로그 검토를 마쳤으면 로그 수준을 INFO(기본값)로 재설정합니다. 예를 들면 다음과 같습니다. 
    curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
  7. kubectl logs 명령어를 실행하여 로그가 INFO 모드로 돌아가는지 확인합니다.