> ## Documentation Index
> Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt
> Use this file to discover all available pages before exploring further.

# فرز المشكلات وحلّها في LogBrew

> أدِر المشكلات في LogBrew. اقرأ أدلة الحدوث، واعرف مالك المشكلة، ثم حُلّها أو أرشفها أو أعد فتحها أو حدّد أولويتها أو أسندها إلى شخص أو فريق.

تجمع المشكلة مرات حدوث الأخطاء التي تشترك في بصمة واحدة. اقرأ ملخص المجموعة
وحدوثًا واحدًا قبل أن تغيّر الحالة أو الأولوية أو المسؤول. تغيير الحالة أو
الأولوية أو المسؤول يوثّق قرارًا للفريق. ولا يصلح البرنامج ولا يعيد كتابة الأحداث
الملتقَطة.

ثبّت [LogBrew CLI](/ar/guides/cli) وشغّل `logbrew login` قبل أن تبدأ.

## المشكلات ومرات الحدوث

تُرجع قائمة المشكلات ملخصًا للمجموعة، وليس حدثًا كاملًا. اقرأ هذه الحقول قبل أن
تفتح التفاصيل:

| الحقل | المعنى |
| - | - |
| `title` | عنوان الإخفاق الملتقَط. |
| `severity` | الخطورة الملتقَطة. |
| `triage.effective_severity` | الخطورة التي يستخدمها LogBrew بعد تطبيق قواعد المشكلات. ويحتفظ `severity` بالقيمة الملتقَطة. وتكون `triage.rule_applied` بالقيمة `true` عندما تنطبق قاعدة. |
| `occurrence_count` | عدد مرات الحدوث المحتفَظ بها في المجموعة. |
| `first_seen_at` | وقت أقدم حدوث محتفَظ به. |
| `last_seen_at` | وقت أحدث حدوث محتفَظ به. |
| `project_id` | المشروع الذي يحتوي على المشكلة. |
| `service_name` | خدمة أحدث حدوث. |
| `release` | إصدار أحدث حدوث. |
| `environment` | بيئة أحدث حدوث. |
| `status` | حالة المشكلة في سير العمل. راجع [قيم الحالة](#status-values). |
| `priority` | ترتيب المشكلة في الفرز. راجع [الأولوية](#priority). |
| `priority_source` | `manual` عندما يحدد شخص الأولوية. و`derived` عندما تتبع الأولوية الخطورة. |
| `assignee` | الحساب أو الفريق المسؤول عن الخطوة التالية، أو `null`. راجع [إسناد المشكلات](#assign-issues). |

عدد مرات الحدوث ليس عدد المستخدمين المتأثرين. تنطبق الأعداد والأوقات على النطاق
المُرجَع، لا على تاريخ الأخطاء كله. ويحدّ عامل التصفية `--since` أو `--until`
من مرات الحدوث التي يعدّها LogBrew. عندما تُبلغ عن عدد، فاذكر معه عوامل التصفية
التي أنتجته.

## <span id="status-values">قيم الحالة</span>

| الحالة | المعنى |
| - | - |
| `unresolved` | تحتاج المشكلة إلى قرار. |
| `resolved` | وضع الفريق علامة على أن المشكلة أُصلحت. الحالة لا تُثبت الإصلاح. |
| `archived` | أخرج الفريق المشكلة من الفرز النشط. |

كان اسم `archived` سابقًا `ignored`. يختار الاسمان المشكلات نفسها، ويُقبل كلاهما
في الإدخال. يعرض `logbrew read` و`logbrew issues` والإصداران 2 و3 من الـ API
القيمة `archived`. أما الإصدار 1 من الـ API (الافتراضي)، وبثّ المتابعة المباشرة،
واستجابة التحقيق في المشكلة فتعرض `ignored`. وتعرض لوحة التحكم هذه الحالات
بالأسماء «غير محلولة» و«محلولة» و«مؤرشفة».

تنطبق الحالة على المشكلة كلها، لا على حدوث واحد. تُظهر الخطورة درجة الإلحاح،
وتوثّق الحالة القرار. أبقِ الاثنين منفصلين. يمكن أن تصبح مشكلة `critical` بالحالة
`resolved` بعد إصلاح تم التحقق منه. وتحتفظ المشكلة `archived` بخطورتها الملتقَطة.

لا يعيد LogBrew فتح مشكلة محلولة تلقائيًا. عندما يصل حدوث جديد بعد الحل، يُبلغ
التحقيق عن `lifecycle.effective_status` بالقيمة `regressed`. وتبقى قيمة `status`
هي `resolved` إلى أن يعيد شخص فتح المشكلة.

## <span id="priority">الأولوية</span>

تحدد الأولوية الترتيب الذي يفرز به الفريق المشكلات:

| الأولوية | المعنى |
| - | - |
| `high` | افحص المشكلة أولًا. |
| `medium` | افحص المشكلة بعد المشكلات `high`. |
| `low` | يمكن أن تنتظر المشكلة. |

لكل مشكلة أولوية. إذا لم يحددها أحد، فإنها تتبع خطورة المشكلة: `error`
و`critical` تعطيان `high`، و`warning` تعطي `medium`، و`info` تعطي `low`.
عندما تغيّر قاعدة مشكلات الخطورة، تتبع الأولوية `triage.effective_severity`.
وعندها تكون قيمة `priority_source` هي `derived`. وعندما يحدد شخص الأولوية، تبقى
ثابتة وتكون قيمة `priority_source` هي `manual`.

لعرض المشكلات التي يجب فحصها أولًا:

```bash theme={null}
logbrew read issues --project "<project_id>" --status unresolved \
  --priority high --since 24h --json
```

## <span id="assign-issues">إسناد المشكلات</span>

أسند المشكلة لتوضّح من المسؤول عن الخطوة التالية. عدد المسؤولين عن المشكلة 0
أو 1: حساب واحد أو فريق واحد.

<Steps>
  <Step title="اعرف من يمكن إسناد المشكلة إليه">
    ```bash theme={null}
    logbrew issues assignees --project "<project_id>" --json
    ```

    تضم `assignees` كل حساب يستطيع قراءة المشروع، مع `user_id` و`name`
    و`email`. وتضم `teams` كل فريق في المؤسسة التي يتبعها المشروع، مع `team_id`
    و`slug` و`name`. لا يمكنك إسناد مشكلة إلى حساب لا يستطيع قراءة المشروع، ولا
    إلى فريق من مؤسسة أخرى.
  </Step>

  <Step title="أسند المشكلة">
    ```bash theme={null}
    logbrew issues assign "<user_id>" "<issue_id>" --json
    logbrew issues assign "team:<team_id>" "<issue_id>" --json
    ```

    استخدم `me` بدلًا من معرّف المستخدم لإسناد المشكلة إلى نفسك. واستخدم
    `logbrew issues unassign "<issue_id>" --json` لإزالة المسؤول. أضف
    `--project` لتغيير ما يصل إلى 100 مشكلة في مشروع واحد.
  </Step>

  <Step title="اقرأ مشكلاتك">
    ```bash theme={null}
    logbrew read issues --project "<project_id>" --assignee me \
      --status unresolved --json
    ```

    استخدم `--assignee my_teams` لمشكلات فرقك، و`--assignee "team:<team_id>"`
    لفريق واحد، و`--assignee none` للمشكلات التي ليس لها مسؤول.
  </Step>
</Steps>

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

عندما يفقد عضو الوصول إلى المشروع، لا تُظهر المشكلات المُسندة إليه أي مسؤول.
وعندما يُحذف فريق، لا تُظهر المشكلات المُسندة إليه أي مسؤول كذلك. وتظهر هذه
المشكلات في القراءات باستخدام `--assignee none`. إذا استعاد العضو الوصول، تُظهره
المشكلات مسؤولًا مرة أخرى، ما لم يغيّر أحد المسؤول أو يُزِله في هذه الأثناء.

## <span id="find-who-owns-an-issue">اعرف مالك المشكلة</span>

```bash theme={null}
logbrew issues owners "<issue_id>" --json
```

تعرض النتيجة المالكين المقترحين، الأنسب أولًا، ومعهم `suggested_assignee`. ولكل
مالك قيمة `source`:

| `source` | المعنى |
| - | - |
| `ownership_rule` | قاعدة من قواعد المشروع تطابق المشكلة. وتُظهر `rule` و`line` و`matched` القاعدة وما طابقته. |
| `codeowners` | سطر من ملف CODEOWNERS في المشروع يطابق مسار إطار في المكدّس. |
| `recent_activity` | غيّر الحساب المشكلة أو أُسندت إليه. |

تعدّ `inputs` ما فحصه LogBrew من مسارات إطارات المكدّس والوحدات وقالب المسار
والوسوم والقواعد. إذا كانت القائمة فارغة ولم تُظهر `inputs` أي مسارات، فهذا يعني
أن المشكلة لا تحمل أدلة يمكن مطابقتها، لا أنها بلا مالك.

اكتب قواعد الملكية في ملف نصي، قاعدة واحدة في كل سطر:

```text theme={null}
# type:pattern owner...
path:src/payments/** ada@example.com #payments
url:/checkout/* #web
service:billing-api ada@example.com
tags.region:eu-* #europe
module:app.billing.* ada@example.com
```

يطابق نمط `path` نهاية مسار إطار المكدّس، لذلك يطابق `src/payments/**` الإطارات
داخل أي مجلد نشر. ويطابق `*` أي نص. المالكون عناوين بريد إلكتروني لحسابات أو
`#team-slug`. وتأتي آخر قاعدة مطابِقة أولًا. ثم أرسل القواعد، أو ملف CODEOWNERS
من GitHub، أو كليهما:

```bash theme={null}
logbrew issues ownership set --project "<project_id>" \
  --rules ownership.txt --codeowners .github/CODEOWNERS --json
logbrew issues ownership --project "<project_id>" --json
```

في CODEOWNERS، يشير البريد الإلكتروني إلى حساب، ويشير `@org/team-slug` إلى
الفريق الذي يحمل ذلك الـ slug. والقواعد التي تذكر حسابًا بلا وصول إلى المشروع أو
فريقًا غير معروف تفشل مع `422`. ومالكو CODEOWNERS الذين لا يشيرون إلى أحد يظهرون
في `unresolved_owners`. والملف الفارغ يمسح نصه.

## <span id="read-the-issue-history">اقرأ تاريخ المشكلة</span>

```bash theme={null}
logbrew issues activity "<issue_id>" --json
```

يعرض التاريخ كل تغيير في الحالة والأولوية والمسؤول وقاعدة الخطورة، الأحدث أولًا،
مع الحساب الذي أجراه. وينتهي بـ `first_seen`. والحساب الذي فقد الوصول إلى المشروع
لا يبقى منه إلا معرّفه. استخدم `--limit` وقيم `next_cursor` لقراءة المزيد.

## <span id="read-your-inbox">اقرأ صندوق الوارد</span>

```bash theme={null}
logbrew inbox --json
logbrew inbox read --json
```

يعرض صندوق الوارد المشكلات التي أسندها إليك أو إلى فرقك أشخاص آخرون، الأحدث
أولًا. وتعدّ `unread` الإسنادات التي جاءت بعد علامة القراءة. ويحرّك
`logbrew inbox read` علامة القراءة إلى الآن. لا يرسل LogBrew بريدًا إلكترونيًا
عن هذه الإسنادات. ولا يعرض صندوق الوارد إلا المشاريع التي تستطيع قراءتها الآن.

## سير العمل الموصى به

<Steps>
  <Step title="اعرض المشكلات غير المحلولة في نطاق واحد">
    ```bash theme={null}
    logbrew read issues --project "<project_id>" --environment production \
      --release api@1.2.3 --status unresolved --since 24h --json
    ```

    أبقِ عوامل التصفية نفسها في القراءات اللاحقة للقائمة. النتيجة الفارغة تعني
    أنه لا توجد مشكلة تطابق هذا النطاق، ولا تُثبت أن المشروع خالٍ من الأخطاء.
    انسخ معرّف المشكلة نفسه تمامًا، لا عنوانها.
  </Step>

  <Step title="اقرأ تفاصيل المشكلة">
    ```bash theme={null}
    logbrew read issue "<issue_id>" --json
    ```

    تأكد من أن المشروع المُرجَع صحيح قبل أن تتابع. تُرجع القراءات لقطة. اقرأ
    المشكلة مرة أخرى قبل أن تغيّر الحالة.
  </Step>

  <Step title="حقّق في حدوث واحد">
    ```bash theme={null}
    logbrew investigate issue "<issue_id>" --occurrence recommended --json
    ```

    لا تستخدم قراءات التفاصيل والتحقيق عوامل تصفية القائمة. قارن
    `subject.project_id` و`event.occurred_at` والإصدار والبيئة بنطاقك. قد يكون
    الحدوث الموصى به أقدم من أحدث حدوث. اتبع
    [التحقيق في مشكلة](/ar/guides/investigate-an-issue) لمراجعة الأدلة كاملة.
  </Step>

  <Step title="اتبع أدلة التتبّع فقط عندما تكون متاحة">
    اقرأ التتبّع فقط عندما تكون قيمة `correlations.trace.status` هي `available`.
    استخدم معرّف التتبّع الوارد في الاستجابة. لا تختلق معرّفًا أبدًا.

    ```bash theme={null}
    logbrew read trace "<trace_id>" --project "<project_id>" --json
    logbrew read logs --trace "<trace_id>" --project "<project_id>" \
      --since 24h --json
    ```

    لا تقبل قراءة التتبّع عامل تصفية زمنيًا. إذا كانت الحالة `not_linked`،
    فتابع بأدلة المشكلة.
  </Step>

  <Step title="تحقّق من النشر المرشّح">
    استخدم الحدوث الذي حقّقت فيه حدوثًا مرجعيًا. احصل على معرّف النشر من أدلة
    النشر أو من عملية الإصدار لديك.

    ```bash theme={null}
    logbrew investigate issue "<issue_id>" verify \
      --baseline-occurrence "<occurrence_id>" \
      --candidate-deployment "<deployment_id>" \
      --json
    ```

    عدم تكرار المشكلة خلال نافذة المراقبة لا يُثبت أن الإصلاح دائم. إذا كانت
    قيمة `status` هي `insufficient_traffic` أو `unavailable`، فأبقِ المشكلة
    `unresolved`. اتبع الإجراء التالي المُرجَع.
  </Step>

  <Step title="غيّر الحالة أو الأولوية أو المسؤول">
    شغّل أمرًا واحدًا. لا تطلب هذه الأوامر تأكيدًا، لذا تحقّق من معرّف المشكلة
    أولًا.

    ```bash theme={null}
    logbrew issues resolve "<issue_id>" --json
    logbrew issues archive "<issue_id>" --json
    logbrew issues reopen "<issue_id>" --json
    logbrew issues priority low "<issue_id>" --json
    logbrew issues assign me "<issue_id>" --json
    ```

    دون `--project`، يقبل كل أمر معرّف مشكلة واحدًا. تحقّق من رمز الخروج ومن
    قيم `status` و`priority` و`assignee` المُرجَعة. إذا غابت النتيجة، فاقرأ
    المشكلة مرة أخرى قبل التغيير التالي.

    يمكن للبرامج النصية الأقدم استخدام `logbrew set issue "<issue_id>" resolved`
    والاختصارات `resolve` و`ignore` و`reopen`. يضبط `ignore` الحالة
    `archived`.
  </Step>
</Steps>

## تغيير عدة مشكلات دفعة واحدة

أضف `--project` لتغيير ما يصل إلى 100 مشكلة في مشروع واحد بأمر واحد:

```bash theme={null}
logbrew issues archive "<issue_id_1>" "<issue_id_2>" "<issue_id_3>" \
  --project "<project_id>" --json
```

يطبّق الأمر تغييرًا واحدًا على كل مشكلة. ولا يجوز أن يظهر معرّف المشكلة إلا مرة
واحدة. يرفض الـ CLI أكثر من 100 معرّف أو أي معرّف مكرر قبل أن يرسل الطلب. وتحتوي
النتيجة على عنصر واحد لكل مشكلة، بترتيب الأمر:

| النتيجة | المعنى |
| - | - |
| `updated` | طبّق LogBrew التغيير. |
| `unchanged` | كانت للمشكلة القيمة المطلوبة من قبل. |
| `not_found` | لا توجد في المشروع مشكلة بهذا المعرّف. ولم يغيّر LogBrew شيئًا لها. |

لكل عنصر `issue_id` و`outcome` و`issue`. و`issue` هي المشكلة بحالتها الحالية،
أو `null` في حالة `not_found`. يمكنك تشغيل الأمر نفسه مرة أخرى بعد فشل في
الشبكة. فالمشكلات التي تغيّرت تُظهر `unchanged`. لأكثر من 100 مشكلة، شغّل أوامر
إضافية. وفي حالة النتيجة `not_found`، انسخ المعرّف مرة أخرى من قائمة مشكلات ذلك
المشروع. راجع
[تحديث المشكلات دفعة واحدة](/ar/reference/telemetry-api#update-issues-in-bulk)
لمعرفة طلب الـ API.

## اختر الحالة التالية

* **أبقِها `unresolved`** عندما يكون الإخفاق نشطًا أو لم يتم التحقق من الإصلاح.
  غياب التتبّع ليس سببًا لأرشفة المشكلة.
* **اضبط `resolved`** بعد أن يقبل الفريق أدلة الإصلاح. الإصلاح المقترح ليس
  دليلًا.
* **اضبط `archived`** لحالة مقبولة أو لإشارة خاصة بالاختبار فقط. ينطبق القرار
  على كل مرات حدوث المشكلة. لا يحتوي الأمر على حقل للسبب، لذا دوّن السبب في
  قيود العمل لدى فريقك.
* **أعد الفتح بالقيمة `unresolved`** عندما يصل حدوث جديد بعد الحل. يحدده
  `lifecycle.regression.first_reappeared_occurrence`. قارنه بالحدوث الذي
  استُخدم للحل. لا تنشئ مشكلة مختلفة.

## تسليم التحقيق

أعطِ الشخص التالي مراجع، لا تفريغًا خامًا للأحداث:

* معرّف المشكلة وحالتها وأولويتها والمسؤول عنها وخطورتها.
* المشروع والخدمة والبيئة والإصدار.
* وقت أول ظهور ووقت آخر ظهور وعدد مرات الحدوث.
* معرّف الحدوث المحدد و`occurrence_selection.reason`.
* `fix.status` و`cause.status` وقيمة `provenance` لكل منهما.
* حالة التتبّع ومعرّفه، إن كانا متاحين.
* حالة إعادة الإنتاج والأدلة المفقودة.
* نتيجة التحقق من النشر المرشّح.
* الإجراء التالي الذي أرجعته الاستجابة.

صنّف الأسباب والإصلاحات المقترحة على أنها مقترحات.

## الاستعادة من أخطاء الـ CLI

تحقّق من رمز خروج العملية قبل أن تحلّل المخرجات. عند النجاح، يذهب JSON إلى
المخرجات القياسية. خطأ التحليل ينتهي برمز الخروج `2`. وخطأ وقت التشغيل ينتهي
برمز الخروج `1`. تذهب أخطاء JSON إلى الخطأ القياسي وتحتوي على `ok: false`
و`error` و`message` و`next`. اعرض `next` على أنه إرشاد، ولا تشغّله تلقائيًا.

مثلًا، الأمر `logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json`
لا يحتوي على `--project`. لذلك ينتهي برمز الخروج `2` قبل إرسال أي طلب، مع الخطأ
`invalid_issue_command`.

عندما يرفض الـ API طلبًا، تكون قيمة `error` هي `api_error`. اقرأ `status` لمعرفة
حالة HTTP، و`api_code` لمعرفة رمز خطأ الـ API.

| النتيجة | الاستعادة |
| - | - |
| `not_logged_in` | اطلب من شخص تشغيل `logbrew login`، ثم أعد محاولة القراءة. |
| `invalid_issue_command` | صحّح الأمر. استخدم `--project` لأكثر من مشكلة واحدة، وبحد أقصى 100 معرّف، وكل معرّف مرة واحدة. |
| معرّف مشكلة غير صالح | انسخ المعرّف نفسه تمامًا من قائمة المشكلات أو من استجابة التفاصيل. |
| المشكلة غير موجودة | تأكد من الحساب الذي سجّلت الدخول به ومن المشروع. |
| يفشل تغيير مع `status` بالقيمة `403` | لا يستطيع الحساب إدارة المشكلات في هذا المشروع. اطلب ذلك من شخص لديه الصلاحية. |
| `invalid_assignee` | يقبل عامل التصفية `--assignee` القيمة `me` أو `none` أو `my_teams` أو معرّف مستخدم أو `team:<team_id>`. |
| يفشل الإسناد مع `status` بالقيمة `422` و`api_code` بالقيمة `validation_failed` | لا يستطيع الحساب قراءة المشروع، أو الفريق ليس من مؤسسة المشروع. اختر واحدًا من `logbrew issues assignees`. |
| `invalid_ownership_command`، `invalid_ownership_file` | صحّح الأمر. يجب أن يكون ملف الملكية نصًا بترميز UTF-8 لا يتجاوز 128 KiB. |
| `invalid_inbox_command` | استخدم `logbrew inbox` أو `logbrew inbox read`. |
| `investigation_response_invalid` | فشلت الاستجابة في تحقق الـ CLI. أعد المحاولة مرة واحدة. إذا تكرر الخطأ، فحدّث الـ CLI أو أبلغ عن المشكلة. لا تتجاوز التحقق. |
| حالة التتبّع `not_linked` | تابع بأدلة المشكلة. لا تقرأ تتبّعًا. |
| حالة التتبّع `unavailable` | أعد محاولة قراءة التحقيق لاحقًا. |
| نتيجة التحقق `insufficient_traffic` | أبقِ المشكلة `unresolved`. انتظر وصول حركة مرور إلى الإصدار المرشّح، ثم تحقّق مرة أخرى. |

الاستجابة الفاشلة لا تُثبت أن تغيير الحالة أو الأولوية أو المسؤول لم يُحدث أثرًا.
اقرأ المشكلة قبل أن تحاول مرة أخرى.

## ما الذي يجعل المشكلة مفيدة

* عنوان واضح ورسالة مقروءة.
* بصمة ثابتة.
* إطارات المكدّس، عندما تكون متاحة.
* سياق الإصدار والبيئة والخدمة.
* سياق التتبّع، عندما يُلتقَط مع الحدوث.
* سمات صغيرة وذات صلة، لا تفريغات كاملة للحمولة.

راجع [مرجع Telemetry API](/ar/reference/telemetry-api) لمعرفة عوامل
تصفية القوائم وعقود الاستجابات.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.