ربط معالجة السجلات في السحابة وعلى الأجهزة المحلية

تتطلب الهندسيات الحديثة القائمة على السحابة حلول معالجة سجلات قوية وقابلة للتوسيع وآمنة لمراقبة التطبيقات الموزعة. تقدم هذه الدراسة حلاً هجينًا لجمع السجلات وتجميعها وتحليلها باستخدام خدمة Azure Kubernetes (AKS) لإنشاء السجلات، ونظام Fluent Bit لجمع السجلات، وخدمة Azure EventHub للتجميع الوسيط، وSplunk المنتشر على مجموعة Apache CloudStack على أرضية محلية لفهرسة السجلات الشاملة والتصور.

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

مقدمة

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

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

تقدم هذه الورقة حلا شاملا يتناول هذه التحديات من خلال استغلال القدرات المجتمعة لموارد Azure و Apache CloudStack. من خلال دمج قابلية التوسع والتحليلات في Azure مع مرونة وفعالية التكلفة لبنية CloudStack على الأرض، يوفر هذا الحل نهجًا قويًا وموحدًا لتسجيل البيانات المركزي.

مراجعة الأدب

تواجه جمع البيانات المركزي في خدمات مايكرو تحديات مثل تأخير الشبكة وتنوع صيغ البيانات والأمان عبر طبقات متعددة. بينما يُستخدم وكلاء خفيفو الوزن مثل Fluent Bit وFluentD على نطاق واسع، إلا أن نقل البيانات الفعال يظل تحديًا.

الحلول مثل ELK stack و Azure Monitor تقدم معالجة سجل مركزية ولكن عادة ما تنطوي على تنفيذات إما في السحاب فقط أو على الأرض فقط، مما يقيد المرونة في النشر الهجين. تسمح الحلول الهجينة للسحاب بالمؤسسات بالاستفادة من قابلية توسع السحابة مع الاحتفاظ بالسيطرة على البيانات الحساسة في بيئات الأرضية. تعالج خطوط معالجة السجل الهجينة، خاصة تلك التي تستخدم تقنيات تدفق الأحداث، الحاجة إلى نقل وتجميع السجلات بشكل قابل للتوسيع.

هندسة النظام

الهندسة المعمارية، الموضحة أدناه، تدمج Azure EventHub و AKS مع Apache CloudStack و Splunk على الأرض. تم تحسين كل مكون لمعالجة السجلات بكفاءة ونقل البيانات بشكل آمن عبر البيئات. 

وصف المكونات

• AKS: يستضيف تطبيقات معبأة في حاويات ويولد سجلات يمكن الوصول إليها من خلال طبقة تجميع السجلات في Kubernetes.
• Fluent Bit: يتم نشره كـ DaemonSet، يقوم بجمع السجلات من عقد AKS. كل نسخة من Fluent Bit تلتقط السجلات من /var/log/containers، تنقيها، وترسلها بتنسيق JSON إلى EventHub.
• Azure EventHub: يعمل كوسيط رسائل عالية الإنتاجية، يجمع السجلات من Fluent Bit ويخزنها مؤقتًا حتى تستلمها Splunk Heavy Forwarder.
• أباتشي كافكا: يعمل كجسر موثوق بين Fluent Bit و Splunk. يقوم Fluent Bit بإعادة توجيه السجلات إلى Kafka باستخدام إضافة الإخراج Kafka الخاصة به، حيث يتم تخزين السجلات ومعالجتها مؤقتًا. يستهلك Splunk بعد ذلك السجلات من Kafka باستخدام موصلات مثل Kafka Connect Splunk Sink أو النصوص المخصصة، مما يضمن توفير بنية معمارية قابلة للتوسيع ومنفصلة.
• موجه السجلات الثقيل لـ Splunk (HF): تم تثبيته في Apache CloudStack، يسترجع الموجه الثقيل السجلات من Azure EventHub باستخدام إضافة Splunk لخدمات Microsoft Cloud. توفر هذه الإضافة تكاملًا سلسًا، مما يمكن الموجه الثقيل من الاتصال بأمان بـ EventHub، واسترجاع السجلات في الوقت الفعلي تقريبًا، وتحويلها حسب الحاجة قبل إعادة التوجيه إلى فهرس Splunk للتخزين والمعالجة
• Splunk على Apache CloudStack: يوفر فهرسة السجلات، والبحث، والتصور، والتنبيه.

تدفق البيانات

