لمعظم العقد الماضي، كان للملاحظة سر مريح: القيد الرئيسي على ما يمكنك ملاحظته لم يكن التقني ولكن المالي. شغّلت الفريق مجموعات Elasticsearch التي كانت فواتيرها أسرع من حركتهم، والاستجابة القياسية كانت رمي البيانات — خفض الاحتفاظ من تسعين يوماً إلى سبعة، أخذ عينات السجلات بنسبة عشرة في المائة، أسقط الإخراج تصحيح بالكامل. ثم، حتماً، حادث سيهبط في الفجوة. البيانات التي كانت تشرحها قد تم تجاهلها لتوفير المال، وقراءة postmortem "زيادة احتفاظ السجل،" والتي لم يمول أحد.
تغيرت الاقتصاديات لأن جيل جديد من الأدوات نقل تخزين السجل من أقراص محلية باهظة الثمن إلى تخزين كائنات رخيصة — S3، GCS، Azure Blob. عندما تكلفة التخزين ترتيب بحجم أقل، لا يعود الاحتفاظ بمفاوضة الميزانية. هذا الدليل يغطي هذا التحول: لماذا كانت العمارة القديمة مكلفة، كيف يعمل نموذج تخزين الكائنات، والأدوات التي تنفذها — Quickwit للبحث عن السجل والاحتفاظ بالتتبعات، OpenObserve كمنصة ملاحظة كاملة، و Vector كخط الأنابيب الذي يغذيهم.
لماذا كانت العمارة القديمة مكلفة
كانت Elasticsearch والمكدسات المبنية عليها مصممة لحالة استخدام صعب: البحث الكامل والنصي التفاعلي على بيانات تتغير، مع النتائج في ميلي ثانية. لتقديم ذلك، فإنهم يبقون الفهارس على أقراص محلية سريعة مرفقة بعقد تعمل بشكل مستمر، تكرار كل شظية للمتانة والتوفر، واحتفظ بهياكل فهرس كبيرة في الذاكرة. كل من هذه الخيارات معقول للبحث، وكل منها مكلف.
تتفاقم التكاليف بطرق تفاجئ الفريق. يتم توفير التخزين بدلاً من استهلاكه — تدفع الأقراس سواء كانت ممتلئة أم لا، وتفرط في التوفير لأن نفاد الأماكن خارج الخدمة. يضاعف النسخ هذا بمعامل اثنين أو ثلاثة. يجب أن تعمل العقد بشكل مستمر حتى عندما لا تُقرأ معظم السجلات بعد يوم من كتابتها. والتوسع مقترن: تحتاج إلى مزيد من التخزين يعني إضافة عقد، وهذا يعني دفع CPU والذاكرة التي لم تحتجها. النتيجة هي منحنى تكلفة يرتفع بشكل حاد مع الاحتفاظ، وهذا هو بالضبط لماذا "تقليل الاحتفاظ" أصبح الرافعة الآلية لتحكم التكلفة.
الخلل الأعمق هو أن السجلات ليست عبء العمل الذي كان Elasticsearch محسّن لـ. البيانات من السجل قابلة للإضافة فقط — مكتوب مرة واحدة، لم تُحدّث أبداً. غالب ما تكون باردة: الغالبية الساحقة لم تُستعلم أبداً، والجزء الصغير الذي يحصل عليه يُستعلم أثناء الحادث، حيث تأخير بضع ثوان مقبول تماماً. الدفع لبحث تفاعلي فوري وآلة الوثيقة قابلة للتغيير عبر petabytes من بيانات write-once التي لا أحد يقرأها هو الخطأ المعماري الأساسي تحت الفاتورة.
نموذج تخزين الكائنات
بدأت العمارة الأحدث من هذه الممتلكات. إذا كانت البيانات قابلة للإضافة فقط وباردة في الغالب، فتخزنها في تخزين الكائنات — وهو تقريباً ترتيب بحجم أرخص لكل terabyte من تخزين الكتلة المخصص، وفعال غير محدود، وقوي بشكل افتراضي بدون إدارة النسخ. ثم فصل الحوسبة عن التخزين: نقاط استعلام تشغيل تقرأ من تخزين الكائنات عند الطلب وقياسها بشكل مستقل عن مقدار البيانات المحتفظ بها. تخزين سنة أخرى من السجلات تكاليف التخزين فقط، وليس المزيد من العقد.
الاستثناء، بالطبع، هو أن تخزين الكائنات بطيء نسبة إلى القرص المحلي — كل قراءة طلب شبكة مع الكمون الذي يعني. الرؤية الهندسية التي تجعل هذا يعمل هي أنه يمكنك تعويض مع الشكل والفهرس. يتم كتابة البيانات في تنسيقات عمودية مضغوطة (Parquet شائع) جنباً إلى جنب مع هياكل الفهرس التي تسمح لـ استعلام أن تجلب فقط نطاقات البايت التي تحتاج بالفعل إليها، بدلاً من فحص كل شيء. التخزين المؤقت القوي يحافظ على البيانات الساخنة قريبة. النتيجة هي استعلامات ترجع في ثوان بدلاً من ميليثانية — مقابل تماماً مقبول لبحث السجل وغير مقبول تماماً لصندوق بحث متجه للمستخدم، وهذا هو بالضبط لماذا تناسب هذه العمارة الملاحظة وليس البحث العام.
ما يشتري هذا، خارج المال، هو تغيير السلوك. عندما يكون الاحتفاظ رخيصاً، تتوقف عن رمي البيانات بقصد مسبق، وهذا يعني الإجابة على الحادث التالي أكثر احتمالاً لا تزال موجودة. هذا هو الفائدة الحقيقية: ليس فاتورة أصغر، بل تحقيقات أقل تنتهي لأن الأدلة تم حذفها.
Quickwit: بحث مبني للسجلات والتتبعات
Quickwit هي أنقى تعبير للفكرة. إنه محرك بحث Rust مصمم من البداية لبيانات إلحاق فقط على تخزين الكائنات — لا يحتاج إلى قرص محلي للفهارس وللآلة الحالة لهم، لأن الفهرس يعيش في S3 كـ الانقسام غير قابل للتغيير. يوفر البحث النصي الحقيقي (ليس فقط التصفية المستندة إلى التسميات)، يعريض API بحث متوافق مع Elasticsearch الذي يسهل الهجرة، ويخدم كـ خلفية Jaeger الأصلية للتتبعات، مما يجعلها ملائمة طبيعية للفريق الذي يشغل بالفعل OpenTelemetry.
حلو Quickwit هو تخزين رخيص وقابل للبحث وطويل الاحتفاظ بالسجلات والتتبعات حيث تريد قدرة بحث حقيقية. تصبح إدارة الاحتفاظ تافهة — انتهاء البيانات القديمة حذف الانقسامات القديمة. التنازل هو الاختصاص: إنها محرك بحث، وليست منصة ملاحظة كاملة، لذا تحضر الرسوم البيانية الخاصة بك (Grafana)، واليقظة الخاصة بك، ومكدسك المقاييس. بالنسبة للفريق الذي يملك بالفعل هذه القطع ويريد إصلاح التكلفة على وجه التحديد، هذا التركيز هو ميزة.
OpenObserve: منصة مدمجة البطاريات
OpenObserve تأخذ نفس رؤية التخزين وتلف منصة كاملة حولها. يتعامل السجلات والمقاييس والتتبعات في نظام واحد، يخزن البيانات كـ Parquet مضغوطة في تخزين الكائنات، ويأتي مع واجهة مستخدم مدمجة واستعلامات SQL ورسوم بيانية وآلة تنبيه — كل ذلك كملف Rust ثنائي واحد هو بصراحة سهل الإعداد. يستقبل OpenTelemetry بشكل أصلي ويدعم Prometheus write عن بعد، لذا يدرج في الأداة الموجودة.
الاستئناف هو الدمج. بدلاً من تشغيل محرك بحث بالإضافة إلى Grafana بالإضافة إلى مكدس تنبيه بالإضافة إلى تخزين المقاييس المنفصل، تشغيل شيء واحد. بالنسبة للفريق الصغير والمتوسط خاصة، يمكن أن توفير الفوائد التشغيلية أهمية أكثر من أي مقارنة لكل terabyte — كل مكون إضافي في مكدس الملاحظة هو شيء ترقية وأمان وتصحيح في الساعة 3 صباحاً. النطاق هو الاعتيادي لمنصات متكاملة: مرونة أقل من تجميع أفضل-من-كل شيء مكونات، والنظام البيئي أصغر من عوالم Grafana أو Elastic. اختره عندما يكون البساطة التشغيلية تستحق أكثر من المرونة.
Vector: خط الأنابيب الذي يجعل الهجرة آمنة
لا تهم أي خلفية إذا كنت لا تستطيع الحصول على البيانات فيها، وهنا هو حيث Vector تصبح الدبوس الهادئ. Vector هو خط أنابيب عالي الأداء وغير مختص بالبائع: يجمع السجلات والمقاييس والتتبعات من أي مصدر، يعيد تشكيلها من خلال تحويلات المكتوبة في VRL، وينقلها إلى أي بالوعة. مكتوبة بـ Rust، فإنها تستخدم جزء من موارد Logstash أو Fluentd — والذي يأتي لأن وكيل يعمل على كل عقدة تمتلكها.
قيمتها الاستراتيجية هي أنها تفصل الأداة الخاصة بك عن الخلفية الخاصة بك. التطبيقات والوكيل شحنة البيانات إلى Vector؛ Vector يقرر أين تذهب. يحول هجرة خلفية من مشروع إعادة أداة على كامل الأسطول إلى تغيير إعدادات — وبشكل حاسم، فإنه يسمح لك الكتابة المزدوجة أثناء الانتقال، إرسال البيانات نفسها إلى كل من المكدس الموجود ومكدس جديد حتى تتمكن من التحقق من البديل في حركة مرور حقيقية قبل القطع. تحويلات Vector أيضاً قطع التكلفة في المصدر: إسقاط السجلات تصحيح، والعينات أحداث عالية الحجم، وتحرير PII قبل التخزين كل ذلك يقلل ما تدفع للحفاظ. حتى الفريق مع لا نية لتغيير الخلفية غالباً ما يجدون Vector يدفع ثمنه على وحدة التخزين وحدها.
تبني هذا بدون هجرة محفوفة بالمخاطر
المسار المعقول هو تدريجي، و Vector هو ما يجعله آمناً. ابدأ بوضع خط أنابيب أمام مكدسك الموجود. انشر Vector، شير المصادر إليه، وامتلك إعادة توجيه إلى ما تشغله اليوم. لا شيء يتغير وظيفياً، لكن اكتسبت نقطة تحكم — ويمكنك فوراً استخدام التحويلات لإسقاط الضوضاء وخفض التكاليف الحالية.
ثم كتابة مزدوجة إلى خلفية مرشح. أضف بالوعة ثانية تشير إلى Quickwit أو OpenObserve واترك حركة مرور الإنتاج الحقيقية تتدفق إلى الاثنين. الآن يمكنك التقييم بصراحة: هل الاستعلامات التي تشغلها بسرعة كافية؟ هل صيغة البحث تغطي احتياجاتك؟ ما هي تكاليف التخزين حقاً في وحدة التخزين؟ هذا أساس أفضل بكثير للقرار من معيار، ويكلف فقط تخزين الخلفية الجديدة أثناء المحاكمة.
بدّل الاحتفاظ قبل بدء الاستعلام الأساسي. حالة وسيطة منخفضة المخاطر هي الاحتفاظ البيانات الساخنة قصيرة الاحتفاظ حيث هي بينما تشحن بيانات الاحتفاظ طويلة إلى تخزين الكائنات. تحصل على فوز التكلفة على الجزء المكلف (احتفاظ طويل) بدون المراهنة على استجابة الحادث على نظام غريب. ثم نقل الاستعلام تدريجياً، بدءاً من التحليل غير العاجل والانتقال إلى استجابة الحادث بمجرد تثقيف الفريق به. وحافظ على المكدس القديم على قيد الحياة حتى خضت الحادث الحقيقي على واحد جديد — الوقت تكتشف فيه ما إذا كان يعمل هو الوقت الذي تريده فيه أقل مفاجأة.
ما تستسلم له، بصراحة
كل العمارة المقايضات شيء، وتستحق أن تكون صريحة عما تتحرك لتخزين الكائنات حتى القرار مستنيران بدلاً من متحمسة.
كمون الاستعلام. قراءات من تخزين الكائنات طلبات شبكة، لذا استعلامات ترجع في ثوان بدلاً من الاستجابات دون ثانية فهرس ملء محلي يمكن تقديمه. لبحث السجل أثناء الحادث هذا بصراحة بخير — تقرأ النتائج، لا تكتب ثدياً. لكن إذا قمت ببناء سير عمل اعتماداً على التصفية التفاعلية الفورية، أو لوحات تحكم التي تطلق العشرات من الاستعلامات عند كل تحديث، فسيشعرون بالبطء. اختبر أنماط الاستعلام الفعلية، لا معيار اصطناعي.
النضج النظام البيئي. Elasticsearch عقد من التراكم تكاملات وبرامج تعليمية وإجابات Stack Overflow والمهندسين الذين يعرفون بالفعل. الأدوات الأحدث مجتمعات أصغر وتوثيق أرقق للحالات الحدودية وأقل من الناس تحتويهم على مستوى كبير. عندما ينقطع شيء في وقت محرج، هذا الفرق حقيقي. API المتوافقة مع Elasticsearch تخفف الهجرة لكن لا تقضي على فجوة المعرفة.
سطح الميزة. Elasticsearch يفعل الكثير خارج بحث السجل — التجميعات المعقدة وآلات التعلم والضبط الملاءمة لغة سؤال غنية. محركات السجل المتخصصة بقصد تفعل أقل. إذا اعتمدت على تلك الإمكانيات، تحقق من نسخة المعادل قبل الالتزام بدلاً من اكتشاف الفجوة في منتصف الهجرة.
الألفة التشغيلية. تقاريرك والتنبيهات والغرائز موالية للمكدس الحالي. خلفية جديدة تعني أوضاع فشل جديدة وفترة حيث الفريق أبطأ في التشخيص مشاكلها. هذا هو أقوى حجة لـ نهج مزدوج-كتابة ولإبقاء المكدس القديم يعمل من خلال حادث حقيقي واحد على الأقل — تريد منحنى التعلم أن يحدث بينما لا تزال لديك بديل.
لا شيء من هذا يفوق انخفاض التكلفة بـ ترتيب بحجم لمعظم الفريق، خاصة تلك التي تحذف البيانات حالياً التي تتمنى أن تملكها. لكنهم السبب للهجرة بشكل متعمد بدلاً من مرة واحدة.
الخط السفلي
أصبحت الملاحظة أرخص بشكل كبير لأن الأدوات أخيراً طابقت عبء العمل. السجلات قابلة للإضافة فقط وباردة في الغالب، لذا تخزينها على أقراص محلية معاد إنتاجها ودائمة الرفع-محسّنة للبحث المتبادل فوري كانت تدفع ميلي-ثانية التفاعلي ومحركات الوثائق الآلية عبر petabytes من بيانات write-once التي لا أحد يقرأها هو الخطأ المعماري تحت الفاتورة. الانتقال إلى تخزين الكائنات مع التنسيقات العمودية والفهرس الذكي يتاجر ميليثانية لثانية — غير ذي صلة لبحث السجل — وخفض تكلفة التخزين بـ ترتيب بحجم. Quickwit يسلم ذلك كمحرك بحث مركز وقابل للبحث وطويل الاحتفاظ مع خلفية Jaeger؛ OpenObserve يسلم أنها منصة موحدة مع واجهة المستخدم والرسوم البيانية والتنبيهات المدمجة؛ و Vector هو خط الأنابيب الذي يفصل الأداة الخاصة بك عن أي واحد، مما يجعل التبني تغيير إعدادات وكتابة مزدوجة بدلاً من الهجرة. ضع خط الأنابيب أولاً، والكتابة المزدوجة لتقييم حركة مرور حقيقية، وتحرك احتفاظ طويل قبل الاستعلام الساخن، وتوقف حذف البيانات التي تشرح الحوادث الخاصة بك.
المراجع والموارد
أدوات
الخلفية والتحليل
Cheatsheets ذات الصلة 1337skills