> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8c05c8a2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# مُدار
> نشر ClickStack المُدار
export const TrackedLink = ({href, eventName, children, ...rest}) => {
const handleClick = () => {
try {
if (typeof window !== "undefined" && window.galaxy && eventName) {
window.galaxy.track(eventName, {
interaction: "click"
});
}
} catch (e) {}
};
return
{children}
;
};
export const Image = ({img, alt, size}) => {
return
;
};
هذا **الدليل موجّه لمستخدمي ClickHouse Cloud الحاليين**. إذا كنت جديدًا على ClickHouse Cloud، فنوصي بدليل [البدء](/ar/clickstack/getting-started/managed) الخاص بـ ClickStack المُدار.
في نمط النشر هذا، تتم استضافة كلٍّ من ClickHouse وواجهة مستخدم ClickStack (HyperDX) على ClickHouse Cloud، مما يقلّل عدد المكوّنات التي يحتاج المستخدم إلى استضافتها ذاتيًا.
إلى جانب تقليل عبء إدارة البنية التحتية، يضمن نمط النشر هذا تكامل المصادقة مع ClickHouse Cloud SSO/SAML. وعلى عكس عمليات النشر المستضافة ذاتيًا، لا حاجة أيضًا إلى توفير مثيل MongoDB لتخزين حالة التطبيق — مثل لوحات المعلومات، وعمليات البحث المحفوظة، وإعدادات المستخدم، والتنبيهات. كما يستفيد المستخدمون من:
* التوسّع التلقائي لقدرات الحوسبة بشكل مستقل عن التخزين
* احتفاظ منخفض التكلفة وعمليًا غير محدود بالاعتماد على تخزين الكائنات
* القدرة على عزل أحمال عمل القراءة والكتابة بشكل مستقل باستخدام Warehouses.
* مصادقة مدمجة
* نُسخ احتياطية مؤتمتة
* ميزات الأمان والامتثال
* ترقيات سلسة
في هذا الوضع، تُترك عملية إدخال البيانات بالكامل للمستخدم. يمكنك إدخال البيانات إلى ClickStack المُدار باستخدام OpenTelemetry Collector المستضاف لديك، أو الإدخال المباشر من مكتبات العميل، أو محركات الجداول الأصلية في ClickHouse (مثل Kafka أو S3)، أو مسارات ETL، أو ClickPipes — خدمة الإدخال المُدارة في ClickHouse Cloud. يوفّر هذا النهج أبسط طريقة وأكثرها كفاءة لتشغيل ClickStack.
### مناسب لـ
يُعد نمط النشر هذا مثاليًا في السيناريوهات التالية:
1. لديك بالفعل بيانات observability في ClickHouse Cloud وترغب في عرضها بصريًا باستخدام ClickStack.
2. تُشغّل عملية نشر واسعة النطاق لـ observability وتحتاج إلى الأداء المخصص وقابلية التوسع التي يوفّرها ClickStack عند تشغيله على ClickHouse Cloud.
3. أنت تستخدم ClickHouse Cloud بالفعل لأغراض التحليلات وتريد تزويد تطبيقك بإمكانات instrumentation باستخدام مكتبات ClickStack — مع إرسال البيانات إلى cluster نفسه. في هذه الحالة، نوصي باستخدام [المستودعات](/ar/products/cloud/features/infrastructure/warehouses) لعزل موارد الحوسبة الخاصة بأعباء عمل observability.
## خطوات الإعداد
يفترض هذا الدليل أنك أنشأت بالفعل خدمة ClickHouse Cloud. إذا لم تكن قد أنشأت خدمة بعد، فاتبع دليل [بدء الاستخدام](/ar/clickstack/getting-started/managed) الخاص بـ ClickStack المُدار. وبذلك ستحصل على خدمة بالحالة نفسها المفترضة في هذا الدليل، أي جاهزة لاستقبال بيانات observability مع تمكين ClickStack.
### أنشئ خدمة جديدة
من الصفحة الرئيسية لـ ClickHouse Cloud، اختر `New service` لإنشاء خدمة جديدة.
### حدّد المزوّد والمنطقة والموارد
**Scale مقابل Enterprise**
نوصي باستخدام [فئة Scale](/ar/products/cloud/features/cloud-tiers) لمعظم أعباء عمل ClickStack. اختر فئة Enterprise إذا كنت بحاجة إلى ميزات أمان متقدمة مثل SAML أو CMEK أو التوافق مع HIPAA. كما توفّر ملفات تعريف عتادية مخصّصة لعمليات نشر ClickStack الكبيرة جدًا. في هذه الحالات، نوصي بالتواصل مع الدعم.
حدّد موفّر Cloud والمنطقة.
عند تحديد CPU والذاكرة، قدِّر ذلك بناءً على معدل نقل إدخال البيانات المتوقع في ClickStack. يوفّر الجدول أدناه إرشادات لتحديد حجم هذه الموارد.
| حجم إدخال البيانات الشهري | موارد الحوسبة الموصى بها |
| ------------------------- | ------------------------ |
| \< 10 TB / شهر | 2 vCPU × 3 نسخ متماثلة |
| 10–50 TB / شهر | 4 vCPU × 3 نسخ متماثلة |
| 50–100 TB / شهر | 8 vCPU × 3 نسخ متماثلة |
| 100–500 TB / شهر | 30 vCPU × 3 نسخ متماثلة |
| 1 PB+ / شهر | 59 vCPU × 3 نسخ متماثلة |
تستند هذه التوصيات إلى الافتراضات التالية:
* يشير حجم البيانات إلى **حجم إدخال البيانات غير المضغوط** شهريًا، وينطبق على كلٍّ من السجلات وآثار التتبع.
* تُعد أنماط الاستعلام نموذجية لحالات استخدام المراقبة، إذ تستهدف معظم الاستعلامات **البيانات الحديثة**، وعادةً آخر 24 ساعة.
* يكون إدخال البيانات **منتظمًا نسبيًا على مدار الشهر**. إذا كنت تتوقع حركة مرور متقطعة أو ارتفاعات مفاجئة، فينبغي توفير هامش سعة إضافي.
* تُدار السعة التخزينية بشكل منفصل عبر تخزين الكائنات في ClickHouse Cloud، وليست عاملًا مقيِّدًا لفترة الاحتفاظ بالبيانات. ونفترض أن البيانات المحتفَظ بها لفترات أطول يُجرى الوصول إليها على نحو غير متكرر.
قد تكون هناك حاجة إلى موارد حوسبة أكبر لأنماط الوصول التي تستعلم بانتظام عن نطاقات زمنية أطول، أو تُجري عمليات تجميع كثيفة، أو تدعم عددًا كبيرًا من المستخدمين المتزامنين.
على الرغم من أن نسختين متماثلتين يمكن أن تلبّيا متطلبات CPU والذاكرة لمعدل إدخال بيانات معيّن، فإننا نوصي باستخدام ثلاث نسخ متماثلة حيثما أمكن لتحقيق السعة الإجمالية نفسها وتحسين التكرار في الخدمة.
هذه القيم **تقديرية فقط** ويجب استخدامها كخط أساس أولي. تعتمد المتطلبات الفعلية على تعقيد الاستعلامات، والتزامن، وسياسات الاحتفاظ، والتباين في معدل نقل إدخال البيانات. راقب دائمًا استخدام الموارد وقم بالتوسعة حسب الحاجة.
بمجرد تحديد المتطلبات، ستستغرق خدمة Managed ClickStack الخاصة بك عدة دقائق لإتمام التجهيز. لا تتردد في استكشاف بقية [ClickHouse Cloud console](/ar/products/cloud/getting-started/intro) أثناء انتظار اكتمال التجهيز.
بمجرد **اكتمال التجهيز، سيتم تفعيل خيار 'ClickStack' في القائمة اليسرى**.
### إعداد الاستيعاب
بعد تجهيز خدمتك، تأكد من تحديدها ثم انقر على "ClickStack" من القائمة اليمنى.
اختر "Start Ingestion"، وسيُطلب منك تحديد مصدر للاستيعاب. يدعم Managed ClickStack كلاً من OpenTelemetry و[Vector](https://vector.dev/) باعتبارهما المصدرين الرئيسيين للاستيعاب. ومع ذلك، يمكن للمستخدمين أيضًا إرسال البيانات مباشرةً إلى ClickHouse ضمن المخطط الخاص بهم باستخدام أي من [التكاملات التي يدعمها ClickHouse Cloud](/ar/integrations/home).
**يُنصح باستخدام OpenTelemetry**
يُنصح بشدة باستخدام OpenTelemetry كتنسيق للاستيعاب.
فهو يوفّر أبسط تجربة وأكثرها كفاءة، مع مخططات جاهزة صُممت خصيصًا للعمل بكفاءة مع ClickStack.
لإرسال بيانات OpenTelemetry إلى Managed ClickStack، يُنصح باستخدام OpenTelemetry Collector. يعمل الـ collector كبوابة تستقبل بيانات OpenTelemetry من تطبيقاتك (ومن collectors أخرى) وتُمرّرها إلى ClickHouse Cloud.
إذا لم يكن لديك collector قيد التشغيل بالفعل، فابدأ تشغيله باتباع الخطوات أدناه. وإذا كانت لديك collectors موجودة، فستجد أيضًا مثالًا على التهيئة.
### ابدأ collector
يفترض ما يلي المسار الموصى به، وهو استخدام **توزيعة ClickStack من OpenTelemetry Collector**، التي تتضمن معالجة إضافية ومُحسّنة خصيصًا لـ ClickHouse Cloud. إذا كنت تريد استخدام OpenTelemetry Collector الخاص بك، فراجع ["تهيئة collectors الموجودة."](#configure-existing-collectors)
للبدء بسرعة، انسخ أمر Docker الموضّح وشغّله.
يجب أن يتضمن هذا الأمر بيانات اعتماد الاتصال الخاصة بك مُعبأة مسبقًا.
**النشر إلى بيئة production**
رغم أن هذا الأمر يستخدم المستخدم `default` للاتصال بـ Managed ClickStack، ينبغي لك إنشاء مستخدم مخصص عند [الانتقال إلى بيئة production](/ar/clickstack/managing/production#create-a-database-ingestion-user-managed) وتعديل التهيئة الخاصة بك.
يؤدي تشغيل هذا الأمر الواحد إلى بدء ClickStack collector مع إتاحة OTLP endpoints على المنفذين 4317 (gRPC) و4318 (HTTP). إذا كان لديك بالفعل instrumentation وagents لـ OpenTelemetry، فيمكنك البدء فورًا في إرسال بيانات telemetry إلى هذه endpoints.
### تهيئة collectors الموجودة
يمكنك أيضًا تهيئة OpenTelemetry Collectors الموجودة لديك أو استخدام التوزيعة الخاصة بك من collector.
**يتطلب ClickHouse exporter**
إذا كنت تستخدم التوزيعة الخاصة بك، مثل [contrib image](https://github.com/open-telemetry/opentelemetry-collector-contrib)، فتأكد من أنها تتضمن [ClickHouse exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/clickhouseexporter).
ولهذا الغرض، نوفّر مثالًا على تهيئة OpenTelemetry Collector يستخدم ClickHouse exporter مع الإعدادات المناسبة ويُفعّل OTLP receivers. تتوافق هذه التهيئة مع الواجهات والسلوك المتوقعين من توزيعة ClickStack.
لمزيد من التفاصيل حول تهيئة OpenTelemetry collectors، راجع ["إدخال البيانات باستخدام OpenTelemetry."](/ar/clickstack/ingesting-data/opentelemetry)
### ابدأ إدخال البيانات (اختياري)
إذا كانت لديك تطبيقات أو بنية تحتية قائمة تريد تزويدها بأدوات OpenTelemetry، فانتقل إلى الأدلة ذات الصلة المرتبطة من خلال UI.
لتزويد تطبيقاتك بالأدوات لجمع traces وlogs، استخدم [language SDKs المدعومة](/ar/clickstack/ingesting-data/sdks/index) التي ترسل البيانات إلى OpenTelemetry Collector الخاص بك، والذي يعمل كبوابة لإدخالها إلى Managed ClickStack.
يمكن [جمع السجلات باستخدام OpenTelemetry Collectors](/ar/clickstack/integration-examples/host-logs) التي تعمل في وضع agent، مع إعادة توجيه البيانات إلى collector نفسها. ولمراقبة Kubernetes، اتبع [الدليل المخصص](/ar/clickstack/integration-examples/kubernetes). وللتكاملات الأخرى، راجع [أدلة البدء السريع](/ar/clickstack/integration-examples/index) الخاصة بنا.
### بيانات تجريبية
بدلًا من ذلك، إذا لم تكن لديك بيانات موجودة، فجرّب إحدى مجموعات البيانات النموذجية لدينا.
* [مجموعة بيانات نموذجية](/ar/clickstack/example-datasets/sample-data) - حمّل مجموعة بيانات نموذجية من العرض التجريبي العام الخاص بنا. شخّص مشكلة بسيطة.
* [الملفات المحلية وmetrics](/ar/clickstack/example-datasets/local-data) - حمّل ملفات محلية وراقب النظام على OSX أو Linux باستخدام OTel collector محلي.
[Vector](https://vector.dev) هو مسار بيانات observability عالي الأداء ومحايد للمورّدين، ويشتهر بشكل خاص باستيعاب السجلات بفضل مرونته وانخفاض استهلاكه للموارد.
عند استخدام Vector مع ClickStack، يكون المستخدمون مسؤولين عن تحديد المخططات الخاصة بهم. وقد تتبع هذه المخططات اصطلاحات OpenTelemetry، لكنها قد تكون أيضًا مخصّصة بالكامل لتمثيل بنى أحداث يحدّدها المستخدم.
**الطابع الزمني مطلوب**
الشرط الصارم الوحيد في Managed ClickStack هو أن تتضمن البيانات **عمود timestamp** (أو حقلًا زمنيًا مكافئًا)، ويمكن تعريفه عند تهيئة data source في ClickStack UI.
يفترض ما يلي أن لديك مثيلًا من Vector قيد التشغيل ومهيّأ مسبقًا باستخدام ingest pipelines لتسليم البيانات.
### أنشئ قاعدة بيانات وجدولًا
يتطلب Vector تعريف جدول ومخطط قبل استيعاب البيانات.
أنشئ أولًا قاعدة بيانات. ويمكن تنفيذ ذلك عبر [ClickHouse Cloud console](/ar/products/cloud/features/sql-console-features/sql-console).
على سبيل المثال، أنشئ قاعدة بيانات للسجلات:
```sql theme={null}
CREATE DATABASE IF NOT EXISTS logs
```
ثم أنشئ جدولًا يتطابق مخططه مع بنية بيانات السجل لديك. يفترض المثال أدناه تنسيقًا تقليديًا لسجل الوصول في Nginx:
```sql theme={null}
CREATE TABLE logs.nginx_logs
(
`time_local` DateTime,
`remote_addr` IPv4,
`remote_user` LowCardinality(String),
`request` String,
`status` UInt16,
`body_bytes_sent` UInt64,
`http_referer` String,
`http_user_agent` String,
`http_x_forwarded_for` LowCardinality(String),
`request_time` Float32,
`upstream_response_time` Float32,
`http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);
```
يجب أن يتوافق جدولك مع مخطط الإخراج الذي يُنتجه Vector. عدّل المخطط حسب الحاجة لبياناتك، مع اتباع [أفضل ممارسات المخطط الموصى بها](/ar/concepts/best-practices/select-data-type).
نوصي بشدة بفهم كيفية عمل [المفاتيح الأساسية](/ar/concepts/core-concepts/primary-indexes) في ClickHouse واختيار مفتاح ترتيب بناءً على أنماط الوصول لديك. راجع الإرشادات [الخاصة بـ ClickStack](/ar/clickstack/managing/performance-tuning#choosing-a-primary-key) بشأن اختيار مفتاح أساسي.
بمجرد إنشاء الجدول، انسخ مقتطف الإعدادات المعروض. عدّل المُدخل لاستهلاك مسارات المعالجة الحالية لديك، وكذلك الجدول الهدف وقاعدة البيانات إذا لزم الأمر. يُفترض أن تكون بيانات الاعتماد مُعبأة مسبقًا.
للمزيد من أمثلة إدخال البيانات باستخدام Vector، راجع ["الإدخال باستخدام Vector"](/ar/clickstack/ingesting-data/vector) أو [توثيق ClickHouse sink في Vector](https://vector.dev/docs/reference/configuration/sinks/clickhouse/) للاطلاع على الخيارات المتقدمة.
### انتقل إلى واجهة مستخدم ClickStack
اختر 'Launch ClickStack' للوصول إلى واجهة ClickStack (HyperDX). ستتم مصادقتك تلقائيًا وسيُعاد توجيهك.
سيتم إنشاء مصادر البيانات مسبقًا لأي بيانات OpenTelemetry.
إذا كنت تستخدم Vector، فستحتاج إلى إنشاء مصادر البيانات الخاصة بك. سيُطلب منك إنشاء مصدر بيانات عند أول تسجيل دخول. نعرض أدناه مثالًا على إعداد مصدر بيانات للسجلات.
يفترض هذا الإعداد مخططًا بأسلوب Nginx مع عمود `time_local` مستخدمًا كطابع زمني. ويُفترض أن يكون هذا، حيثما أمكن، عمود الطابع الزمني المعرَّف في المفتاح الأساسي. **هذا العمود إلزامي**.
نوصي أيضًا بتحديث `Default SELECT` لتحديد الأعمدة التي ستُعرض في عرض السجلات بشكل صريح. وإذا كانت هناك حقول إضافية متاحة، مثل اسم الخدمة أو مستوى السجل أو عمود body، فيمكن إعدادها أيضًا. كما يمكن تجاوز عمود عرض الطابع الزمني إذا كان مختلفًا عن العمود المستخدم في المفتاح الأساسي للجدول والمُعد أعلاه.
في المثال أعلاه، لا يوجد عمود `Body` في البيانات. وبدلًا من ذلك، يُعرَّف باستخدام تعبير SQL يعيد تكوين سطر سجل Nginx من الحقول المتاحة.
للاطلاع على خيارات أخرى ممكنة، راجع [مرجع الإعدادات](/ar/clickstack/managing/config).
بمجرد إنشائه، ينبغي أن يتم توجيهك إلى عرض البحث حيث يمكنك البدء فورًا في استكشاف بياناتك.
وهذا كل شيء — لقد أصبحت جاهزًا تمامًا. 🎉
انطلق واستكشف ClickStack: ابدأ بالبحث في السجلات والتتبعات، واطّلع على كيفية ترابط السجلات والتتبعات والمقاييس في الوقت الفعلي، وأنشئ لوحات المعلومات، واستكشف خرائط الخدمات، واكتشف Event deltas وPatterns، وأعدّ التنبيهات لتبقى سبّاقًا في معالجة المشكلات.
### حدد خدمة
من الصفحة الرئيسية لـ ClickHouse Cloud، حدد الخدمة التي تريد تمكين ClickStack المُدار لها.
**تقدير الموارد**
يفترض هذا الدليل أنك قد وفّرت موارد كافية للتعامل مع حجم بيانات الأوبزرفابيليتي التي تخطط لاستيعابها والاستعلام عنها باستخدام ClickStack. لتقدير الموارد المطلوبة، راجع دليل [تقدير الموارد](/ar/clickstack/managing/estimating-resources).
إذا كانت خدمة ClickHouse لديك تستضيف بالفعل أعباء عمل قائمة، مثل تحليلات التطبيقات في الوقت الفعلي، فنوصي بإنشاء خدمة فرعية باستخدام [ميزة warehouses في ClickHouse Cloud](/ar/products/cloud/features/infrastructure/warehouses) لعزل عبء عمل الأوبزرفابيليتي. يضمن ذلك عدم تأثر تطبيقاتك الحالية، مع إبقاء مجموعات البيانات متاحة من كلتا الخدمتين.
### انتقل إلى واجهة ClickStack
حدّد 'ClickStack' من قائمة التنقل اليسرى. ستتم إعادة توجيهك إلى واجهة ClickStack وستتم مصادقتك تلقائيًا استنادًا إلى أذونات ClickHouse Cloud الخاصة بك.
إذا كانت هناك أي جداول OpenTelemetry موجودة بالفعل في خدمتك، فسيتم اكتشافها تلقائيًا وإنشاء مصادر البيانات المقابلة لها.
**الاكتشاف التلقائي لمصادر البيانات**
يعتمد الاكتشاف التلقائي على مخطط جداول OpenTelemetry القياسي الذي توفّره توزيعة ClickStack الخاصة بـ OpenTelemetry Collector. يتم إنشاء المصادر لقاعدة البيانات التي تضم المجموعة الأكثر اكتمالًا من الجداول. ويمكن إضافة جداول إضافية [كمصادر بيانات منفصلة](/ar/clickstack/managing/config#datasource-settings) عند الحاجة.
إذا نجح الاكتشاف التلقائي، فمن المفترض أن يتم توجيهك إلى عرض البحث حيث يمكنك البدء فورًا في استكشاف بياناتك.
إذا نجحت هذه الخطوة، فهذا كل ما في الأمر — أنت جاهز تمامًا 🎉، وإلا فانتقل إلى إعداد إدخال البيانات.
### إعداد الاستيعاب
إذا فشل الاكتشاف التلقائي، أو لم تكن لديك جداول موجودة، سيُطلب منك إعداد الاستيعاب.
حدد "Start Ingestion" وستظهر لك مطالبة باختيار مصدر استيعاب. يدعم Managed ClickStack كلًّا من OpenTelemetry و[Vector](https://vector.dev/) بوصفهما مصدرَي الاستيعاب الرئيسيين. غير أن المستخدمين أحرار أيضًا في إرسال البيانات مباشرةً إلى ClickHouse وفق مخططهم الخاص، باستخدام أيٍّ من [تكاملات ClickHouse Cloud المدعومة](/ar/integrations/home).
**يُوصى باستخدام OpenTelemetry**
يُنصح بشدة باستخدام OpenTelemetry كصيغة للإدخال.
فهو يوفّر أبسط تجربة وأكثرها كفاءة، مع مخططات جاهزة صُممت خصيصًا للعمل بكفاءة مع ClickStack.
لإرسال بيانات OpenTelemetry إلى Managed ClickStack، يُنصح باستخدام OpenTelemetry Collector. يعمل الـ collector كبوابة تستقبل بيانات OpenTelemetry من تطبيقاتك (ومن collectors أخرى) ثم تُمرّرها إلى ClickHouse Cloud.
إذا لم يكن لديك collector قيد التشغيل بالفعل، فابدأ بتشغيل واحد باتباع الخطوات أدناه. وإذا كانت لديك collectors موجودة، فستجد أيضًا مثالًا على التهيئة.
### بدء تشغيل collector
يفترض ما يلي المسار الموصى به، وهو استخدام **توزيعة ClickStack من OpenTelemetry Collector**، التي تتضمن معالجة إضافية ومُحسّنة خصيصًا لـ ClickHouse Cloud. إذا كنت تريد استخدام OpenTelemetry Collector الخاص بك، فراجع ["تهيئة collectors الموجودة."](#configure-existing-collectors)
للبدء بسرعة، انسخ أمر Docker الموضّح وشغّله.
**عدّل هذا الأمر باستخدام بيانات اعتماد الخدمة الخاصة بك، التي دوّنتها عند إنشاء خدمتك.**
**النشر إلى بيئة production**
رغم أن هذا الأمر يستخدم المستخدم `default` للاتصال بـ Managed ClickStack، ينبغي إنشاء مستخدم مخصّص عند [الانتقال إلى بيئة production](/ar/clickstack/managing/production#create-a-database-ingestion-user-managed) وتعديل التهيئة.
يؤدي تشغيل هذا الأمر الواحد إلى بدء ClickStack collector مع إتاحة نقاط نهاية OTLP على المنفذين 4317 (gRPC) و4318 (HTTP). إذا كانت لديك بالفعل إعدادات instrumentation ووكلاء OpenTelemetry، فيمكنك البدء فورًا في إرسال بيانات القياس عن بُعد إلى نقاط النهاية هذه.
### تهيئة collectors الموجودة
يمكنك أيضًا تهيئة OpenTelemetry Collectors الموجودة لديك أو استخدام التوزيعة الخاصة بك من الـ collector.
**مطلوب ClickHouse exporter**
إذا كنت تستخدم التوزيعة الخاصة بك، مثل [contrib image](https://github.com/open-telemetry/opentelemetry-collector-contrib)، فتأكّد من أنها تتضمن [ClickHouse exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/clickhouseexporter).
ولهذا الغرض، يتوفر مثال على تهيئة OpenTelemetry Collector يستخدم ClickHouse exporter مع الإعدادات المناسبة ويُعرّض OTLP receivers. تتطابق هذه التهيئة مع الواجهات والسلوك المتوقعَين من توزيعة ClickStack.
فيما يلي مثال على هذه التهيئة (ستُعبَّأ متغيرات البيئة مسبقًا عند النسخ من UI):
```yaml theme={null}
receivers:
otlp/hyperdx:
protocols:
grpc:
include_metadata: true
endpoint: "0.0.0.0:4317"
http:
cors:
allowed_origins: ["*"]
allowed_headers: ["*"]
include_metadata: true
endpoint: "0.0.0.0:4318"
processors:
batch:
memory_limiter:
# 80% of maximum memory up to 2G, adjust for low memory environments
limit_mib: 1500
# 25% of limit up to 2G, adjust for low memory environments
spike_limit_mib: 512
check_interval: 5s
connectors:
routing/logs:
default_pipelines: [logs/out-default]
error_mode: ignore
table:
- context: log
statement: route() where IsMatch(attributes["rr-web.event"], ".*")
pipelines: [logs/out-rrweb]
exporters:
debug:
verbosity: detailed
sampling_initial: 5
sampling_thereafter: 200
clickhouse/rrweb:
database: default
endpoint:
password:
username: default
ttl: 720h
logs_table_name: hyperdx_sessions
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
clickhouse:
database: default
endpoint:
password:
username: default
ttl: 720h
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
service:
pipelines:
traces:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
metrics:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/in:
receivers: [otlp/hyperdx]
exporters: [routing/logs]
logs/out-default:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/out-rrweb:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse/rrweb]
```
لمزيد من التفاصيل حول تهيئة OpenTelemetry Collectors، راجع ["إدخال البيانات باستخدام OpenTelemetry."](/ar/clickstack/ingesting-data/opentelemetry)
### بدء إدخال البيانات (اختياري)
إذا كانت لديك تطبيقات أو بنية تحتية قائمة وتريد تزويدها بـ OpenTelemetry، فانتقل إلى الأدلة ذات الصلة المرتبطة من "ربط تطبيق".
لتزويد تطبيقاتك بما يمكّنها من جمع traces وlogs، استخدم [language SDKs المدعومة](/ar/clickstack/ingesting-data/sdks/index) التي ترسل البيانات إلى OpenTelemetry Collector الخاص بك، والذي يعمل كبوابة لإدخالها إلى Managed ClickStack.
ويمكن [جمع السجلات باستخدام OpenTelemetry Collectors](/ar/clickstack/integration-examples/host-logs) التي تعمل في وضع agent، مع إعادة توجيه البيانات إلى الـ collector نفسه. ولمراقبة Kubernetes، اتبع [الدليل المخصص](/ar/clickstack/integration-examples/kubernetes). أما للتكاملات الأخرى، فراجع [أدلة quickstart](/ar/clickstack/integration-examples/index) الخاصة بنا.
[Vector](https://vector.dev) هو خط أنابيب عالي الأداء ومحايد للمورّدين لبيانات observability، ويشتهر خصوصًا في ingest السجلات بفضل مرونته وانخفاض استهلاك الموارد.
عند استخدام Vector مع ClickStack، يكون المستخدمون مسؤولين عن تحديد المخططات الخاصة بهم. وقد تتبع هذه المخططات اصطلاحات OpenTelemetry، لكنها قد تكون أيضًا مخصّصة بالكامل لتمثيل بنى أحداث يحدّدها المستخدم.
**الطابع الزمني مطلوب**
الشرط الصارم الوحيد في Managed ClickStack هو أن تتضمن البيانات **عمود طابع زمني** (أو حقل وقت مكافئ)، ويمكن تعريفه عند تهيئة مصدر البيانات في ClickStack UI.
يفترض ما يلي أن لديك مثيلًا من Vector قيد التشغيل ومُهيّأ مسبقًا باستخدام ingest pipelines ويقوم بإرسال البيانات.
### أنشئ قاعدة بيانات وجدولًا
يتطلب Vector تحديد جدول ومخطط قبل ingest البيانات.
أنشئ أولًا قاعدة بيانات. ويمكن القيام بذلك عبر [ClickHouse Cloud console](/ar/products/cloud/features/sql-console-features/sql-console).
على سبيل المثال، أنشئ قاعدة بيانات للسجلات:
```sql theme={null}
CREATE DATABASE IF NOT EXISTS logs
```
ثم أنشئ جدولًا يتطابق مخططه مع بنية بيانات السجل. يفترض المثال أدناه تنسيق سجل وصول Nginx الكلاسيكي:
```sql theme={null}
CREATE TABLE logs.nginx_logs
(
`time_local` DateTime,
`remote_addr` IPv4,
`remote_user` LowCardinality(String),
`request` String,
`status` UInt16,
`body_bytes_sent` UInt64,
`http_referer` String,
`http_user_agent` String,
`http_x_forwarded_for` LowCardinality(String),
`request_time` Float32,
`upstream_response_time` Float32,
`http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);
```
يجب أن يتوافق جدولك مع مخطط المخرجات الذي يُنشئه Vector. عدّل المخطط حسب الحاجة لبياناتك، مع اتباع [أفضل ممارسات المخطط](/ar/concepts/best-practices/select-data-type) الموصى بها.
نوصي بشدة بفهم كيفية عمل [المفاتيح الأساسية](/ar/concepts/core-concepts/primary-indexes) في ClickHouse واختيار مفتاح ترتيب استنادًا إلى أنماط الوصول لديك. راجع الإرشادات [الخاصة بـ ClickStack](/ar/clickstack/managing/performance-tuning#choosing-a-primary-key) حول اختيار مفتاح أساسي.
بمجرد إنشاء الجدول، انسخ مقتطف الإعدادات الظاهر. عدّل المُدخل لاستهلاك مسارات المعالجة الحالية لديك، وكذلك الجدول الهدف وقاعدة البيانات إذا لزم الأمر. يجب أن تكون بيانات الاعتماد مُعبأة مسبقًا.
للمزيد من أمثلة إدخال البيانات باستخدام Vector، راجع ["الإدخال باستخدام Vector"](/ar/clickstack/ingesting-data/vector) أو [توثيق مصبّ ClickHouse في Vector](https://vector.dev/docs/reference/configuration/sinks/clickhouse/) للاطلاع على الخيارات المتقدمة.
### الانتقال إلى واجهة مستخدم ClickStack
بعد إكمال إعداد إدخال البيانات والبدء في إرسالها، حدِّد "التالي".
إذا كنت قد أدخلت بيانات OpenTelemetry باستخدام هذا الدليل، فسيتم إنشاء مصادر البيانات تلقائيًا، ولن تحتاج إلى أي إعداد إضافي. يمكنك البدء في استكشاف ClickStack فورًا. سيتم توجيهك إلى عرض البحث مع تحديد مصدر تلقائيًا، بحيث يمكنك بدء الاستعلام مباشرةً.
هذا كل ما في الأمر — أصبحت جاهزًا 🎉.
إذا كنت قد أدخلت البيانات عبر Vector أو أي مصدر آخر، فسيُطلب منك تهيئة مصدر البيانات.
يفترض الإعداد أعلاه مخططًا بأسلوب Nginx، مع استخدام العمود `time_local` كطابع زمني. ويُفضَّل، متى أمكن، أن يكون هذا هو عمود الطابع الزمني المعرَّف ضمن المفتاح الأساسي. **هذا العمود إلزامي**.
نوصي أيضًا بتحديث `Default SELECT` لتحديد الأعمدة التي تُعرض صراحةً في عرض السجلات. وإذا كانت هناك حقول إضافية متاحة، مثل اسم الخدمة أو مستوى السجل أو عمود `body`، فيمكن تهيئتها أيضًا. ويمكن أيضًا تعيين عمود مختلف لعرض الطابع الزمني إذا كان يختلف عن العمود المستخدم في المفتاح الأساسي للجدول والمُهيأ أعلاه.
في المثال أعلاه، لا يوجد عمود `Body` في البيانات. وبدلًا من ذلك، يُعرَّف باستخدام تعبير SQL يعيد تكوين سطر سجل Nginx من الحقول المتاحة.
للاطلاع على خيارات أخرى ممكنة، راجع [مرجع الإعدادات](/ar/clickstack/managing/config#hyperdx).
بعد تهيئة المصدر، انقر فوق "حفظ" وابدأ في استكشاف بياناتك.
## مهام إضافية
### منح حق الوصول إلى ClickStack المُدار
1. انتقل إلى الخدمة الخاصة بك في وحدة تحكم ClickHouse Cloud
2. انتقل إلى **Settings** → **SQL Console Access**
3. عيّن مستوى الأذونات المناسب لكل مستخدم:
* **Service Admin → Full Access** - مطلوب لتمكين التنبيهات
* **Service Read Only → Read Only** - يمكنه عرض بيانات observability وإنشاء dashboards
* **No access** - لا يمكنه الوصول إلى HyperDX
**تتطلب التنبيهات وصول Admin**
لتمكين التنبيهات، يجب أن يسجّل الدخول إلى HyperDX مرة واحدة على الأقل مستخدم واحد لديه أذونات **Service Admin** (المعيّنة إلى **Full Access** في القائمة المنسدلة **SQL Console Access**). يؤدي ذلك إلى تهيئة مستخدم مخصص في قاعدة البيانات لتشغيل استعلامات التنبيهات.
### استخدام ClickStack مع حوسبة للقراءة فقط
يمكن لواجهة مستخدم ClickStack أن تعمل بالكامل على خدمة ClickHouse Cloud للقراءة فقط. ويُوصى بهذا الإعداد عندما تريد عزل أحمال الإدخال والاستعلام.
#### كيف يختار ClickStack موارد الحوسبة
تتصل واجهة مستخدم ClickStack دائمًا بخدمة ClickHouse التي يتم تشغيلها منها في وحدة تحكم ClickHouse Cloud.
وهذا يعني:
* إذا فتحت ClickStack من خدمة للقراءة فقط، فستُشغَّل جميع الاستعلامات التي تصدرها واجهة مستخدم ClickStack على موارد الحوسبة المخصّصة للقراءة فقط.
* إذا فتحت ClickStack من خدمة للقراءة والكتابة، فسيستخدم ClickStack موارد الحوسبة الخاصة بها بدلًا من ذلك.
لا يلزم إجراء أي تهيئة إضافية داخل ClickStack لفرض وضع القراءة فقط.
#### الإعداد الموصى به
لتشغيل ClickStack على موارد compute للقراءة فقط:
1. أنشئ أو حدِّد خدمة ClickHouse Cloud ضمن الـ warehouse ومُهيأة للقراءة فقط.
2. في وحدة تحكم ClickHouse Cloud، حدِّد الخدمة المهيأة للقراءة فقط.
3. شغِّل ClickStack من قائمة التنقل اليسرى.
بمجرد تشغيله، سترتبط واجهة مستخدم ClickStack تلقائيًا بهذه الخدمة المهيأة للقراءة فقط.
### إضافة المزيد من مصادر البيانات
يدعم ClickStack OpenTelemetry دعمًا أصيلًا، لكنه لا يقتصر عليه فقط — يمكنك استخدام مخططات الجداول الخاصة بك إذا رغبت.
يوضح ما يلي كيف يمكن للمستخدمين إضافة مصادر بيانات إضافية بخلاف تلك التي تُضبط تلقائيًا.
#### استخدام مخططات OpenTelemetry
إذا كنت تستخدم OTel collector لإنشاء قاعدة البيانات والجداول داخل ClickHouse، فاترك جميع القيم الافتراضية كما هي في نموذج إنشاء المصدر، واملأ الحقل `Table` بالقيمة `otel_logs` لإنشاء مصدر سجلات. ينبغي اكتشاف جميع الإعدادات الأخرى تلقائيًا، ما يتيح لك النقر على `Save New Source`.
لإنشاء مصادر للتتبعات ومقاييس OTel، يمكنك اختيار `Create New Source` من القائمة العلوية.
من هنا، حدِّد نوع المصدر المطلوب ثم الجدول المناسب. على سبيل المثال، للتتبعات، حدِّد الجدول `otel_traces`. ينبغي اكتشاف جميع الإعدادات تلقائيًا.
**ربط المصادر**
لاحظ أن مصادر البيانات المختلفة في ClickStack—مثل السجلات والتتبعات—يمكن ربطها ببعضها البعض. ولتمكين ذلك، يلزم إجراء إعدادات إضافية في كل مصدر. على سبيل المثال، في مصدر السجلات يمكنك تحديد مصدر التتبعات المقابل، والعكس صحيح في مصدر التتبعات. راجع ["المصادر المترابطة"](/ar/clickstack/managing/config#correlated-sources) لمزيد من التفاصيل.
#### استخدام المخططات المخصصة
يمكن للمستخدمين الذين يرغبون في ربط ClickStack بخدمة حالية تحتوي على بيانات إكمال إعدادات قاعدة البيانات والجدول حسب الحاجة. سيتم اكتشاف الإعدادات تلقائيًا إذا كانت الجداول متوافقة مع مخططات OpenTelemetry لـ ClickHouse.
إذا كنت تستخدم مخططًا خاصًا بك، فنوصي بإنشاء مصدر للسجلات مع التأكد من تحديد الحقول المطلوبة — راجع ["إعدادات مصدر السجل"](/ar/clickstack/managing/config#logs) لمزيد من التفاصيل.
## اختيار المخطط: Map مقابل JSON
يخزّن ClickStack السمات في أعمدة `Map(LowCardinality(String), String)` افتراضيًا. هذا هو المخطط الموصى به لأعباء عمل Observability. وعند دمجه مع [تسلسل map المقسّم إلى buckets](/ar/reference/data-types/map#bucketed-map-serialization) وفهارس النص على مفاتيح map وقيمه، فإنه يوفّر عمليات بحث انتقائية من دون الكلفة الإضافية لإدخال كل مفتاح على حدة كما في JSON subcolumns الديناميكية.
يتوفر مخطط من النوع `JSON` في مرحلة بيتا للتقييم على أعباء العمل التي تتضمن مجموعة صغيرة ومستقرة من مفاتيح السمات. وهو **غير موصى به** كخيار افتراضي. راجع [Map مقابل نوع JSON](/ar/clickstack/ingesting-data/schema/map-vs-json) للاطلاع على المقارنة الكاملة ومتغيرات البيئة المطلوبة لتمكين دعم JSON.