Skip to main content
يقبل كل مسار قراءة مفاتيح استعلام خاصة به. ويرفض المسار الوارد في مصفوفة عوامل التصفية أي مفتاح غير معروف أو قيمة من نوع خاطئ، فيُرجع 422 وvalidation_failed، ما لم تذكر المصفوفة غير ذلك. الأسماء البديلة المختصرة مثل project وtrace وuser ليست مفاتيح استعلام. لا تنقل عامل تصفية من مسار إلى آخر.

إنشاء طلب مع عوامل التصفية

ضع سلسلة الاستعلام بعد المسار. استخدم --data-urlencode حتى تبقى الأحرف المحجوزة آمنة. يقرأ هذا الطلب السجلات الحرجة لمشروع واحد خلال آخر 24 ساعة:
أضف عوامل التصفية بهذا الترتيب:
  1. اختر المشروع باستخدام project_id أو project_ids.
  2. أضف نطاقًا زمنيًا باستخدام since، ويمكنك إضافة until.
  3. أضف عوامل تصفية الخدمة أو الإصدار أو البيئة أو الحالة أو العوامل الخاصة بالإشارة.
  4. اضبط limit للحصول على صفحة أصغر.
  5. لا تضف حقول المؤشر إلا بعد أن تُرجعها استجابة بالمؤشر.
يطابق كل صف مُرجَع كل عوامل التصفية في الطلب. وإذا حذفت عامل تصفية، يُطبَّق الإعداد الافتراضي للمسار. مثلًا، يستخدم GET /api/logs القيمة status=active عندما تحذف status.

مصفوفة عوامل التصفية

يجب أن تكون المفاتيح الواردة في عمود «مطلوب» موجودة في الطلب. وكل المفاتيح الأخرى اختيارية. في التحقيق في المشكلات، تكون قيمة selection إحدى القيم first أو latest أو recommended. أرسل selection أو occurrence_id، لا كليهما. ويحتاج كلاهما إلى response_version من 2 إلى 13. مع الإصدار 2 أو أحدث ودون أداة اختيار، يستخدم LogBrew القيمة recommended. احصل على occurrence_id من GET /api/telemetry/issues/{issue_id}/events. تقبل مسارات التحليلات من نوع POST نص JSON. راجع تحليلات المنتج.

عوامل التصفية المشتركة والخاصة بالإشارة

تضيّق service_name وrelease وenvironment نطاق كل قائمة لبيانات القياس عن بُعد. استخدم القيم نفسها تمامًا التي يرسلها الـ SDK لديك. بعض عوامل التصفية خاصة بإشارة واحدة:
  • تقبل السجلات search وtrace_id وseverity وattribute_filters.
  • تقبل السجلات status: active (الافتراضي) أو ignored أو all. يختار ignored السجلات التي تخفيها قاعدة سجلات من العرض النشط.
  • تقبل المشكلات status الخاصة بالمشكلة: unresolved أو resolved أو archived. وignored اسم أقدم لـ archived ويختار المشكلات نفسها.
  • تقبل المشكلات severity: info أو warning أو error أو critical.
  • تقبل المشكلات priority: high أو medium أو low.
  • تقبل المشكلات assignee: me للمشكلات المُسندة إلى الحساب الذي سجّل الدخول، أو none للمشكلات التي ليس لها مسؤول، أو my_teams للمشكلات المُسندة إلى فرقك، أو معرّف مستخدم، أو team:<team_id>.
  • تقبل الإجراءات والمقاييس name.
  • تقبل الإجراءات distinct_id.
  • تقبل التتبّعات status الخاصة بالتتبّع وmin_duration_ms.
  • تقبل عمليات النشر status: succeeded أو failed.
يقارن عاملا التصفية severity للسجلات والمشكلات الخطورة الفعلية. إذا غيّرت قاعدة الخطورة، يستخدم عامل التصفية قيمة القاعدة. راجع قيم الخطورة.

النطاق الزمني

