> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# عزل أعباء عمل القراءة والكتابة

> فصل أعباء عمل الاستيعاب والاستعلام في ClickStack باستخدام مستودعات في ClickHouse Cloud

export const ScalePlanFeatureBadge = ({feature = 'هذه الميزة', linking_verb_are = false}) => {
  return <div className="scalePlanFeatureContainer">
            <div className="scalePlanFeatureBadge">
                ميزة باقة Scale
            </div>
            <div>
                <p>{feature} {linking_verb_are ? 'متوفرة' : 'متوفرة'} في باقتَي Scale وEnterprise. للترقية، انتقل إلى صفحة الخطط في Cloud Console.</p>
            </div>
        </div>;
};

تفرض أعباء عمل الـ observability مطلبين مختلفين تمامًا على البيانات نفسها. فعملية الاستيعاب مستمرة وكثيفة الكتابة، وتستهلك عمليات الدمج في الخلفية وحدة المعالجة المركزية والذاكرة لفترة طويلة بعد انتهاء عملية الإدراج. أما عبء الاستعلامات فغير منتظم: إذ تبلغ لوحات المعلومات وعمليات البحث ذروتها أثناء وقوع حادثة، وهو الوقت الذي يكون فيه بطء الاستجابة أقل ما يمكن تقبله.

مع [مستودعات](/ar/products/cloud/features/infrastructure/warehouses) في ClickHouse Cloud، يمكن خدمة كلا عبئي العمل من البيانات نفسها عبر موارد compute منفصلة، بحيث لا يتنافس أي منهما مع الآخر على وحدة المعالجة المركزية والذاكرة.

<ScalePlanFeatureBadge feature="Compute-compute separation" />

الـ مستودعات ميزة في ClickHouse Cloud، لذا فإن الإعداد الموضّح هنا ينطبق على ClickStack عند تشغيله مع ClickHouse Cloud، بحيث يُحدَّد حجم كل جانب من جانبي التقسيم ويُوسَّع ويُخمَد بشكل مستقل فوق نسخة واحدة من البيانات.

<Note>
  **متى يكون العزل مجديًا**

  يستهدف العزل عمليات النشر الكبيرة ذات الاستيعاب المستمر. فإذا كان حجم البيانات المخزَّنة أقل من 100 تيرابايت شهريًا تقريبًا، تستوعب خدمة قراءة وكتابة واحدة كلا عبئي العمل عادةً، ولا حاجة على الأرجح إلى خدمة ثانية. استخدم [sizing model](/ar/clickstack/managing/estimating-resources) لتقدير حجم بياناتك المضغوطة شهريًا.
</Note>

<h2 id="why-isolate">
  لماذا نعزل القراءات عن الكتابات
</h2>

