Grafana: Grafana überwachen

++

: +1:

Stellen Sie sicher, dass die Integritäts-URL keine Sitzungen generiert

: +1:

+1, dies wäre sehr nützlich, um grafana hinter loadbalancer auszuführen. Loadbalancer ruft das HTTP / health auf, um zu überprüfen, ob grafana HTTP 200 OK zurückgibt.

Ich habe etwas ganz Einfaches zusammengestellt, bin aber im Moment nicht besonders zufrieden damit.

Wenn jemand einen Blick auf den aktuellen Status gegen den Master werfen möchte: https://github.com/grafana/grafana/compare/master...theangryangel : feature / health_check

Es gibt so etwas zurück wie:

{"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"}}

Bei der Datenbankprüfung habe ich ursprünglich einige Statistiken zurückgegeben, aber das habe ich herausgeschnitten. Ich könnte die Abfrage auf etwas viel Einfacheres wie "select 1" umstellen und überprüfen, ob sie fehlerfrei ist. Ich bin mir nicht sicher, ob es sich lohnt.

Mit dem Session Check bin ich auch nicht besonders zufrieden. Es scheint nicht einfach zu sein, einen Test zu testen, ohne einen Test-Macaron-Server hochzufahren und sich von der Panik zu erholen, die beim Starten eines Sitzungsanbieters oder beim Ändern von Macaron / Sitzung auftreten würde, um jedem Test eine Testfunktion hinzuzufügen Anbieter. Da es gerade irritierend ist, wird ein Set-Cookie-Header zurückgegeben, den ich nicht besonders möchte. Ich würde mich über eine Eingabe freuen, wo ich dies von jemandem nehmen kann, der mehr Erfahrung mit Macaron hat 😞

Das Suchen nach Datenquellen scheint angesichts der Schreibweise von grafana nicht besonders sinnvoll zu sein. Wahrscheinlich vernünftiger, um es Ihrem regulären Überwachungssystem hinzuzufügen.

Ich hatte das gleiche Problem und verwende als Problemumgehung einen API-Aufruf vom Load Balancer mit einem dedizierten Authentifizierungs-API-Schlüssel. Ich verwende HAProxy, das einige nützliche "versteckte" Funktionen zum Festlegen benutzerdefinierter HTTP-Header in option httpchk bietet:

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

(Ich muss HTTP / 1.0 anstelle von 1.1 verwenden, da letzteres das Setzen des Host-Headers erfordert und ich ihn in der HAProxy-Konfiguration nicht dynamisch abrufen kann.)

/api/org scheint die einfachste Anforderung mit geringem Overhead zu sein und gibt HTTP 200 zurück, genau das, was der Load Balancer benötigt - und erstellt keine neuen Sitzungen.

Irgendwelche Fortschritte oder PR zu diesem Thema?

+1

Ich würde dies in einen separaten Endpunkt für / Lebendigkeit und / Bereitschaft aufteilen, wie es in Kubernetes die beste Vorgehensweise ist. / liveness zeigt nur an, ob grafana selbst betriebsbereit ist, / readiness zeigt an, ob es bereit ist, Datenverkehr zu empfangen, und prüft, ob seine Abhängigkeiten erreichbar sind.

In Kubernetes wird der Endpunkt der Lebendigkeit überprüft, und wenn mehrmals nicht mit 200 OK geantwortet wird, wird der Container getötet und durch einen neuen ersetzt. Der Bereitschaftsendpunkt wird verwendet, um den Container zu einem Teil eines Dienstes zu machen und Datenverkehr auf seinen Weg zu senden. Wie das Hinzufügen und Entfernen von einem Load Balancer.

+1

Was ist mit dem Hinzufügen eines Prometheus-Endpunkts /metrics?

+1

Für alle, die bei einigen Diensten wie Amazon ECS Gesundheitschecks benötigen:
Verwenden Sie diesen Hack: Pfad /public/img/grafana_icon.svg , HTTP-Code: 200.

+1

