7.3. 문제 해결 체크리스트
API에 대한 요청이 있을 수 있는 위치를 확인하려면 다음 검사를 수행합니다.
7.3.1. API
API가 up이고 요청에 응답하는지 확인하려면 API에 직접 동일한 요청을 수행합니다(API 게이트웨이를 통과하지 않음). API 게이트웨이를 통과하는 요청과 동일한 매개변수 및 헤더를 보내고 있는지 확인해야 합니다. 실패하는 정확한 요청이 확실하지 않은 경우 API 게이트웨이와 API 간 트래픽을 캡처합니다.
호출이 성공하면 API에 대한 문제를 제외할 수 있습니다. 그렇지 않으면 API의 문제를 추가로 해결해야 합니다.
7.3.2. API 게이트웨이 > API
API 게이트웨이와 API 간의 네트워크 문제를 제외하려면 API 게이트웨이 서버에서 앞에 있는 직접 API를 통해 직접 API 게이트웨이 서버와 동일한 호출을 수행합니다.
호출이 성공하면 API 게이트웨이 자체의 문제 해결으로 이동할 수 있습니다.
7.3.3. API 게이트웨이
API 게이트웨이가 올바르게 작동하는지 확인하는 여러 단계가 있습니다.
7.3.3.1. 1. API 게이트웨이가 실행 중입니까?
게이트웨이가 실행 중인 시스템에 로그인합니다. 이 오류가 발생하면 게이트웨이 서버가 다운되었을 수 있습니다.
로그인한 후 NGINX 프로세스가 실행 중인지 확인합니다. 이를 위해 ps ax | grep nginx 또는 htop 를 실행합니다.
목록에 nginx 마스터 프로세스 및 NGINX가 실행됩니다.
nginx 작업자 프로세스가 표시되면
7.3.3.2. 2. 게이트웨이 로그에 오류가 있습니까?
다음은 게이트웨이 로그에 표시될 수 있는 몇 가지 일반적인 오류입니다(예: error.log).
API 게이트웨이가 API에 연결할 수 없음
upstream timed out (110: Connection timed out) while connecting to upstream, client: X.X.X.X, server: api.example.com, request: "GET /RESOURCE?CREDENTIALS HTTP/1.1", upstream: "http://Y.Y.Y.Y:80/RESOURCE?CREDENTIALS", host: "api.example.com"
API 게이트웨이 3scale에 연결할 수 없음
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"
7.3.4. API 게이트웨이 > 3scale
API 게이트웨이가 올바르게 실행 중인지 확인한 후 다음 단계는 API 게이트웨이와 3scale 간의 연결 문제를 해결하는 것입니다.
7.3.4.1. 1. API 게이트웨이가 3scale에 도달할 수 있습니까?
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를 사용할 수 있습니다.
7.3.4.2. 2. 3scale 주소를 올바르게 확인하는 API 게이트웨이가 있습니까?
nginx.conf에 resolver 지시문이 추가되었는지 확인합니다.
예를 들어 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.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 Service Management API에서 현재 작업 중인 IP 주소를 확인합니다. 이는 3scale에서 사용할 수 있는 IP 주소의 전체 범위가 아닙니다. 일부 IP 주소는 용량상의 이유로 교체 및 해제될 수 있습니다. 또한 향후 3scale 서비스에 대한 도메인 이름을 추가할 수 있습니다. 이를 위해 통합 중에 제공된 특정 주소에 대해 항상 테스트해야 합니다(해당하는 경우).
7.3.4.3. 3. API 게이트웨이가 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: Cryostat_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:)은 3scale로 전송된 요청 헤더를 출력합니다. 이 경우 Host, User-Agent, Accept, X-Forwarded-Proto 및 X-Forwarded-For.
두 번째 항목(2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8:: )은 3scale의 응답을 출력합니다. < error code="access_token_invalid">access_token "7c6f24f5"는 유효하지 않습니다.
둘 다 원래 요청(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에 대한 정확한 요청을 확인할 수 있습니다.
7.3.5. 3scale
7.3.5.1. 1. 3scale을 사용할 수 있습니까?
Twitter에서 3scale 상태 페이지 또는 @3scalestatus 를 확인합니다.
7.3.5.2. 2. 3scale에서 오류를 반환합니까?
3scale을 사용할 수도 있지만 API 게이트웨이로 오류를 반환하여 API로 이동하는 호출을 방지할 수 있습니다. 3scale에서 직접 권한 부여 호출을 수행하고 응답을 확인합니다. 오류가 발생하면 #troubleshooting-api-error-codes[오류 코드] 섹션을 확인하여 문제가 무엇인지 확인합니다.
7.3.5.3. 3. 3scale 디버그 헤더 사용
X-3scale-debug 헤더를 사용하여 API를 호출하여 3scale 디버그 헤더를 켤 수도 있습니다.
curl -v -X GET "https://api.example.com/endpoint?user_key" X-3scale-debug: Cryostat_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 < X-3scale-matched-rules: /aos/internal/gate_status/v1/flights/histories < X-3scale-credentials: user_key=b3ad95279b0600a2595165404fbae70c < X-3scale-usage: usage%5Bhits%5D=1 < X-3scale-hostname: apicast-staging-3-nkhnn < X-3scale-service-id: 2 < X-3scale-service-name: api
7.3.5.4. 4. 통합 오류 확인
3scale으로의 트래픽에 대한 문제가 있는지 확인하려면 https://YOUR_DOMAIN-admin.3scale.net/apiconfig/errors 에서 관리 포털의 통합 오류를 참조하십시오.
통합 오류의 이유 중 하나는 server 블록에서 사용할 수 없는 underscores_in_headers 지시문을 사용하여 헤더에서 인증 정보를 보내는 것입니다.
7.3.6. 클라이언트 API 게이트웨이
7.3.6.1. 1. 공용 인터넷에서 API 게이트웨이에 연결할 수 있습니까?
브라우저를 게이트웨이 서버의 IP 주소(또는 도메인 이름)로 전달해 보십시오. 이 작업이 실패하면 관련 포트에서 방화벽을 열 수 있는지 확인합니다.
7.3.6.2. 2. 클라이언트에서 API 게이트웨이에 연결할 수 있습니까?
가능한 경우 이전에 설명한 방법(telnet, curl 등) 중 하나를 사용하여 클라이언트에서 API 게이트웨이에 연결을 시도합니다. 연결에 실패하면 문제가 둘 사이의 네트워크에 있습니다.
그렇지 않으면 클라이언트의 문제 해결으로 API를 호출해야 합니다.
7.3.7. 클라이언트
7.3.7.1. 1. 다른 클라이언트를 사용하여 동일한 호출을 테스트합니다.
요청이 예상된 결과를 반환하지 않으면 다른 HTTP 클라이언트로 테스트합니다. 예를 들어 Java HTTP 클라이언트를 사용하여 API를 호출하고 cURL을 사용하여 잘못된 내용이 표시되는 경우입니다.
클라이언트와 게이트웨이 간에 프록시를 통해 API를 호출하여 클라이언트에서 보내는 정확한 매개변수와 헤더를 캡처할 수도 있습니다.
7.3.7.2. 2. 클라이언트에서 보낸 트래픽 검사
Wireshark와 같은 도구를 사용하여 클라이언트가 수행하는 요청을 확인합니다. 그러면 클라이언트가 API를 호출하는지 여부와 요청의 세부 정보를 확인할 수 있습니다.