عیب یابی

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

خطای ایستیو 404 (یافت نشد).

اشکال زدایی خطای 404 (Not Found) در ایستیو می تواند خسته کننده باشد. امیدواریم این به شما مکانی را بدهد تا شروع کنید به ردیابی جایی که ممکن است همه چیز اشتباه باشد.

درگیری Wildcard Gateway

تنها یک تعریف دروازه می تواند وجود داشته باشد که از مقدار میزبان علامت "*" استفاده کند. اگر هر چیز دیگری را مستقر کرده باشید که شامل یک Gateway باشد، تماس های مشتری با وضعیت 404 ناموفق خواهند بود.

مثال:

$ istioctl get gateways
GATEWAY NAME         HOSTS     NAMESPACE   AGE
bookinfo-gateway     *         default     20s
httpbin-gateway      *         default     3s

اگر چنین است، باید یکی از دروازه‌های متضاد را حذف یا تغییر دهید.

ردیابی جایی که مسیر در حال شکست است

ایستیو مانند پیاز است (یا شاید اوگر)، لایه‌هایی دارد. یک راه سیستماتیک برای اشکال زدایی 404 این است که از هدف خارج شوید.

حجم کار باطن

بررسی کنید که می‌توانید به حجم کاری از ماشین کناری دسترسی داشته باشید:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers

ماشین کناری

آدرس سرویس خود را تنظیم کنید و آدرس IP قسمت بار کاری را دریافت کنید.

SERVICE=httpbin.default.svc.cluster.local:80
  POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')

دسترسی به حجم کاری از طریق کاروان جانبی:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"

یا اگر Istio mTLS فعال باشد:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v https://$SERVICE/headers --resolve "$SERVICE:$POD_IP" --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

دروازه (یا یک ماشین کناری جلو)

دسترسی به سرویس از دروازه:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header

یا اگر Istio mTLS فعال باشد:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v https://$SERVICE/headers --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

تجزیه و تحلیل از دست رفته

اگر تجزیه و تحلیل را در رابط کاربری Analytics نمی بینید، این دلایل احتمالی را در نظر بگیرید:

• مصرف Apigee را می توان چند دقیقه به تاخیر انداخت
• Envoy gRPC Access Log به درستی پیکربندی نشده است
• فرستاده نمی تواند به سرویس از راه دور برسد
• سرویس از راه دور بارگذاری نمی شود

کلید API وجود ندارد یا بد رد نمی شود

اگر اعتبار سنجی کلید API به درستی کار نمی کند، این دلایل احتمالی را در نظر بگیرید:

پروکسی مستقیم

پیکربندی ext-authz بررسی کنید.

• مطمئن شوید که شنونده برای رهگیری پیکربندی شده است.
• پیکربندی ext-authz بررسی کنید.

درخواست های نامعتبر در حال بررسی و مجاز هستند

• سرویس از راه دور برای باز کردن شکست پیکربندی شده است
• فرستاده برای بررسی های RBAC پیکربندی نشده است

برای کسب اطلاعات در مورد نحوه رسیدگی به این مشکلات، به موضوع مستندات Envoy زیر مراجعه کنید: مجوز خارجی ، و به اطلاعات مربوط به ویژگی failure_mode_allow مراجعه کنید. این ویژگی به شما اجازه می دهد تا رفتار فیلتر را در مورد خطاها تغییر دهید.

JWT مفقود یا بد رد نمی شود

دلیل احتمالی این است که فیلتر Envoy JWT پیکربندی نشده است.

کلید API معتبر ناموفق است

علل احتمالی

• فرستاده نمی تواند به سرویس راه دور برسد
• مدارک شما معتبر نیست
• محصول Apigee API برای target و env پیکربندی نشده است

مراحل عیب یابی

محصول API خود را در Apigee بررسی کنید

• آیا برای محیط شما (تست در مقابل پرود) فعال است؟

  محصول باید به همان محیطی متصل شود که سرویس از راه دور شما وجود دارد.

• آیا به هدفی که به آن دسترسی دارید متصل است؟

  بخش اهداف سرویس از راه دور Apigee را بررسی کنید. به یاد داشته باشید، نام سرویس باید یک نام میزبان کاملا واجد شرایط باشد. اگر یک سرویس Istio باشد، نام آن چیزی شبیه helloworld.default.svc.cluster.local code خواهد بود - که نشان دهنده سرویس helloworld در فضای نام default است.

• آیا مسیر منبع با درخواست شما مطابقت دارد؟

  به یاد داشته باشید، مسیری مانند / یا /** با هر مسیری مطابقت دارد. همچنین می‌توانید از علامت‌های عام «*» یا «**» برای تطبیق استفاده کنید.

• آیا برنامه توسعه دهنده دارید؟

  محصول API باید به یک برنامه توسعه دهنده متصل شود تا کلیدهای آن بررسی شود.

درخواست خود را بررسی کنید

• آیا شما کلید مصرف کننده را در x-api-key header پاس می کنید؟

  مثال:

  curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"

• آیا از یک کلید مصرف کننده خوب استفاده می کنید؟

  اطمینان حاصل کنید که اعتبارنامه‌های برنامه‌ای که استفاده می‌کنید برای محصول API شما تأیید شده است.

گزارش های سرویس از راه دور را بررسی کنید

1. سرویس از راه دور را با ورود به سیستم در debug level شروع کنید. به تنظیم سطوح گزارش سرویس از راه دور مراجعه کنید.

   از گزینه -l debug در خط فرمان استفاده کنید. به عنوان مثال:

   apigee-remote-service-envoy -l debug

2. سعی کنید به هدف خود دسترسی پیدا کنید و سیاهههای مربوط را بررسی کنید

   لاگ ها را برای خطی که چیزی شبیه به این است بررسی کنید:

   Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: []
   Selected: [helloworld]
   Eliminated: [helloworld2 doesn't match path: /hello]
   

تنظیم سطوح گزارش خدمات از راه دور

با استفاده از پرچم خط فرمان، می‌توانید سرویس راه دور را در یکی از حالت‌های اشکال‌زدایی زیر، به ترتیب صریح، راه‌اندازی کنید، جایی که debug بیش‌ترین و کمترین error دارد:

• debug - پرحرف ترین حالت ورود به سیستم.
• info - پیش فرض
• warn
• error - حالت ورود به سیستم حداقل پرمخاطب.

به عنوان مثال، برای شروع سرویس در سطح debug :

apigee-remote-service-envoy -l debug