يقبل since عددًا صحيحًا موجبًا من الساعات أو الأيام، مثل 24h أو 7d، أو طابعًا زمنيًا بصيغة RFC3339. والمدة المختصرة نسبية إلى وقت كل طلب. لا يقبل until إلا طابعًا زمنيًا بصيغة RFC3339. وهو وقت نهاية غير شامل: الصف الذي يقع عند until تمامًا ليس ضمن النتيجة. أما since فشامل. مثلًا، يختار since=2026-10-01T00:00:00Z وuntil=2026-10-02T00:00:00Z يومًا واحدًا كاملًا. يقارن LogBrew الأوقات بدقة المللي ثانية. يجب أن يكون until بعد since. إذا لم يكن كذلك، أو إذا لم يكن until طابعًا زمنيًا بصيغة RFC3339، يفشل الطلب مع 422 وvalidation_failed. للقراءة عبر عدة صفحات، اختر وقت بدء واحدًا بصيغة RFC3339 وأبقِه في كل صفحة. وأبقِ قيمة until نفسها في كل صفحة أيضًا. يقرأ هذا الطلب سجلات الأخطاء ليوم واحد:
تستخدم قائمة عمليات النشر قواعد زمنية مختلفة. لا يقبل since وuntil فيها إلا طوابع زمنية بصيغة RFC3339، وكلاهما شامل. ويقارنان وقت انتهاء عملية النشر.

إصدار استجابة المشكلات

تقبل قائمة المشكلات وتفاصيل المشكلة response_version=1 أو response_version=2، response_version=3 أو response_version=4. الإصدار 1 هو الافتراضي. وتفشل أي قيمة أخرى مع 422 وvalidation_failed.
  • يعرض الإصدار 1 الحالة المؤرشفة بالاسم ignored. ولا يعرض الأولوية.
  • يعرض الإصدار 2 الحالة المؤرشفة بالاسم archived. ويضيف priority وpriority_source.
  • يحتوي الإصدار 3 على كل حقول الإصدار 2. ويضيف assignee.
  • يحتوي الإصدار 4 على كل حقول الإصدار 3. ويحمل assignee الحقل type: user أو team.
يقبل كل إصدار status=archived وpriority وassignee. راجع استجابة المشكلة.

عامل تصفية الخطورة

استخدم severity=info|warning|error|critical مع GET /api/logs. والمفتاح الأقدم level اسم بديل للتوافق. يقبل المفتاحان القيم المعيارية والأسماء البديلة trace وdebug وwarn وfatal. يحوّل LogBrew الاسم البديل إلى قيمته المعيارية قبل المقارنة. إذا أرسل الطلب severity وlevel معًا، يوحّد LogBrew قيمتيهما أولًا. وتُرفض القيم المتعارضة مع:

عوامل تصفية التتبّعات

في اكتشاف التتبّعات، تكون قيمة status إما error أو ok. احذفها لتضمين الاثنين. يجب أن تكون قيمة min_duration_ms صفرًا أو أكثر. وهي تنطبق على اكتشاف التتبّعات فقط. يعثر هذا الطلب على تتبّعات الأخطاء التي استغرقت 500 مللي ثانية على الأقل:
في تفاصيل التتبّع وملخصه، رمّز trace_id بترميز النسبة المئوية (percent-encoding) بوصفه جزءًا من المسار. لا ترسله كمفتاح استعلام.

نطاق المشروع

استخدم project_id=<project-uuid> لقراءة مشروع واحد. في المسارات التي تذكر project_ids في المصفوفة، استخدم project_ids=<uuid>,<uuid> لمجموعة محددة من 2 إلى 50 مشروعًا. وفي هذه المسارات، احذف المفتاحين كليهما لقراءة كل مشروع يستطيع الحساب قراءته. أما المسار الذي يتطلب project_id فلا يقبل إلا مشروعًا واحدًا.
يرفض LogBrew هذه الاختيارات مع 422 وvalidation_failed:
  • طلب يحتوي على project_id وproject_ids معًا.
  • قيمة project_ids تضم أقل من معرّفين أو أكثر من 50 معرّفًا.
  • معرّف مكرر أو معرّف ليس UUID.
إذا كان أحد المعرّفات في project_ids لمشروع لا يستطيع الحساب قراءته، يفشل الطلب مع 404 وnot_found. لا تحذف هذا المعرّف وتتابع. اطلب من المستخدم اختيار مجموعة جديدة. أبقِ نطاق المشروع نفسه في كل صفحة بالمؤشر. لا تُزِل عامل تصفية المشروع بعد نتيجة فارغة، لأن ذلك يطرح سؤالًا مختلفًا.

