Grafana: الرسم البياني: حدود المقياس التلقائي Y (الحد الأدنى كحد أقصى)

شكرا ، فكرة مثيرة للاهتمام. يبدو حالة حافة صغيرة. لكنني أتفق ، يمكن أن يكون مفيدًا في بعض الأحيان.

نعم ، أردت فقط أن أكتب أفكاري على الورق. :بيرة:

لا أعتقد أن هذه قضية متطرفة.
ضبط AutoScale up. قم بتعيين 0-100 على أنه الحد الأدنى للغضب ولكن اسمح للرسم البياني بالحجم الكبير الذي يريده. لقد تسبب هذا في حالة من الذعر عدة مرات بين المديرين ونواب الرئيس حتى جعلتهم ينظرون إلى النطاق الذي كان عليه.

+1 يوجد الكثير من بيانات السلاسل الزمنية التي أتخيلها في grafana عند صفر + ضوضاء ، وهذا يجعل الرسوم البيانية تبدو فوضوية وغير واضحة.

+1 من مستخدم Grafana.net.

سيساعد الحد الأدنى للمقياس في أشياء مثل واجهات الشبكة ، حيث تكون بعض روابطنا الخاصة / vpn خاملة (حوالي 20 كيلو بايت / ثانية) ولكن عند الاستخدام تكون 50-100 ميجا بايت / ثانية. إذا قمت بضبط المقياس على 100 ميغا بايت / ثانية وانتهى الأمر ، فلا أعرف ، وإذا قمت بتعيينه على 200 ميغا بايت / ثانية ، فلا يمكنني رؤية البيانات بوضوح عندما تكون 5-10 ميغا بايت / ثانية فقط.

أفهم أن هذه الوظيفة ربما تكون مفيدة فقط لعدد قليل جدًا من الأشخاص. لكنني كنت أقوم بالقرصنة على هذا قليلاً. وقد توصلت إلى شيء يناسبني. يضيف الالتزام في مفترقتي مربع Y-Span إلى علامة التبويب Axes.

حيث X عبارة عن عدد صحيح أو عدد عشري:

~X Span X around average
=X Span X around current value
>X Span is atleast X
<X Span is clamped to X

https://github.com/thoj/grafana/commit/7dcdccbd42e9f63b7388e439f7194fe7ead8039a

مثال لماذا أحتاجه:

أي مصلحة في العلاقات العامة؟