1. جمع السجلات في AKS: يقوم Fluent Bit بمتابعة ملفات السجلات في /var/log/containers، وتصفية السجلات غير الضرورية ووسم كل سجل بالبيانات الوصفية (على سبيل المثال، اسم الحاوية، والنطاق).
2. إعادة التوجيه إلى EventHub: يتم إرسال السجلات إلى EventHub عبر HTTPS باستخدام إضافة الإخراج azure_eventhub الخاصة بـ Fluent Bit، مما يضمن نقل البيانات بشكل آمن.
3. أباتشي كافكا: يتم جمع سجلات من AKS بواسطة فلوينت بيت، الذي يعمل كـ DaemonSet، الذي يحلل ويحولها إلى أباتشي كافكا من خلال إضافة الإخراج الخاصة به. يعمل كافكا كمخزن عالي النفاذية، يخزن ويقسم السجلات لزيادة التوسع. يقوم سبلانك بامتصاص هذه السجلات من كافكا باستخدام موصلات أو سكريبتات، مما يتيح فهرسة وتحليل ومراقبة في الوقت الحقيقي.
4. استحضار السجلات باستخدام Splunk Heavy Forwarder: يتصل الإعادة الثقيلة في أباتشي كلاودستاك بـ EventHub باستخدام أداة تطوير برمجيات EventHubs SDK ويقوم بجلب السجلات، ثم يحولها إلى مؤشر سبلانك المحلي للتخزين والمعالجة.
5. تخزين وتحليل في سبلانك: تتم فهرسة السجلات في سبلانك، مما يسمح بعمليات بحث في الوقت الحقيقي، وتصور لوحات القيادة، وتنبيهات استنادًا إلى أنماط السجلات.

منهجية

نشر فلوينت بيت كـ DaemonSet في AKS

تخزين تكوين فلوينت بيت في ConfigMap ونشره كـ DaemonSet. فيما يلي التكوين الموسع لفلوينت بيت DaemonSet:

Name:         fluentbit-cm
Namespace:    fluentbit
Labels:       k8s-app=fluentbit
Annotations:  
Data
crio-logtag.lua:
local reassemble_state = {}
function reassemble_cri_logs(tag, timestamp, record)
  -- التحقق من السجل الوارد
  if not record or not record.logtag or not record.log or type(record.log) == 'table' then
    return 0, timestamp, record
  end
  -- إنشاء مفتاح فريد لإعادة التجميع بناءً على التيار والعلامة
  local reassemble_key = (record.stream or "unknown_stream") .. "::" .. tag
  -- التعامل مع شظايا السجلات (logtag == 'P')
  if record.logtag == 'P' then
    -- تخزين الشظية في حالة إعادة التجميع
    reassemble_state[reassemble_key] = (reassemble_state[reassemble_key] or "") .. record.log
    return -1, 0, 0 -- Do not forward this fragment
  end
  -- التعامل مع نهاية سجل مجزأ
  if reassemble_state[reassemble_key] then
    -- دمج الشظايا المخزنة مع السجل الحالي
    record.log = (reassemble_state[reassemble_key] or "") .. (record.log or "")
    -- مسح الحالة المخزنة لهذا المفتاح
    reassemble_state[reassemble_key] = nil
    return 1, timestamp, record -- Forward the reassembled log
  end
  -- إذا لم يكن هناك حاجة لإعادة التجميع، فقم بإعادة توجيه السجل كما هو
  return 0, timestamp, record
end
INCLUDE filter-kubernetes.conf
filter-kubernetes.conf:
[FILTER]
    Name kubernetes
    Match test.app.splunk.*
    Kube_URL https://kubernetes.default.svc:443
    Kube_CA_File /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token
    Kube_Tag_Prefix test.app.splunk.var.log.containers
    Merge_Log On
    Merge_Log_Key log_processed
    K8S-Logging.Parser On
    K8S-Logging.Exclude On
    Labels Off
    Annotations Off
    Keep_Log Off
 
fluentbit.conf:
[SERVICE]
    Flush         1
    Log_Level     info
    Daemon        on
    Parsers_File  parsers.conf
    HTTP_Server   On
    HTTP_Listen   0.0.0.0
    HTTP_Port     2020
    Health_Check On 
    HC_Errors_Count 1
    HC_Retry_Failure_Count 1 
    HC_Period 5    

INCLUDE input-kubernetes.conf
INCLUDE output-kafka.conf

