डिप्लॉय और बदलाव

Status200 आपके प्रोजेक्ट में हुए बदलावों का रिकॉर्ड रखता है: डिप्लॉय, Kubernetes रोलआउट, कॉन्फ़िगरेशन बदलाव, और वे सुधार जो उसने खुद चलाए। हर बदलाव उसकी सेवा के चार्ट पर एक मार्कर के रूप में दिखाया जाता है, और Status200 AI किसी घटना की जांच करते समय उन्हें पढ़ता है, ताकि "यह 10:02 वाले डिप्लॉय के ठीक बाद शुरू हुआ" वह पहली बात हो जो आपको पता चले, आख़िरी नहीं।

यह कैसे काम करता है#

Status200 अपने आप क्या रिकॉर्ड करता है#

इनके लिए आपको कुछ भी भेजने की ज़रूरत नहीं है। Status200 इन्हें उस टेलीमेट्री से रिकॉर्ड करता है जो उसे पहले से मिल रही है, और उससे जो वह खुद करता है।

• कोई सेवा जो पहला संस्करण रिपोर्ट करती है, वह उसकी बेसलाइन है, डिप्लॉय नहीं। महीनों से चल रही कोई सेवा उस पल डिप्लॉय नहीं होती जब Status200 उसकी टेलीमेट्री पाना शुरू करता है।
• पिछले 30 दिनों में देखे गए किसी संस्करण पर रोलबैक रिकॉर्ड नहीं होता, क्योंकि वह संस्करण नया नहीं है। Status200 AI जो रोलबैक चलाता है, वह सुधार के रूप में रिकॉर्ड होता है।
• एक घंटे में 6 से ज़्यादा नए संस्करण या ReplicaSet आने पर, घंटा पूरा होने तक वे रिकॉर्ड होना बंद हो जाते हैं। वरना हर पॉड के साथ बदलने वाला कोई "संस्करण", जैसे बिल्ड टाइमस्टैम्प, हर पॉड के लिए एक डिप्लॉय रिकॉर्ड कर देता।

डिप्लॉय सिर्फ़ उसी सेवा के लिए रिकॉर्ड होता है जो service.version रिपोर्ट करती है। इसे एनवायरनमेंट और कमिट के साथ, अपने OpenTelemetry SDK या कलेक्टर के रिसोर्स एट्रिब्यूट में सेट करें:

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 बदलावों का उपयोग कैसे करता है#

किसी घटना या अलर्ट की हर AI जांच उन बदलावों से शुरू होती है जो उससे पहले के 2 घंटों में, और उसके बाद के 10 मिनट में रिकॉर्ड हुए; बाद के ये 10 मिनट उस पाइपलाइन के लिए हैं जो रोलआउट पूरा होने के बाद अपना डिप्लॉय रिकॉर्ड करती है। जिन सेवाओं, क्लस्टर और होस्ट से घटना जुड़ी है, उन पर हुए बदलाव सबसे पहले आते हैं।

इनमें से अधिकतम 4 बदलावों के लिए, जो किसी सेवा का नाम बताते हैं, Status200 बदलाव से पहले और बाद के 30 मिनट में उस सेवा की टेलीमेट्री पढ़ता है, और अगर बदलाव के ठीक बाद सेवा मापने लायक रूप से बिगड़ गई, तो उस बदलाव को संदिग्ध चिह्नित करता है:

Status200 इन संख्याओं से तय करता है कि कौन-सा बदलाव संदिग्ध है, इससे नहीं कि बदलाव का शीर्षक क्या कहता है। जांच सबसे पहले संदिग्ध बदलाव को परखती है, बताती है कि क्या घटना उसी से हुई, और बताती है कि क्या उसे रोलबैक करना सबसे तेज़ सुरक्षित सुधार है।

जब संदिग्ध बदलाव किसी ऐसे क्लस्टर पर Kubernetes रोलआउट हो जिसके AI सुधार चालू हैं, तो Status200 AI सबसे पहले उसे रोलबैक करता है, एक kubectl rollout undo से जिसे Status200 रिकॉर्ड किए गए बदलाव से बनाता है। कोड भेजने वाले डिप्लॉय को उसके कमिट के ज़रिए रोलबैक किया जाता है: जांच उस कमिट या पुल रिक्वेस्ट का नाम बताती है जिससे चीज़ें बिगड़ीं, ताकि एक फ़िक्स पुल रिक्वेस्ट ठीक उसी को वापस ले सके।

Status200 हर डिप्लॉय को अपने आप भी परखता है, चाहे किसी को सूचित किया जाए या नहीं। डिप्लॉय के बाद के 30 मिनट बीत जाने पर, वह उन्हें उन्हीं सीमाओं के हिसाब से डिप्लॉय से पहले के 30 मिनट से मिलाता है, और अगर सेवा बिगड़ गई, तो एक AI इनसाइट उस सेवा पर हुए डिप्लॉय का नाम बताती है।

Status200 AI ने जो सुधार पुल रिक्वेस्ट खोला हो, उसे भी इसी तरह परखा जाता है: जैसे ही किसी रिकॉर्ड किए गए डिप्लॉय में उसका कमिट होता है, Status200 वहाँ उस पर नज़र रखता है जिसके लिए सुधार था - अपवाद, वह ऑपरेशन जिसे उसने तेज़ किया, इंसिडेंट या अलर्ट के पीछे का मॉनिटर, वह टेलीमेट्री जो वह जोड़ता है - और बताता है कि सुधार कारगर रहा या नहीं (स्वचालित कोड सुधार देखें)। डिप्लॉय हुए सुधार को डिप्लॉय के संस्करण में तभी पढ़ा जाता है जब सेवा की अपनी टेलीमेट्री वह संस्करण बताती है, वरना डिप्लॉय के 10 मिनट बाद से, जब पुराने इंस्टेंस रुक चुके हों।

किसी जांच में और AI से पूछें में, recent_changes किसी भी समय-अवधि के बदलाव सूचीबद्ध करता है, और get_change_details दिखाता है कि किसी डिप्लॉय ने क्या भेजा: सेवा के पिछले डिप्लॉय के बाद के कमिट, उनके लेखक, पुल रिक्वेस्ट और वे फ़ाइलें जिन्हें उन्होंने बदला। इसके लिए बदलाव पर कमिट और 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 होता है।

सीमाएँ#

अगले कदम#