Wenn Sie in der Zwischenzeit nur nach einem einfachen HTTP code: 200 suchen, verwenden Sie einfach /login . Mein Kollege und ich haben Grafana gerade in einem Kubernetes-Cluster bereitgestellt, und die Verwendung dieses Endpunkts hat für die Liveness / Readiness-Tests einwandfrei funktioniert. Funktioniert auch für den Load Balancer von Google Compute Engine.

Denken Sie, jeder weiß, wie man dies technisch impliziert, aber es geht darum, die Überwachung des Dienstzustands einschließlich externer Abhängigkeiten explizit zu unterstützen.

von meinem Iphone gesendet

Am 5. Dezember 2016, um 16:09 Uhr, schrieb Hunter Satterwhite [email protected] :

Wenn Sie nach einem einfachen HTTP-Code suchen: 200, verwenden Sie einfach / login. Mein Kollege und ich haben Grafana gerade in einem Kubernetes-Cluster bereitgestellt, und die Verwendung dieses Endpunkts hat für die Liveness / Readiness-Tests einwandfrei funktioniert. Funktioniert auch für den Load Balancer von Google Compute Engine.

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Ich möchte unseren speziellen Anwendungsfall hinzufügen: Wir benötigen einen einfachen HTTP-Endpunkt, um zu überprüfen, ob sich ein Benutzer anmelden und Diagramme anzeigen kann. Ich weiß, dass wir die statischen Ressourcen und Endpunkte wie /login , um das Fehlen zu umgehen, aber wir brauchen wirklich etwas, das überprüft, ob die Grafana-Interna wie erwartet ausgeführt werden. Wir benötigen nicht unbedingt Statusprüfungen zum Abrufen von Daten aus Datenquellen, da wir für diese separate Integritätsprüfungen haben.

+1 dazu.

Am Montag, 5. Dezember 2016, um 23:51 Uhr, Philip Wernersbach <
[email protected]> schrieb:

Ich möchte unseren speziellen Anwendungsfall hinzufügen: Wir benötigen einen einfachen HTTP-Endpunkt für
Überprüfen, ob sich ein Benutzer anmelden und Diagramme anzeigen kann. Ich weiß, dass wir das nutzen können
statische Ressourcen und Endpunkte wie / login, um die Abwesenheit zu umgehen
davon, aber wir brauchen wirklich etwas, das die Grafana überprüft
Interna laufen wie erwartet. Wir brauchen nicht unbedingt Statusprüfungen
zum Abrufen von Daten aus Datenquellen, da wir separate Integritätsprüfungen haben
für diejenigen.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/grafana/grafana/issues/3302#issuecomment-265060171 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AIESgm7BZw3jqs8ElVWU9v7CjtcXBYFwks5rFOm-gaJpZM4Gm4T8
.

- -

[Bild: TransLoc_logos_gear-blue_600x600.png]

Hunter Satterwhite

Leitender Build & Operations Engineer, TransLoc

Zelle: 252.762.5177 | http://transloc.com http://www.transloc.com/

[Bild: Social Media Icons-03.png] https://www.facebook.com/TransLoc/ [Bild:
Social Media Icons-04.png] https://www.linkedin.com/company/transloc [Bild:
Social Media Icons-02.png] http://www.twitter.com/transloc [Bild: Social
Mediensymbole-01.png] http://www.instagram.com/transloc_inc

Daher gibt es derzeit in 4.0 einen / api / Metrics-Endpunkt mit einigen internen Metriken.

Aber das Problem verlangt so etwas

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

Wäre gut mit einer detaillierteren Beschreibung für das, was hier erwartet wird. Sollte der API-Integritätsaufruf eine Live-Überprüfung mit allen Datenquellen in allen Organisationen durchführen? Sollte dies im laufenden Betrieb erfolgen, wenn der / health-API-Aufruf erfolgt?
Was bedeutet Autorisierung ok?

@torkelo wird eine Idee

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