input-kubernetes.conf:
[INPUT]
    Name           tail
    Tag              test.app.splunk*
    Alias            test.app.splunk-input
    Path              /var/log/containers/*test.app.splunk.log
    Parser            cri
    DB                /var/log/flb_kube.db
    Buffer_Chunk_Size 256K
    Buffer_Max_Size   24MB
    Mem_Buf_Limit     1GB
    Skip_Long_Lines   On
    Refresh_Interval  5

output-kafka.conf:
[OUTPUT]
    Name           kafka
    Alias             test.app.splunk-output
    Match             test.app.splunk.*
    Brokers            prod-region-logs-premium.servicebus.windows.net:9094
    Topics            test.app.splunk
    Retry_Limit       5
    rdkafka.security.protocol SASL_SSL
    rdkafka.sasl.mechanism    PLAIN
    rdkafka.sasl.username     $ConnectionString
    rdkafka.sasl.password      Endpoint=sb://prod-region-logs-premium.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=***********************************************=
[OUTPUT]

parsers.conf:
[PARSER]
    Name         cri
    Format       regex
    Regex        ^(?[^ ]+) (?stdout|stderr) (?[^ ]*) (?.*)$
    Time_Key     time
    Time_Format %Y-%m-%dT%H:%M:%S.%L%z
[PARSER]
    Name    nginx
    Format regex
    Regex ^(?[^ ]*) (?[^ ]*) (?[^ ]*) \[(?[^\]]*)\] "(?\S+)(?: +(?[^\"]*?)(?: +\S*)?)?" (?[^ ]*) (?[^ ]*)(?: "(?[^\"]*)" "(?[^\"]*)")?$
    Time_Key time
    Time_Format %d/%b/%Y:%H:%M:%S %z
[PARSER]
    Name    json
    Format json
    Time_Key time
    Time_Format %d/%b/%Y:%H:%M:%S %z
[PARSER]
    Name         docker
    Format       json
    Time_Key     time
    Time_Format %Y-%m-%dT%H:%M:%S.%L
    Time_Keep    On
    Decode_Field_As json log do_next
    Decode_Field_As escaped  message
[PARSER]
    Name         syslog
    Format       regex
    Regex        ^\<(?[0-9]+)\>(?[^ ]* {1,2}[^ ]* [^ ]*) (?[^ ]*) (?[a-zA-Z0-9_\/\.\-]*)(?:\[(?[0-9]+)\])?(?:[^\:]*\:)? *(?.*)$
    Time_Key     time
    Time_Format %b %d %H:%M:%S
BinaryData
Events:  

• [INPUT] تحدد قسم جمع السجلات من الدليل /var/log/containers.
• [FILTER] القسم يثري السجلات بالبيانات الوصفية لـ Kubernetes.
• [OUTPUT] القسم يكون تكوين Fluent Bit لإرسال السجلات إلى EventHub بتنسيق JSON.

تكوين Azure EventHub

يتطلب EventHub وجود مسمى فضاء أسماء ونسخة معينة من EventHub، والوصول من خلال سياسات وصول مشتركة.

• إعداد مسمى الفضاء الأسماء وEventHub: قم بإنشاء مسمى فضاء أسماء ونسخة EventHub في Azure، ثم قم بتعيين سياسة إرسال Send واحصل على سلسلة الاتصال.
• تكوين الأداء العالي: يتم تكوين EventHub بعدد كبير من الأقسام لدعم التوسع، والتخزين المؤقت، وتيارات البيانات المتزامنة من Fluent Bit.

تكوين Splunk Heavy Forwarder في Apache CloudStack

يستعيد Splunk Heavy Forwarder السجلات من EventHub ويحولها إلى مؤشر Splunk.

• إضافة لخدمات Microsoft Cloud: قم بتثبيت الإضافة لتمكين الاتصال بـ EventHub. قم بتكوين المدخل في inputs.conf:

[azure_eventhub://eventhub_name]
index = <index_name>
eventhub_namespace = <namespace>
shared_access_key_name = <access_key_name>
shared_access_key = <access_key>
batch_size = 500
interval = 30
sourcetype = _json
disabled = 0

• معالجة دفعية: ضبط حجم الدفعة إلى 500 والفاصل الزمني إلى 30 ثانية لتحسين عملية الاستيعاب البيانات وتقليل تكرار مكالمات الشبكة.

فهرسة Splunk وتصور

• إثراء البيانات: تُثرى السجلات بالبيانات الوصفية الإضافية في Splunk باستخدام استخراج الحقول.
• البحث ولوحات التحكم: تمكّن استعلامات SPL عمليات البحث في الوقت الحقيقي، وتوفر لوحات التحكم المخصصة تصورًا لأنماط السجلات.
• التنبيه: يتم تكوين التنبيهات للتفاعل على أنماط السجلات المحددة، مثل معدلات الأخطاء العالية أو التحذيرات المتكررة من حاويات محددة.

الأداء والتوسع

تظهر الاختبارات أن النظام يمكنه التعامل مع عملية استيعاب السجلات عالية الإنتاجية، مع قدرات تخزين EventHub التي تمنع فقدان البيانات أثناء انقطاع الشبكة. يظل استخدام موارد Fluent Bit على عقد AKS أدنى، ويتعامل مؤشر Splunk بكفاءة مع حجم السجلات من خلال تكوينات فهرسة وتصفية مناسبة.

الأمان

يتم استخدام HTTPS لتأمين التواصل بين AKS و EventHub، بينما يستخدم Splunk HF مفاتيح آمنة للمصادقة مع EventHub. ينفذ كل مكون في الخط الزمني آليات إعادة المحاولة للحفاظ على سلامة البيانات.

استخدام الموارد

• يتوسط Fluent Bit متوسط 100-150 ميجابايت من الذاكرة و 0.2-0.3 وحدة معالجة مركزية على عقد AKS.
• يتم تعديل استخدام موارد EventHub ديناميكيًا استنادًا إلى تكوينات القسم والإنتاجية.
• يتم توازن حمل Splunk HF من خلال معالجة الدفعات، مما يحسن نقل البيانات دون تحميل موارد Apache CloudStack بشكل زائد.

الموثوقية والتحمل للأخطاء

تستخدم الحلول تخزين EventHub لضمان الاحتفاظ بالسجلات في حالة فشل المكونات السفلية. يدعم EventHub أيضًا سياسات إعادة المحاولة، مما يعزز بشكل إضافي سلامة البيانات والموثوقية.

النقاش

مزايا بنية السحابة الهجينة

توفر هذه البنية المرونة والقابلية للتوسع والأمان من خلال دمج خدمات Azure مع التحكم المحلي. كما أنها تستفيد من إمكانيات البث والتخزين المعتمدة على السحابة دون المساس بسيادة البيانات.

القيود

بينما يقدم EventHub تجميع بيانات موثوق، تزداد التكاليف مع وحدات الإنتاجية، مما يجعل من الضروري تحسين تكوينات تحويل السجلات. بالإضافة إلى ذلك، فإن نقل البيانات بين السحابة والبيئات المحلية يقدم تأخيرات محتملة.

التطبيقات المستقبلية

يمكن توسيع هذه البنية من خلال دمج التعلم الآلي لاكتشاف الشذوذ في السجلات أو إضافة دعم لمزودي سحابة متعددة لتوسيع معالجة السجلات ومرونة السحابة المتعددة.

الخاتمة

تظهر هذه الدراسة فعالية خط معالجة السجلات الهجين الذي يستفيد من موارد السحابة والمحلية. من خلال دمج خدمة Azure Kubernetes (AKS)، وAzure EventHub، وSplunk على Apache CloudStack، نخلق حلاً قابلاً للتوسع ومرنًا لإدارة وتحليل السجلات بشكل مركزي. تعالج هذه البنية التحديات الرئيسية في تسجيل البيانات الموزعة، بما في ذلك الإنتاجية العالية للبيانات، والأمان، وتحمل الأخطاء.

استخدام Fluent Bit كمجمع سجل خفيف الوزن في AKS يضمن جمع البيانات بكفاءة مع استهلاك موارد أدنى. تتيح قدرات تخزين Azure EventHub للتخزين المؤقت والتجميع الموثوق بالسجلات، مما يجعلها مناسبة تمامًا للتعامل مع حركة السجلات المتغيرة وضمان سلامة البيانات في حالة وجود مشكلات في الاتصال. يتيح Splunk Heavy Forwarder ونشر Splunk في Apache CloudStack للمؤسسات الاحتفاظ بالسيطرة على تخزين السجلات والتحليلات مع الاستفادة من قابلية التوسع والمرونة لموارد السحاب.

يوفر هذا النهج مزايا كبيرة للمؤسسات التي تحتاج إلى نموذج سحابي هجين، مثل التحكم المحسن في البيانات، والامتثال لمتطلبات مكان البيانات، والقدرة على التوسع وفق الطلب. يمكن للأعمال المستقبلية استكشاف دمج التعلم الآلي لتعزيز تحليل السجلات، والكشف التلقائي عن الشواذ، والتوسع إلى نموذج سحابي متعدد لزيادة المتانة والتنوع. تقدم هذه البحثية هندسة معمارية أساسية قابلة للتكيف مع احتياجات الأنظمة الحديثة والموزعة في بيئات المؤسسات.

المراجع

Azure Event Hubs و Kafka

• نظرة عامة على Azure Event Hubs Kafka
• البدء السريع: Kafka مع Azure Event Hubs

الرصد والتسجيل الهجين

• أنماط مراقبة الهجين والمتعدد السحابة
• استراتيجيات مراقبة السحابة الهجينة

تكامل Splunk

• تشغيل Azure Event Hubs على Splunk
• بيانات Azure داخل منصة Splunk

نشر AKS

• Splunk Enterprise على AKS (GitHub)