استقرارها و تغییرها

Status200 سابقه‌ای از آنچه در پروژهٔ شما تغییر کرده است نگه می‌دارد: استقرارها، به‌روزرسانی‌های تدریجی Kubernetes، تغییرهای پیکربندی، و اصلاح‌هایی که خودش اجرا کرده است. هر تغییر به‌صورت یک نشانگر روی نمودارهای سرویسش کشیده می‌شود، و Status200 AI هنگام بررسی یک حادثه آن‌ها را می‌خواند، پس «درست پس از استقرار ساعت ۱۰:۰۲ شروع شد» نخستین چیزی است که می‌فهمید، نه آخرین.

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

آنچه Status200 خودش ثبت می‌کند#

برای این‌ها لازم نیست چیزی بفرستید. Status200 آن‌ها را از تله‌متری‌ای که از قبل دریافت می‌کند، و از کارهایی که خودش انجام می‌دهد، ثبت می‌کند.

• نخستین نسخه‌ای که یک سرویس گزارش می‌دهد خط پایهٔ آن است، نه یک استقرار. سرویسی که ماه‌ها در حال اجرا بوده است، در لحظه‌ای که Status200 دریافت تله‌متری‌اش را آغاز می‌کند مستقر نمی‌شود.
• بازگشت به نسخه‌ای که در ۳۰ روز گذشته دیده شده است ثبت نمی‌شود، چون آن نسخه تازه نیست. بازگشتی که Status200 AI اجرا کند به‌عنوان یک اصلاح ثبت می‌شود.
• بیش از ۶ نسخه یا ReplicaSet تازه در یک ساعت، تا پایان آن ساعت دیگر ثبت نمی‌شوند. وگرنه «نسخه‌ای» که با هر پاد تغییر می‌کند، مانند مهر زمانی یک build، برای هر پاد یک استقرار ثبت می‌کرد.

استقرار فقط برای سرویسی ثبت می‌شود که service.version را گزارش می‌دهد. آن را همراه با محیط و کامیت، در ویژگی‌های منبع SDK یا کالکتور OpenTelemetry خود تنظیم کنید:

OTEL_RESOURCE_ATTRIBUTES="service.version=2.3.1,deployment.environment.name=production,vcs.ref.head.revision=$GIT_SHA"

به‌روزرسانی تدریجی به عامل Kubernetes نیاز دارد، که تله‌متری هر پاد را با Deployment و ReplicaSet آن مهر می‌زند.

ثبت یک استقرار از خط لوله#

یک خط لوله می‌تواند یک استقرار، یا هر تغییر دیگری، را همان لحظه که رخ می‌دهد ثبت کند: یک تغییر پیکربندی، یک مهاجرت، یک پرچم ویژگی. با یک کلید دریافت دادهٔ تله‌متری از پروژهٔ شما می‌نویسد، از همان نوعی که برنامه‌هایتان تله‌متری را با آن می‌فرستند. یکی را در تنظیمات پروژه → تله‌متری و APM → کلیدهای دریافت داده بسازید.

کلیدی که به یک سرویس سنجاق شده باشد، هر تغییری را زیر همان سرویس ثبت می‌کند.

oneuptime deploy \
  --service checkout \
  --service-version 2.3.1 \
  --commit "$GIT_SHA" \
  --environment production \
  --url https://status200.ru \
  --ingestion-key "$STATUS200_TELEMETRY_INGESTION_KEY"

- name: Record the deploy in Status200
  env:
    STATUS200_URL: https://status200.ru
    STATUS200_TELEMETRY_INGESTION_KEY: ${{ secrets.STATUS200_TELEMETRY_INGESTION_KEY }}
  run: |
    npx -y @status200/cli deploy \
      --service checkout \
      --service-version "${{ github.ref_name }}" \
      --commit "${{ github.sha }}" \
      --repository "${{ github.server_url }}/${{ github.repository }}" \
      --environment production

curl -X POST https://status200.ru/telemetry/change-events/v1/ingest \
  -H "Content-Type: application/json" \
  -H "x-status200-token: $STATUS200_TELEMETRY_INGESTION_KEY" \
  -d '{"events": [{"serviceName": "checkout", "version": "2.3.1", "commit": "1a2b3c4", "environment": "production"}]}'

روی یک Status200 خودمیزبان، به‌جای https://status200.ru نشانی خودتان را به کار ببرید. API پاسخ می‌دهد که چند رویداد را ذخیره کرد و چند تا را کنار گذاشت:

{ "ingested": 1, "skipped": 0 }

برای همهٔ گزینه‌های CLI، oneuptime deploy را ببینید.

Status200 AI چگونه از تغییرها استفاده می‌کند#

