عمليات تقنية المعلومات
اسأل Dynatrace وSplunk في محادثة واحدة
كيف يعمل بوتيفاي مع Dynatrace وSplunk: الأسئلة التي يجيب عنها، وقدرات DQL وSPL وITSI التي يستخدمها، ولماذا يبقى للقراءة فقط افتراضيا.
آخر تحديث · 6 دقائق قراءة
لماذا تربط بوتيفاي بـDynatrace وSplunk معا؟
تستخدم مؤسسات كثيرة المنصتين معا لأسباب وجيهة: Dynatrace لمراقبة التطبيقات والبنية التحتية مع اكتشاف المشكلات تلقائيا وخريطة الاعتماديات، وSplunk للبحث في السجلات والأمن وبيانات الأحداث طويلة الاحتفاظ. وأثناء الحادثة يتنقل المهندسون بين المنصتين، ويعيدون كتابة السؤال نفسه بلغة DQL ثم بلغة SPL، ويطابقون الخوادم والخدمات بالعين.
بوتيفاي يلغي هذا التنقل: يحتفظ بسؤال واحد ونافذة زمنية واحدة، ويستدعي كل منصة عبر واجهتها البرمجية، ويجمع النتائج في إجابة واحدة. ولا ينسخ بيانات المراقبة إلى أي مكان؛ بل يستعلم من المنصات التي تدفع ثمنها أصلا، بالصلاحيات التي تمنحها له.
ما الأسئلة التي تجيب عنها عبر Dynatrace وSplunk معا؟
أفضل الأسئلة هي التي يطرحها المهندسون أصلا في قنوات الحوادث، وتكون إجابتها موزعة على أداتين أو أكثر.
- ما المشكلات المفتوحة الآن على خدمة المدفوعات، وما السبب الجذري بحسب Dynatrace؟
- هل نُشر شيء على خدمة الدفع خلال الساعتين السابقتين لارتفاع زمن الاستجابة؟
- اعرض سجلات الأخطاء من خوادم order-api منذ 09:30 مجمّعة حسب رسالة الخطأ.
- ما تنبيهات Splunk التي انطلقت خلال الليل، وهل يطابق أي منها مشكلة مفتوحة في Dynatrace؟
- هل توجد أحداث بارزة في ITSI للخدمة نفسها، ومتى بدأت؟
- ما أبطأ التتبعات عبر خدمة الدفع في الساعة الأخيرة، وأي استدعاء لاحق يستهلك معظم الوقت؟
ما قدرات Dynatrace التي يستخدمها بوتيفاي؟
الموصل الجيد لـDynatrace يعرض البيئة كمجموعة أدوات محددة بدلا من استدعاء عام واحد، لتكون لكل أداة صلاحياتها ومستوى خطورتها. يقدّم بوتيفاي 14 أداة لـDynatrace: ثلاث عشرة منها للقراءة وتعمل مباشرة، وواحدة للكتابة تنتظر الموافقة دائما.
لغة DQL هي لغة الاستعلام القائمة على خطوط المعالجة للبيانات المخزنة في Grail، واستعلام DQL طلب للقراءة فقط. كما يقدّم Dynatrace ذكاء اصطناعيا توليديا، عُرف سابقا باسم Davis CoPilot وأصبح اليوم ضمن Dynatrace Intelligence، يحوّل الأسئلة بلغة طبيعية إلى DQL ويشرح استعلامات DQL بلغة مفهومة.
| الأداة | وظيفتها | الموافقة |
|---|---|---|
| list_problems | تسرد المشكلات النشطة والمحلولة ضمن نافذة زمنية | تعمل مباشرة |
| get_problem | تجلب أدلة السبب الجذري والكيانات المتأثرة لمشكلة واحدة | تعمل مباشرة |
| list_entities | تسرد الخوادم والخدمات والحاويات وقواعد البيانات المطابقة لمحدِّد | تعمل مباشرة |
| get_entity | تجلب خصائص كيان واحد وعلاقاته ووسومه | تعمل مباشرة |
| get_entity_type_schema | تعيد بنية نوع الكيان لبناء محدِّدات صحيحة | تعمل مباشرة |
| query_metrics | تستعلم عن مقياس زمني ضمن نافذة زمنية | تعمل مباشرة |
| search_logs | تنفّذ بحث سجلات بلغة DQL في Grail | تعمل مباشرة |
| query_traces | تنفّذ بحث تتبعات بلغة DQL في Grail | تعمل مباشرة |
| verify_dql | تفحص استعلام DQL بحثا عن أخطاء الصياغة دون تشغيله | تعمل مباشرة |
| davis_nl_to_dql | تحوّل سؤالا بلغة طبيعية إلى DQL عبر Davis CoPilot | تعمل مباشرة |
| davis_explain_dql | تشرح استعلام DQL بلغة طبيعية عبر Davis CoPilot | تعمل مباشرة |
| list_events | تسرد الأحداث، ومنها أحداث النشر والتغيير، ضمن نافذة زمنية | تعمل مباشرة |
| list_deployments | تسرد أحداث النشر والتغيير لربط المشكلة بإصدار حديث | تعمل مباشرة |
| ingest_deployment_event | تسجّل حدث نشر في Dynatrace | تنتظر الموافقة دائما |
ما قدرات Splunk التي يستخدمها بوتيفاي؟
تُكتب عمليات البحث في Splunk بلغة SPL. وأدوات Splunk لدى بوتيفاي في بوتيفاي كلها للقراءة فقط، وأداة البحث ترفض العمل من دون نافذة زمنية وحد أقصى للنتائج، فلا يتحول سؤال غامض إلى بحث مكلف في كل البيانات منذ البداية.
| الأداة | وظيفتها | الموافقة |
|---|---|---|
| run_spl_search | تشغّل بحث SPL بنافذة زمنية وحد نتائج إلزاميين وتعيد الصفحة الأولى | تعمل مباشرة |
| get_search_results | تتصفح نتائج مهمة بحث سابقة دون إعادة تشغيلها | تعمل مباشرة |
| list_saved_searches | تسرد عمليات البحث المحفوظة المتاحة للرمز | تعمل مباشرة |
| run_saved_search | تشغّل بحثا محفوظا باسمه | تعمل مباشرة |
| list_fired_alerts | تسرد التنبيهات التي انطلقت ضمن نافذة زمنية محددة | تعمل مباشرة |
| list_indexes | تسرد الفهارس المتاحة للرمز | تعمل مباشرة |
| get_field_summary | تلخّص الحقول المتاحة في فهرس | تعمل مباشرة |
| list_itsi_notable_events | تسرد الأحداث البارزة في IT Service Intelligence (تتطلب ترخيص ITSI) | تعمل مباشرة |
لماذا القراءة فقط افتراضيا، ولماذا تحتاج أحداث النشر إلى موافقة؟
القراءة من Dynatrace وSplunk لا تُعطّل بيئة الإنتاج، لذلك تعمل هذه الأدوات دون أن تبطئ المهندس. أما الكتابة فمختلفة حتى لو بدت بريئة. فحدث النشر المرسَل إلى Events API v2 في Dynatrace يصبح جزءا من الخط الزمني الذي يعتمد عليه Dynatrace وفريقك لربط المشكلات بالإصدارات، والحدث الخاطئ، على كيان خاطئ أو في وقت خاطئ، يضلل كل تحقيق لاحق.
ولهذا تنتظر أداة أحداث النشر في بوتيفاي دائما موافقة شخص على الحدث بعينه، ولا تدخل صلاحية كتابة الأحداث (events:ingest) ضمن الصلاحيات الافتراضية لـDynatrace. أما رموز Splunk فتعتمد على الأدوار، أي أن دور الرمز في Splunk يحدد ما يستطيع الوصول إليه؛ فامنحه دورا لا يبحث إلا في الفهارس التي يحتاجها بوتيفاي.
مثال: التحقيق في ارتفاع زمن استجابة خدمة الدفع عبر المنصتين
هكذا يمكن أن يمر سؤال واحد مثل «لماذا أصبحت خدمة الدفع بطيئة عند 14:05؟» عبر المنصتين. يختار بوتيفاي كل خطوة بناء على نتيجة الخطوة السابقة.
- list_problems من 12:00 حتى الآن تجد مشكلة مفتوحة على خدمة الدفع، وget_problem تعيد الكيانات المتأثرة وأدلة السبب الجذري من Dynatrace.
- list_deployments للنافذة نفسها تُظهر نشر إصدار على خدمة الدفع عند 13:58.
- query_traces باستعلام DQL للتتبعات تُظهر أن معظم الزيادة في زمن الاستجابة في استدعاءات خدمة المخزون.
- run_spl_search على فهرس التطبيق، محدودا بين 13:30 و14:30، يجد خطأ مهلة اتصال جديدا من عميل خدمة المخزون بدأ عند 14:04.
- list_itsi_notable_events تؤكد حدثا بارزا في ITSI على خدمة المخزون عند 14:06، وlist_fired_alerts تُظهر تنبيه Splunk المرتبط.
- يكتب بوتيفاي ملخصا موجزا: السبب المرجح هو تغيير عميل المخزون في إصدار 13:58، مع ربط كل ادعاء بالاستعلام الذي أنتجه، وخطوة تالية مقترحة لمهندس المناوبة.
كيف تضمن صحة استعلامات DQL وSPL التي يكتبها الذكاء الاصطناعي؟
تكتب النماذج اللغوية استعلامات معقولة الشكل لكنها أحيانا خاطئة بصمت: اسم حقل خاطئ، أو فهرس خاطئ، أو شرط لا يعيد شيئا. ابنِ الضمانات في مسار الأدوات نفسه بدلا من الاعتماد على حرص النموذج.
- الاستكشاف قبل الاستعلام: اسرد الفهارس ولخّص الحقول في Splunk، واجلب بنية نوع الكيان في Dynatrace، قبل كتابة الاستعلام.
- التحقق قبل التشغيل: افحص DQL بأداة verify_dql، واستخدم خطوة الشرح حين يحتاج المهندس إلى فهم ما يفعله الاستعلام.
- تفضيل الاستعلامات المعتمدة: البحث المحفوظ الذي يثق به فريقك أفضل من استعلام SPL جديد كُتب تحت الضغط.
- تقييد كل شيء: نافذة زمنية واحدة لكل استدعاء، وحد أقصى للنتائج في كل بحث.
- إظهار الاستعلام: يجب أن تتضمن كل نتيجة في الإجابة استعلام DQL أو SPL الذي أنتجها، ليعيد المهندس تشغيله في واجهة المنصة نفسها.
أسئلة شائعة
هل يستطيع بوتيفاي كتابة استعلامات SPL لـSplunk وDQL لـDynatrace؟
نعم، يكتب الاثنين، ويستطيع في DQL الاستعانة بقدرة Dynatrace نفسها على تحويل اللغة الطبيعية إلى DQL. ويجب أن تُقيَّد الاستعلامات بنافذة زمنية وحد للنتائج، وأن يُتحقق منها حيث تسمح المنصة، وأن تُعرض مع النتائج ليراجعها المهندسون.
هل يحتاج بوتيفاي صلاحية كتابة في Dynatrace أو Splunk؟
لا، ليس للتحقيق. كل ما في التحقيق المعتاد قراءة فقط. صلاحية الكتابة لازمة فقط لإجراءات مثل تسجيل حدث نشر، ويجب أن تتطلب موافقة في كل مرة.
هل يحل بوتيفاي محل Davis AI أو Splunk ITSI؟
لا. الذكاء الاصطناعي المدمج في Dynatrace وSplunk ITSI يرصدان المشكلات ويجمعان الأحداث داخل بياناتهما. أما بوتيفاي فيقرأ مخرجاتهما ويربطها بالمنصة الأخرى وبطلبات التغيير والحوادث.
ما الصلاحيات المناسبة لاتصالات Dynatrace وSplunk؟
في Dynatrace امنح صلاحيات القراءة للمشكلات والكيانات والمقاييس والأحداث والسجلات والتتبعات، وأضف صلاحية تسجيل الأحداث فقط إذا أردت كتابة أحداث النشر. وفي Splunk استخدم رمزا لا يسمح دوره إلا بالبحث في الفهارس التي يحتاجها بوتيفاي.
هل يقرأ بوتيفاي أحداث ITSI البارزة من دون ITSI؟
لا. الأحداث البارزة جزء من Splunk IT Service Intelligence، فالأداة تعمل فقط مع بيئات Splunk المرخّص فيها ITSI. ومن دونه يظل بوتيفاي قادرا على استخدام التنبيهات المنطلقة وعمليات البحث المحفوظة وبحث SPL.