thoj سيكون ذلك إضافة رائعة. نستخدم عتبات لبعض الرسوم البيانية ونود أن نعرضها دائمًا ، ولكننا ما زلنا نقيس الرسم البياني لإظهار نقاط أعلى بكثير من العتبة. سيعمل "> X" بشكل جيد هنا (و

lpalm نعم! سأضيف طلب سحب لمحاولة بدء المناقشة ،

تم تنفيذه في https://github.com/grafana/grafana/pull/6051

هل هذا في قطار الإصدار 4.0.x؟ أحاول استخدام "<" و ">" في إعدادات المحور ص ولكن دون جدوى.

لم يكن علينا التراجع عنها ، فقد أردنا إدخال / واجهة مستخدم أكثر سهولة في الاستخدام من مجرد ميزة مخفية حيث يدعم حقل الإدخال تعبيرات مثل > و < لذلك تم إرجاع الميزة في انتظار الوقت لمعرفة واجهة المستخدم

هل يمكن أن يكون لدينا هذا في صندوق الإسقاط إلى جانب Y-min و Y-max؟

مرحبا،

لقد أنشأت هذه الميزة لمشروع الجرافيت منذ فترة وتوصلت إلى الاستنتاج التالي بأنني لن أرغب أبدًا في استخدام yMax ، لأنني أريد دائمًا معرفة قيم الرسم البياني ، وهو ما لن أفعله مع
هل هناك أي شخص يعتقد أن yMax هي وظيفة مفيدة أم أنه ينبغي إعادة تصميم yMax ليعمل كـ minYMax ؟

أعني ، إذا قمت بتعيين yMax على x وتجاوز العداد x ، فلن يرغب أي شخص في معرفة مقدار تجاوزه الحد؟

أستخدم yMax عندما يكون لدي نسب مئوية للتأكد من أن 100٪ دائمًا في أعلى الرسم البياني (حتى لو كان هناك صورة صغيرة)

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

iksaif نعم ، لكن هذا لا يتطلب إصلاح yMax. نظرًا لأن الرسم البياني الخاص بك لن يتجاوز أبدًا 100% وأن yMax الديناميكي الخاص بك سيكون 100% سيبدو الرسم البياني الخاص بك تمامًا كما هو الحال مع التنفيذ الحالي لـ yMax ؟

thoj الذي لا يبدو أنه مقياس موثوق؟ ألا تريد بدلاً من ذلك استبعاد تلك الارتفاعات من الرسم البياني أم أنك إذا كنت تهتم بها تعرف القيمة فعلاً؟

Kvistian ، سيحدث ، لأسباب ، أنه يعرض 100.02 ٪ ، وأنا أحب حقيقة أنني قادر على تحديد ذلك.

هناك أيضًا أوقات أرغب فيها فقط في معرفة متى أريد "التكبير" ويمكنني استخدام yMax للقيام بذلك.

حسنًا ، لكنك توافق على أن معظم الحالات تتطلب yMax ديناميكيًا؟ في هذه الحالة ، هل من المنطقي جعل yMax ديناميكيًا ووظيفة جديدة مثل staticYMax أو fixedYMax لتلك الحالات المتطورة؟ وبالتالي ، فإن وجود yMax ديناميكي كإعداد افتراضي لأنه يمثل حالة الاستخدام العام.

يبدو أن تعيين الحد الأدنى لأعلى الرسم البياني قد يكون مفيدًا ، لكنني لن أغير دلالات yMax الحالية (والتي هي بالفعل الحد الأقصى y الذي يمكن عرضه).

سيكون من المثير للاهتمام العثور على كيفية تسمية هذا الشيء في برامج أخرى مماثلة

Kvistian لا يريد الجميع استخدام grafana لعرض مقاييس نظيفة لطيفة فقط من الخوادم. أرغب في عرض مقاييس من العمليات الفيزيائية الصاخبة ويمكنها إرجاع بيانات غريبة في بعض الأحيان. انظر الأمثلة والتوضيحات الخاصة بي هنا: https://github.com/grafana/grafana/pull/5720

thoj لم أقترح إزالته إذا كانت ميزة مفيدة ، لقد تساءلت ببساطة عما إذا كانت كذلك. ولكن يبدو أن هناك بعض حالات الاستخدام الخاصة به ، لذا في هذه الحالة لا ينبغي إزالته. لكنني شخصياً أشعر أنه يجب أن يكون هناك المزيد من الحالات التي ترغب فيها باستخدام yMax ديناميكي. عندما تعثرت في مشكلة الجرافيت ، افترضت بالفعل أن yMax سيحل مشكلتي (حيث لم أستطع رؤية أي حالة مفيدة لـ yMax ثابت فعلي). في النهاية إنها مجرد مشكلة تسمية في هذه المرحلة.

لا يهمني حقًا ما إذا كان يطلق عليه yMax أو minYMax ، فقط اعتقدت أن yMax تبدو وكأنها وظيفة default التي يجب أن تحل حالة الاستخدام الأكثر شيوعًا.

أعرض قيمة حالة شحن البطارية (SOC) وسأحب حقًا ميزة القدرة على تعيين حد أعلى وأدنى مع الحفاظ على القياس التلقائي ضمن هذه الحدود.

فيما يلي بعض الصور للمشكلة التي أواجهها من خلال تعيين قيمة Y-Max أو عدم تعيينها.

إذا لم أقم بتعيين قيمة Y-Max ،

0% <= y_scale_values <= 100%

إذا قمت بتعيين قيمة Y-Max ، فعندئذٍ عندما يكون لديّ قيم SOC منخفضة لفترة طويلة ، لا يتم قياس الرسم البياني تلقائيًا ، كما هو موضح في الصورة أدناه.

ما أريده هو أن أكون قادرًا على تعيين حد أعلى (100٪) وحد أدنى (0٪) ولكن لا يزال لديك مقياس الرسم التلقائي ضمن هذه الحدود كما هو الحال في الوقت الحالي عندما لا يتم تعيين حدود Y.

فقط أضف حالة الاستخدام الخاصة بنا. نحن نراقب موقعًا إلكترونيًا ولدينا مستوى أساسي من التحقق من صحة حركة المرور لمثيلات "العمل" ، والتي أود عرضها كخط رسم بياني "منخفض" (على سبيل المثال 0.1 طلب / ثانية لكن المحور سيكون 1 كحد أدنى ، بينما لا يزال يُمكِّن محور الرسم البياني من التوسع لأعلى عند وصول حركة المرور "الحقيقية".

هناك اختراق للحد الأدنى لقيمة المحور Y.

قم بإنشاء مقياس Baseline للحد الأدنى من المقياس الذي تريده. اخترت هنا 1 ثانية لوقت وحدة المعالجة المركزية:

أضف تجاوزات للمقياس الأساسي لإخفائه من الرسم البياني:

هذا هو.

العيب الوحيد هو أنه يمكنك رؤية خط الأساس الخاص بك وتحوم فوقه:

أحتاج أيضًا إلى هذا لعرض IO.

على سبيل المثال ، يمكن أن تكون سرعة القراءة 50 كيلو بايت / دقيقة أو 500 ميجا بايت / دقيقة ، وتعيين بعض الحد الأدنى للمقياس - على سبيل المثال 100 ميجابايت / دقيقة كإعداد افتراضي سيجعل طريقة الرسوم البيانية أكثر اتساقًا.

+1
رجاء؟

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

حسنًا ، يمكنني التعايش مع ذلك :) هل نظر أي شخص إلى ردود الفعل؟ لقد لاحظت الآن أنه يمكنك الفرز حسب مقدار ردود الفعل ، لذلك هذا شيء على الأقل. شكر

أعتقد أنه سيتم تغطية حالات استخدام معظم الأشخاص عن طريق إضافة مربع اختيار "حد ضعيف" بجوار حقلي Y-Min و Y-Max. إذا قمت بنقل Y-Max إلى الصف التالي ، فيجب أن يكون هناك مساحة كافية لكل من مربع الاختيار والتسمية ، ويجب أن تكون الوظيفة واضحة تمامًا :)

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

