لدي موقع يعمل بثلاث حزم كوبرنيتيس (هذا ما طلبوه!). تُظهر إحصائيات الزحف أكثر من 120 ألف مشاهدة صفحة يوميًا. لكن هناك . . . عدد قليل جدًا . . . من المستخدمين، وأقل من 1000 منشور، لذا لا يوجد الكثير من الزحف المطلوب القيام به. عند مراقبة ملف production.log لأحد الحزم لبضع دقائق، يظهر فقط حركة مرور إلى /srv/status التي يستخدمها كوبرنيتيس كمراقب للصحة. هل ينبغي احتساب ذلك كزاحف؟ هل هناك شيء آخر قد أغفلته؟
لا، لا ينبغي احتساب ذلك.
120 ألف هو الرقم الدقيق لمعدل ثابت قدره 5 آلاف في الساعة، لذا أقول إنهم يُحتسبون رغم أنه لا ينبغي ذلك.
ربما هناك خطأ ما في عملية الكشف؟
أستطيع التأكيد على أنها تُحتسب (وتم تسجيلها من 127.0.0.1)
SELECT * from web_crawler_requests
where date = '2020-03-05'
order by count desc
تعديل: أيضًا، يبدو أنني ضعيف في الأرقام، حيث إن العدد يبلغ حوالي 12 ألف طلب يوميًا.
وهذا أمر محير أيضًا، لأنه إذا قمت بتشغيل أمر grep -c /srv/status في الـ 3 حاويات (pods)، فإن كل منها يحتوي على حوالي 15 ألف سطر يطابق /srv/status خلال الـ 20 ساعة التي تعمل فيها. وبالتالي، سيكون العدد قريبًا من 50 ألف طلب يوميًا.
يتم احتسابها، وإذا كنت لا ترغب في احتسابها، فهناك خيار واضح يمكنك استخدامه
قم بتعيين رأس HTTP الخاص بـ Discourse-Track-View إلى 0 في الطلب الصادر
أقدر أنك تبالغ في تقدير ما هو واضح بالنسبة لي. 
هذا شبه واضح.
حسناً، هل أحتاج فعلاً إلى ضبط HTTP_DISCOURSE_TRACK_VIEW=false في متغيرات البيئة (ENV) الممررة للحاوية عند تشغيلها؟ أم عليّ أن أرتب الأمر بحيث يتضمن العنصر الذي يضغط على /srv/status رأس Discourse-Track-View: 0؟ (أو ربما يكون الرمز =، لكنني أفترض أنني سأتمكن من استنتاج ذلك).
تحرير: أعتقد أن هذا قد نجح (شكراً لك، @Falco!)، لكنني سأعود بالتقرير غداً عندما أتمكن من التأكد تماماً من نجاحه.
تحرير 2: كما أن GKE لا يحتوي فقط على فحوصات صحة من k8s، بل أيضاً فحوصات صحة من موزع الحمل، لذا يجب تكوين كلاهما مع إضافة رأس Discourse-Track-View: 0.
الأخير. بافتراض أن الشيء يحتوي على ميزة تسمح لك باستخدام رؤوس مخصصة 
نعم، رؤوس مخصصة:
pods/probe/http-liveness.yaml
apiVersion: v1
kind: Pod
metadata:
labels: {...}
name: liveness-http
spec:
containers:
- name: ...
image: ...
readinessProbe:
httpGet:
path: /srv/status
port: 80
httpHeaders:
- name: Discourse-Track-View
value: "0"
periodSeconds: 3
livenessProbe:
httpGet:
# تم إرساله https://github.com/discourse/discourse/pull/9136
path: /srv/status?shutdown_ok=1
port: 80
httpHeaders:
- name: Discourse-Track-View
value: "0" # لاحظ علامات الاقتباس، لتجنب تحويل yaml القيمة إلى عدد صحيح
initialDelaySeconds: 3
periodSeconds: 3
شكرًا لك، كين! أقدر ذلك حقًا. هذا ما أحاوله، ويبدو أنه يعمل، لكنني كنت أنتظر حتى غدًا لأرى ما إذا كان يعمل حقًا.
أعتقد أنه افتراضيًا، @سام، لا ينبغي احتساب هذا المسار. لا أرى أي فائدة في احتساب “مشاهدات الصفحة” لهذا المسار أبدًا.. هل ترى أنت ذلك؟
بالتأكيد، يمكننا إضافة تجاوز هنا، لكن الاختبار يتطلب بعض الحذر، كما أننا لا نملك نمطًا واضحًا للتجاوز.
يجب أن تكون الردود مستبعدة بالفعل من تتبع العرض لأنها من نوع text/plain وليست text/html.
ما هو المسار الدقيق الذي كان GoogleHC يستهدفه؟ إذا كان يستهدف /، فهذه هي مشكلتك؛ وكان عدّ العرض صحيحًا.
همم. أعتقد أنني أضفت رؤوس الصفوف الموصوفة أعلاه إلى كل من K8s وموزع الحمل، وأن كليهما يتصل بـ /srv/status، وأنا متأكد من ذلك. ومع ذلك، لا يزال عدد النقرات 12,960 نقرًا يوميًا في معظم الأيام. سأعيد النظر في الأمر قريبًا.
شكرًا لك على مساعدتك!
كانت هذه هي المشكلة. ظننت أنني قمت بتكوين كل من موازن الحمل وفحص صحة k8s لاستهداف /srv/status، لكن أحدهما كان يستهدف /. لذا، عندما اكتشفت أخيرًا كيفية إصلاح ذلك، اختفت المشكلة.
الأخبار السارة هي أن إضافة Discourse-Track-View ليست ضرورية!
الآن سأقوم بضبط جميع فحوصات الصحة الخاصة بـ uptime robot لاستخدام /srv/status.