رفتن به محتوا
وقتی Status200 داده دریافت نمی‌کند

وقتی Status200 داده دریافت نمی‌کند

وقتی Status200 دوباره راه‌اندازی می‌شود، ارتقا می‌یابد یا داده‌های انباشته را پردازش می‌کند، هیچ‌چیز از آنچه عامل‌ها، گردآورنده‌ها، پراب‌ها و فرستنده‌های ضربان شما می‌فرستند به مانیتورهایتان نمی‌رسد. Status200 ثبت می‌کند که این اتفاق چه زمانی می‌افتد و هرگز آن زمان را به حساب یک سرور، یک میزبان یا هر منبع دیگری نمی‌گذارد: آن زمان پایش نشده است، پس از کار افتادگی نیست.

چگونه کار می‌کند

هر فرایند Status200 که داده می‌گیرد، تا وقتی به پایگاه‌داده‌هایی که داده را در آن‌ها نگه می‌دارد دسترسی دارد، هر 30 ثانیه ثبت می‌کند که در حال دریافت است. Status200 سه نوع زمان را کنار می‌گذارد:

  • بدون دریافت: هیچ فرایندی بیش از 90 ثانیه چیزی ثبت نکرده است. Status200 متوقف بود، در حال راه‌اندازی دوباره یا ارتقا بود، یا به یکی از پایگاه‌داده‌هایش دسترسی نداشت.
  • اتصال دوباره: 2 دقیقهٔ نخست پس از آنکه Status200 دوباره دریافت می‌کند، وقتی عامل‌ها دوباره وصل می‌شوند و آنچه را نگه داشته‌اند می‌فرستند.
  • جبران عقب‌ماندگی: تا وقتی صف داده‌های در انتظار پردازش بیش از یک دقیقه عقب است، زمانِ پس از قدیمی‌ترین داده‌ای که هنوز در آن منتظر است.
flowchart TB receiving["در حال دریافت"] -->|"90 ثانیه بدون ثبت"| down["بدون دریافت"] down -->|"یک فرایند دوباره ثبت می‌کند"| grace["2 دقیقه اتصال دوباره"] grace --> again["در حال دریافت"]

زمانی که Status200 کنار می‌گذارد

راه‌اندازی دوباره‌ای که کمتر از 90 ثانیه طول بکشد شکاف نیست: گردآورنده‌ها آنچه را نتوانستند برسانند دوباره می‌فرستند.

در این مدت چه چیزی تغییر می‌کند

کجاStatus200 چه می‌کند
مانیتورهای سرور / ماشین مجازیIs Online فقط دقیقه‌هایی را می‌شمارد که Status200 در حال دریافت بود: به‌طور پیش‌فرض، یک سرور پس از 3 دقیقه سکوتی که Status200 می‌توانست بشنود آفلاین می‌شود.
مانیتورهای درخواست ورودی و ایمیل ورودیRecieved In Minutes و Not Recieved In Minutes فقط دقیقه‌هایی را می‌شمارند که Status200 در حال دریافت بود. وقتی چنین معیاری برقرار شود، دلیل آن می‌گوید چند دقیقه از آن دقیقه‌ها کنار گذاشته شد.
مانیتورهای میزبان، Kubernetes، Docker، متریک‌ها، لاگ‌ها، ردیابی‌ها و دیگر مانیتورهایی که تله‌متری می‌خوانندبررسی‌ای که پنجره‌اش زمانی را دربر دارد که Status200 در حال دریافت نبود، صبر می‌کند تا آن زمان از پنجره بیرون برود، و هرگز بیش از 15 دقیقه پس از پایان آن صبر نمی‌کند. تا آن موقع هیچ‌چیز تغییر نمی‌کند: نه تغییر وضعیتی، و نه حادثه یا هشداری باز یا حل می‌شود. تا وقتی صف عقب است، بررسی به‌جای اکنون تا جایی می‌خواند که صف به آن رسیده است.
میزبان‌ها، خوشه‌ها و بقیهٔ موجودییک منبع فقط وقتی قطع‌شده می‌شود که آستانهٔ سکوت آن، برای بیشترشان 15 دقیقه، در زمانی بگذرد که Status200 در حال دریافت بود.
پراب‌ها و عامل‌های هوش مصنوعیپس از 3 دقیقه سکوت در زمانی که Status200 در حال دریافت بود قطع‌شده می‌شوند.
نمودارهای در دسترس بودن میزبان‌ها، میزبان‌های Docker و Podman و خوشه‌های Kubernetesآن زمان به‌صورت پایش نشده سایه می‌خورد، و خط به‌جای افتادن به حالت ازکارافتاده در آنجا قطع می‌شود. نشان آپ‌تایم آن زمان را کنار می‌گذارد؛ بازه‌ای که داده دارد همچنان فعال حساب می‌شود.
آپ‌تایم صفحات وضعیت و SLOهاهر دو از وضعیت مانیتورها محاسبه می‌شوند: بدون تغییر وضعیت نادرست، از کار افتادگی نادرستی هم نیست.
نکته

