لطالما كانت فكرة معرفة ما يمكنك فعله باستخدام ELK والمصادر المرتجلة للسجلات والإحصائيات. على صفحات موقع Habr ، أخطط لإظهار مثال عملي لكيفية استخدام خادم مصغر منزلي ، على سبيل المثال ، يمكنك تحديد مصيدة honeypot باستخدام نظام تحليل السجل استنادًا إلى مكدس ELK. سأخبرك في هذه المقالة عن أبسط مثال لتحليل سجلات جدار الحماية باستخدام مكدس ELK. في المستقبل ، أود أن أصف إعدادات البيئة لتحليل حركة مرور Netflow ومقالب pcap بواسطة Zeek.
إذا كان لديك عنوان IP عام وجهاز ذكي أكثر أو أقل كبوابة / جدار حماية ، فيمكنك تنظيم مصيدة خاملة سلبية عن طريق إعداد الطلبات الواردة لمنافذ TCP و UDP "اللذيذة". يوجد مثال لتكوين جهاز توجيه Mikrotik تحت قطة ، ولكن إذا كان لديك جهاز توجيه بائع مختلف (أو نظام أمان آخر) في متناول اليد ، فستحتاج فقط إلى معرفة بعض تنسيقات البيانات والإعدادات الخاصة بالمورد ، وستحصل على نفس النتيجة.
تنصل
لا يتظاهر المقال بأنه أصلي ، ولا يعالج مشاكل التسامح مع الخطأ في الخدمات ، والأمن ، وأفضل الممارسات ، وما إلى ذلك. من الضروري اعتبار هذه المادة أكاديمية ، فهي مناسبة للتعرف على الوظيفة الأساسية لمكدس ELK وآلية تحليل السجل لجهاز الشبكة. ومع ذلك ، قد يكون من المثير للاهتمام بالنسبة للمبتدئ أيضًا.
تم إطلاق المشروع من ملف docker-compose ، ومن السهل جدًا نشر بيئتك المماثلة ، حتى لو كان لديك جهاز توجيه بائع آخر في متناول اليد ، ما عليك سوى فهم بعض الشيء عن تنسيقات البيانات والإعدادات الخاصة بالمورد. بالنسبة للباقي ، حاولت أن أصف بالتفصيل قدر الإمكان جميع الفروق الدقيقة المرتبطة بتكوين خطوط أنابيب Logstash وتعيينات Elasticsearch في الإصدار الحالي من ELK. يتم استضافة جميع مكونات هذا النظام على
جيثب ، بما في ذلك تكوينات الخدمة. في نهاية المقالة ، سأفعل قسم استكشاف الأخطاء وإصلاحها ، الذي سيصف خطوات تشخيص المشكلات الشائعة للقادمين الجدد إلى هذا العمل.
مقدمة
على الخادم نفسه ، قمت بتركيب نظام المحاكاة الافتراضية Proxmox ، حيث تم إطلاق حاويات Docker machine KVM عليه. من المفترض أن تعرف كيفية عمل عامل النقل ورسو السفن ، نظرًا لوجود أمثلة تكوين كافية حول استخدام الإنترنت. لن أتطرق إلى مشكلات تثبيت Docker ، سأكتب قليلاً عن إنشاء عامل الإرساء.
نشأت فكرة إطلاق honeypot في عملية دراسة Elasticsearch و Logstash و Kibana. في حياتي المهنية ، لم أشارك مطلقًا في إدارة هذه المجموعة واستخدامها عمومًا ، لكن لديّ مشاريع هواية ، بفضلها اهتممت كثيرًا باستكشاف الإمكانيات التي يوفرها محرك بحث Elasticsearch و Kibana ، والذي يمكنك من خلاله تحليل البيانات وتصورها.
بلدي ليس أحدث خادم NUC مصغرة مع 8GB RAM يكفي فقط لبدء مكدس ELK مع عقدة مرنة واحدة. في بيئات الإنتاج ، هذا ، بالطبع ، غير مستحسن ، ولكن فقط مناسب للتدريب. فيما يتعلق بمسألة الأمن ، هناك ملاحظة في نهاية المقال.
الإنترنت مليء بالتعليمات الخاصة بتركيب مكدس ELK وتكوينه للقيام بمهام مماثلة (على سبيل المثال ،
تحليل هجمات القوة الغاشمة على ssh باستخدام Logstash الإصدار 2 ،
وتحليل سجلات Suricata باستخدام Filebeat الإصدار 6 ) ، ولكن في معظم الحالات ، لا يتم إيلاء الاهتمام الواجب للتفاصيل ، لذلك 90 في المائة من المواد ستكون للإصدارات 1 إلى 6 (في وقت كتابة هذا التقرير ، كان الإصدار الحالي من ELK هو 7.5.0). هذا أمر مهم لأنه من الإصدار 6
قرر Elasticsearch
إزالة كيان نوع التعيين ، وبالتالي تغيير بناء جملة الاستعلام وهيكل التعيين. يعد قالب التعيين في مرن كائنًا مهمًا بشكل عام ، وبالتالي لن تكون هناك مشكلات فيما بعد في أخذ العينات والتصور ، أنصحك بعدم المشاركة في لصق النسخ ومحاولة فهم ما تفعله. علاوة على ذلك ، سأحاول شرح معنى العمليات والتكوينات الموضحة بوضوح.
إعداد جهاز التوجيه
بالنسبة إلى الشبكة المنزلية ، أستخدم Mikrotik كموجه ، لذلك سيكون مثالاً على ذلك. ولكن يمكن تكوين أي نظام تقريبًا لإرسال syslog إلى خادم بعيد ، سواء كان جهاز توجيه أو خادمًا أو أي نظام أمان آخر يمكنه تسجيل الدخول.
إرسال رسائل syslog إلى خادم بعيد
في Mikrotik ، لتكوين تسجيل الدخول إلى خادم بعيد من خلال CLI ، ما عليك سوى إدخال أمرين:
/system logging action add remote=192.168.88.130 remote-port=5145 src-address=192.168.88.1 name=logstash target=remote /system logging add action=logstash topics=info
تكوين قواعد جدار الحماية مع تسجيل
نحن مهتمون فقط ببعض البيانات (اسم المضيف ، عنوان IP ، اسم المستخدم ، عنوان url ، وما إلى ذلك) ، والتي يمكنك من خلالها الحصول على صورة أو اختيار جميل. في أبسط الحالات ، من أجل الحصول على معلومات حول عمليات فحص المنافذ ومحاولات الوصول ، تحتاج إلى تكوين مكون جدار الحماية لتسجيل مشغلات القاعدة. في Mikrotik ، قمت بإعداد القواعد في جدول NAT ، وليس Filter ، لأنني في المستقبل سوف أضع مجموعات من شأنها أن تحاكي عمل الخدمات ، وهذا سيسمح لي بالتحقيق في مزيد من المعلومات حول سلوك الروبوتات ، لكن هذا سيناريو أكثر تقدماً وليس هذا الوقت.
تحذير! في التكوين أدناه ، يتم تنفيذ منفذ TCP القياسي لخدمة SSH (22) في الشبكة المحلية. إذا كنت تستخدم SSH للوصول إلى الموجه من الخارج وكان للإعدادات منفذ 22 (
طباعة خدمة IP في CLI و
IP> خدمات في Winbox) ، يجب إعادة تعيين المنفذ لإدارة SSH ، أو عدم إدخال القاعدة الأخيرة في الجدول.
أيضًا ، بناءً على اسم واجهة WAN (إذا لم يتم استخدام جسر WAN) ، فأنت بحاجة إلى تغيير المعلمة
في الواجهة إلى المعلمة المناسبة.
/ip firewall nat add action=netmap chain=dstnat comment="HONEYPOT RDP" dst-port=3389 in-interface=bridge-wan log=yes log-prefix=honeypot_rdp protocol=tcp to-addresses=192.168.88.201 to-ports=3389 add action=netmap chain=dstnat comment="HONEYPOT ELASTIC" dst-port=9200 in-interface=bridge-wan log=yes log-prefix=honeypot_elastic protocol=tcp to-addresses=192.168.88.201 to-ports=9211 add action=netmap chain=dstnat comment=" HONEYPOT TELNET" dst-port=23 in-interface=bridge-wan log=yes log-prefix=honeypot_telnet protocol=tcp to-addresses=192.168.88.201 to-ports=2325 add action=netmap chain=dstnat comment="HONEYPOT DNS" dst-port=53 in-interface=bridge-wan log=yes log-prefix=honeypot_dns protocol=udp to-addresses=192.168.88.201 to-ports=9953 add action=netmap chain=dstnat comment="HONEYPOT FTP" dst-port=21 in-interface=bridge-wan log=yes log-prefix=honeypot_ftp protocol=tcp to-addresses=192.168.88.201 to-ports=9921 add action=netmap chain=dstnat comment="HONEYPOT SMTP" dst-port=25 in-interface=bridge-wan log=yes log-prefix=honeypot_smtp protocol=tcp to-addresses=192.168.88.201 to-ports=9925 add action=netmap chain=dstnat comment="HONEYPOT SMB" dst-port=445 in-interface=bridge-wan log=yes log-prefix=honeypot_smb protocol=tcp to-addresses=192.168.88.201 to-ports=9445 add action=netmap chain=dstnat comment="HONEYPOT MQTT" dst-port=1883 in-interface=bridge-wan log=yes log-prefix=honeypot_mqtt protocol=tcp to-addresses=192.168.88.201 to-ports=9883 add action=netmap chain=dstnat comment="HONEYPOT SIP" dst-port=5060 in-interface=bridge-wan log=yes log-prefix=honeypot_sip protocol=tcp to-addresses=192.168.88.201 to-ports=9060 add action=dst-nat chain=dstnat comment="HONEYPOT SSH" dst-port=22 in-interface=bridge-wan log=yes log-prefix=honeypot_ssh protocol=tcp to-addresses=192.168.88.201 to-ports=9922
في Winbox ، يتم تكوين نفسه في
علامة تبويب IP> جدار الحماية> NAT .
سيقوم الموجه الآن بإعادة توجيه الحزم المستلمة إلى العنوان المحلي 192.168.88.201 والمنفذ المخصص. الآن لا أحد يستمع إلى هذه المنافذ ، وبالتالي فإن الاتصالات سوف تنقطع. في المستقبل ، في عامل الميناء ، يمكنك تشغيل مصيدة honeypot ، والتي يوجد الكثير منها لكل خدمة. إذا لم يكن هذا مخططًا ، فبدلاً من قواعد NAT ، يجب عليك كتابة قاعدة بها إجراء الإفلات في سلسلة Filter.
بدء تشغيل ELK باستخدام عامل التهيئة
بعد ذلك ، يمكنك البدء في تكوين المكون الذي سيقوم بمعالجة السجلات. أنصحك بالتدرب على المستودع واستنساخه على الفور لرؤية ملفات التكوين بالكامل. يمكن رؤية جميع التكوينات الموضحة هناك ، في نص المقال ، سأنسخ جزءًا فقط من التكوينات.
❯❯ git clone https://github.com/mekhanme/elk-mikrot.git
في بيئة اختبار أو تطوير ، من الأنسب تشغيل حاويات الإرساء باستخدام عامل الإرساء. في هذا المشروع ، استخدم ملف docker-compose الخاص
بالإصدار الأحدث
3.7 في الوقت الحالي ، وهو يتطلب إصدار مشغل docker 18.06.0+ ، لذلك يجدر تحديث
عامل الإرساء ، وكذلك docker-compose.
❯❯ curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose ❯❯ chmod +x /usr/local/bin/docker-compose
نظرًا لأن الإصدارات الحديثة من docker-compose ، فقد تم
قطع المعلمة mem_limit وتمت إضافة النشر ، والذي يعمل فقط في وضع سرب (
نشر مكدس docker ) ، مما يؤدي إلى بدء
تكوين تكوين docker بحدود يؤدي إلى حدوث خطأ. نظرًا لأنني لا أستخدم سرب ، وأريد أن يكون لدي حدود للموارد ، يجب أن أبدأ ذلك بخيار -
التوافق ، والذي يحول الحدود من الإصدارات الجديدة من عامل
الإرساء إلى ما يعادلها من غير اللحام.
اختبار التشغيل لجميع الحاويات (في الخلفية -d):
❯❯ docker-compose --compatibility up -d
سيتعين عليك الانتظار حتى يتم تنزيل جميع الصور ، وبعد اكتمال الإطلاق ، يمكنك التحقق من حالة الحاويات باستخدام الأمر:
❯❯ docker-compose --compatibility ps
نظرًا لحقيقة أن جميع الحاويات ستكون على نفس الشبكة (إذا لم تحدد الشبكة بشكل صريح ، فسيتم إنشاء جسر جديد ، وهو مناسب في هذا السيناريو) ، ويحتوي docker-compose.yml على معلمة اسم
الحاوية لجميع
الحاويات ، وسيكون للحاويات بالفعل اتصال عبر DNS المدمج عامل ميناء. نتيجة لذلك ، ليس مطلوبًا تسجيل عناوين IP في تكوينات الحاوية. في التكوين Logstash ، يتم تسجيل الشبكة الفرعية 192.168.88.0/24 على أنها محلية ، علاوة على ذلك ، سيكون هناك تفسيرات أكثر تفصيلاً في التهيئة ، وفقًا لذلك يمكنك توضيح مثال التكوين قبل البدء.
تكوين خدمات ELK
علاوة على ذلك ، ستكون هناك توضيحات حول كيفية تكوين وظائف مكونات ELK ، وكذلك بعض الإجراءات الأخرى التي ستحتاج إلى تنفيذها على Elasticsearch.
لتحديد الإحداثيات الجغرافية حسب عنوان IP ، ستحتاج إلى تنزيل قاعدة بيانات
GeoLite2 المجانية من MaxMind:
❯❯ cd elk-mikrot && mkdir logstash/geoip_db ❯❯ curl -O https://geolite.maxmind.com/download/geoip/database/GeoLite2-City-CSV.zip && unzip GeoLite2-City-CSV.zip -d logstash/geoip_db && rm -f GeoLite2-City-CSV.zip ❯❯ curl -O https://geolite.maxmind.com/download/geoip/database/GeoLite2-ASN-CSV.zip && unzip GeoLite2-ASN-CSV.zip -d logstash/geoip_db && rm -f GeoLite2-ASN-CSV.zip
إعداد Logstash
ملف التكوين الرئيسي هو
logstash.yml ، حيث قمت بتسجيل خيار إعادة تحميل التكوين تلقائيًا ، فإن بقية إعدادات بيئة الاختبار ليست مهمة. يوصف تكوين معالجة البيانات (السجلات) في Logstash في ملفات
conf منفصلة ، وعادة ما يتم تخزينها في دليل
خط أنابيب . في المخطط ، عند استخدام
خطوط أنابيب متعددة ، يصف ملف
pipelines.yml خطوط الأنابيب المنشطة. خط الأنابيب عبارة عن سلسلة من الإجراءات على البيانات غير المهيكلة من أجل تلقي البيانات مع بنية محددة في الإخراج. يعتبر المخطط مع
pipelines.yml مهيأ بشكل منفصل اختياريًا ، ويمكنك الاستغناء عنه من خلال تنزيل جميع التكوينات من دليل
خط الأنابيب المثبت ، ومع ذلك ، باستخدام ملف
pipelines.yml محدد ، يكون التكوين أكثر مرونة ، حيث يمكنك تشغيل وإيقاف ملفات
conf من دليل
خطوط الأنابيب التكوينات الضرورية. بالإضافة إلى ذلك ، تعمل إعادة تحميل التكوينات فقط في نظام خطوط الأنابيب المتعددة.
❯❯ cat logstash/config/pipelines.yml - pipeline.id: logstash-mikrot path.config: "pipeline/logstash-mikrot.conf"
التالي يأتي الجزء الأكثر أهمية من التكوين Logstash. يتكون وصف خط الأنابيب من عدة أقسام - في البداية ، تتم الإشارة إلى المكونات الإضافية في قسم "
الإدخال " بمساعدة Logstash التي تستقبل البيانات. تتمثل أسهل طريقة لجمع syslog من جهاز الشبكة في استخدام مكونات إدخال
tcp /
udp . المعلمة المطلوبة الوحيدة لهذه الإضافات هي
المنفذ ، ويجب تحديدها كما هي في إعدادات جهاز التوجيه.
القسم الثاني هو
المرشح ، الذي يصف الإجراءات الأخرى بالبيانات التي لم يتم تنظيمها بعد. في المثال الخاص بي ، يتم حذف رسائل syslog غير الضرورية من جهاز توجيه مع نص معين. يتم ذلك باستخدام الشرط وإجراء
الإسقاط القياسي ، والذي يتجاهل الرسالة بأكملها إذا تم استيفاء الشرط. في
الحالة ، يتم التحقق من حقل
الرسالة لوجود نص معين.
إذا لم تسقط الرسالة ،
فستذهب إلى أسفل السلسلة وتدخل عامل تصفية
grok . كما تقول الوثائق ،
يعد grok طريقة رائعة لتحليل بيانات السجل غير المهيكلة إلى شيء منظم ويمكن الاستعلام عنه . يتم استخدام هذا الفلتر لمعالجة سجلات الأنظمة المختلفة (نظام لينكس syslog ، خادم الويب ، قاعدة البيانات ، أجهزة الشبكة ، إلخ). بناءً على
الأنماط الجاهزة ، يمكنك ، دون إنفاق الكثير من الوقت ، إنشاء محلل لأي تسلسل متكرر أكثر أو أقل. من المريح استخدام
محلل عبر الإنترنت للتحقق من صحته (في أحدث إصدار من Kibana ، توجد وظائف مماثلة في قسم
أدوات Dev ).
المجلد
"./logstash/patterns:/usr/share/logstash/patterns" مسجل في
docker -compose.yml ، في دليل
الأنماط يوجد ملف به أنماط مجتمع قياسية (للراحة فقط ، معرفة ما إذا كنت قد نسيت) ، وكذلك ملف به أنماط من عدة أنواع من رسائل Mikrotik (وحدات
Firewall و
Auth) ، عن طريق القياس ، يمكنك إضافة القوالب الخاصة بك لرسائل ذات بنية مختلفة.
تتيح لك الخيارات القياسية
add_field و
remove_field إضافة أو إزالة الحقول من الرسالة التي تتم معالجتها داخل أي مرشح. في هذه الحالة ، يتم حذف حقل
المضيف ، والذي يحتوي على اسم المضيف الذي تم استلام الرسالة منه. في المثال الخاص بي ، يوجد مضيف واحد فقط ، لذلك لا توجد نقطة في هذا المجال.
علاوة على ذلك ، في نفس قسم
التصفية ، قمت بتسجيل مرشح
cidr ، والذي يتحقق من الحقل بعنوان IP للتأكد من توافقه مع شرط الدخول في الشبكة الفرعية المحددة ويضع العلامة. استنادًا إلى العلامة الموجودة في السلسلة الإضافية ، سيتم تنفيذ الإجراءات أو عدم تنفيذها (إذا كان ذلك على وجه التحديد ، فإن هذا لا يؤدي إلى إجراء بحث جغرافي عن العناوين المحلية في المستقبل).
يمكن أن يكون هناك أي عدد من أقسام
التصفية ، بحيث يكون هناك عدد أقل من الشروط داخل قسم واحد ، في القسم الجديد الذي حددته لإجراءات الرسائل بدون العلامة
src_local ، أي ، تتم معالجة أحداث جدار الحماية هنا التي نهتم بها بعنوان المصدر.
نحن الآن بحاجة إلى التحدث أكثر قليلاً عن المكان الذي تحصل منه Logstash على معلومات GeoIP. يدعم Logstash قواعد بيانات GeoLite2. هناك العديد من خيارات قاعدة البيانات ، وأنا استخدم قاعدتي بيانات: GeoLite2 City (التي تحتوي على معلومات حول البلد والمدينة والمنطقة الزمنية) و GeoLite2 ASN (معلومات حول النظام المستقل الذي ينتمي إليه عنوان IP).
يشترك المكون الإضافي لـ
geoip أيضًا في إضافة معلومات GeoIP إلى الرسالة. من المعلمات ، يجب عليك تحديد الحقل الذي يحتوي على عنوان IP والقاعدة المستخدمة واسم الحقل الجديد الذي سيتم كتابة المعلومات به. في المثال الخاص بي ، يتم تنفيذ نفس الشيء لعناوين IP الوجهة ، ولكن حتى الآن في هذا السيناريو البسيط ، لن تكون هذه المعلومات مهمة ، لأن عنوان الوجهة سيكون دائمًا عنوان جهاز التوجيه. ومع ذلك ، في المستقبل سيكون من الممكن إضافة سجلات إلى خط الأنابيب هذا ليس فقط من جدار الحماية ، ولكن أيضًا من الأنظمة الأخرى حيث سيكون من المناسب النظر إلى كلا العنوانين.
يتيح لك مرشح التغيير تغيير حقول الرسائل وتعديل النص في الحقول نفسها ؛ وتصف الوثائق بالتفصيل العديد من الأمثلة على ما يمكنك القيام به. في هذه الحالة ، يتم استخدامه لإضافة علامة ، وإعادة تسمية الحقول (لمزيد من التصور للسجلات في Kibana ، مطلوب تنسيق معين للكائن
النقطة الجغرافية ، وسوف أتطرق إلى هذا الموضوع أكثر من ذلك) وحذف الحقول غير الضرورية.
يؤدي هذا إلى إنهاء قسم معالجة البيانات ويمكن أن يشير فقط إلى مكان إرسال رسالة منظمة. في هذه الحالة ، سيقوم Elasticsearch بجمع البيانات ، وستحتاج فقط إلى إدخال عنوان IP والمنفذ واسم الفهرس. يوصى بإدخال الفهرس بحقل تاريخ متغير بحيث يتم إنشاء فهرس جديد كل يوم.
إعداد Elasticsearch
العودة إلى Elasticsearch. تحتاج أولاً إلى التأكد من تشغيل الخادم. يتم التفاعل بشكل مرن بكفاءة أكبر من خلال واجهة برمجة تطبيقات Rest في CLI. باستخدام curl ، يمكنك رؤية حالة العقدة (استبدل localhost بعنوان ip docker host):
❯❯ curl localhost:9200
ثم يمكنك محاولة فتح Kibana في
مضيف محلي : 5601. ليست هناك حاجة لتكوين أي شيء في واجهة الويب Kibana (ما لم يتم تغيير المظهر إلى الظلام). نحن مهتمون بمعرفة ما إذا كان قد تم إنشاء فهرس ، للقيام بذلك ، افتح قسم
الإدارة وحدد
إدارة فهرس Elasticsearch في الجزء العلوي الأيسر. يمكنك هنا معرفة عدد المستندات التي يتم فهرستها ، وكم يستغرق مساحة القرص ، ويمكنك أيضًا الاطلاع على معلومات حول تعيين الفهرس من معلومات مفيدة.
بعد ذلك فقط تحتاج إلى تسجيل قالب التعيين الصحيح. هذه المعلومات ضرورية لـ Elastic حتى يفهم أنواع البيانات التي تنتمي إليها الحقول. على سبيل المثال ، لإجراء تحديدات خاصة تستند إلى عناوين IP ، بالنسبة لحقل
src_ip ، يجب
عليك تحديد نوع بيانات
ip بشكل صريح ، وتحديد الموقع الجغرافي ، يجب عليك تحديد حقل
geoip.location بتنسيق معين وتسجيل نوع
نقطة تحديد الموقع الجغرافي. لا يلزم وصف جميع الحقول الممكنة ، نظرًا لأن الحقول الجديدة يتم تحديد نوع البيانات تلقائيًا بناءً على أنماط ديناميكية (
طويلة للأرقام
والكلمات الأساسية للسلاسل).
يمكنك كتابة قالب جديد إما باستخدام curl أو مباشرة من وحدة Kibana (قسم
أدوات Dev ).
❯❯ curl -X POST -H "Content-Type: application/json" -d @elasticsearch/logstash_mikrot-template.json http://192.168.88.130:9200/_template/logstash-mikrot
بعد تغيير التعيين ، تحتاج إلى حذف الفهرس:
❯❯ curl -X DELETE http://192.168.88.130:9200/logstash-mikrot-2019.12.16
عند وصول رسالة واحدة على الأقل إلى الفهرس ، تحقق من التعيين:
❯❯ curl http://192.168.88.130:9200/logstash-mikrot-2019.12.16/_mapping
لمزيد من استخدام البيانات في Kibana ، تحتاج إلى إنشاء
نمط في
الإدارة> Kibana Index Pattern . أدخل
اسم الفهرس بالرمز * (
logstash-mikrot *) حتى تتطابق جميع المؤشرات ، حدد حقل
الطابع الزمني كحقل مع التاريخ والوقت. في حقل
معرف نمط فهرس مخصص ، يمكنك إدخال معرف النمط (على سبيل المثال ،
logstash-mikrot ) ، في المستقبل يمكن أن يسهل هذا الوصول إلى الكائن.
تحليل البيانات والتصور في كيبانا
بمجرد إنشاء
نمط الفهرس ، يمكنك المتابعة إلى الجزء الأكثر إثارة للاهتمام - تحليل البيانات والتصور. يتمتع Kibana بالكثير من الوظائف والأقسام ، ولكن حتى الآن سنهتم بفرعين فقط.
اكتشاف
هنا يمكنك عرض المستندات في الفهارس وتصفية والبحث وعرض المعلومات المستلمة. من المهم عدم نسيان الخط الزمني الذي يحدد الإطار الزمني في شروط البحث.
تصور
في هذا القسم ، يمكنك بناء التصور بناءً على البيانات التي تم جمعها. أبسط شيء هو عرض مصادر مسح الروبوتات على خريطة جغرافية ، إما منقط أو في شكل خريطة حرارة. هناك أيضًا العديد من الطرق لإنشاء الرسوم البيانية ، وتحديد الاختيارات ، إلخ.
في المستقبل ، أخطط للإدلاء بمزيد من التفاصيل حول معالجة البيانات ، وربما التصور ، وربما شيء آخر مثير للاهتمام. في عملية الدراسة سأحاول استكمال البرنامج التعليمي.
استكشاف الأخطاء وإصلاحها
إذا لم يظهر الفهرس في Elasticsearch ، فيجب أولاً إلقاء نظرة على سجلات Logstash:
❯❯ docker logs logstash --tail 100 -f
لن يعمل Logstash إذا لم يكن هناك اتصال مع Elasticsearch ، أو كان هناك خطأ في تكوين خط الأنابيب هو السبب الرئيسي ويصبح الأمر واضحًا بعد إجراء دراسة متأنية للسجلات التي تتم كتابتها إلى عامل النقل json بشكل افتراضي.
إذا لم تكن هناك أخطاء في السجل ، فستحتاج إلى التأكد من أن Logstash يمسك الرسائل على مأخذ التوصيل الذي تم تكوينه. لأغراض التصحيح ، يمكنك استخدام
stdout كإخراج :
stdout { codec => rubydebug }
بعد ذلك ، سيكتب Logstash معلومات debag عند استلام الرسالة مباشرة إلى السجل.
يعد فحص Elasticsearch بسيطًا جدًا - ما عليك سوى إجراء حليقة لطلب GET على عنوان IP ومنفذ الخادم أو نقطة نهاية API محددة. على سبيل المثال ، انظر إلى حالة الفهارس في جدول قابل للقراءة من قبل الإنسان:
❯❯ curl -s 'http://192.168.88.130:9200/_cat/indices?v'
لن يبدأ Kibana أيضًا إذا لم يكن هناك اتصال بـ Elasticsearch ، فمن السهل رؤية ذلك من خلال السجلات.
إذا لم تفتح واجهة الويب ، فعليك التأكد من أن جدار الحماية قد تم تكوينه أو تعطيله بشكل صحيح في نظام Linux (في Centos كانت هناك مشاكل في
iptables ورسو السفن ، وتم حلها بناءً على نصيحة
الموضوع ). تجدر الإشارة أيضًا إلى أنه في الأجهزة غير المنتجة للغاية ، يمكن تحميل جميع المكونات لعدة دقائق. مع نقص الذاكرة ، قد لا يتم تحميل الخدمات على الإطلاق. عرض استخدام موارد الحاوية:
❯❯ docker stats
إذا كان شخص ما فجأة لا يعرف كيفية تغيير تكوين الحاويات بشكل صحيح في
ملف docker-compose.yml وإعادة تشغيل الحاويات ، يتم ذلك عن طريق تحرير
docker-compose.yml واستخدام نفس الأمر مع إعادة تشغيل نفس المعلمات:
❯❯ docker-compose --compatibility up -d
في الوقت نفسه ، في الأقسام التي تم تغييرها ، يتم مسح الكائنات القديمة (الحاويات ، والشبكات ، والمجلدات) وإعادة إنشاء كائنات جديدة وفقًا للتهيئة. لا تضيع بيانات الخدمات في الوقت نفسه ، حيث
يتم استخدام وحدات التخزين المسماة ، والتي لا يتم حذفها مع الحاوية ، ويتم تثبيت التكوينات من النظام المضيف ، حتى تتمكن Logstash من مراقبة ملفات التكوين وإعادة تشغيل تكوين خط أنابيب عند تغيير الملف.
يمكنك إعادة تشغيل الخدمة بشكل منفصل باستخدام
أمر إعادة التشغيل docker (ليس من الضروري أن تكون في الدليل باستخدام
docker-compose.yml) :
❯❯ docker restart logstash
يمكنك أن ترى تكوين كائن
عامل ميناء مع
أمر تفتيش عامل ميناء ، هو أكثر ملاءمة لاستخدامه مع
jq .
استنتاج
أريد أن أشير إلى أنه لم يتم الإبلاغ عن الأمان في هذا المشروع لأنه بيئة اختبار (dev) وليس من المخطط إطلاقه خارج جهاز التوجيه. إذا قمت بنشرها للاستخدام الأكثر خطورة ، فأنت بحاجة إلى اتباع أفضل الممارسات ، وتثبيت شهادات HTTPS ، وإنشاء نسخ احتياطية ، ومراقبة طبيعية (والتي لا تبدأ بجوار النظام الرئيسي). بالمناسبة ، يعمل Traefik في وحدة الإرساء الخاصة بي على الخادم الخاص بي ، وهو وكيل عكسي لبعض الخدمات ، وينهي أيضًا TLS على نفسه ويقوم بالمصادقة. أي أنه بفضل DNS المكوّن والوكيل العكسي ، أصبح من الممكن الوصول إلى واجهة الويب Kibana من الإنترنت باستخدام HTTPS غير مضبوط وكلمة مرور (كما أفهمها ، في إصدار المجتمع لا تدعم Kibana حماية كلمة المرور لواجهة الويب). أخطط لوصف تجربتي في إعداد Traefik للاستخدام على شبكة منزلية مع Docker.