هل يوجد حل حاليا للقيام بذلك؟

أي تحديثات لهذا؟ هذا يجعل إنشاء لوحات معلومات جيدة أمرًا صعبًا للغاية.

تتمثل إحدى أفكار واجهة المستخدم في أن يكون لديك:

• YMax (soft) - يمتد الجزء العلوي من الرسم البياني دائمًا إلى هنا على الأقل
• YMax (صعب) - لا يمتد الجزء العلوي من الرسم البياني إلى ما هو أبعد من هنا
• YMin (ناعم) - يمتد الجزء السفلي من الرسم البياني دائمًا إلى هنا على الأقل
• YMin (صعب) - لا يمتد الجزء السفلي من الرسم البياني إلى أبعد من هنا

يمكن أن يكون الأمر الآخر في هذا هو الحد الأدنى للمدى للمحور Y الذي يحدد أن المدى من Y-low الحالي إلى Y-high يجب ألا يكون أبدًا أقل من القيمة المحددة. بهذه الطريقة يكون التجسيد مجانيًا لتعيين المكان الذي يجب أن يبدأ فيه المحور y وينتهي - وفي نفس الوقت تجنب التغييرات الطفيفة في القيم التي سيتم عرضها على شكل جبال.

أجد أيضًا أن هذه مشكلة شائعة جدًا مع البيانات الصاخبة وأن معظم البيانات صاخبة.

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

منذ ما يقرب من عامين:

قام بإعادة الميزة في انتظار الوقت لمعرفة واجهة المستخدم

الرجاء إعادة > و < بينما يتم أخذ واجهة مستخدم أفضل بعين الاعتبار.

أنا في انتظار يائس لميزة مثل تلك التي تمت إزالتها منذ عامين!

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

هناك اختراق للحد الأدنى لقيمة المحور Y.

قم بإنشاء مقياس Baseline للحد الأدنى من المقياس الذي تريده. اخترت هنا 1 ثانية لوقت وحدة المعالجة المركزية:

أضف تجاوزات للمقياس الأساسي لإخفائه من الرسم البياني:

هذا هو.

العيب الوحيد هو أنه يمكنك رؤية خط الأساس الخاص بك وتحوم فوقه:

بالنسبة لأولئك الذين يقرؤون عمل bobrik المفيد ، يمكنك في هذه الأيام أيضًا إخفاء العنصر baseline من تلميحات الأدوات في التجاوز أيضًا.

bobrik @ sb3tcs مرحبًا ، أرغب في استخدام الحل البديل الخاص بك ، ولكن ينتهي الأمر بـ Grafana بخطأ في بناء جملة الاستعلام إذا كان كل ما وضعته في الاستعلام هو 20 أو أي رقم آخر. كيف يتم إنشاء مقياس الأساس؟ أم أن برنامج Grafana 5.1 الخاص بي أقدم من أن يدعم هذا النوع من الاستعلام؟

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

لقد أضفت استعلامًا إضافيًا بنفس نقاط البيانات:
الإزاحة (-20) الكليبواسطة (1 م ، دقيقة) إزالة أسفل القيمة (0) مجموعة ألياس (مخفي_ دقيقة)

هذا يغير التكبير الديناميكي من
دقيقة تصل إلى الحد الأقصى
إلى
min-20 (مع عدم الخوض في السلبيات) حتى الحد الأقصى

لإخفاء الرسم البياني المزيف:
تجاوز التصور باستخدام regex "/hidden_.*/"
الخطوط: خطأ
الأسطورة: خطأ
إخفاء في تلميح الأداة: صحيح

ربما يمكنك مزامنة المحور ص بين الرسوم البيانية المتعددة. مثل لوحة لكل خادم واجمع الحد الأدنى / الحد الأقصى من نقاط البيانات لجميع الخوادم في كل لوحة.

لقد وجدت حلاً آخر. لقد أضفت للتو سلسلة زمنية min و max مع علامة min و max. كان الخط مثل هذا
weather,sensorID=min temperature=0
weather,sensorID=max temperature=20
يتم إضافتها إلى الرسم البياني وإخفائها كما هو مذكور أعلاه. المشكلة الوحيدة هي أنك تحتاج إلى حقنها بشكل منتظم.
إليك كيف تبدو ، قد تحتاج إلى ضبط درجة الحرارة القصوى على 19 بحيث تقوم تلقائيًا بضبط المحور على 20.

تحرير: أدخل الحد الأقصى 19 وكان يعمل.

لقد عثرت على هذا الخيط بحثًا عن حل لإعداد y-max مرن في Grafana. بالنسبة لحالة الاستخدام الخاصة بي ، أقوم برسم وقت استجابة الطلب وحجمه لواجهة برمجة التطبيقات. أريد تعيين y-max مرنًا إلى حوالي 500 مللي ثانية (0.5 ثوانٍ) ، حتى أتمكن من رؤية الفوارق الدقيقة للمكالمات ذات زمن الوصول المنخفض بشكل أفضل من خلال استبعاد القيم المتطرفة الشائكة والضبط التلقائي لـ y-max عندما يكون الحد الأقصى لوقت الاستجابة أقل من تلك العتبة.

لقد حاولت ضبط: y-min إلى 0 و y-max إلى <.5 ، ولكن بعد ذلك يختفي المحور y تمامًا أو يتجاهل y-min. حدثت هذه المشكلة بغض النظر عن الرسم البياني لوقت الاستجابة وطلب استعلامات وحدة التخزين معًا / بشكل منفصل. هل حدث أي تقدم جديد في هذه القضية؟ سيكون مفيدًا حقًا لفريقي.

أقوم بتضمين بعض لقطات الشاشة للرسم البياني الخاص بي مع تكوين y-max بشكل مختلف (كل حالة مصنفة بعنوان الرسم البياني)

إذا كنت لا تريد رسم قيم تزيد عن 500 مللي ثانية ، يمكنك محاولة استخدام removeAboveValue (0.5)
ثم أخبر الرسم البياني بكيفية معالجة القيم الخالية

لا يوجد دليل إذا كانت هناك طريقة لاستخدام المعلمات المحسوبة لهذه الوظيفة

الحل الأساسي الأكثر حداثة قليلاً كما يلي:

يؤدي هذا إلى إيقاف ظهور الاستعلام الأساسي في الرسم البياني ، ووسيلة الإيضاح ، وتلميح أداة التمرير ، كما يمنعه من التسبب في مشكلات في التكديس.

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

سيكون من المثير للاهتمام العثور على كيفية تسمية هذا الشيء في برامج أخرى مماثلة

Highchartjs تسميها softMin / softMax.
https://api.highcharts.com/highcharts/yAxis

AnyChart يطلق عليه soft min / max.
https://docs.anychart.com/Axes_and_Grids/Scales#soft

يحتوي Chartjs على خيار "مين / ماكس" للتعامل مع حالة الاستخدام هذه.
https://www.chartjs.org/docs/latest/axes/cartesian/linear.html#axis -range-settings

تسميها amCharts min / max وrictMin / Max.
https://www.amcharts.com/docs/v4/reference/valueaxis/#strictMinMax_property

RRDtool على سبيل المثال له حدود "ناعمة" بشكل افتراضي عندما يستخدم المرء مقياس تلقائي ، ولكن لديه خيار يسمى rigid يفرض حدودًا "صارمة" على المقياس.

[-u | - قيمة الحد الأعلى] [-l | - قيمة الحد الأدنى] [-r | - صلب] [--allow-shrink]

بشكل افتراضي ، سيتم قياس الرسم البياني تلقائيًا بحيث يضبط المحور الصادي على نطاق البيانات. يمكنك تغيير هذا السلوك عن طريق تعيين الحدود بشكل صريح. سيتراوح المحور الصادي المعروض على الأقل من الحد الأدنى إلى الحد الأعلى. سيظل القياس التلقائي يسمح بتمديد تلك الحدود ما لم يتم تعيين الخيار الجامد. يغير allow-shrink سلوك الصلابة من خلال السماح بتقليص الحجم التلقائي ، ولن يتجاوز الرسم البياني الحدود التي حددها المستخدم.
https://oss.oetiker.ch/rrdtool/doc/rrdgraph.en.html

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

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

قد يؤدي خيار نطاق المحور ص الأدنى للقياس التلقائي إلى إزالة هذا المطلب. عند استخدامها في مجموعة من القيم حيث لا يتجاوز نطاق البيانات (على سبيل المثال ، abs(max(Y)-min(Y)) ) الحد الأدنى الذي تم تكوينه من نطاق المحور الصادي ، سيتم تعيين الحد الأدنى والحد الأقصى للقيم على المحور ص بحيث يتم تعيين البيانات تتمركز عموديًا. هذا يتجنب مشكلة المبالغة في الفروق الصغيرة ، دون أن يحتاج مصمم الرسم البياني إلى معرفة قيم المحور ص بالضبط في وقت مبكر.

جزء سريع من الكود الكاذب لتوضيح العملية الحسابية:

minRange = 25
dataRange = abs(max(Y)-min(Y))
if dataRange < minRange:
    yAxisExtension = (minRange - dataRange) / 2
    yAxisMin = min(Y) - yAxisExtension
    yAxisMax = max(Y) + yAxisExtension

لن يدفع هذا النهج القيم المتطرفة بعيدًا عن المقياس ، مثل التركيز على المتوسط.

كمثال لحالة الاستخدام ، تخيل أنك تصمم لوحة معلومات لمراقبة البيانات من NUT / upsd ، وتقوم بتجميع الرسم البياني لاستخدام الطاقة. في حين أن متوسط ​​UPS الخاص بي قد يبلغ 400 واط ، فقد يكون متوسط ​​\ u200b \ u200b شخص آخر 100W أو 1000W ، اعتمادًا على شكل إعداد أجهزته. ليس من الممكن معرفة هذا في وقت مبكر. عادة ما تكون كمية الطاقة المسحوبة ثابتة إلى حد ما على مدى فترة زمنية قصيرة ، على الرغم من ذلك ، مما يعني أنها عرضة لمبالغة المحور y عند إجراء القياس التلقائي. هذه حالة استخدام مثالية لنطاق المحور الصادي الأدنى ، حيث يمكنك وضع افتراضات معقولة حول مقياس التباين خلال فترة زمنية معينة ، ولكن ليس حجم القيمة المطلقة.

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