Grafana: مراقبة جرافانا

++

: +1:

تأكد من أن عنوان url الخاص بالصحة لا يُنشئ جلسات

: +1:

+1 ، سيكون هذا مفيدًا جدًا لتشغيل grafana خلف loadbalancer ، سوف يستدعي loadbalancer / health HTTP للتحقق من أن grafana تعيد HTTP 200 OK.

لقد جمعت شيئًا بسيطًا ، لكنني لست سعيدًا به بشكل خاص في الوقت الحالي.

إذا كان أي شخص يرغب في إلقاء نظرة على الحالة الحالية مقابل الماجستير: https://github.com/grafana/grafana/compare/master...theangryangel : feature / health_check

تقوم بإرجاع شيء مثل:

{"current_timestamp":"2016-06-04T18:43:49+01:00","database_ok":true,"session_ok":true,"version":{"built":1464981754,"commit":"v3.0.4+158-g7cbaf06-dirty","version":"3.1.0"}}

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

فحص الجلسة لست سعيدًا بشكل خاص بأي منهما. لا يبدو أن هناك طريقة سهلة للاختبار دون الوقوف على خادم معكرون للاختبار والاسترداد () من الذعر الذي قد يحدث عند بدء موفر جلسة ، أو تعديل ماكرون / جلسة لإضافة ميزة اختبار لكل من مقدمي. نظرًا لأنه الآن مزعج ، يتم إرجاع رأس Set-Cookie ، والذي لا أريده بشكل خاص. سأكون ممتنًا لبعض المدخلات لأخذ هذا من شخص أكثر خبرة مع ماكرون 😞

لا يبدو التحقق من مصادر البيانات أمرًا عقلانيًا بشكل خاص لمحاولة ذلك نظرًا لكيفية كتابة grafana. ربما يكون أكثر عقلانية لإضافته إلى نظام المراقبة المنتظم.

كنت أواجه نفس المشكلة وكحل بديل ، أستخدم استدعاء API من موازن التحميل مع مفتاح API مخصص للمصادقة. أنا أستخدم HAProxy ، الذي يحتوي على بعض الميزات "المخفية" المفيدة لتعيين رؤوس HTTP المخصصة في option httpchk :

option httpchk GET /api/org HTTP/1.0\r\nAccept:\ application/json\r\nContent-Type:\ application/json\r\nAuthorization:\ Bearer\ your_api_key\r\n

(أحتاج إلى استخدام HTTP / 1.0 بدلاً من 1.1 ، نظرًا لأن الأخير يتطلب إعداد رأس المضيف ولا يمكنني الحصول عليه ديناميكيًا في HAProxy config).

يبدو أن /api/org هو أبسط طلب مع القليل من النفقات العامة ويعيد HTTP 200 ، وهو بالضبط ما يحتاجه موازن التحميل - ولا ينشئ أي جلسات جديدة.

أي تقدم أو العلاقات العامة في هذه القضية؟

+1

أود أن أقسم هذا إلى نقطة نهاية منفصلة / استعداد كما هو أفضل ممارسة في kubernetes. / liveness يشير فقط إلى ما إذا كان grafana نفسه يعمل ، / يشير الجاهزية إلى ما إذا كان جاهزًا لتلقي حركة المرور وسيتحقق مما إذا كان يمكن الوصول إلى تبعياته.

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

+1

ماذا عن إضافة نقطة نهاية بروميثيوس / المقاييس؟

+1

لمن يحتاج إلى فحوصات صحية على بعض الخدمات مثل Amazon ECS:
استخدم هذا الاختراق: المسار /public/img/grafana_icon.svg ، كود HTTP: 200.

+1

في هذه الأثناء ، إذا كنت تبحث فقط عن HTTP code: 200 بسيط ، فما عليك سوى استخدام /login . لقد قمت أنا وزميلي بنشر Grafana في مجموعة Kubernetes واستخدمنا نقطة النهاية هذه بشكل جيد لتحقيقات الحيوية / الاستعداد. يعمل أيضًا مع موازن تحميل Google Compute Engine.

أعتقد أن الجميع يعرف كيف يشير إلى ذلك تقنيًا ولكن الهدف هو دعم مراقبة صحة الخدمة بشكل صريح بما في ذلك التبعيات الخارجية.

مرسل من الايفون الخاص بي

في 5 كانون الأول (ديسمبر) 2016 ، الساعة 4:09 مساءً ، كتب Hunter Satterwhite [email protected] :

إذا كنت تبحث عن رمز HTTP بسيط: 200 ، فما عليك سوى استخدام / تسجيل الدخول. لقد قمت أنا وزميلي بنشر Grafana في مجموعة Kubernetes واستخدمنا نقطة النهاية هذه بشكل جيد لتحقيقات الحيوية / الاستعداد. يعمل أيضًا مع موازن تحميل Google Compute Engine.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

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

+1 لهذا.

يوم الإثنين 5 ديسمبر 2016 الساعة 11:51 مساءً ، فيليب ويرنرسباخ <
[email protected]> كتب:

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/grafana/grafana/issues/3302#issuecomment-265060171 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AIESgm7BZw3jqs8ElVWU9v7CjtcXBYFwks5rFOm-gaJpZM4Gm4T8
.