السلاسل المقسّمة إلى فواصل زمنية

يُرجع GET /api/telemetry/metrics/series مقياسًا واحدًا مقسّمًا إلى فواصل زمنية. ويُرجع GET /api/telemetry/summary/volume أعداد الإشارات مقسّمة إلى فواصل زمنية. يستخدم المساران هذه القواعد:
  • since مطلوب. وuntil اختياري، وقيمته الافتراضية وقت الطلب.
  • لا يتجاوز النطاق من since إلى until مدة 31 يومًا.
  • تكون قيمة interval إحدى القيم auto أو 1m أو 5m أو 15m أو 1h أو 6h أو 1d. القيمة الافتراضية auto. ويفشل الفاصل الذي ينتج أكثر من 500 فاصل زمني.
  • service_name وrelease وenvironment عوامل تصفية مطابقة تامة.
في سلاسل المقاييس، name هو الاسم الدقيق للمقياس من GET /api/telemetry/metrics. وتكون قيمة group_by إحدى القيم none أو service_name أو release أو environment. وتكون قيمة series_limit من 1 إلى 20. في حجم الإشارات، يجب ألا يكون until في المستقبل، ولا تقبل response_version إلا القيمة 1.

تصفية سمات السجلات

استخدم GET /api/logs/attributes للعثور على مسارات السمات وأنواعها التي يمكنك البحث فيها. ثم أرسل attribute_filters إلى GET /api/logs. يحتاج الطلبان كلاهما إلى since.

قراءة فهرس السمات

يعثر هذا الطلب على المسارات الرقمية التي تحتوي على status في مشروع واحد:
الاستجابة كائن، وليست مصفوفة مجرّدة. يحتوي هذا المثال المصطنع على سمتين وعلى صفحة أخرى:
تكون قيمة type إحدى القيم string أو number أو boolean. وobserved_count هو عدد السجلات في النطاق التي تحمل هذا المسار وهذا النوع. وlast_seen_at هو وقت أحدثها. قد يحمل السجل الواحد مسارات كثيرة. لا تجمع الأعداد للحصول على عدد السجلات. يخبرك coverage بالسجلات التي يستطيع عامل تصفية السمات البحث فيها: مجموع المجموعات الثلاث يساوي total_logs. ولا تغيّر type وsearch والمؤشر في الفهرس التغطية. والقائمة attributes الفارغة لا تعني أن total_logs تساوي صفرًا. لا يحتوي الفهرس على المفتاح status. ويقارن عامل تصفية الخطورة فيه الخطورة الملتقَطة، لا الخطورة الفعلية. search جزء من المسار طوله من 1 إلى 128 بايت دون أحرف تحكم. ويحدد limit عدد السمات في الصفحة.

متابعة الفهرس

لا يستخدم الفهرس pagination=cursor. كرّر كل عامل تصفية، وانسخ الحقول الثلاثة كلها من next_cursor: توقف عندما تكون قيمة next_cursor هي null.

تطبيق عامل تصفية ذي نوع

انسخ المسار والنوع من الفهرس. تستخدم المسارات صيغة JSON Pointer، لا المفاتيح المفصولة بالنقاط. أبقِ أي تهريب ~0 أو ~1 في المسار دون تغيير. يقرأ هذا الطلب السجلات التي تكون حالة الاستجابة الرقمية فيها 500 أو أكثر:
attribute_filters مصفوفة JSON تضم من 1 إلى 4 عوامل تصفية. يجب أن يطابق السجل كل عامل تصفية. لكل عامل تصفية path وtype وoperator وvalue. ويجب أن يطابق نوع JSON لـ value قيمة type: فالرقم 500 ليس السلسلة "500". لا يطابق ne إلا السجلات التي تحمل المسار. والسجل الذي لا يحمل المسار لا يطابق ne. في النوع string، يكون case_sensitive اختياريًا وقيمته الافتراضية false. ويرفض LogBrew "case_sensitive": true مع number وboolean. تنطبق هذه الحدود:
  • لا تتجاوز مصفوفة JSON مقدار 4,096 بايت.
  • لا تتجاوز القيمة النصية 1,024 بايت.
  • يحتاج contains وstarts_with إلى سلسلة غير فارغة.
  • يجب أن يكون الرقم محدودًا وأن يقع بين -9,007,199,254,740,992 و9,007,199,254,740,992.
