carbon c relay
3.8.1 (28-04-2024)
carbon-c-relay -f -File [ options ... ]
يقبل Carbon-C-Relay مقاييس الجرافيت وتطهيرها وتطهيرها وإعادة كتابة ومجمعات الجرافيت من خلال الاستماع إلى الاتصالات الواردة ونقل الرسائل إلى خوادم أخرى محددة في تكوينها. تتمثل الوظيفة الأساسية في توجيه الرسائل عبر قواعد مرنة إلى الوجهات المطلوبة.
Carbon-C-Relay هو برنامج بسيط يقرأ معلومات التوجيه الخاصة به من ملف. تسمح وسيطات سطر الأوامر بتعيين موقع هذا الملف ، بالإضافة إلى مقدار المرسلين (مؤشرات الترابط العامل) لاستخدامه لقراءة البيانات من الاتصالات الواردة وتمريرها إلى الوجهة (المقصودة) الصحيحة. يدعم ملف المسار بنيتين رئيسيتين: المجموعات والمباريات. يمكن إرسال المجموعات الأولى من مقاييس بيانات المضيفين ، وتحديد الأخير المقاييس التي يجب إرسالها إلى المجموعة. تعتبر قواعد التجميع بمثابة مباريات. إعادة كتابة الإجراءات التي تؤثر بشكل مباشر على المقياس عند النقطة التي تظهر فيها في التكوين.
لكل مقياس استلامه بواسطة التتابع ، يتم تنفيذ التطهير. يتم إجراء التغييرات التالية قبل أي تطابق أو قاعدة إجمالية أو إعادة كتابة يرى المقياس:
[0-9a-zA-Z-_:#] ، ولكن يمكن تجاوزه على سطر الأوامر. لاحظ أن العلامات (عند الحضور والمسموح بها) لا تتم معالجتها بهذه الطريقة. تتحكم هذه الخيارات في سلوك الكربون-C-Relay .
-v : سلسلة النسخة والخروج.
-d : تمكين وضع التصحيح ، هذا يطبع إحصائيات إلى stdout وطباعة رسائل إضافية حول بعض المواقف التي واجهتها التتابع والتي عادة ما تكون مطوئة للغاية بحيث لا يمكن تمكينها. عند دمجها مع -t (وضع الاختبار) ، يطبع هذا أيضًا مسارات الكعب ومحتويات حلقة المكثفات المتسقة.
-s : تمكين وضع التقديم. في هذا الوضع ، لا يتم إنشاء الإحصاءات الداخلية. بدلاً من ذلك ، يتم الإبلاغ عن ضغط قائمة الانتظار وقطرات المقاييس على stdout. يعد هذا الوضع مفيدًا عند استخدامه كمرحلة لتقديم "المهمة" فقط للترجمة إلى (مجموعة من) المرحلات الرئيسية. ليست هناك حاجة إلى إحصائيات حول مرحلات التقديم في هذه الحالة ، ويمكن أن تتسبب بسهولة في فيضان غير مُعد من المقاييس على سبيل المثال عند استخدامه في كل مضيف محليًا.
-S : تمكين وضع يشبه IoStat حيث يتم الإبلاغ عن كل ثانية من الحالة الحالية للإحصاء. هذا يعني -s التقديم.
-t : وضع الاختبار. لا يقوم هذا الوضع بأي توجيه على الإطلاق ، ولكن بدلاً من ذلك يقرأ الإدخال من stdin ويطبع الإجراءات التي سيتم اتخاذها بالنظر إلى التكوين المحمّل. يعد هذا الوضع مفيدًا جدًا لاختبار طرق ترحيل بناء جملة التعبير العادية وما إلى ذلك. كما يسمح أيضًا بإعطاء نظرة ثاقبة حول كيفية تطبيق التوجيه في التكوينات المعقدة ، لأنه يعرض إعادة كتابة ومجاميع تجري أيضًا. عندما تتكرر -t ، ستختبر التتابع فقط التكوين للصلاحية والخروج بعد ذلك مباشرة. يتم قمع أي مخرجات قياسية في هذا الوضع ، مما يجعله مثاليًا لشراء البدء لاختبار تكوين (جديد).
-f تهيئة ملف : قراءة التكوين من تهيئة ملف . يتكون التكوين من مجموعات وطرق. راجع بناء جملة التكوين لمزيد من المعلومات حول الخيارات وبناء بناء الجملة لهذا الملف.
-l LOOD-File : استخدم ملف السجل لكتابة الرسائل. بدون هذا الخيار ، يكتب الترحيل على حد سواء إلى stdout و stderr . عند تسجيل الدخول إلى الملف ، يتم تدوين جميع الرسائل مع MSG عند إرسالها إلى stdout ، ERR عند إرسالها إلى Stderr .
منفذ -p : استمع للاتصالات على منفذ المنفذ. يتم استخدام رقم المنفذ لكل من مآخذ TCP و UDP و UNIX sockets . في الحالة الأخيرة ، يحتوي ملف المقبس على رقم المنفذ. يتخلف المنفذ إلى عام 2003 ، والذي يستخدمه أيضًا carbon-cache.py الأصلي. لاحظ أن هذا ينطبق فقط على الإعدادات الافتراضية ، عندما تكون توجيهات listen في التكوين ، يتم تجاهل هذا الإعداد.
-w العمال : استخدم العمال عدد المواضيع. العدد الافتراضي للعمال يساوي كمية نوى وحدة المعالجة المركزية المكتشفة. من المنطقي تقليل هذا الرقم على العديد من الآلات ، أو عندما تكون حركة المرور منخفضة.
-b Batchsize : قم بتعيين مقدار المقاييس التي تم إرسالها إلى الخوادم البعيدة مرة واحدة لتثبيت . عندما يرسل الترحيل مقاييس إلى الخوادم ، فإنه سيسترجع المقاييس من قائمة الانتظار batchsize للمقاييس التي تنتظر هذا الخادم وإرسالها تلو الآخر. سيكون لحجم الدُفعة تأثير ضئيل على إرسال الأداء ، لكنه يتحكم في مقدار استلام القفل في قائمة الانتظار. الافتراضي هو 2500 .
-q QueueSize : يحتوي كل خادم من التكوين الذي سترسل فيه الترحيل مقاييس إليه ، يحتوي على قائمة انتظار مرتبطة به. يسمح قائمة الانتظار هذه بتعطيل الاضطرابات والانفجارات. سيتم تعيين حجم قائمة الانتظار هذه على قوائم الانتظار التي تسمح بتخزين هذا الكمية من المقاييس في قائمة الانتظار قبل أن تفيض ، ويبدأ الترحيل في إسقاط المقاييس. كلما زاد عدد قائمة الانتظار ، يمكن امتصاص المزيد من المقاييس ، ولكن سيتم استخدام المزيد من الذاكرة بواسطة التتابع. حجم قائمة الانتظار الافتراضي هو 25000 .
-L : يحدد أقصى تركيب الأكشاك إلى الأكشاك قبل أن يبدأ الترحيل في إسقاط المقاييس لخادم. عندما تملأ قائمة انتظار ، يستخدم التتابع آلية تسمى المماطلة للإشارة إلى العميل (الكتابة إلى التتابع) لهذا الحدث. على وجه الخصوص عندما يرسل العميل كمية كبيرة من المقاييس في وقت قصير جدًا (الانفجار) ، يمكن أن يساعد المماطلة في تجنب إسقاط المقاييس ، لأن العميل يحتاج فقط إلى التباطؤ قليلاً ، وهو أمر ممكن في كثير من الحالات (على سبيل المثال عند Cating A مع nc (1)). ومع ذلك ، يمكن أن يعرقل هذا السلوك أيضًا ، ويتوقف الكتاب بشكل مصطنع والذين لا يستطيعون التوقف بسهولة. لهذا يمكن تعيين الأكشاك من 0 إلى 15 ، حيث يمكن أن يستغرق كل كشك حوالي ثانية واحدة على العميل. تم تعيين القيمة الافتراضية على 4 ، والتي تهدف إلى سيناريو الاضطراب العرضي وجهد الحد الأقصى لعدم فضفاضة مع تباطؤ معتدلة للعملاء.
-C Cacertpath : اقرأ CA CERTS (للاستخدام مع اتصالات TLS/SSL) من مسار أو ملف معين. عندما لا تعطى ، يتم استخدام المواقع الافتراضية. يتم تنفيذ التحديد الصارم للنظير ، لذلك عند استخدام الشهادات الموقعة ذاتيا ، تأكد من تضمين CA CER في الموقع الافتراضي ، أو توفير المسار إلى CERT باستخدام هذا الخيار.
-T : يحدد مهلة IO بالمللي ثانية المستخدمة لاتصالات الخادم. الافتراضي هو 600 مللي ثانية ، ولكن قد يحتاج إلى زيادة عند استخدام روابط WAN للخوادم المستهدفة. تتيح القيمة المنخفضة نسبيًا لمهلة الاتصال للتتابع إنشاء خادم سريعًا لا يمكن الوصول إليه ، وعلى هذا النحو ، فإن استراتيجيات تجاوز الفشل للبدء قبل أن يتم تشغيل قائمة الانتظار.
-c chars : يحدد الشخصيات الموجودة بجوار [A-Za-z0-9] المسموح بها في المقاييس إلى chars . أي حرف ليس في هذه القائمة ، يتم استبداله بالترحيل بـ _ (السطحي). القائمة الافتراضية للأحرف المسموح بها هي -_:# .
-m الطول : يحد من الأسماء المترية أن تكون بطول بايت طويل. أي خطوط تحتوي على أسماء مترية أكبر من هذا سيتم التخلص منها.
-M الطول يحد من المدخلات إلى خطوط بايت الطول على معظم. سيتم التخلص من أي خطوط زائدة. لاحظ أن -m يجب أن تكون أصغر من هذه القيمة.
-H اسم HostName : Override HostName الذي تم تحديده بواسطة مكالمة إلى gethostname (3) مع اسم المضيف . يتم استخدام اسم المضيف بشكل رئيسي في الإحصائيات Metrics carbon.relays.<hostname>.<...>
-B Backlog : تعيين اتصال TCP استمع إلى اتصالات تراكم . القيمة الافتراضية هي 32 ولكن على الخوادم التي تتلقى العديد من الاتصالات المتزامنة ، من المحتمل أن يتم زيادة هذا الإعداد لتجنب الأخطاء التي تم رفض الاتصال على العملاء.
-U bufsize : يعين المقبس أحجام الإرسال/الاستقبال في البايت ، لكل من سيناريوهات TCP و UDP. عند إلغاء عملية غير محدودة ، يتم استخدام نظام التشغيل الافتراضي. يتم تحديد الحد الأقصى أيضًا بواسطة نظام التشغيل. يتم تعيين الأحجام باستخدام setSockopt مع الأعلام so_rcvbuf و so_sndbuf. قد يكون ضبط هذا الحجم ضروريًا لسيناريوهات الحجم الكبيرة ، والتي قد يتم تطبيقها -B . إن التحقق من RECV-Q وقيم أخطاء تلقي من NetStat يعطي تلميحًا جيدًا حول استخدام المخزن المؤقت.
-E : تعطيل فصل الاتصالات الواردة الخمول. بشكل افتراضي ، يقوم الترحيل بفصل اتصالات عميل الخمول بعد 10 دقائق. يفعل ذلك لمنع السد من الانسداد عندما يستمر عميل معيب أو ضار في فتح الاتصالات دون إغلاقها. عادة ما يمنع نفاد واصفات الملفات. بالنسبة لبعض السيناريوهات ، ومع ذلك ، ليس من المرغوب فيه فصل الاتصالات الخاملة ، وبالتالي فإن تمرير هذا العلم سيعطل هذا السلوك.
-D : Deamonise في الخلفية بعد بدء التشغيل. يتطلب هذا الخيار أن يتم تعيين أعلام -l و -P أيضًا.
-P Pidfile : اكتب PID من عملية الترحيل إلى ملف يسمى Pidfile . هذا مفيد بشكل خاص عندما يكون الخفي مع مديري init.
-O عتبة : الحد الأدنى لعدد القواعد التي يمكن العثور عليها قبل محاولة تحسين مجموعة القواعد. الافتراضي هو 50 ، لتعطيل المحسن ، استخدم -1 ، لتشغيل Optimiser استخدام 0 . يحاول المُحسِّن تجميع قواعد لتجنب قضاء الوقت المفرط في مطابقة التعبيرات.
يدعم ملف التكوين بناء الجملة التالي ، حيث تبدأ التعليقات بحرف # ويمكن أن تظهر في أي موضع على خط وقمع الإدخال حتى نهاية هذا السطر:
cluster <name>
< <forward | any_of | failover> [useall] |
<carbon_ch | fnv1a_ch | jump_fnv1a_ch> [replication <count>] [dynamic] >
<host[:port][=instance] [proto <udp | tcp>]
[type linemode]
[transport <plain | gzip | lz4 | snappy>
[ssl | mtls <pemcert> <pemkey>]]> ...
;
cluster <name>
file [ip]
</path/to/file> ...
;
match
<* | expression ...>
[validate <expression> else <log | drop>]
send to <cluster ... | blackhole>
[stop]
;
rewrite <expression>
into <replacement>
;
aggregate
<expression> ...
every <interval> seconds
expire after <expiration> seconds
[timestamp at <start | middle | end> of bucket]
compute <sum | count | max | min | average |
median | percentile<%> | variance | stddev> write to
<metric>
[compute ...]
[send to <cluster ...>]
[stop]
;
send statistics to <cluster ...>
[stop]
;
statistics
[submit every <interval> seconds]
[reset counters after interval]
[prefix with <prefix>]
[send to <cluster ...>]
[stop]
;
listen
type linemode [transport <plain | gzip | lz4 | snappy>
[<ssl | mtls> <pemcert>
[protomin <tlsproto>] [protomax <tlsproto>]
[ciphers <ssl-ciphers>] [ciphersuites <tls-suite>]
]
]
<<interface[:port] | port> proto <udp | tcp>> ...
</ptah/to/file proto unix> ...
;
# tlsproto: <ssl3 | tls1.0 | tls1.1 | tls1.2 | tls1.3>
# ssl-ciphers: see ciphers(1)
# tls-suite: see SSL_CTX_set_ciphersuites(3)
include </path/to/file/or/glob>
;
يمكن تعريف مجموعات متعددة ، ولا تحتاج إلى الرجوع إليها بقاعدة المطابقة. تشير جميع المجموعات إلى واحد أو أكثر من المضيف ، باستثناء مجموعة file التي تكتب إلى الملفات في نظام الملفات المحلي. قد يكون host عنوان IPv4 أو IPv6 أو اسم مضيف. نظرًا لأن المضيف يتبعه اختياري : ومنفذ ، لعناوين IPv6 التي لا يمكن تفسيرها بشكل خاطئ ، يجب إعطاء منفذ ، أو عنوان IPv6 محاطًا بأقواس ، على سبيل المثال [::1] . يمكن استخدام بنود transport proto الاختيارية للف الاتصال في طبقة ضغط أو تشفير أو تحديد استخدام UDP أو TCP للاتصال بالخادم البعيد. عند حذف الاتصال الافتراضي إلى اتصال TCP عادي. لا يمكن أن يكون type linemode إلا في الوقت الحالي ، مثل وضع Python المخلل غير معتمد.
يتم حل أسماء مضيف DNS على عنوان واحد ، وفقًا لقواعد التفضيل في RFC 3484. تحتوي المجموعات any_of failover forward على useall صريح يتيح التوسع في الأسماء المضيفة لحل عناوين متعددة. باستخدام هذا الخيار ، يصبح كل عنوان من أي نوع وجهة عنقودية. هذا يعني على سبيل المثال أنه يتم إضافة عناوين IPv4 و IPv6.
هناك مجموعتان من أنواع المجموعات ، ومجموعات إعادة التوجيه البسيطة ومجموعات التجزئة المتسقة.
مجموعات forward file
ترسل مجموعات file forward ببساطة كل ما يتلقونه للأعضاء المحددة (عناوين المضيف أو الملفات). عندما يكون لدى المجموعة أعضاء متعددين ، يتم إرسال جميع المقاييس الواردة إلى جميع الأعضاء ، مما يكرر بشكل أساسي دفق مقياس الإدخال على جميع الأعضاء.
any_of cluster
مجموعة any_of هي متغير صغير من الكتلة forward ، ولكن بدلاً من إرسال مقاييس الإدخال إلى جميع الأعضاء المحددة ، فإنها ترسل كل مقياس وارد إلى واحد فقط من الأعضاء المحددة. الغرض من ذلك هو سيناريو متوازن حيث يمكن لأي من الأعضاء الحصول على أي مقياس. كما يوحي any_of ، عندما يصبح أي من الأعضاء غير قابل للوصول ، سيتلقى الأعضاء الباقون على الفور دفق الإدخال الكامل للمقاييس. هذا يعني على وجه التحديد أنه عند استخدام 4 أعضاء ، سيتلقى كل منهم حوالي 25 ٪ من مقاييس الإدخال. عندما يصبح أحد الأعضاء غير متاح (على سبيل المثال ، انقطاع الشبكة ، أو إعادة تشغيل الخدمة) ، سيتلقى كل من الأعضاء الثلاثة المتبقية حوالي 25 ٪ / 3 = 8 ٪ من حركة المرور (33 ٪). بدلاً من ذلك ، سوف يتلقون 1/3 إجمالي المدخلات. عند تصميم سعة الكتلة ، يجب أن يأخذ المرء في الاعتبار أنه في الحالات الأكثر تطرفًا ، سيتلقى العضو النهائي المتبقي جميع حركة الإدخال.
يمكن أن تكون مجموعة any_of على وجه الخصوص مفيدة عندما تشير الكتلة إلى مرحلات أو ذاكرة التخزين المؤقت الأخرى. عند استخدامه مع مرحلات أخرى ، فإنه يتم تحميله بشكل فعال ، ويتكيف على الفور مع عدم توفر الأهداف. عند استخدامها مع ذاكرة التخزين المؤقت ، هناك تفاصيل صغيرة لكيفية عمل any_of ، مما يجعلها مناسبة للغاية. لا يتم تنفيذ هذا الموجه حول أي أعضاء متاح ، ولكنه بدلاً من ذلك يستخدم استراتيجية تجزئة متسقة لتقديم نفس المقاييس إلى نفس الوجهة طوال الوقت. هذا يساعد ذاكرة التخزين المؤقت ، ويجعل من السهل استرداد نقاط بيانات غير ملتزم (من ذاكرة التخزين المؤقت واحدة) ، ولكن لا يزال يسمح بإعادة تشغيل المتنقلة. عندما يصبح العضو متاحًا ، لا يتم تغيير وجهات التجزئة ، ولكن بدلاً من ذلك يتم نشر حركة المرور المخصصة للعقدة غير المتوفرة بالتساوي على العقد المتاحة.
مجموعة failover
تشبه مجموعة failover مجموعة any_of ، ولكن تتمسك بالترتيب الذي يتم به تعريف الخوادم. هذا هو تنفيذ سيناريو تجاوز الفشل الخالص بين الخوادم. يتم إرسال جميع المقاييس إلى عضو واحد على الأكثر ، لذلك لا يوجد تجزئة أو موازنة. على سبيل المثال ، لن ترسل مجموعة failover مع عضوين فقط مقاييس إلى العضو الثاني عندما يصبح العضو الأول غير متوفر. بمجرد عودة العضو الأول ، يتم إرسال جميع المقاييس إلى العقدة الأولى مرة أخرى.
مجموعة carbon_ch
ترسل مجموعة carbon_ch المقاييس إلى العضو المسؤول وفقًا لخوارزمية التجزئة المتسقة كما هو مستخدم في ترحيل الكربون الأصلي. من الممكن أن يكون هناك أعضاء متعددين إذا تم ضبط النسخ المتماثل على قيمة أعلى من 1. عند تعيين dynamic ، لا يؤدي فشل أي من الخوادم إلى إسقاط المقاييس لهذا الخادم ، ولكن بدلاً من ذلك يتم إرسال المقاييس غير القابلة للتسليم إلى أي خادم آخر في المجموعة حتى لا تضيع المقاييس. هذا مفيد للغاية عندما يكون النسخ المتماثل 1.
يعتمد حساب Hashring ، الذي يحدد الطريقة التي يتم بها توزيع المقاييس ، على مضيف الخادم (أو عنوان IP) instance الاختياري للعضو. هذا يعني أن استخدام هدفين carbon_ch على منافذ مختلفة ولكن على نفس المضيف سيخطط إلى نفس Hashkey ، مما يعني عدم وجود توزيع للمقاييس. يتم استخدام المثيل لعلاج هذا الموقف. يتم إلحاق مثيل للعضو بعد المنفذ ، ويفصله علامة متساوية ، على سبيل المثال 127.0.0.1:2006=a على سبيل المثال a . الحالات هي مفهوم تم تقديمه بواسطة ذاكرة التخزين المؤقت للكربون الأصلي ، ويجب استخدامها وفقًا لتكوين هؤلاء.
تجزئة متسقة تتسق بمعنى أن إزالة عضو من الكتلة لا ينبغي أن يؤدي إلى إعادة تعيين كاملة لجميع المقاييس للأعضاء ، ولكن بدلاً من ذلك لا تضيف سوى المقاييس من العضو الذي تمت إزالته إلى جميع الأعضاء الباقين ، تقريبًا يحصل كل منهم على حصته العادلة. في الاتجاه الآخر ، عند إضافة عضو ، يجب أن يرى كل عضو مجموعة فرعية من مقاييسها موجهة الآن إلى العضو الجديد. هذه ميزة مهمة على التجزئة العادية ، حيث ستتسبب كل إزالة أو إضافة للأعضاء (أيضًا عبر أي تغيير في عنوان IP أو اسم المضيف) إلى إعادة تعيين كاملة لجميع المقاييس على جميع المقاييس المتاحة.
fnv1a_ch CLUSTER
مجموعة fnv1a_ch هي تحسن غير متوافق مع carbon_ch الذي تم تقديمه بواسطة Carbon-C-Relay. يستخدم تقنية تجزئة مختلفة (FNV1A) والتي هي أسرع من التحويل MD5 الذي يستخدمه carbon_ch . الأهم من ذلك ، تستخدم مجموعات fnv1a_ch كل من المضيف والمنفذ لتمييز الأعضاء. يكون هذا مفيدًا عندما تعيش أهداف متعددة على نفس المضيف الذي يفصله المنفذ للتو.
نظرًا لأن خاصية instance لم تعد ضرورية مع fnv1a_ch بهذه الطريقة ، يتم استخدامها لتجاوز المضيف تمامًا: سلسلة المنفذ التي سيتم حساب Hashkey. هذا جانب مهم ، لأن Hashkey يحدد المقاييس التي يتلقاها عضو. يسمح هذا التجاوز بالعديد من الأشياء ، بما في ذلك عناوين IP القديمة المتنوعة على سبيل المثال عندما تم ترحيل الجهاز إلى أجهزة أحدث. مثال على ذلك سيكون 10.0.0.5:2003=10.0.0.2:2003 حيث يتلقى آلة في العنوان 5 الآن المقاييس لآلة كانت في العنوان 2.
في حين أن استخدام الحالات بهذه الطريقة يمكن أن يكون مفيدًا للغاية لإجراء عمليات الترحيل في المجموعات الحالية ، وللحصول على مجموعات الإعداد حديثًا ، تسمح بالمثيلات بتجنب هذا العمل باستخدام مثيل من اليوم الأول لفصل موقع الجهاز من المقاييس التي يتلقاها. ضع في اعتبارك على سبيل المثال 10.0.0.1:2003=4d79d13554fa1301476c1f9fe968b0ac حيث يتم استخدام hash عشوائي كمثيل. هذا من شأنه أن يسمح بتغيير المنفذ و/أو عنوان IP للخادم الذي يتلقى البيانات عدة مرات دون التعامل مع أي إرث مرئي ، على افتراض أن التجزئة العشوائية يتم الاحتفاظ بها. لاحظ أنه نظرًا لأن اسم المثيل يستخدم كمدخلات تجزئة كاملة ، فمن المحتمل أن تؤدي الحالات كـ a ، b ، وما إلى ذلك إلى توزيع سوء التجزئة ، لأن تجزئةها لديها القليل جدًا من المدخلات. لهذا السبب ، فكر في استخدام أسماء المثيلات الطويلة والغالبًا مثل التجزئة العشوائية المستخدمة في المثال أعلاه لسلوك توزيع التجزئة الأفضل.
jump_fnv1a_ch cluster
مجموعة jump_fnv1a_ch هي أيضًا مجموعة تجزئة متسقة مثل الاثنين السابقتين ، لكنها لا تأخذ مضيف العضو أو المنفذ أو المثيل على الإطلاق. هذا يعني أن نوع المجموعة ينظر إلى الترتيب الذي يتم تعريف الأعضاء ، انظر أيضًا أدناه لمعرفة المزيد عن هذا الطلب. ما إذا كان هذا مفيدًا بالنسبة لك يعتمد على السيناريو الخاص بك. على النقيض من نوعين من مجموعات التجزئة المتسقين ، فإن تجزئة القفز لديها موازنة مثالية تقريبًا على الأعضاء المحددة في المجموعة. ومع ذلك ، يأتي هذا على حساب عدم القدرة على إزالة أي عضو ولكن الأخير من المجموعة دون التسبب في إعادة تعيين كاملة لجميع المقاييس على جميع الأعضاء. ما يعنيه هذا في الأساس هو أن هذا التجزئة جيد للاستخدام مع مجموعات ثابتة أو متزايدة باستمرار حيث تتم إزالة العقد القديمة أبدًا ، ولكن يتم استبدالها بدلاً من ذلك.
إذا كان لديك مجموعة حيث يتم إزالة العقد القديمة ، فإن تجزئة القفز ليست مناسبة لك. تجزئة القفز مع الخوادم في قائمة مرتبة. نظرًا لأن هذا الترتيب مهم ، يمكن أن يكون صريحًا باستخدام المثيل كما هو مستخدم في أنواع المجموعات السابقة. عندما يتم إعطاء مثيل مع الأعضاء ، سيتم استخدامه كمفتاح فرز. بدون هذه الحالة ، سيكون الطلب كما هو موضح في ملف التكوين ، والذي قد يكون عرضة للتغييرات عندما يكون EG الذي تم إنشاؤه بواسطة بعض برامج إدارة التكوين. على هذا النحو ، من المحتمل أن يكون من الممارسات الجيدة إصلاح ترتيب الخوادم مع مثيلات بحيث يكون من الواضح ما هي العقد الصحيحة لجامس القفز. يمكن للمرء فقط استخدام الأرقام لهذه ، ولكن كن على علم بأن الفرز من 1 و 2 و 10 ينتج عن 1 و 10 و 2 ، لذلك من الأفضل استخدام شيء مثل P0001 ، P0002 ، P0010 بدلاً من ذلك.
قواعد المطابقة هي طريقة لتوجيه المقاييس الواردة إلى مجموعة أو أكثر. تتم معالجة قواعد المطابقة من أعلى إلى أسفل حيث يتم تعريفها في الملف. من الممكن تحديد مباريات متعددة في نفس القاعدة. يمكن لكل قاعدة تطابق إرسال البيانات إلى مجموعة أو أكثر. نظرًا لأن قواعد المطابقة "تمر عبر" ما لم تتم إضافة الكلمة الرئيسية stop ، يمكن استخدام تعبير المطابقة المصمم بعناية لاستهداف مجموعات أو مجموعات متعددة. تسمح هذه القدرة بتكرار المقاييس ، بالإضافة إلى إرسال مقاييس معينة إلى مجموعات بديلة مع طلب دقيق واستخدام الكلمة الرئيسية stop . تتجاهل المجموعة blackhole الخاصة التي يتم إرسالها إليها. يمكن أن يكون هذا مفيدًا للتخلص من المقاييس غير المرغوب فيها في بعض الحالات. نظرًا لأن رمي المقاييس بعيدًا لا معنى له إذا كانت المباريات الأخرى ستقبل نفس البيانات ، وهي تطابق مع Counthing the Blackhole Cluster ، لها stop ضمني. يضيف شرط validation فحصًا إلى البيانات (ما يأتي بعد المقياس) في شكل تعبير منتظم. عندما يتطابق هذا التعبير ، سيتم تنفيذ قاعدة المطابقة كما لو لم يكن هناك شرط التحقق من الصحة. ومع ذلك ، إذا فشلت ، يتم إحباط قاعدة المطابقة ، ولن يتم إرسال أي مقاييس إلى الوجهات ، وهذا هو سلوك drop . عند استخدام log ، يتم تسجيل المقياس إلى Stderr. يجب توخي الحذر مع الأخير لتجنب الفيضانات السجل. عند وجود شرط التحقق من صحة ، يجب ألا تكون الوجهات موجودة ، وهذا يسمح بتطبيق قاعدة التحقق العالمية. لاحظ أن قواعد التطهير يتم تطبيقها قبل الانتهاء من التحقق ، وبالتالي لن يكون للبيانات مساحات مكررة. يتم استخدام route using الجملة لإجراء تعديل مؤقت للمفتاح المستخدم للإدخال إلى روتين التجزئة المتسق. الغرض الأساسي هو توجيه حركة المرور بحيث يتم إرسال البيانات المناسبة إلى مثيلات التجميع المطلوبة.
تتخذ قواعد إعادة كتابة تعبيرًا منتظمًا كمدخلات لتتناسب مع المقاييس الواردة ، وتحويلها إلى الاسم المتري الجديد المطلوب. في الاستبدال ، يُسمح لمطابقة مجموعات الالتقاط المحددة في التعبير العادي للمدخلات. تطابق server.(x|y|z). يسمح لاستخدام EG role.1. في الاستبدال. إذا لزم الأمر ، يمكن استخدام تدوين g{n} بدلاً من n حيث يتم اتباع المؤتمر الخلفي بواسطة عدد صحيح ، مثل g{1}100 . تنطبق بعض التحذيرات على التنفيذ الحالي لقواعد إعادة كتابة. أولاً ، يحدد موقعها في ملف التكوين متى يتم تنفيذ إعادة الكتابة. تتم إعادة الكتابة في مكانها ، مثل هذه قاعدة التطابق قبل أن تتطابق إعادة الكتابة مع الاسم الأصلي ، وهي قاعدة مطابقة بعد إعادة الكتابة لم تعد تتطابق مع الاسم الأصلي. يجب توخي الحذر مع الطلب ، حيث يمكن أن تحدث قواعد إعادة كتابة متعددة متتالية ، على سبيل المثال ، يتم استبدال a بـ b و b يتم استبدالها بـ c في قاعدة إعادة الكتابة التالية. التحذير الثاني مع التنفيذ الحالي ، هو أنه لا يتم تطهير أسماء القياس المعاد كتابتها ، مثل المقاييس الواردة حديثًا. وبالتالي ، يمكن أن تظهر النقاط المزدوجة والأحرف الخطرة المحتملة إذا تم تصميم سلسلة الاستبدال لإنتاجها. تقع على عاتق الكاتب مسؤولية التأكد من أن المقاييس نظيفة. إذا كانت هذه مشكلة للتوجيه ، فيمكن للمرء أن يعتبر الحصول على مثيل إعادة كتابة فقط يوجه جميع المقاييس إلى مثيل آخر من شأنه القيام بالتوجيه. من الواضح أن المثيل الثاني سوف يقوم بتطهير المقاييس عند وصولها. يسمح تدوين المؤتمر الخلفي بإصدار الرموز البديلة وأصبعها باستخدام الرموز السفلية ( _ ) و Carret ( ^ ) تتبعها مباشرةً بعد الانزلاق الخلفي. على سبيل المثال ، role._1. كما أن الاستبدال سوف يسقط محتويات 1 . يمكن استخدام النقطة ( . ) بطريقة مماثلة ، أو اتباعها بعد السطح السفلي أو الإقحوان لاستبدال النقاط مع السطح في الاستبدال. يمكن أن يكون هذا مفيدًا لبعض المواقف التي يتم فيها إرسال المقاييس إلى الجرافيت.
تأخذ المجموعات المحددة مقاييس الإدخال واحدة أو أكثر التي يتم التعبير عنها بواسطة واحد أو أكثر من عمليات الانفصال العادية ، على غرار قواعد المطابقة. يتم تجميع المقاييس الواردة على مدار فترة زمنية محددة بواسطة الفاصل الزمني في الثواني. نظرًا لأن الأحداث قد تصل قليلاً في وقت لاحق من الوقت ، فإن وقت انتهاء الصلاحية في ثوان يحدد متى يجب اعتبار التجميعات نهائية ، حيث لا يُسمح بإضافة أي إدخالات جديدة بعد الآن. علاوة على التجميع ، يمكن حساب مجموعات متعددة. يمكن أن تكون من نفس أنواع التجميع أو مختلفة ، ولكن يجب أن تكتب إلى مقياس جديد فريد. يمكن أن تتضمن الأسماء المترية مراجع خلفية مثل تعبيرات إعادة كتابة ، مما يسمح بقواعد التجميع الفردية القوية التي تعطي العديد من التجميعات. عند عدم send to شرط ، يتم إرسال المقاييس المنتجة إلى التتابع كما لو تم تقديمها من الخارج ، وبالتالي تنطبق قواعد المطابقة والتجميع على تلك. يجب توخي الحذر بأن الحلقات يتم تجنبها بهذه الطريقة. لهذا السبب ، يتم تشجيع استخدام send to Clause ، لتوجيه حركة مرور الإخراج حيثما أمكن ذلك. مثل لقواعد المطابقة ، من الممكن تحديد أهداف الكتلة المتعددة. أيضًا ، مثل قواعد المطابقة ، تنطبق الكلمة الرئيسية stop على التحكم في تدفق المقاييس في عملية المطابقة.
يتم إهمال send statistics to البناء وسيتم إزالتها في الإصدار التالي. استخدم بناء statistics الخاصة بدلاً من ذلك.
يمكن لبناء statistics التحكم في بعض الأشياء حول الإحصاءات (الداخلية) التي تنتجها التتابع. يمكن استخدام send to الهدف لتجنب حلقات جهاز التوجيه عن طريق إرسال الإحصاءات إلى مجموعة (مجموعات) وجهة معينة. -H افتراضي ، يتم تسبق المقاييس مع carbon.relays.<hostname> يمكن تعيين هذه البادئة باستخدام prefix with شرط مشابه لهدف قاعدة إعادة الكتابة. تطابق الإدخال في هذه الحالة هو التعبير العادي المُحدد مسبقًا ^(([^.]+)(..*)?)$ على اسم المضيف. على هذا النحو ، يمكن للمرء أن يرى أن البادئة الافتراضية يتم تعيينها بواسطة carbon.relays..1 . لاحظ أن هذا يستخدم ميزة الاستبدال بديلة من خلال إعادة الكتابة من قواعد إعادة كتابة. بالنظر إلى تعبير الإدخال ، تتوفر مجموعات المطابقة التالية: 1 اسم المضيف بأكمله ، 2 اسم المضيف القصير و 3 Domainname (مع النقطة الرائدة). قد يكون من المنطقي استبدال الافتراضي بشيء مثل carbon.relays._2 بشكل افتراضي ، يتم تقديم المقاييس كل 60 ثانية ، ويمكن تغيير ذلك باستخدام submit every <interval> seconds reset counters after interval على مجموعة أكثر توافقًا من القيم إلى خدم الكربون.
يمكن تحديد المنافذ والبروتوكولات التي يجب أن تستمع إليها الترحيل للاتصالات الواردة باستخدام توجيه listen . حاليا ، يجب أن يكون جميع المستمعين من نوع linemode . يمكن تحديد ضغط اختياري أو تغليف تشفير للمنفذ والواجهة الاختيارية المعطاة بواسطة عنوان IP ، أو مقبس UNIX حسب الملف. عندما لا يتم تحديد الواجهة ، يتم افتراض أي واجهة على جميع بروتوكولات IP المتاحة. في حالة عدم وجود توجيهات listen ، ستستخدم الترحيل المستمعين الافتراضيين للمنفذ 2003 على TCP و UDP ، بالإضافة إلى UNIX Socket /tmp/.s.carbon-c-relay.2003 . هذا عادة ما يمتد إلى 5 مستمعين على نظام تمكين IPv6. يتطابق الافتراضي مع سلوك الإصدارات قبل V3.2.
في حالة يصبح التكوين طويلًا جدًا ، أو يتم إدارته بشكل أفضل في ملفات منفصلة ، يمكن استخدام التوجيه include لقراءة ملف آخر. سيتم قراءة الملف المحدد في مكانه وإضافته إلى تكوين جهاز التوجيه في وقت التضمين. النتيجة النهائية هي تكوين مسار كبير. يمكن استخدام عبارات include متعددة عبر ملف التكوين. سيؤثر تحديد المواقع على ترتيب القواعد كالمعتاد. احذر من دعم التضمين المتكرر ( include من ملف مضمن) ، ولا توجد ضمانات حاليًا لحلقة إدراج. بالنسبة إلى ما يستحق ، من المحتمل أن تستخدم هذه الميزة مع ملفات التكوين البسيطة (على سبيل المثال عدم include ).
تطورت Carbon-C-Relay مع مرور الوقت ، ومتنامية الميزات عند الطلب حيث أثبتت الأداة أنها مستقرة وتناسب المهمة بشكل جيد. أدناه اتبع بعض الأمثلة المشروحة للبنيات التي يمكن استخدامها مع التتابع.
يمكن تعريف المجموعات بقدر ضرورة. يتلقون بيانات من قواعد المطابقة ، ويحدد نوعهم أي أعضاء الكتلة يحصلون أخيرًا على البيانات المتري. أبسط أشكال الكتلة هي مجموعة forward :
cluster send-through
forward
10.1.0.1
;
سيتم إعادة توجيه أي مقياس تم إرساله إلى مجموعة send-through إلى الخادم على عنوان IPv4 10.1.0.1 . إذا حددنا خوادم متعددة ، فإن كل هذه الخوادم ستحصل على نفس المقياس ، وبالتالي:
cluster send-through
forward
10.1.0.1
10.2.0.1
;
ينتج عنه ما ورد أعلاه ازدواجية من المقاييس إرسال إلى كلا الجهازين. يمكن أن يكون هذا مفيدًا ، ولكن في معظم الوقت ليس كذلك. يشبه نوع الكتلة any_of forward ، لكنه يرسل كل مقياس وارد إلى أي من الأعضاء. المثال نفسه مع هذه المجموعة سيكون:
cluster send-to-any-one
any_of 10.1.0.1:2010 10.1.0.1:2011;
هذا من شأنه أن ينفذ سيناريو متعدد الأطوار ، حيث يتم استخدام خادمين ، يتم نشر الحمل بينهما ، ولكن في حالة فشل أي منهما ، يتم إرسال جميع المقاييس إلى الباقي. يعمل هذا عادةً بشكل جيد على مرحلات المنبع ، أو لموازنة عمليات ذاكرة التخزين المؤقت للكربون التي تعمل على نفس الجهاز. إذا أصبح أي عضو غير متاح ، على سبيل المثال بسبب إعادة تشغيل المتداول ، يتلقى الأعضاء الآخرون حركة المرور. إذا كان من الضروري الحصول على فشل حقيقي ، حيث يتم استخدام الخادم الثانوي فقط إذا كان الأول قد انخفض ، فسيتم تنفيذ ما يلي:
cluster try-first-then-second
failover 10.1.0.1:2010 10.1.0.1:2011;
تختلف هذه الأنواع عن نوعي مجموعة التجزئة الثابتة:
cluster graphite
carbon_ch
127.0.0.1:2006=a
127.0.0.1:2007=b
127.0.0.1:2008=c
;
إذا فشل أحد الأعضاء في هذا المثال ، يتم الاحتفاظ بجميع المقاييس التي ستذهب إلى هذا العضو في قائمة الانتظار ، في انتظار عودة العضو. يعد هذا مفيدًا لمجموعات آلات آذان الكربون حيث من المستحسن أن ينتهي نفس المقياس على نفس الخادم دائمًا. يتوافق نوع مجموعة carbon_ch مع تجزئة متسقة للكربون ، ويمكن استخدامها للمجموعات الموجودة التي يسكنها الكربون. ومع ذلك ، بالنسبة للمجموعات الجديدة ، من الأفضل استخدام نوع مجموعة fnv1a_ch ، لأنه أسرع ، ويسمح بالموازنة عبر العنوان نفسه ولكن منافذ مختلفة بدون رقم مثيل ، في حدة إلى carbon_ch .
نظرًا لأنه يمكننا استخدام مجموعات متعددة ، يمكننا أيضًا تكرارها دون استخدام نوع الكتلة forward ، بطريقة أكثر ذكاءً:
cluster dc-old
carbon_ch replication 2
10.1.0.1
10.1.0.2
10.1.0.3
;
cluster dc-new1
fnv1a_ch replication 2
10.2.0.1
10.2.0.2
10.2.0.3
;
cluster dc-new2
fnv1a_ch replication 2
10.3.0.1
10.3.0.2
10.3.0.3
;
match *
send to dc-old
;
match *
send to
dc-new1
dc-new2
stop
;
في هذا المثال ، يتم إرسال جميع المقاييس الواردة لأول مرة إلى dc-old ، ثم dc-new1 وأخيراً إلى dc-new2 . لاحظ أن نوع الكتلة من dc-old مختلف. سيتم إرسال كل مقياس وارد إلى عضوين من جميع المجموعات الثلاث ، وبالتالي تكرار في إجمالي 6 وجهات. لكل مجموعة يتم حساب الأعضاء الوجهة بشكل مستقل. فشل المجموعات أو الأعضاء لا يؤثر على الآخرين ، لأن الجميع لديهم طوابير فردية. يمكن أيضًا كتابة المثال أعلاه باستخدام ثلاث قواعد مطابقة لكل DC ، أو قاعدة مطابقة واحدة لجميع DCs الثلاثة. الفرق هو في الأداء بشكل أساسي ، وعدد المرات التي يجب أن تتم مطابقة المقياس الوارد مع التعبير. قاعدة stop في قاعدة المباراة في dc-new ليست ضرورية تمامًا في هذا المثال ، لأنه لم يعد هناك قواعد مطابقة متابعة. ومع ذلك ، إذا كانت المباراة ستستهدف مجموعة فرعية محددة ، على سبيل المثال ^sys. ، وسيتم تعريف المزيد من المجموعات ، قد يكون ذلك ضروريًا ، على سبيل المثال في المثال المختصر التالي:
cluster dc1-sys ... ;
cluster dc2-sys ... ;
cluster dc1-misc ... ;
cluster dc2-misc ... ;
match ^sys. send to dc1-sys;
match ^sys. send to dc2-sys stop;
match * send to dc1-misc;
match * send to dc2-misc stop;
كما يمكن أن نرى ، دون stop في قاعدة تطابق DC2-SYS ، جميع المقاييس التي تبدأ بـ sys. سيتم إرسالها أيضًا إلى DC1-MISC و DC2-MISC. يمكن أن يكون هذا هو المطلوب ، بالطبع ، ولكن في هذا المثال ، هناك مجموعة مخصصة لمقاييس sys .
لنفترض أنه سيكون هناك بعض المقياس غير المرغوب فيه الذي يتم إنشاؤه للأسف ، دعنا نفترض بعض البرامج السيئة/القديمة. لا نريد تخزين هذا المقياس. مجموعة blackhole مناسبة لذلك ، عندما يكون من الصعب في الواقع أن كل ما تريده من القائمة البيضاء. النظر في ما يلي:
match
some_legacy1$
some_legacy2$
send to blackhole
stop;
هذا من شأنه أن يرمي جميع المقاييس التي تنتهي ببعض some_legacy ، والتي سيكون من الصعب تصفية ذلك. بما أن الأمر مهم ، يمكن استخدامه في بناء مثل هذا:
cluster old ... ;
cluster new ... ;
match * send to old;
match unwanted send to blackhole stop;
match * send to new;
في هذا المثال ، ستتلقى المجموعة القديمة المقياس غير المرغوب فيه للمجموعة الجديدة. لذلك ، فإن الترتيب الذي تحدث فيه القواعد مهم للتنفيذ.
يمكن استخدام التحقق من الصحة لضمان أن تكون بيانات المقاييس كما هو متوقع. يمكن أن يكون التحقق العالمي لقيم العدد (بدون نقطة عائمة):
match *
validate ^[0-9]+ [0-9]+$ else drop
;
(لاحظ الهروب مع backslash من المساحة ، قد تكون قادرًا على استخدام s أو [:space:] بدلاً من ذلك ، يعتمد هذا على تطبيق regex الذي تم تكوينه.)
يمكن أن يوجد شرط التحقق من الصحة في كل قاعدة تطابق ، لذلك من حيث المبدأ ، ما يلي صالح:
match ^foo
validate ^[0-9]+ [0-9]+$ else drop
send to integer-cluster
;
match ^foo
validate ^[0-9.e+-]+ [0-9.e+-]+$ else drop
send to float-cluster
stop;
لاحظ أن السلوك مختلف في المثالين السابقون. عندما لا يتم تحديد أي send to مجموعات ، فإن خطأ التحقق من الصحة يجعل المباراة تتصرف مثل الكلمة الرئيسية stop . Likewise, when validation passes, processing continues with the next rule. When destination clusters are present, the match respects the stop keyword as normal. When specified, processing will always stop when specified so. However, if validation fails, the rule does not send anything to the destination clusters, the metric will be dropped or logged, but never sent.
The relay is capable of rewriting incoming metrics on the fly. This process is done based on regular expressions with capture groups that allow to substitute parts in a replacement string. Rewrite rules allow to cleanup metrics from applications, or provide a migration path. In it's simplest form a rewrite rule looks like this:
rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
into server._1.2.3.34
;
In this example a metric like server.DC.role.name123 would be transformed into server.dc.role.name.name123 . For rewrite rules hold the same as for matches, that their order matters. Hence to build on top of the old/new cluster example done earlier, the following would store the original metric name in the old cluster, and the new metric name in the new cluster:
rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
into server._1.2.3.34
;
rewrite ^server.(.+).(.+).([a-zA-Z]+)([0-9]+)
into server.g{_1}.g{2}.g{3}.g{3}g{4}
;
The alternate syntax for backreference notation using g{n} instead of n notation shown above. Both rewrite rules are identical.
match * send to old;
rewrite ... ;
match * send to new;
Note that after the rewrite, the original metric name is no longer available, as the rewrite happens in-place.
Aggregations are probably the most complex part of carbon-c-relay. Two ways of specifying aggregates are supported by carbon-c-relay. The first, static rules, are handled by an optimiser which tries to fold thousands of rules into groups to make the matching more efficient. The second, dynamic rules, are very powerful compact definitions with possibly thousands of internal instantiations. A typical static aggregation looks like:
aggregate
^sys.dc1.somehost-[0-9]+.somecluster.mysql.replication_delay
^sys.dc2.somehost-[0-9]+.somecluster.mysql.replication_delay
every 10 seconds
expire after 35 seconds
timestamp at end of bucket
compute sum write to
mysql.somecluster.total_replication_delay
compute average write to
mysql.somecluster.average_replication_delay
compute max write to
mysql.somecluster.max_replication_delay
compute count write to
mysql.somecluster.replication_delay_metric_count
;
In this example, four aggregations are produced from the incoming matching metrics. In this example we could have written the two matches as one, but for demonstration purposes we did not. Obviously they can refer to different metrics, if that makes sense. The every 10 seconds clause specifies in what interval the aggregator can expect new metrics to arrive. This interval is used to produce the aggregations, thus each 10 seconds 4 new metrics are generated from the data received sofar. Because data may be in transit for some reason, or generation stalled, the expire after clause specifies how long the data should be kept before considering a data bucket (which is aggregated) to be complete. In the example, 35 was used, which means after 35 seconds the first aggregates are produced. It also means that metrics can arrive 35 seconds late, and still be taken into account. The exact time at which the aggregate metrics are produced is random between 0 and interval (10 in this case) seconds after the expiry time. This is done to prevent thundering herds of metrics for large aggregation sets. The timestamp that is used for the aggregations can be specified to be the start , middle or end of the bucket. Original carbon-aggregator.py uses start , while carbon-c-relay's default has always been end . The compute clauses demonstrate a single aggregation rule can produce multiple aggregates, as often is the case. Internally, this comes for free, since all possible aggregates are always calculated, whether or not they are used. The produced new metrics are resubmitted to the relay, hence matches defined before in the configuration can match output of the aggregator. It is important to avoid loops, that can be generated this way. In general, splitting aggregations to their own carbon-c-relay instance, such that it is easy to forward the produced metrics to another relay instance is a good practice.
The previous example could also be written as follows to be dynamic:
aggregate
^sys.dc[0-9].(somehost-[0-9]+).([^.]+).mysql.replication_delay
every 10 seconds
expire after 35 seconds
compute sum write to
mysql.host.1.replication_delay
compute sum write to
mysql.host.all.replication_delay
compute sum write to
mysql.cluster.2.replication_delay
compute sum write to
mysql.cluster.all.replication_delay
;
Here a single match, results in four aggregations, each of a different scope. In this example aggregation based on hostname and cluster are being made, as well as the more general all targets, which in this example have both identical values. Note that with this single aggregation rule, both per-cluster, per-host and total aggregations are produced. Obviously, the input metrics define which hosts and clusters are produced.
With use of the send to clause, aggregations can be made more intuitive and less error-prone. Consider the below example:
cluster graphite fnv1a_ch ip1 ip2 ip3;
aggregate ^sys.somemetric
every 60 seconds
expire after 75 seconds
compute sum write to
sys.somemetric
send to graphite
stop
;
match * send to graphite;
It sends all incoming metrics to the graphite cluster, except the sys.somemetric ones, which it replaces with a sum of all the incoming ones. Without a stop in the aggregate, this causes a loop, and without the send to , the metric name can't be kept its original name, for the output now directly goes to the cluster.
When configuring cluster you might want to check how the metrics will be routed and hashed. That's what the -t flag is for. For the following configuration:
cluster graphite_swarm_odd
fnv1a_ch replication 1
host01.dom:2003=31F7A65E315586AC198BD798B6629CE4903D089947
host03.dom:2003=9124E29E0C92EB63B3834C1403BD2632AA7508B740
host05.dom:2003=B653412CD96B13C797658D2C48D952AEC3EB667313
;
cluster graphite_swarm_even
fnv1a_ch replication 1
host02.dom:2003=31F7A65E315586AC198BD798B6629CE4903D089947
host04.dom:2003=9124E29E0C92EB63B3834C1403BD2632AA7508B740
host06.dom:2003=B653412CD96B13C797658D2C48D952AEC3EB667313
;
match *
send to
graphite_swarm_odd
graphite_swarm_even
stop
;
Running the command: echo "my.super.metric" | carbon-c-relay -f config.conf -t , will result in:
[...]
match
* -> my.super.metric
fnv1a_ch(graphite_swarm_odd)
host03.dom:2003
fnv1a_ch(graphite_swarm_even)
host04.dom:2003
stop
You now know that your metric my.super.metric will be hashed and arrive on the host03 and host04 machines. Adding the -d flag will increase the amount of information by showing you the hashring
When carbon-c-relay is run without -d or -s arguments, statistics will be produced. By default they are sent to the relay itself in the form of carbon.relays.<hostname>.* . See the statistics construct to override this prefix, sending interval and values produced. While many metrics have a similar name to what carbon-cache.py would produce, their values are likely different. By default, most values are running counters which only increase over time. The use of the nonNegativeDerivative() function from graphite is useful with these.
The following metrics are produced under the carbon.relays.<hostname> namespace:
metricsReceived
The number of metrics that were received by the relay. Received here means that they were seen and processed by any of the dispatchers.
metricsSent
The number of metrics that were sent from the relay. This is a total count for all servers combined. When incoming metrics are duplicated by the cluster configuration, this counter will include all those duplications. In other words, the amount of metrics that were successfully sent to other systems. Note that metrics that are processed (received) but still in the sending queue (queued) are not included in this counter.
metricsDiscarded
The number of input lines that were not considered to be a valid metric. Such lines can be empty, only containing whitespace, or hitting the limits given for max input length and/or max metric length (see -m and -M options).
metricsQueued
The total number of metrics that are currently in the queues for all the server targets. This metric is not cumulative, for it is a sample of the queue size, which can (and should) go up and down. Therefore you should not use the derivative function for this metric.
metricsDropped
The total number of metric that had to be dropped due to server queues overflowing. A queue typically overflows when the server it tries to send its metrics to is not reachable, or too slow in ingesting the amount of metrics queued. This can be network or resource related, and also greatly depends on the rate of metrics being sent to the particular server.
metricsBlackholed
The number of metrics that did not match any rule, or matched a rule with blackhole as target. Depending on your configuration, a high value might be an indication of a misconfiguration somewhere. These metrics were received by the relay, but never sent anywhere, thus they disappeared.
metricStalls
The number of times the relay had to stall a client to indicate that the downstream server cannot handle the stream of metrics. A stall is only performed when the queue is full and the server is actually receptive of metrics, but just too slow at the moment. Stalls typically happen during micro-bursts, where the client typically is unaware that it should stop sending more data, while it is able to.
connections
The number of connect requests handled. This is an ever increasing number just counting how many connections were accepted.
disconnects
The number of disconnected clients. A disconnect either happens because the client goes away, or due to an idle timeout in the relay. The difference between this metric and connections is the amount of connections actively held by the relay. In normal situations this amount remains within reasonable bounds. Many connections, but few disconnections typically indicate a possible connection leak in the client. The idle connections disconnect in the relay here is to guard against resource drain in such scenarios.
dispatch_wallTime_us
The number of microseconds spent by the dispatchers to do their work. In particular on multi-core systems, this value can be confusing, however, it indicates how long the dispatchers were doing work handling clients. It includes everything they do, from reading data from a socket, cleaning up the input metric, to adding the metric to the appropriate queues. The larger the configuration, and more complex in terms of matches, the more time the dispatchers will spend on the cpu. But also time they do /not/ spend on the cpu is included in this number. It is the pure wallclock time the dispatcher was serving a client.
dispatch_sleepTime_us
The number of microseconds spent by the dispatchers sleeping waiting for work. When this value gets small (or even zero) the dispatcher has so much work that it doesn't sleep any more, and likely can't process the work in a timely fashion any more. This value plus the wallTime from above sort of sums up to the total uptime taken by this dispatcher. Therefore, expressing the wallTime as percentage of this sum gives the busyness percentage draining all the way up to 100% if sleepTime goes to 0.
server_wallTime_us
The number of microseconds spent by the servers to send the metrics from their queues. This value includes connection creation, reading from the queue, and sending metrics over the network.
dispatcherX
For each indivual dispatcher, the metrics received and blackholed plus the wall clock time. The values are as described above.
destinations.X
For all known destinations, the number of dropped, queued and sent metrics plus the wall clock time spent. The values are as described above.
aggregators.metricsReceived
The number of metrics that were matched an aggregator rule and were accepted by the aggregator. When a metric matches multiple aggregators, this value will reflect that. A metric is not counted when it is considered syntactically invalid, eg no value was found.
aggregators.metricsDropped
The number of metrics that were sent to an aggregator, but did not fit timewise. This is either because the metric was too far in the past or future. The expire after clause in aggregate statements controls how long in the past metric values are accepted.
aggregators.metricsSent
The number of metrics that were sent from the aggregators. These metrics were produced and are the actual results of aggregations.
Please report them at: https://github.com/grobian/carbon-c-relay/issues
Fabian Groffen <[email protected]>
All other utilities from the graphite stack.
This project aims to be a fast replacement of the original Carbon relay. carbon-c-relay aims to deliver performance and configurability. Carbon is single threaded, and sending metrics to multiple consistent-hash clusters requires chaining of relays. This project provides a multithreaded relay which can address multiple targets and clusters for each and every metric based on pattern matches.
There are a couple more replacement projects out there, which are carbon-relay-ng and graphite-relay.
Compared to carbon-relay-ng, this project does provide carbon's consistent-hash routing. graphite-relay, which does this, however doesn't do metric-based matches to direct the traffic, which this project does as well. To date, carbon-c-relay can do aggregations, failover targets and more.
This program was originally developed for Booking.com, which approved that the code was published and released as Open Source on GitHub, for which the author would like to express his gratitude. Development has continued since with the help of many contributors suggesting features, reporting bugs, adding patches and more to make carbon-c-relay into what it is today.