Standardmäßig führen Integritätsprüfungen Live-Überprüfungen aller Dinge durch, wenn der Endpunkt aufgerufen wird. Wenn Benutzer Integritätsprüfungen auf bestimmte Dinge beschränken möchten, können Sie etwas wie elasticsearch für die Clusterintegrität tun. Wenn es sich um einen externen Dienst handelt (Autorisierung, Datenbank usw.), wird mindestens ein Konnektivitätstest durchgeführt und jede andere für die Sache angemessene Überprüfung der Integrität (z. B. SELECT 1 für Datenbank, LDAP-Bindungstest für Autorisierung usw.) durchgeführt.

Mit einer solchen Ausgabe können Überwachungsprüfungen ganzheitlich auf Probleme prüfen, bestimmte Probleme finden und entsprechend ausgeben.

+1

@torkelo Entschuldigung für die verspätete Antwort habe gerade Ihre Fragen gesehen.

TL; DR
@andyfeller Hat in seinem Kommentar gute Arbeit geleistet und es ist ziemlich genau das, was ich mir vorgestellt habe

Der Endpunkt (oder die Endpunkte), die zur Überwachung von Grafana verwendet werden, sollten zwei Fragen mit Details beantworten:
A) Ist diese Grafana-Instanz betriebsbereit?
B) Läuft diese Grafana-Instanz gemäß ihren Konfigurationsabsichten wie erwartet?

"Konfigurationsabsichten" sind hier der Schlüssel. Mit Absicht meine ich, dass der Administrator, wenn er beispielsweise als Datenquelle hinzufügt, erwartet, dass diese verfügbar ist, unabhängig davon, ob die gespeicherte Konfiguration richtig ist oder nicht. Wenn Grafana keine konfigurierte Datenquelle zur Verfügung steht, sollte der Überwachungsendpunkt dies angeben und warum auf die gleiche Weise die äußerst nützliche Schaltfläche "Test" funktioniert.

