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 Key 및 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): YOUR_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 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7:)은 3scale로 전송된 요청 헤더를 출력합니다. Host, User-Agent, accept, X-Forwarded-Proto 및 X-Forwarded-Forwarded.

두 번째 항목(2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8:)은 3scale의 응답을 출력합니다. 이 경우 <error code="access_token_invalid">access_token "7c6f24f is invalid: expired or never defined</error> 입니다.

둘 다 원래 요청(GET /api/contacts.access_token_token=7c6f24f5) 및 하위 요청 위치(/threescale_authrep)와 업스트림 요청(upstream: "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 code] 섹션을 확인하여 문제가 무엇인지 확인합니다.

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 블록에서 활성화되지 않은 underscores_in_headers 지시문을 사용하여 헤더에 자격 증명을 보낼 수 있습니다.

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

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

그렇지 않으면 클라이언트가 API에 대한 호출을 수행하는 문제 해결으로 이동해야 합니다.

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

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

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