* **الكتابات لم تعد تُضعف القراءات.** فالاستيعاب المستمر لبيانات OpenTelemetry — عمليات الإدراج نفسها، إضافةً إلى عمليات الدمج في الخلفية التي تليها — يزاحم استعلامات لوحات المعلومات والبحث على CPU والذاكرة. وقد يتدهور زمن استجابة القراءة بشكل ملحوظ أثناء تشغيل الاستيعاب، ثم يتعافى بمجرد توقفه.
* **القراءات لم تعد تُعطّل الكتابات.** فالتنازع يسري في الاتجاهين: إذ قد يستنزف استعلام آنيّ ثقيل أو عرض لوحة معلومات مكلف ذاكرة الخدمة فتفشل عمليات الإدراج تمامًا، لا أن تبطؤ فحسب.
* **موارد المعالجة المخصصة للقراءة فقط تتفرغ بالكامل للاستعلامات.** فالخدمات للقراءة فقط لا تنفّذ أي عمليات دمج في الخلفية خارج جداول النظام، كما أنها تدخل في وضع الخمول دون تأخير، بخلاف خدمات القراءة والكتابة التي قد تُبقيها عمليات الدمج نشطة.
* **كل جانب يُحدَّد حجمه على حدة.** يقدّر [نموذج تحديد الحجم](/ar/clickstack/managing/estimating-resources) موارد المعالجة اللازمة للاستيعاب وتلك اللازمة للاستعلامات كلًّا على حدة، ويتيح لك المستودع تجهيز كل منهما كخدمة مستقلة. وفوق خط الأساس البالغ استعلامًا واحدًا في الثانية في النموذج، تهيمن موارد معالجة الاستعلامات — إذ يصل [المثال التطبيقي](/ar/clickstack/managing/estimating-resources#worked-example) عند 5 استعلامات في الثانية إلى 58 وحدة vCPU للاستيعاب مقابل 290 للاستعلامات — ومن ثَمّ يمكن لخدمة كتابة صغيرة أن تغذّي خدمة قراءة أكبر منها بكثير.
* **الخمول والتوسيع التلقائي يُهيَّآن لكل خدمة على حدة.** فلكل خدمة عدد نسخ متماثلة خاص بها وإعدادات توسيع تلقائي وخمول تلقائي خاصة بها، فتبقى خدمة الكتابة عاملة دائمًا من أجل الاستيعاب المستمر، بينما تدخل خدمة القراءة في وضع الخمول خارج ساعات العمل.
* **التخزين غير مُكرَّر.** تتشارك الخدمات داخل المستودع المجلد نفسه في التخزين الكائني والجداول نفسها، و[تتم فوترة التخزين مرة واحدة فقط](/ar/products/cloud/features/infrastructure/warehouses#pricing).
* **يمكن تقييد الوصول لكل نقطة نهاية.** تُطبَّق قوائم الوصول بعناوين IP لكل خدمة على حدة، بحيث لا يمكن الوصول إلى نقطة نهاية الكتابة إلا من الـ collectors الخاصة بك، ولا إلى نقطة نهاية القراءة إلا من نشر ClickStack لديك. راجع دليلنا حول [التحكم في الوصول عبر الشبكة](/ar/products/cloud/features/infrastructure/warehouses#network-access-control).

<h2 id="architecture">
  المعمارية
</h2>

الطوبولوجيا الموصى بها هي مستودع يحتوي على خدمة قراءة وكتابة واحدة للاستيعاب وخدمة للقراءة فقط واحدة لـ ClickStack:

| الخدمة | النوع | المسؤوليات | العملاء |
| - | - | - | - |
| Primary | قراءة وكتابة | الاستيعاب، عمليات الدمج في الخلفية، DDL (إنشاء الجداول، TTL، العروض المُجسَّدة) | OpenTelemetry collector، ClickPipes، Vector، SQL console / العميل للإدارة |
| Secondary | للقراءة فقط | البحث، اللوحات، الـ notebooks، تقييم التنبيهات | واجهة ClickStack (HyperDX) |

ضع في اعتبارك ما يلي عند تخطيط الطوبولوجيا:

* الخدمة الأولى في أي مستودع تكون دائماً قراءة وكتابة، ونوع الخدمة **يُحدَّد عند الإنشاء ولا يمكن تغييره** - وللتبديل بين للقراءة فقط و قراءة وكتابة، أنشئ خدمة جديدة في الـ مستودع.
* تتشارك جميع الخدمات في الـ مستودع نفس cloud provider، والـ region، وإصدار ClickHouse و Keeper، وجدول ترقية الخدمة الـ primary.
* استخدم خدمة قراءة وكتابة **واحدة** للاستيعاب. فعمليات الدمج تُوزَّع على جميع خدمات قراءة وكتابة التي تتشارك التخزين، لذا قد تُنفِّذ خدمةٌ أخرى عملية دمج ناتجة عن إدخال جرى على خدمة معيّنة. وإذا كانت تلك الخدمة الأخرى تعالج كذلك استعلامات ثقيلة، فستتنافس هذه الاستعلامات مع عملية الدمج على وحدة المعالجة المركزية والذاكرة في الخدمة التي تنفّذها، ما يُبطئ عمليات الدمج الخاصة بإدخالات الخدمة الأولى، ويُبطئ معها أداء الإدخال. أبقِ أعباء عمل الاستعلامات على الخدمة الـ للقراءة فقط، ولا تُضِف خدمة قراءة وكتابة ثانية إلا إذا احتجت إلى [فصل عمليات الدمج عن الاستيعاب](#separating-merges).

<h2 id="setup">
  إعداد نشر معزول
</h2>

<Steps>
  <Step title="إعداد الخدمة بوضع القراءة والكتابة" id="prepare-read-write-service">
    استخدم خدمتك الحالية — أو الخدمة الأساسية في مستودع جديد — لعملية الاستيعاب، مع تحديد حجمها بما يتناسب مع موارد الحوسبة اللازمة للاستيعاب وفقًا لـ[نموذج تحديد الحجم](/ar/clickstack/managing/estimating-resources).

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

    ```sql theme={null}
    CREATE DATABASE otel;
    CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '<strong-password>';
    GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;
    ```

    أنشئ كلمة المرور باستخدام أداة مثل `openssl rand -base64 24` واحفظها في مدير أسرار بدلًا من حفظها في ملف manifest أو في سجل أوامر shell. راجع دليلنا حول [إنشاء مستخدم استيعاب](/ar/clickstack/ingesting-data/collector#creating-an-ingestion-user) لمزيد من التفاصيل.

    إذا كانت هذه الخدمة جزءًا من مستودع بيانات، فلاحظ أن عبارات DDL على مستوى قاعدة البيانات قد تتوقف عن الاستجابة عندما تكون خدمة أخرى ضمنه في حالة خمول - راجع [الإدارة وعبارات DDL](#administration).
  </Step>

  <Step title="أضف خدمة للقراءة فقط إلى المستودع" id="add-read-only-service">
    في ClickHouse Cloud console، انقر على علامة الزائد الموجودة على الـ service الذي أعددته للتوّ لإنشاء service ثانٍ يشترك معه في البيانات. اختر **read-only** كنوع للـ service، وحدّد حجمه بما يتناسب مع موارد compute المخصصة للاستعلامات وفقًا لـ sizing model.

    للاطلاع على الشرح الكامل، راجع دليلنا حول [كيفية إعداد warehouse](/ar/products/cloud/features/infrastructure/warehouses#setup-warehouses).
  </Step>

  <Step title="وجّه الاستيعاب إلى خدمة القراءة والكتابة" id="point-ingestion">
    قم بتهيئة الـ collector للتصدير إلى نقطة نهاية الخدمة **read-write**، مع المصادقة بصفة مستخدم الاستقبال (ingestion):

    ```shell theme={null}
    CLICKHOUSE_ENDPOINT=https://<read-write-service>.clickhouse.cloud:8443
    CLICKHOUSE_USER=hyperdx_ingest
    CLICKHOUSE_PASSWORD=<strong-password>
    HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel
    ```

    راجع [خيارات تهيئة collector](/ar/clickstack/managing/config#otel-collector) للاطلاع على التفاصيل، أو الإعدادات المكافئة لـ [Vector](/ar/clickstack/ingesting-data/vector) ومسارات الاستيعاب الأخرى.

    تُرفض عمليات الكتابة المُرسلة إلى نقطة النهاية المخصصة للقراءة فقط، لذا يجب أن يستهدف collector دائمًا الخدمة ذات صلاحية القراءة والكتابة.
  </Step>

  <Step title="وجّه ClickStack إلى خدمة القراءة فقط" id="point-clickstack">
    تتصل ClickStack UI دائمًا بـ ClickHouse service التي تم إطلاقها منها في ClickHouse Cloud console. ولتشغيلها على read-only compute:

    1. حدّد read-only service في ClickHouse Cloud console.
    2. حدّد **ClickStack** من قائمة التنقل اليسرى.

    بعد ذلك، يُنفَّذ كل استعلام تُصدره الواجهة على read-only compute تلك، ولا حاجة إلى أي تهيئة داخل ClickStack. راجع دليلنا حول [استخدام ClickStack مع read-only compute](/ar/clickstack/deployment/managed#clickstack-read-only-compute).

    <Warning>
      **حالة ClickStack مرتبطة بنطاق الخدمة**

      تنتمي dashboards و saved searches و alerts و sources إلى الخدمة التي تم إطلاق ClickStack منها، ولا تنتقل معك إلى خدمة أخرى داخل الـ warehouse نفسه — حتى لو كانت الخدمتان تتشاركان البيانات نفسها. أما الـ sources التي تستخدم [مخطط OpenTelemetry الافتراضي](/ar/clickstack/deployment/managed#adding-data-sources) فيتم اكتشافها تلقائيًا في الخدمة الجديدة، لذا يعمل البحث في تلك البيانات على الفور، لكن الـ sources المخصصة أو المهيّأة يدويًا — وكل ما حفظته غير ذلك — يجب إنشاؤها من جديد.

      اختر الخدمة التي تريد تشغيل ClickStack منها قبل أن تبدأ ببناء dashboards. وإذا كنت تنقل عملية نشر قائمة بالفعل، فانتبه إلى أن alerts التي أُنشئت على الخدمة السابقة تستمر في التقييم هناك — على compute تلك الخدمة — إلى أن تحذفها.
    </Warning>
  </Step>

  <Step title="تحقّق من عملية التقسيم" id="verify">
    نفّذ عملية بحث أو افتح dashboard في ClickStack، ثم تحقّق من الـ node التي انتهت إليها الاستعلامات. تُكتب جداول `system` على الـ node التي نفّذت الاستعلام، لذا فإن أي service يضم أكثر من replica واحدة يحتاج إلى [`clusterAllReplicas`](/ar/reference/system-tables/overview#querying-across-nodes) مع اسم العنقود `default` لتغطيتها جميعًا. وعلى الـ service ذات الوضع **read-only**، من المفترض أن ترى استعلامات ClickStack:

    ```sql theme={null}
    SELECT 
        user, 
        query_kind, 
        http_user_agent,
        count()
    FROM clusterAllReplicas('default', system.query_log)
    WHERE event_time > now() - toIntervalMinute(10) 
      AND type = 'QueryFinish'
      AND is_initial_query = 1
    GROUP BY ALL
    ORDER BY count() DESC;
    ```

    النتيجة الفارغة هنا لا تعني بحد ذاتها أن الاستعلامات ذهبت إلى مكان آخر: فجدول `system.query_log` يُفرَّغ دوريًا — كل 7.5 ثانية افتراضيًا — لذا قد لا يظهر فيه استعلام نُفِّذ مباشرة بعد عملية بحث. انتظر قليلًا ثم نفّذه مرة أخرى، أو افرض التفريغ باستخدام [`SYSTEM FLUSH LOGS`](/ar/reference/statements/system#flush-logs) إن كانت لديك الصلاحية اللازمة.

    التجميع حسب `user` و`http_user_agent` هو ما يُحدد مصدر حركة الاستعلامات: فهو يميّز واجهة المستخدم عن SQL console وعن أي جهة أخرى تتصل بنقطة النهاية، أيًا كانت الجداول التي تشير إليها مصادرك. أما التصفية على `is_initial_query = 1` فتُبقي صفًا واحدًا لكل استعلام كما أُرسل — إذ تُسجَّل الاستعلامات الثانوية الناتجة عن التنفيذ الموزّع، والاستعلامات الداخلية التي تُقيّم [العروض المُجسَّدة](/ar/reference/system-tables/query_views_log)، بشكل منفصل مع `is_initial_query = 0`.

    وعلى الخدمة ذات وضع **read-write**، ينبغي أن يُظهر الاستعلام نفسه عمليات إدخال من مستخدم الاستقبال ودون أي حركة استعلامات من ClickStack.

    تنفيذ الاستعلام على كل خدمة على حدة هو الفحص الموثوق، لأن العنقود `default` لا يحتوي إلا على نسخ الخدمة المتصل بها. وللحصول على عرض تجميعي يشمل المستودع بالكامل، استخدم اسم العنقود `all_groups.default` بدلًا من ذلك:

    ```sql theme={null}
    SELECT 
        hostName() AS host, 
        query_kind, 
        count()
    FROM clusterAllReplicas('all_groups.default', system.query_log)
    WHERE event_time > now() - toIntervalMinute(10) 
      AND type = 'QueryFinish'
      AND is_initial_query = 1
    GROUP BY ALL;
    ```

    هناك أمران يجب أخذهما في الحسبان مع هذا الاستعلام: الخدمات التي انتقلت إلى حالة السكون (idled) لا يمكنها المساهمة بأي rows، لذا فعِّلها أولاً إذا كنت بحاجة إلى نتائج كاملة، كما أن `hostName()` يحدد replica وليس خدمة — ولإسناد النشاط إلى خدمة محددة، استعلم عن تلك الخدمة مباشرةً.
  </Step>
</Steps>

<h2 id="separating-merges">
  فصل عمليات الدمج عن الاستيعاب
</h2>

عند معدلات استيعاب مرتفعة جدًا ومستمرة، تصبح عمليات الدمج — وليست عمليات الإدراج نفسها — هي التكلفة المهيمنة على خدمة الاستيعاب. ولأن عمليات الدمج تُوزَّع على جميع خدمات القراءة والكتابة التي تتشارك التخزين نفسه، فقد تُسحب أيضًا إلى خدمة كنت تنوي استخدامها لغرض آخر.

في عمليات النشر هذه، يمكن نقل عمليات الدمج خارج خدمة الاستيعاب بالكامل، مما يمنحك بنية مكوّنة من ثلاث خدمات:

| الخدمة | النوع | المسؤوليات |
| - | - | - |
| الاستيعاب | قراءة وكتابة، مع تعطيل عمليات الدمج | تقبل عمليات الإدراج فقط |
| الدمج | قراءة وكتابة | تنفّذ جميع عمليات الدمج والتعديلات في الخلفية للمستودع |
| الاستعلام | للقراءة فقط | تخدم ClickStack |

<Info>
  **يتطلب طلب دعم**

  تعطيل عمليات الدمج على خدمة قراءة وكتابة غير قابل للضبط من Cloud console. [تواصل مع الدعم](https://clickhouse.com/support/program) لتطبيقه على خدمة ما.
</Info>

تستحق هذه البنية النظر عندما يُشبع الاستيعاب وحده خدمة كاملة، أو عندما تحتاج إلى خدمتي قراءة وكتابة لأن كلتيهما يجب أن تكتبا. أما إذا كان عبء عمل الاستعلام لديك مخدومًا بالكامل من ClickStack — الذي يقرأ فقط — فإن [الفصل الأبسط بين خدمة القراءة والكتابة وخدمة القراءة فقط](#architecture) يغطي هذا المتطلب ويمثل المسار الأفضل دعمًا.

عند تشغيل هذه البنية، انتبه لما يلي:

* **لا تعتمد على الخمول التلقائي في أيٍّ من خدمتي القراءة والكتابة.** فالخدمة التي عُطِّلت فيها عمليات الدمج لا تزال تعالج أحداث تنزيل أجزاء البيانات وإزالتها الناتجة عن عمليات الإدراج في أماكن أخرى من المستودع، كما أن ارتفاع عدد أجزاء البيانات غير المدموجة قد يمنع الخمول وحده. خطّط لبقاء خدمتي القراءة والكتابة كلتيهما مستيقظتين باستمرار.
* **أبعِد الاستعلامات عن خدمتي القراءة والكتابة كلتيهما.** فاستعلامات `SELECT` الثقيلة على خدمة قراءة وكتابة تتنافس مع أعمال الدمج على المعالج والذاكرة، وهو بالضبط نمط الفشل الذي وُجدت هذه البنية لتجنبه. وجّه ClickStack إلى خدمة القراءة فقط كما هو موضّح [أعلاه](#point-clickstack).
* **التعديلات، إن وُجدت لديك، تُتتبَّع على الخدمة التي تنفّذها.** والتعديلات نادرة في الأوبزرفابيليتي — إذ يضبط مخطط ClickStack القيمة [`ttl_only_drop_parts = 1`](/ar/clickstack/managing/ttl)، ولذلك يُسقِط الاحتفاظ الاعتيادي أجزاء البيانات المنتهية الصلاحية بالكامل أثناء عمليات دمج TTL بدلًا من تعديل الصفوف للتخلص منها. وإذا أرسلت فعلًا أمر `ALTER` ينتج عنه تعديل إلى خدمة الاستيعاب، فستنفّذه خدمة الدمج، ويظهر تقدّمه في [`system.mutations`](/ar/reference/system-tables/mutations) هناك بدلًا من خدمة الاستيعاب.

<h2 id="administration">
  الإدارة وDDL
</h2>

يجب تنفيذ جميع تغييرات المخطط على خدمة **القراءة والكتابة**، بما في ذلك:

* إنشاء الجداول - يقوم به ClickStack collector تلقائيًا عند أول عملية استيعاب
* [تعديل TTL](/ar/clickstack/managing/ttl#modifying-ttl) لتغيير مدة الاحتفاظ
* إنشاء [عروض مُجسَّدة](/ar/clickstack/managing/materialized-views) لتسريع الاستعلامات
* إضافة [فهارس التخطي والـ projections وغيرها من تحسينات الأداء](/ar/clickstack/managing/performance-tuning)

المستخدمون والأدوار والأذونات ليست تغييرات في المخطط - فهي مشتركة بين جميع الخدمات في الـ مستودع، لذا يكفي إنشاء كل منها مرة واحدة فقط من أي خدمة. وتنشئ [خطوات الإعداد](#prepare-read-write-service) المذكورة أعلاه مستخدم الاستيعاب. أما أي عميل آخر تُوجّهه إلى خدمة القراءة فقط فينبغي أن يُصادق كمستخدم استعلام منفصل للقراءة فقط يمتلك [الأذونات التي تتطلبها ClickStack UI](/ar/clickstack/managing/production#user-permissions) - لا بأذونات الاستيعاب الموضحة أعلاه.

اتصل بخدمة القراءة والكتابة باستخدام [SQL console أو clickhouse client](/ar/clickstack/managing/admin). ولأن الـ مستودع يتشارك التخزين وضوابط الوصول، تظهر التغييرات فورًا لخدمة القراءة فقط. وإذا كنت قد [فصلت عمليات الدمج عن الاستيعاب](#separating-merges)، فيمكن إرسال العبارات إلى أي من خدمتي القراءة والكتابة - لكن انتبه إلى أن الـ تعديلات تُنفَّذ ويُتابَع تقدمها على خدمة الدمج.

<Warning>
  **قد تتوقف عبارات DDL الخاصة بقاعدة البيانات عن الاستجابة عندما تكون خدمة أخرى في حالة سكون**

  يمكن أن تُحجب عبارات `CREATE` و`RENAME` و`DROP DATABASE` بفعل خدمات ساكنة أو متوقفة في الـ مستودع، فتتوقف عن الاستجابة. ويسهل حدوث ذلك في هذه الطوبولوجيا، لأن خدمات القراءة فقط تدخل في السكون دون تأخير. نفّذ العبارات على مستوى قاعدة البيانات مع [`distributed_ddl_task_timeout=0`](/ar/reference/settings/session-settings/distributed-ddl#distributed_ddl_task_timeout)، مضبوطًا لكل استعلام أو على مستوى الـ session:

  ```sql theme={null}
  CREATE DATABASE otel
  SETTINGS distributed_ddl_task_timeout=0
  ```

  وأي خدمة أوقفتها يدويًا يجب تشغيلها من جديد قبل أن تُنفَّذ الاستعلامات عليها.
</Warning>

تُشغَّل العروض المُجسَّدة بفعل عملية الإدراج، ولذلك تنفّذها خدمة القراءة والكتابة. أما خدمة القراءة فقط فتستعلم من جداول الهدف الخاصة بها كأي جدول آخر، بما في ذلك العروض [المسجَّلة على مصدر ClickStack](/ar/clickstack/managing/config#materialized-views-settings) لتسريع الاستعلامات.

<h2 id="agentic-workloads">
  عزل أعباء العمل الوكيلة
</h2>

تُعد المساعدات الذكية المتصلة عبر [خادم ClickStack MCP](/ar/clickstack/mcp) حركة قراءة مثلها مثل أي لوحة معلومات، غير أن نمط حِملها مختلف: فالوكيل الذي يحقق في حادثة يُصدر عدداً كبيراً من الاستعلامات الاستكشافية المتلاحقة، على نطاقات زمنية لم يخترها أحد مسبقاً. ومشاركة خدمة واحدة للقراءة فقط بين الوكلاء وواجهة المستخدم تضع هذه الدفقة في طريق لوحات المعلومات التي يطالعها المهندس أثناء الحادثة نفسها.

ينطبق هنا نمط المستودع ذاته - امنح الوكلاء موارد حوسبة للقراءة فقط خاصة بهم:

<Steps>
  <Step title="أضف خدمة ثانية للقراءة فقط" id="agentic-add-service">
    أنشئ خدمة أخرى للقراءة فقط داخل المستودع، تماماً كما في [الإعداد أعلاه](#add-read-only-service). فهي تقرأ الجداول نفسها التي تقرأها الخدمة التي تخدم واجهة المستخدم، دون الحاجة إلى نسخ أي بيانات.

    ثم شغّل ClickStack عليها مرة واحدة من ClickHouse Cloud console، كما في [توجيه ClickStack إلى خدمة للقراءة فقط](#point-clickstack). يحتاج Cloud MCP إلى خدمة مفعّل عليها ClickStack إضافة إلى MCP نفسه - راجع [متطلبات MCP المسبقة](/ar/clickstack/mcp#managed-prerequisites).

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

  <Step title="فعّل MCP على تلك الخدمة" id="agentic-enable-mcp">
    افتح الخدمة المخصصة للقراءة فقط في ClickHouse Cloud console، وانقر على **Connect**، ثم اختر **Connect with MCP** وفعّل الخيار. راجع [تفعيل خادم MCP البعيد](/ar/products/cloud/features/ai-ml/mcp/remote-mcp#enable-remote-mcp-server).
  </Step>

  <Step title="وجّه عملاء MCP إليها" id="agentic-point-clients">
    نقطة نهاية Cloud MCP واحدة لجميع الخدمات - إذ تُوجَّه الطلبات عبر الترويسة `x-service-id`، وفي غيابها تذهب إلى أول خدمة ClickStack استخدمها حسابك. انسخ تهيئة MCP الحالية وأضف الترويسة مع معرّف خدمة القراءة فقط الجديدة:

    ```shell theme={null}
    claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
      --header "x-service-id: <read-only-agent-service-id>"
    ```

    يمكن لأي عميل MCP حمل هذه الترويسة - راجع [استهداف خدمة محددة](/ar/clickstack/mcp#managed-service-override) للاطلاع على التهيئة المكافئة في Cursor وVS Code وغيرهما.
  </Step>
</Steps>

<Warning>
  **يكتب MCP الحالة في الخدمة التي يستهدفها**

  بإمكان خادم MCP إنشاء لوحات معلومات وتنبيهات وعمليات بحث محفوظة إضافة إلى تنفيذ الاستعلامات، وتكون هذه الحالة محصورة بالخدمة التي وُجّه إليها الطلب، شأنها شأن كل [حالة ClickStack](#point-clickstack). فلوحة المعلومات التي ينشئها وكيل على خدمة الوكلاء لن تظهر في ClickStack UI المُشغّلة من الخدمة التي تخدم مهندسيك، والتنبيه الذي ينشئه هناك يُقيَّم على موارد حوسبة تلك الخدمة - وهنا ستؤدي خدمة الوكلاء الخاملة إلى تأخير عمليات التقييم أو تفويتها، كما هو موضح [أدناه](#isolating-alerts). لذا وجّه الوكلاء الذين يُتوقع منهم إنشاء مخرجات دائمة إلى الخدمة نفسها التي يستخدمها فريقك.
</Warning>

<h2 id="alerts">
  التنبيهات
</h2>

يقيّم ClickStack التنبيه على الـ service الذي أُنشئ منه، لذا تعمل التنبيهات على نفس الـ compute الذي تعمل عليه الـ UI، أي الـ للقراءة فقط service في هذه البنية.

<Note>
  **Managed ClickStack**

  لتمكين التنبيهات، يجب أن يسجّل الدخول إلى ClickStack مرة واحدة على الأقل مستخدمٌ واحد على الأقل يمتلك permissions الخاصة بـ **Service Admin**. يؤدي ذلك إلى تجهيز الـ database user المخصص الذي ينفّذ استعلامات التنبيهات، ويُستخدم هذا المستخدم بشكل مشترك بين جميع الـ services في الـ مستودع. راجع دليلنا حول [منح الوصول إلى Managed ClickStack](/ar/clickstack/deployment/managed#configure-access).
</Note>

تقييم التنبيهات هو عبء عمل استعلامي متكرر، فضعه في الحسبان عند تحديد قيمة QPS التي تحدد على أساسها حجم الـ للقراءة فقط service، إذ يتعامل [sizing model](/ar/clickstack/managing/estimating-resources#refining-sizing-assumptions) مع استعلامات البحث ولوحات المعلومات والتنبيهات كرقم إجمالي واحد.

<h3 id="isolating-alerts">
  عزل تقييم التنبيهات
</h3>

لا يمكن توجيه حِمل التنبيهات مركزيًا، لأن التنبيهات ينشئها المستخدمون: فمن يضيف تنبيهًا في ClickStack يضيفه إلى الخدمة التي يعمل فيها، ويُقيَّم التنبيه على موارد حوسبة تلك الخدمة. ولا يوجد إعداد ينقل تنبيهات خدمة ما إلى مكان آخر.

ما يمكنك عزله هو التنبيهات التي تملكها مركزيًا، أي تلك التي يتولى فريق المنصة صيانتها لصالح المؤسسة بأكملها، وهي عادةً الأكثر تكرارًا في التقييم. امنحها خدمة للقراءة فقط خاصة بها داخل المستودع، وأنشئها من نسخة ClickStack مُشغَّلة هناك:

| الخدمة | النوع | تخدم |
| - | - | - |
| الاستيعاب | قراءة وكتابة | OpenTelemetry collector |
| الاستعلام | للقراءة فقط | واجهة ClickStack، والتنبيهات التي ينشئها المستخدمون لأنفسهم |
| التنبيه | للقراءة فقط | التنبيهات المشتركة التي يتولى فريق المنصة صيانتها |

<Warning>
  **عطّل الخمول التلقائي على خدمة التنبيه**

  تهيئة تنبيهات على خدمة ما لا تُبقيها مستيقظة؛ فتقييمات التنبيهات التي تصل إلى خدمة خامدة تتأخر إلى أن تستيقظ الخدمة أو تفشل تمامًا، ولهذا قد تفوت التقييماتُ خدمةَ تنبيه تُرك فيها الخمول التلقائي مُمكَّنًا. أوقف الخمول التلقائي على تلك الخدمة وخطّط لأن تكون مُشغَّلة دائمًا. وينطبق الأمر ذاته في أي مكان تُقيَّم فيه تنبيهاتك: فإذا كانت تعمل على الخدمة التي تخدم الواجهة، فلا يصح ترك تلك الخدمة تخمد كذلك.
</Warning>

أما المقايضات المتبقية فهي تلك الناتجة عن كون الحالة خاصة بكل خدمة:

* التنبيهات المشتركة، وأي لوحات معلومات مرتبطة بها، توجد على خدمة التنبيه فقط ولا تظهر للمستخدمين الذين يعملون على خدمة الاستعلام. وتُسلَّم الإشعارات إلى [الأهداف](/ar/clickstack/features/alerts) ذاتها في الحالتين، فما يفقده المستخدمون هو رؤية التعريفات، لا التنبيه نفسه.
* المصادر على خدمة التنبيه كائنات منفصلة. فالمصادر التي تستخدم [مخطط OpenTelemetry الافتراضي](/ar/clickstack/deployment/managed#adding-data-sources) يتم اكتشافها تلقائيًا، أما المصادر المخصصة فيجب تهيئتها هناك أيضًا قبل أن يتمكن أي تنبيه من الإشارة إليها.

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

<h2 id="considerations">
  اعتبارات إضافية
</h2>

**الخمول التلقائي.** ينتظر الاستعلام الأول الموجَّه إلى خدمة للقراءة فقط دخلت في حالة خمول حتى تبدأ الخدمة، وبذلك يقايض الاستخدام المتقطع قليلاً من زمن الاستجابة مقابل إنفاق أقل. لا تعتمد على التنبيهات لمنع الخمول — عطِّل الخمول التلقائي في أي خدمة تعتمد عليها في تقييم التنبيهات، كما هو موضح [أعلاه](#isolating-alerts). صحيحٌ أن الاستيعاب المستمر يُبقي خدمة القراءة والكتابة مستيقظة، لكن إذا كان الاستيعاب لديك متقطعاً أو مجدولاً، فإن الدفعة الأولى بعد فترة الخمول تنتظر بالطريقة نفسها، وهو ما يظهر على شكل تأخر في بيانات القياس عن بُعد.

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

**حدود النسخ المتماثلة.** يخضع العدد الإجمالي للنسخ المتماثلة عبر جميع الخدمات في المستودع لحد أقصى افتراضي — راجع [حدود الاستخدام](/ar/products/cloud/guides/best-practices/usagelimits).

**عزل ClickStack عن أعباء العمل الأخرى.** إذا كنت تضيف ClickStack إلى خدمة تشغّل بالفعل أعباء عمل أخرى، مثل تحليلات التطبيقات في الوقت الفعلي، فتُستخدم ميزة المستودع نفسها لمنح الـ observability موارد حوسبة خاصة به. راجع دليلنا حول [عزل أعباء عمل الـ observability](/ar/clickstack/managing/estimating-resources#isolating-workloads).

للاطلاع على المجموعة الكاملة من سلوكيات المستودعات وقيودها، راجع دليلنا حول [المستودعات](/ar/products/cloud/features/infrastructure/warehouses).