Es hilft mir zu denken, dass ein Flugzeug abhebt. Zuerst muss ich wissen, dass das Flugzeug fertig gestartet ist und sich in der Luft befindet. Dann muss ich wissen, dass das Flugzeug wie erwartet auf sein Ziel zufliegt (lassen Sie uns nicht darauf eingehen, was Reiseflughöhe erreichen "bedeutet ;-))

Dies kann etwas mit dem / live / ready verglichen werden, auf das andere hingewiesen haben, oder / health (1) / state (2) des Elasticsearch-Modells oder / health und / info von Sensu (3).
IMHO ein Endpunkt ist genug, aber 2 Endpunkte in den meisten modernen Tools zu sehen, ist _kinda_ meine Meinung zu ändern; Sagen wir einfach, ich bin noch nicht überzeugt, da ich denke, dass B eine Teilmenge von A ist, also würde ich dafür sorgen, dass der zurückgegebene JSON dies widerspiegelt, anstatt zwei Endpunkte zu haben. Dann kann eines Tages, wenn Grafana geclustert werden kann, ein "/ cluster_state" hinzugefügt werden.

In Bezug auf die Details jeder Antwort sind hier meine nicht erschöpfenden ersten Gedanken:
Ein Detail:

• Status (zB rot / gelb / grün)
• Statuskommentar (zB "Alles ist gut" / "Komponente Foo konnte nicht gestartet werden" / "Starten")
• Version (zB v4.1.1-1)

B Details:

• DB-Status (zB rot / gelb / grün)
• DB-Details (z. B. "Verbindung konnte nicht hergestellt werden, schlechte Authentifizierung" oder Verbindung zu mySQL v4.1 unter xxx.yyy ok. Zzz: 3306 , Schemaversion v34132, ja, SQL-Schemas sollten versioniert werden (4))
• Authentifizierung / Autorisierung (zB LDAP-Verbindung zu xx.xx.xx: 389 ok)
• Datenquellen (z. B. Datenquelle 1, Typ Graphit, Status Rot, Statuskommentar "Authentifizierungsfehler, Datenquelle 2, Typ Elasticsearch, Status Grün, Statuskommentar" Alles gut ")

In B kann noch viel mehr passieren, weshalb es sinnvoller sein könnte, die Überwachung in zwei Endpunkte zu unterteilen, meh.

In Bezug darauf, wie vorzugehen ist, was passiert, wenn der Endpunkt abgefragt wird (im laufenden Betrieb, APIs usw.), würde ich mich auf die Person beschränken, die jemals implementiert wird.

Ein paar - offensichtliche? - Ratschläge:

• Achten Sie sehr auf die Ressourcen, die zum Sammeln von Überwachungsdaten verwendet werden, und gehen Sie mit dem Instrumentierungscode sehr "schützend" um. Helfen Sie Grafana-Administratoren, zu vermeiden, dass "meine Überwachung von Grafana Grafana heruntergefahren hat" oder "Grafana hat sich seit Beginn der Überwachung um X% verlangsamt" .

• Seien Sie so sicher wie möglich in Bezug auf die bereitgestellten Überwachungsdaten. Alarmmüdigkeit ist eine Plage

(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/

Also kam gerade 4.2.0 heraus und es gibt immer noch keine Möglichkeit, den Dienst zu testen? (denke k8s Cluster)

@torkelo Ich denke, @dynek hat einen Punkt, dies ist nicht mehr optional. Ob es sich um einen neuen Abschnitt in den Dokumenten handelt, der sich mit der Überwachung von Grafana befasst, in dem dokumentiert ist, was heute mit der vorhandenen Instrumentierung (z. B. Hebeladministrations- oder Metrikseite) getan werden kann, oder um eine vollständig ausgearbeitete dedizierte API wie in diesem Vorschlag .
Bitte verstehen Sie das nicht falsch. Ich möchte Ihnen nicht sagen, welche Prioritäten gesetzt werden sollen. Es ist nur ein schwieriger Verkauf für eine Anwendung, "Enterprise Ready" zu sein, ohne einen speziellen Teil für die Überwachung.

+1

Es wurde ein einfacher http-Endpunkt hinzugefügt, um die Gesundheit von grafana zu überprüfen:

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

Wenn die Datenbank (mysql / postgres / sqlite3) nicht erreichbar ist, wird im Feld database "fehlgeschlagen" zurückgegeben. Grafana antwortet weiterhin mit dem Statuscode 200. Ich bin mir nicht sicher, was in diesem Fall richtig ist.

Das Wichtigste an diesem Endpunkt ist, dass niemals Sitzungen erstellt werden (etwas, das andere API-Aufrufe möglicherweise tun, wenn Sie sie nicht mit einem API-Schlüssel oder einer grundlegenden Authentifizierung aufrufen).

Wäre es nicht am besten, mit dem Statuscode 503 zurückzukehren, wenn die Datenbank nicht erreichbar ist?

Kubernetes verwendet:

Jeder Code größer oder gleich 200 und kleiner als 400 zeigt Erfolg an. Jeder andere Code weist auf einen Fehler hin.

Ja, ich denke, der 503-Statuscode, wenn der Datenbankstatus fehlgeschlagen ist, wird am besten aktualisiert

Der /api/health 503 bedeutet, dass der Endpunkt readiness in Kubernetes verwendet wird. Wenn diese Prüfung für liveness ein Datenbankproblem dazu, dass alle Pods getötet werden. Gibt es einen Abfrageparameter, um die Datenbankprüfung wegzulassen?

@JorritSalverda Sie könnten wahrscheinlich tcpSocket Check-in livenessProbe

/metrics keine Sitzungen und gibt keine Datenbankanforderung aus.

Wir haben in der Regel aggressive Bereitschaftsprüfungen und entspannte Lebendigkeitsprüfungen, 1 Sekunde, 1 Fehler für die Bereitschaft, während es 60 Sekunden sind. 10 Fehlschläge 1 Erfolg für die Lebendigkeit. Dies ermöglicht eine reaktionsschnelle Umleitung, wenn ein Problem vorliegt, aber gleichzeitig, wenn die Selbstwiederherstellung erfolgt möglich, verhindert unnötige Pod-Neustarts. Ein anhaltendes DB-Problem würde jedoch einen Neustart verursachen, der möglicherweise hilfreich ist, wenn ein fehlerhafter Containerstatus vorliegt.