هر بررسی هوش مصنوعی برای یک حادثه یا هشدار از تغییرهایی آغاز می‌شود که در ۲ ساعت پیش از آن، و در ۱۰ دقیقهٔ پس از آن، ثبت شده‌اند؛ این ۱۰ دقیقه برای خط لوله‌ای است که استقرارش را پس از پایان به‌روزرسانی تدریجی ثبت می‌کند. تغییرهای روی سرویس‌ها، خوشه‌ها و میزبان‌هایی که حادثه به آن‌ها پیوند دارد، اول می‌آیند.

برای حداکثر ۴ تا از آن‌ها که نام یک سرویس را دارند، Status200 تله‌متری سرویس را در ۳۰ دقیقهٔ پیش و پس از تغییر می‌خواند، و اگر سرویس درست پس از تغییر به‌طور محسوسی بدتر شده باشد، آن تغییر را مشکوک علامت می‌زند:

Status200 از روی همین اعداد تصمیم می‌گیرد کدام تغییر مشکوک است، نه از روی آنچه عنوان یک تغییر می‌گوید. بررسی اول تغییر مشکوک را وارسی می‌کند، می‌گوید که آیا آن تغییر باعث حادثه شده است یا نه، و می‌گوید که آیا بازگرداندنش سریع‌ترین اصلاح امن است یا نه.

وقتی تغییر مشکوک یک به‌روزرسانی تدریجی Kubernetes روی خوشه‌ای باشد که اصلاح‌های هوش مصنوعی در آن روشن است، Status200 AI اول آن را بازمی‌گرداند، با یک kubectl rollout undo که Status200 از روی تغییر ثبت‌شده می‌سازد. استقراری که کد منتشر می‌کند از راه کامیت‌هایش بازگردانده می‌شود: بررسی، کامیت یا Pull Requestی را که مشکل را ایجاد کرده نام می‌برد، تا یک Pull Request اصلاحی بتواند دقیقاً همان را برگرداند.

Status200 همچنین هر استقرار را خودش وارسی می‌کند، چه کسی خبر شود چه نه. وقتی ۳۰ دقیقهٔ پس از یک استقرار گذشت، آن‌ها را با همان آستانه‌ها با ۳۰ دقیقهٔ پیش از آن مقایسه می‌کند، و اگر سرویس بدتر شده باشد، یک بینش هوش مصنوعی آن استقرار را روی همان سرویس نام می‌برد.

یک Pull Request اصلاحی که Status200 AI باز کرده نیز به همین شکل وارسی می‌شود: به‌محض اینکه یک استقرار ثبت‌شده کامیت آن را در خود داشته باشد، Status200 همان‌جا آنچه را اصلاح برایش بود زیر نظر می‌گیرد - استثنا، عملیاتی که سریع‌ترش کرده، مانیتورِ پشت حادثه یا هشدار، تله‌متری‌ای که می‌افزاید - و می‌گوید که آیا اصلاح جواب داد یا نه (ببینید اصلاح خودکار کد). اصلاحِ مستقرشده فقط وقتی در نسخه استقرار خوانده می‌شود که تله‌متری خود سرویس آن نسخه را گزارش کند، و در غیر این صورت از ۱۰ دقیقه پس از استقرار، وقتی نمونه‌های قدیمی متوقف شده‌اند.

در یک بررسی و در پرسش از هوش مصنوعی، recent_changes تغییرهای هر بازه‌ای را فهرست می‌کند، و get_change_details نشان می‌دهد که یک استقرار چه چیزی را منتشر کرد: کامیت‌ها از استقرار پیشین سرویس به این سو، نویسندگانشان، Pull Requestها و فایل‌هایی که تغییر دادند. این کار به کامیتِ ثبت‌شده روی تغییر و مخزنی نیاز دارد که از طریق GitHub App متصل شده باشد.

مرجع#

فیلدها#

فیلدهای سطح بالا به‌صورت ویژگی با نام‌های OpenTelemetry ذخیره می‌شوند: version به‌صورت service.version، commit به‌صورت vcs.ref.head.revision، repository به‌صورت vcs.repository.url.full، branch به‌صورت vcs.ref.head.name، pullRequest به‌صورت vcs.change.id و environment به‌صورت deployment.environment.name. ویژگی‌ای که با یکی از این نام‌ها فرستاده شود بر فیلد متناظرش مقدم است.

ویژگی‌هایی که نامشان با status200. آغاز می‌شود متعلق به خود Status200 هستند و از آنچه یک خط لوله می‌فرستد حذف می‌شوند. هر تغییری که یک خط لوله ثبت می‌کند این را در status200.change.source می‌گوید، که مقدارش api است.

محدودیت‌ها#

گام‌های بعدی#