-

[صورة: TransLoc_logos_gear-blue_600x600.png]

صياد ساتروايت

مهندس البناء والعمليات الرئيسي ، TransLoc

الخلية: 252.762.5177 | http://transloc.com http://www.transloc.com/

[صورة: رموز الوسائط الاجتماعية-03.png] https://www.facebook.com/TransLoc/ [صورة:
Social media icons-04.png] https://www.linkedin.com/company/transloc [الصورة:
Social media icons-02.png] http://www.twitter.com/transloc [الصورة: social
أيقونات الوسائط 01.png] http://www.instagram.com/transloc_inc

لذلك توجد حاليًا نقطة نهاية 4.0 a / api / metrics مع بعض المقاييس الداخلية.

لكن القضية تتطلب شيئًا كهذا

{ "date_sources_ok": True, "database_ok": True, "authorization_ok": True, "grafana_version": "2.5.1" }

سيكون جيدًا مع وصف أكثر تفصيلاً لما هو متوقع هنا. هل يجب أن يقوم استدعاء السلامة الخاص بواجهة برمجة التطبيقات بإجراء فحص مباشر لجميع مصادر البيانات في جميع المؤسسات؟ هل يجب أن يتم ذلك بسرعة أثناء إجراء مكالمة api / health؟
ماذا يعني التفويض طيب؟

torkelo سيطرح فكرة ولكن بالتأكيد يجب أن تسمح الصحة لكل من خادم grafana بالإضافة إلى المكونات الإضافية المثبتة لتسجيل أشياء عشوائية للإبلاغ عنها:

{
    "ok": false,
    "items": [
        "datasources": {
            "ok": true,
        },
        "database": {
            "ok": false,
            "msg": "Cannot communicate ###.###.###.###/XXXXXXX"
        },
        ...
    ]
}

بشكل افتراضي ، تقوم الفحوصات الصحية بإجراء فحوصات مباشرة لجميع الأشياء عند استدعاء نقطة النهاية. إذا كان الناس يريدون عزل الفحوصات الصحية لأشياء محددة ، فيمكنك القيام بشيء مثل البحث المطاطي لصحة المجموعة . عندما يكون الشيء عبارة عن خدمة خارجية (ترخيص ، قاعدة بيانات ، إلخ) ، يتم إجراء اختبار الاتصال عند الحد الأدنى وأي فحص آخر معقول لشيء ما (مثل SELECT 1 لقاعدة البيانات ، واختبار ربط LDAP للترخيص ، إلخ).

سيسمح وجود مثل هذا بمخرجات المراقبة بالتحقق بشكل شامل من المشكلات أثناء البحث عن مشاكل محددة والمخرجات وفقًا لذلك.

+1

torkelo آسف للإجابة المتأخرة رأيت أسئلتك للتو.

TL ؛ DR
andyfeller قام بعمل جيد في تعليقه وهذا ما كان

يجب أن تجيب نقطة النهاية (أو نقاط النهاية) المستخدمة لمراقبة Grafana على سؤالين بالتفاصيل:
أ) هل نسخة Grafana هذه جاهزة وجاهزة؟
ب) هل يعمل مثيل Grafana هذا كما هو متوقع وفقًا لأهداف التكوين الخاصة به؟

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

يساعدني ذلك في التفكير من حيث إقلاع الطائرة ، أولاً أحتاج إلى معرفة أن الطائرة قد انتهت من الإقلاع وهي في الجو ، ثم أحتاج إلى معرفة أن الطائرة تحلق نحو وجهتها كما هو متوقع (دعنا لا ندخل في ما " الوصول إلى ارتفاع الرحلة البحرية "يعني ؛-))

يمكن مقارنة هذا إلى حد ما بـ / مباشر / جاهز أشار إليه الآخرون أو / health (1) / حالة (2) لنموذج Elasticsearch أو / health و / info من Sensu (3).
تكفي نقطة نهاية واحدة IMHO ولكن رؤية نقطتي نهاية في معظم الأدوات الحديثة هي _kinda_ تغيير رأيي ؛ دعنا نقول فقط إنني غير مقتنع بعد لأنني أعتقد أن B هي مجموعة فرعية من A ، لذا سأجعل JSON الذي تم إرجاعه يعكس ذلك بدلاً من الحصول على نقطتي نهاية. ثم في أحد الأيام عندما يمكن تجميع Grafana ، يمكن إضافة "cluster_state / /".

الآن فيما يتعلق بتفاصيل كل إجابة ، ها هي أفكاري الأولية - غير الشاملة -:
التفاصيل:

• الحالة (مثل أحمر / أصفر / أخضر)
• تعليق الحالة (على سبيل المثال "كل شيء جيد" / "تعذر بدء مكون Foo" / "جارٍ البدء")
• الإصدار (مثل v4.1.1-1)

تفاصيل ب:

• حالة قاعدة البيانات (مثل أحمر / أصفر / أخضر)
• تفاصيل قاعدة البيانات (على سبيل المثال ، "لا يمكن الاتصال ، أو مصادقة سيئة" ، أو اتصال جيد بـ mySQL v4.1 في xxx.yyy. zzz: 3306 ، إصدار المخطط v34132 ، نعم يجب إصدار مخططات SQL (4))
• المصادقة / التفويض (مثل اتصال LDAP بـ xx.xx.xx: 389 موافق)
• مصادر البيانات (مثل Datasource 1 ، type Graphite ، status Red ، status comment "auth failure، Datasource 2، type Elasticsearch، status Green، status comment" all good ")

هناك الكثير الذي يمكن أن يتم وضعه في B وهذا هو السبب في أن تقسيم المراقبة إلى نقطتين نهائيتين قد يكون أكثر منطقية ، meh.

فيما يتعلق بكيفية متابعة ما يحدث عندما يتم الاستعلام عن نقطة النهاية (أثناء التنقل ، واجهات برمجة التطبيقات ، وما إلى ذلك) ، أود أن أتردد لمن ينتهي به الأمر بالتنفيذ.

زوجان - واضح؟ - على الرغم من النصائح:

• ضع في اعتبارك الموارد المستخدمة لجمع بيانات المراقبة وكن "وقائيًا" للغاية باستخدام رمز الأجهزة ، وساعد مشرفي Grafana على تجنب مواقف "مراقبتي لـ Grafana أدت إلى انخفاض Grafana" أو "تباطأت سرعة Grafana بنسبة X٪ منذ أن بدأت في مراقبتها" .

• كن على يقين قدر الإمكان من بيانات المراقبة المقدمة ، فإن التعب الناتج عن التنبيه هو وباء

(1) https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html
(2) https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state.html
(3) https://sensuapp.org/docs/0.23/api/health-and-info-api.html#the -info-api-endpoint
(4) https://blog.codinghorror.com/get-your-database-under-version-control/

إذن 4.2.0 خرج للتو ولا تزال هناك طريقة لفحص الخدمة؟ (اعتقد k8s الكتلة)

torkelo أعتقد أن dynek لديه وجهة نظر ، هذا لم يعد اختياريًا بعد الآن. سواء كان قسمًا جديدًا في المستندات مخصصًا لـ "كيفية مراقبة Grafana" حيث يتم توثيق ما يمكن عمله اليوم باستخدام الأجهزة الحالية (مثل صفحة الإدارة أو المقاييس) أو واجهة برمجة تطبيقات مخصصة كاملة كما في هذا الاقتراح ، نحتاج إلى شيء بالأمس .
من فضلك لا تأخذ هذا بطريقة خاطئة ، لا أقصد إخبارك بما يجب أن تكون عليه الأولويات ، إنه فقط من الصعب بيع التطبيق ليكون "Enterprise Ready" بدون جزء مخصص لكيفية مراقبته.

+1

تمت إضافة نقطة نهاية http بسيطة للتحقق من صحة grafana:

GET /api/health 
{
  "commit": "349f3eb",
  "database": "ok",
  "version": "4.1.0"
}

إذا كانت قاعدة البيانات (mysql / postgres / sqlite3) غير قابلة للوصول ، فستعيد "فشل" في الحقل database . سيظل غرافانا يجيب برمز الحالة 200. لست متأكدًا مما هو صحيح في هذه الحالة.

أهم شيء في نقطة النهاية هذه هو أنها لن تتسبب أبدًا في إنشاء الجلسات (شيء ما قد تفعله استدعاءات api الأخرى إذا لم تتصل بها بمفتاح api أو مصادقة أساسية).

ألن يكون من الأفضل العودة برمز الحالة 503 عندما يتعذر الوصول إلى قاعدة البيانات؟

يستخدم Kubernetes:

يشير أي رمز أكبر من أو يساوي 200 وأقل من 400 إلى النجاح. أي رمز آخر يشير إلى الفشل.

نعم ، أعتقد أن رمز الحالة 503 عند فشل حالة db هو الأفضل ، سيتم تحديثه

وسائل 503 في /api/health نقطة النهاية يستخدم أفضل فقط ل readiness الاختيار في Kubernetes. إذا تم استخدام هذا الاختيار مقابل liveness ، فستؤدي مشكلة في قاعدة البيانات إلى قتل جميع القرون. هل هناك معلمة استعلام لترك فحص قاعدة البيانات؟

JorritSalverda ربما يمكنك استخدام tcpSocket في livenessProbe

/metrics بإنشاء جلسات أو إصدار طلب db.

عادة ما يكون لدينا فحوصات استعداد عدوانية وفحوصات مريحة للحيوية ، ثانية واحدة ، فشل واحد للاستعداد ، في حين أنه 60 ثانية 10 فشل نجاح واحد للحيوية ، هذا يسمح بإعادة التوجيه سريع الاستجابة عند وجود مشكلة ، ولكن في نفس الوقت إذا كان التعافي الذاتي ممكن ، يمنع إعادة تشغيل جراب غير ضروري. لكن مشكلة قاعدة البيانات المستمرة قد تتسبب في إعادة التشغيل والتي قد تساعد بالفعل إذا كانت بسبب حالة حاوية سيئة.