Skip to main content
أنشئ تذكرة دعم عندما تحتاج مشكلة إلى متابعة. بعدها يمكن لشخص أو لوكيل ذكاء اصطناعي متابعة التذكرة وإضافة السياق المطلوب. لا يقرأ التذكرة إلا الحساب الذي أنشأها وفريق الدعم في LogBrew.
استخدم رمز Bearer للحساب، مثل $LOGBREW_TOKEN. لا تستخدم أبدًا مفتاح استيعاب المشروع. أزل البيانات الخاصة قبل أن تكتب العنوان أو الوصف أو بيانات التشخيص. الحجب التلقائي لا يغني عن هذه المراجعة.

إنشاء تذكرة

من CLI، شغّل:
يضبط CLI قيمة source على cli. يضيف --diagnostics اسم الملف التنفيذي ونسخة CLI ونظام التشغيل والمعمارية فقط. شغّل logbrew support --help لعرض كل الخيارات. لا يرسل CLI مفتاح إعادة محاولة عند إنشاء التذكرة. إذا لم تكن النتيجة مؤكدة، فشغّل logbrew support list --json قبل أن تشغّل الأمر مرة أخرى. وإلا فقد تنشئ تذكرة ثانية. من الـ API، أرسل POST /api/support/tickets مع source وcategory وtitle وdescription. لتكون إعادة المحاولة آمنة، أنشئ مفتاح إعادة محاولة مرة واحدة للبلاغ، وأرسله في الترويسة Idempotency-Key. يستخدم هذا المثال قيمًا اصطناعية:
يتكون مفتاح إعادة المحاولة من 1 إلى 128 حرف ASCII مرئيًا، بلا مسافات. لإعادة المحاولة، أرسل المفتاح نفسه مع نص الطلب نفسه، فتُرجع الاستجابة التذكرة نفسها. استخدم مفتاحًا جديدًا لكل بلاغ مختلف. انتهاء المهلة لا يثبت أن الإنشاء فشل. الترويسة Idempotency-Key اختيارية. ومن دونها، قد ينشئ الطلب المكرر تذكرة أخرى. الحقول الاختيارية هي project_id وenvironment وruntime وframework وsdk_package وsdk_version وrelease وtrace_id وevent_id وdiagnostics. احذف project_id عندما لا تخص المشكلة مشروعًا معيّنًا. ويجب أن يحدد project_id مشروعًا نشطًا في حسابك. يُرجع الطلب الناجح HTTP 200:
تبدأ معرّفات التذاكر بـ sup_. استخدم next إرشادًا للشخص، وnext_action للتحكم في البرنامج. لحذف مشروع، استخدم إعدادات المشروع أو logbrew projects delete. لا تطلب حذف مشروع في تذكرة دعم.

كتابة بلاغ مفيد

  • أبلغ عن مشكلة واحدة في كل تذكرة.
  • اختر أقرب category. لا تستخدم other إلا عندما لا تناسب أي فئة.
  • اذكر في title عَرَضًا واحدًا وواجهة واحدة.
  • اكتب description في صورة خطوات، ثم النتيجة المتوقعة والنتيجة الملاحَظة.
  • أضف معرّفات المشروع أو الإصدار أو التتبّع أو الحدث فقط عندما تحدد العطل نفسه.
استخدم مفاتيح diagnostics التالية: diagnostics كائن JSON بحجم يصل إلى 16 KB بعد الحجب. يستبدل LogBrew القيمة بـ [redacted] عندما يدل مفتاحها على بيانات اعتماد أو جلسة أو عنوان بريد إلكتروني. ويستبدل أيضًا النص الذي يشبه بيانات اعتماد أو عنوان URL أو مسارًا محليًا. ويقصّر LogBrew كذلك النصوص الطويلة، ويحدّ من التداخل والمفاتيح وعناصر القوائم. لا تعتمد على هذا الحجب. أزل البيانات الخاصة قبل أن ترسل الطلب.

متابعة التذكرة

تقبل القائمة project_id وstatus وsource وcategory وrelease وlimit. القيمة الافتراضية لـ limit هي 100، والحد الأقصى 500. لترقيم الصفحات بالمؤشر، أرسل pagination=cursor. في الصفحات التالية، كرر عوامل التصفية نفسها، وأرسل cursor_time وcursor_id من next_cursor. معرّف المؤشر هو معرّف تذكرة يبدأ بـ sup_. توقف عندما تكون قيمة next_cursor هي null. يستخدم CLI الخيارات --project و--status و--source و--category و--release و--limit و--pagination و--cursor-time و--cursor-id. قيم الحالة هي open وrouted وin_progress وwaiting_on_user وresolved وclosed. يمكنك ضبط open أو closed فقط. طلب الإغلاق أو إعادة الفتح المكرر ينجح دون أن يغيّر شيئًا، لذلك يمكنك إعادة الطلب نفسه تمامًا. اتبع الحالة المُرجَعة وnext_action:

إضافة السياق المطلوب

ردّ عندما تطلب التذكرة سياقًا. تكون حالة هذه التذكرة waiting_on_user، وقيمة next_action.code هي provide_context.
يحتوي نص طلب الـ API على context وdiagnostics الاختياري. يجب أن يحتوي نص context على 1 إلى 4,000 حرف. لا تضع بيانات اعتماد أو عناوين URL أو أسماء مضيفين أو مسارات محلية في context. يرفض الـ API هذا النص مع 422. أرسل مفتاح إعادة محاولة في الترويسة Idempotency-Key، فمسار السياق يتطلب هذه الترويسة. يتكون المفتاح من 1 إلى 128 حرف ASCII مرئيًا، بلا مسافات. استخدم مفتاحًا جديدًا لكل رد، ولا تُعِد استخدام المفتاح إلا لإعادة محاولة الرد نفسه. يقبل الـ API السياق ما دامت التذكرة open أو routed أو in_progress أو waiting_on_user. ويقبل ردًا واحدًا لكل حالة من حالات التذكرة. بعد الرد، انتظر تغيّر الحالة قبل أن ترسل مزيدًا من السياق. الرد على تذكرة حالتها waiting_on_user يضبط حالتها على open. اقرأ status المُرجَعة بدلًا من افتراض هذا التغيير. يُرجع الرد الناجح ticket_id وcontext_id وstatus وcreated_at وnext وnext_action. يبدأ context_id بـ ctx_. اقرأ التذكرة مرة أخرى قبل أن تجيب عن أي طلب لاحق. يُرجع GET /api/support/tickets/{ticket_id}/context أحدث 20 إدخال سياق، من الأقدم إلى الأحدث. لكل إدخال context_id وcontext وdiagnostics وcreated_at. هذه القائمة بلا مؤشر. الرد على تذكرة حالتها resolved أو closed يُرجع 422 مع code: "validation_failed". لا تُعِد فتح التذكرة إلا إذا أراد المستخدم متابعة طلب الدعم هذا. لا يمنح next_action الوكيل إذنًا بتغيير حالة الحساب.

التعافي من الأخطاء

تحتوي استجابات الأخطاء على error وcode وnext وnext_action. راجع أخطاء API.

الحفاظ على أمان البلاغ

لا ترسل أبدًا أسرارًا أو رموزًا مميزة أو ترويسات تفويض أو مفاتيح استيعاب أو سجلات خامًا أو بيانات عملاء أو مسارات محلية أو أسماء مضيفين أو شيفرة مصدرية لا علاقة لها بالمشكلة. أرسل ملخصًا قصيرًا ومحجوبًا. للفحوص التي تجريها بنفسك، راجع استكشاف الأخطاء وإصلاحها.