کنار گذاشتن زمان به معنای پر کردن آن نیست. یک منبع هرگز برای زمانی که Status200 نمی‌توانست آن را بشنود فعال نشان داده نمی‌شود: آن زمان فقط داوری نمی‌شود. همین که Status200 دوباره دریافت کند، منبعی که واقعاً از کار افتاده است از آن پس بر اساس آنچه می‌فرستد یا نمی‌فرستد داوری می‌شود.

نصب‌های خودمیزبان

هنگام راه‌اندازی

وقتی یک فرایند Status200 در حال راه‌اندازی است، به هر درخواستی جز بررسی‌های وضعیت خودش با 503 Service Unavailable و Retry-After: 5 پاسخ می‌دهد، و مرورگر صفحه‌ای می‌گیرد که خودش را دوباره بارگذاری می‌کند. گردآورنده‌ها و SDKهای OpenTelemetry چنین درخواستی را به‌جای دور ریختن داده دوباره می‌فرستند. /status/ready تا وقتی فرایند آماده نشده شکست می‌خورد، پس Kubernetes پیش از آن هیچ ترافیکی به آن نمی‌فرستد.

رونوشت‌های worker

یک فرایند فقط وقتی ثبت می‌کند که Status200 در حال دریافت است که ترافیک ورودی بتواند به آن برسد. اگر رونوشت‌هایی اجرا می‌کنید که فقط صف‌ها را پردازش می‌کنند و هیچ ingressی جلوی آن‌ها نیست، روی آن‌ها RECEIVES_INGRESS_TRAFFIC را روی false بگذارید. وگرنه وقتی همهٔ رونوشت‌هایی که ترافیک می‌گیرند از کار افتاده‌اند، آن‌ها به ثبت کردن ادامه می‌دهند و آن قطعی دوباره به حساب منابع شما گذاشته می‌شود. چارت Helm این را از قبل روی پادهای worker خود تنظیم می‌کند، و یک کانتینر تنهای Status200 به هیچ تنظیمی نیاز ندارد.

کانتینر workerYAML
env:
  - name: RECEIVES_INGRESS_TRAFFIC
    value: "false"

چه چیزی ثبت می‌شود

Status200 از زمانی که به نسخه‌ای ارتقا دهید که این ثبت را دارد، نگه‌داشتن آن را آغاز می‌کند؛ زمانِ پیش از آن مثل همیشه داوری می‌شود. تا وقتی هیچ فرایندی ثبت نمی‌کند که در حال دریافت است، زمانِ پس از آخرین ثبت حداکثر تا یک ساعت شکاف به شمار می‌آید؛ پس از آن سکوت دوباره شمرده می‌شود، تا ثبتی که دیگر نوشته نمی‌شود نتواند قطعی منابع شما را برای مدت طولانی پنهان کند. ثبت‌ها 400 روز نگه داشته می‌شوند، و وقتی Status200 نمی‌تواند آن‌ها را بخواند، سکوت را چنان داوری می‌کند که گویی در تمام مدت در حال دریافت بوده است.

گام‌های بعدی