12.3. API 요청 문제 식별

게이트웨이가 실행 중인 시스템에 로그인합니다. 이 경우 게이트웨이 서버가 다운될 수 있습니다.

로그인한 후 NGINX 프로세스가 실행 중인지 확인합니다. 이를 위해 ps ax | grep nginx 또는 htop 를 실행합니다.

nginx 마스터 프로세스 및 nginx 작업자 프로세스 가 목록에 표시되면 NGINX가 실행되고 있습니다.

다음은 게이트웨이 로그에 표시되는 몇 가지 일반적인 오류입니다(예: error.log).

NGINX를 API 게이트웨이로 사용하는 경우 게이트웨이가 3scale에 연결할 수 없을 때 nginx 오류 로그에 다음 메시지가 표시됩니다.

2015/11/20 11:33:51 [error] 3578#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 127.0.0.1, server: , request: "GET /api/activities.json?user_key=USER_KEY HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.186:443/transactions/authrep.xml?provider_key=YOUR_PROVIDER_KEY&service_id=SERVICE_ID&usage[hits]=1&user_key=USER_KEY&log%5Bcode%5D=", host: "localhost"

업스트림 값을 기록해 둡니다. 이 IP는 3scale 제품이 해결한 IP 중 하나에 해당합니다. 이는 3scale에 도달하는 데 문제가 있음을 의미합니다. 역방향 DNS 조회를 수행하여 nslookup 을 호출하여 IP의 도메인을 확인할 수 있습니다.

예를 들어 API 게이트웨이가 3scale에 도달할 수 없기 때문에 3scale이 중단된 것은 아닙니다. 가장 일반적인 이유 중 하나는 API 게이트웨이가 3scale에 연결하지 못하도록 하는 방화벽 규칙입니다.

게이트웨이와 3scale 간에 연결이 시간 초과될 수 있는 네트워크 문제가 있을 수 있습니다. 이 경우 일반적인 연결 문제를 해결하여 문제가 있는 위치를 식별하는 단계를 거쳐야 합니다.

네트워킹 문제를 배제하려면 traceroute 또는 MTR을 사용하여 라우팅 및 패킷 전송을 확인합니다. 3scale 및 API 게이트웨이에 연결할 수 있는 머신에서 동일한 명령을 실행하고 출력을 비교할 수도 있습니다.

또한 API 게이트웨이와 3scale 간에 전송되는 트래픽을 보려면 3scale 제품(su1.3scale.net)에 HTTP 끝점을 사용하여 일시적으로 전환할 때 tcpdump를 사용할 수 있습니다.

resolver 지시문이 nginx.conf에 추가되었는지 확인합니다.

예를 들어, nginx.conf에서:

http {
  lua_shared_dict api_keys 10m;
  server_names_hash_bucket_size 128;
  lua_package_path ";;$prefix/?.lua;";
  init_by_lua 'math.randomseed(ngx.time()) ; cjson = require("cjson")';

  resolver 8.8.8.8 8.8.4.4;

Google DNS (8.8.8.8 및 8.8.4.4)를 선호하는 DNS로 대체할 수 있습니다.

API 게이트웨이에서 DNS 확인을 확인하려면 지정된 확인자 IP를 사용하여 nslookup을 호출합니다.

nslookup su1.3scale.net 8.8.8.8
;; connection timed out; no servers could be reached

위의 예에서는 Google DNS에 연결할 수 없는 경우 반환되는 응답을 보여줍니다. 이 경우 확인자 IP를 업데이트해야 합니다. nginx error.log에 다음 경고가 표시될 수도 있습니다.

2016/05/09 14:15:15 [alert] 9391#0: send() failed (1: Operation not permitted) while resolving, resolver: 8.8.8.8:53

마지막으로 dig any su1.3scale.net 을 실행하여 3scale 서비스 관리 API에 현재 작동 중인 IP 주소를 확인합니다. 이는 3scale에서 사용할 수 있는 전체 IP 주소 범위가 아닙니다. 일부는 용량의 이유로 축소되거나 제거될 수 있습니다. 또한 3scale 서비스에 대한 도메인 이름을 나중에 더 추가할 수 있습니다. 이를 위해 통합 중에 제공된 특정 주소에 대해 항상 테스트해야 합니다.

API 게이트웨이가 3scale에 있는지 확인하려면 nginx.conf 의 3scale authrep 위치(API 키 및 App\_id 인증 모드의 경우/threescale_authrep )에 스니펫을 추가할 수 있습니다.

body_filter_by_lua_block{
  if ngx.req.get_headers()["X-3scale-debug"] == ngx.var.provider_key then
    local resp = ""
    ngx.ctx.buffered = (ngx.ctx.buffered or "") .. string.sub(ngx.arg[1], 1, 1000)
    if ngx.arg[2] then
      resp = ngx.ctx.buffered
    end

    ngx.log(0, ngx.req.raw_header())
    ngx.log(0, resp)
  end
}

이 스니펫은 X-3scale-debug 헤더 가 전송될 때 다음과 같은 추가 로깅을 nginx error.log에 추가합니다(예: curl -v -H 'X-3scale-debug: gainR_PROVIDER_KEY' -X GET "https://726e3b99.ngrok.com/api/contacts.json?access_token=7c6f24f5"

그러면 다음 로그 항목이 생성됩니다.

2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7: GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1
Host: 726e3b99.ngrok.io
User-Agent: curl/7.43.0
Accept: */*
X-Forwarded-Proto: https
X-Forwarded-For: 2.139.235.79

 while sending to client, client: 127.0.0.1, server: pili-virtualbox, request: "GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.94:443/transactions/oauth_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5", host: "726e3b99.ngrok.io"
2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8: <?xml version="1.0" encoding="UTF-8"?><error code="access_token_invalid">access_token "7c6f24f5" is invalid: expired or never defined</error> while sending to client, client: 127.0.0.1, server: pili-virtualbox, request: "GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.94:443/transactions/oauth_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5", host: "726e3b99.ngrok.io"

첫 번째 항목(2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7:7: )은 3scale로 전송된 요청 헤더를 인쇄합니다. Host, User-Agent, Accept, X-Forwarded-Proto 및 X-Forwarded-For

두 번째 항목(2016/05/05 14:33 [] 7238#0: *57 [lua] body_filter_by_lua:8:8:) 은 3scale의 응답을 출력합니다. 이 경우 <error code="access_token_invalid">access_token "7c6f245""가 만료되지 않았습니다.

원본 요청(GET /api/anchors.json?access_token=7c6f24f5) 및 하위 요청 위치(/threescale_authrep)와 업스트림 요청(stream: "https://54.83.62.94:443/transactions/threescale_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5".)을 출력합니다. 이 마지막 값을 사용하면 3scale IP 중 어느 것이 해결되었으며 3scale에 대한 정확한 요청도 확인할 수 있습니다.

3scale을 사용할 수 있지만 API 게이트웨이에 오류를 반환하여 API로의 호출을 방해하는 것도 가능합니다. 3scale에서 권한 부여를 직접 호출하고 응답을 확인하십시오. 오류가 발생하면 #troubleshooting-api-error-codes[Error Codes] 섹션을 확인하여 문제가 무엇인지 확인합니다.

X-3scale-debug 헤더로 API를 호출하여 3scale 디버그 헤더를 실행할 수도 있습니다. 예를 들면 다음과 같습니다.

curl -v -X GET "https://api.example.com/endpoint?user_key" X-3scale-debug: YOUR_SERVICE_TOKEN

이렇게 하면 API 응답이 포함된 다음 헤더가 반환됩니다.

X-3scale-matched-rules: /, /api/contacts.json
< X-3scale-credentials: access_token=TOKEN_VALUE
< X-3scale-usage: usage[hits]=2
< X-3scale-hostname: HOSTNAME_VALUE

관리 포털의 통합 오류를 확인하여 트래픽을 3scale로 보고하는 모든 문제를 확인할 수도 있습니다. https://YOUR_DOMAIN-admin.3scale.net/apiconfig/errors 에서 참조하십시오.

통합 오류의 이유 중 하나는 server 블록에서 밑줄_in_headers 지시문을 사용하여 헤더에서 자격 증명을 보낼 수 있습니다.

브라우저를 게이트웨이 서버의 IP 주소(또는 도메인 이름)로 전달해 보십시오. 이 작업이 실패하면 관련 포트에서 방화벽을 열어야 합니다.

가능한 경우 이전에 설명한 방법 (telnet, curl 등) 중 하나를 사용하여 클라이언트의 API 게이트웨이에 연결하십시오. 연결에 실패하면 문제는 둘 사이의 네트워크에 있습니다.

그렇지 않으면 API를 호출하는 클라이언트 문제 해결을 위해 이동해야 합니다.

요청이 예상 결과를 반환하지 않으면 다른 HTTP 클라이언트로 테스트합니다. 예를 들어 Java HTTP 클라이언트가 있는 API를 호출하는 경우 cURL을 사용하여 잘못된 교차 점검이 표시됩니다.

클라이언트와 게이트웨이 간에 프록시를 통해 API를 호출하여 클라이언트에서 전송하는 정확한 매개변수와 헤더를 캡처할 수도 있습니다.

controlPlane과 같은 도구를 사용하여 클라이언트가 요청하는 요청을 확인합니다. 이렇게 하면 클라이언트가 API를 호출하는지와 요청 세부 정보를 확인할 수 있습니다.