السجل الذي لا يستطيع الفهرس البحث فيه لا يطابق أي عامل تصفية. لكنه قد يظهر في طلب لا يحتوي على attribute_filters. لمعرفة استجابة السجل، راجع استجابة السجل.

تصحيح أخطاء السمات

يُرجع كل خطأ أدناه 422 مع validation_failed: صحّح الطلب قبل أن تعيد المحاولة. لا تحذف عامل تصفية، لأن ذلك يغيّر النتيجة.

ترقيم الصفحات بالمؤشر

وضع المؤشر اختياري. ودونه تُرجع مسارات القوائم مصفوفة مجرّدة. أرسل pagination=cursor دون حقول المؤشر للصفحة الأولى. ولكل صفحة تالية، كرّر كل عامل تصفية وأرسل مجموعة حقول المؤشر كاملة: انقل حقول next_cursor المُرجَعة إلى الطلب التالي:
  • يذهب next_cursor.time إلى cursor_time.
  • يذهب next_cursor.id إلى cursor_id.
  • في التتبّعات، يذهب next_cursor.trace_id إلى cursor_trace_id.
  • في الإصدارات، أضف cursor_ قبل اسم كل حقل مُرجَع، فمثلًا يذهب next_cursor.release إلى cursor_release.
توقف عندما تكون قيمة next_cursor هي null. لا تحسب المؤشر من الصف الأخير. ولا يغيّر مؤشر الإصدارات المشاريع المحددة. أبقِ project_id أو project_ids الأصلي.
يحدد limit حجم الصفحة. وقد تحتوي الصفحة على صفوف أقل. لا تقبل هذه المسارات page أو page_number. في أغلب المسارات، يحوّل LogBrew قيمة limit التي تتجاوز الحد الأقصى إلى الحد الأقصى. أما قائمة عمليات النشر فترفض قيمة limit خارج النطاق من 1 إلى 100 مع 422. وتُرجع قائمة عمليات النشر دائمًا كائن صفحة يحتوي على next_cursor، حتى دون pagination=cursor. يرفض LogBrew هذه الطلبات مع 422 وvalidation_failed:
  • قيمة pagination غير cursor.
  • حقول المؤشر دون pagination=cursor.
  • مجموعة حقول مؤشر غير مكتملة.
  • قيمة cursor_time ليست طابعًا زمنيًا بصيغة RFC3339.
يحدد المؤشر موضعًا، ولا يجمّد البيانات. ابدأ صفحة أولى جديدة عندما تحتاج إلى عرض محدَّث. يستخدم الـ CLI الحقول نفسها:

تشخيص النتيجة الفارغة

القائمة الفارغة تعني أنه لم يطابق أي صف كل عوامل التصفية. ولا تقول شيئًا عن الإشارات الأخرى. افحص الطلب بهذا الترتيب:
  1. تأكد من معرّف المشروع.
  2. أزِل عوامل التصفية الاختيارية واحدًا تلو الآخر.
  3. وسّع since إذا كان الحدث المتوقع أقدم. وأزِل until أو أخّره إذا كان الحدث المتوقع أحدث.
  4. قارن service_name وrelease وenvironment بالقيم التي يرسلها الـ SDK لديك.
  5. في السجلات، أضف status=all إذا كان من الممكن أن تخفي قاعدة سجلات السجل المتوقع.
  6. تأكد من أن المسار يقبل كل عامل تصفية.

الاستعادة من استعلام مرفوض

يُرجع الاستعلام المرفوض غلاف الخطأ القياسي. ويُرجع المفتاح غير المعروف أو القيمة من نوع خاطئ 422:
الإصلاحات الشائعة:
  • استبدل الاسم البديل المختصر بالمفتاح الوارد في مصفوفة عوامل التصفية.
  • أرسل كل حقول مؤشر المتابعة التي يحتاجها المسار.
  • أزِل حقول المؤشر من طلب الصفحة الأولى.
  • استخدم أداة اختيار واحدة فقط للمشروع.
  • استبدل قيمة الخطورة أو حالة التتبّع غير المدعومة بقيمة معيارية.
لمعرفة رموز الأخطاء والاستعادة، راجع أخطاء API. ولمعرفة نصوص الاستجابات، راجع تنسيقات الاستجابة.