Grafana: Nicht autorisiert

Könntest du noch ein paar Details geben:

• Sind das zwei separate Instanzen?
• Welche Aktion löst den nicht autorisierten Fehler aus?
• Werden Sie abgemeldet oder funktionieren nur bestimmte Aktionen nicht?

Sind sie auf verschiedenen IPs/Domain-Namen eingerichtet? Wenn der Domainname derselbe ist und sich nur nach Port unterscheidet, müssen Sie eindeutige Sitzungscookies haben und sich an mich erinnern

-Das sind separate Instanzen
-Ich weiß nicht, welche Aktion das Unbefugte auslöst, es passiert einfach, wenn ich Grafiken anschaue oder auf grafana zugreife
-Manchmal werde ich ausgeloggt
-Getrennte Domänen

Ich treffe dies auf Grafana 4.6.x mit oauth über Github. Es ist scheinbar zufällig, wenn ich die Tabs wechsle und zu Grafana zurückkomme. Eine Aktualisierung wird das Problem "korrigieren", aber es kommt manchmal später wieder.

Ich sehe das gleiche Problem bei Grafana v4.6.2 (Commit: 8db5f08), alles funktioniert wie erwartet, und plötzlich erhalte ich eine Unauthorized-Warnung (und einige Grafiken sind leer, aber einige werden normal angezeigt).

Als DataSource verwende ich Prometheus.

Ich denke auch, dass dies hauptsächlich passiert, wenn das Dashboard automatisch aktualisiert wird, aber es behebt sich selbst, wenn ich es manuell aktualisiere.

Ähnliches Problem auch hier, aber mit einer einzelnen Grafana-Instanz mit HTTPS und Postgres-Datenquelle.

Wenn das Dashboard geöffnet ist, sind alle Diagramme in Ordnung. Aber manchmal danach zeigen einige der Grafiken bei der automatischen Aktualisierung "Nicht autorisiert"-Fehler, aber innerhalb der nächsten (oder nächsten) Auto-Aktualisierung kehren sie in den Normalzustand zurück, kehren dann aber manchmal später wieder in den "Unautorisiert"-Zustand zurück und wiederholen sich dieses zufällige Verhalten bei jeder automatischen Aktualisierung.

Ich bin mir nicht sicher, ob es damit zusammenhängt, habe aber die folgenden Protokollmeldungen gefunden.

lvl=eror msg="Benutzer mit ID konnte nicht abgerufen werden" logger=context userId=1 error="Benutzer nicht gefunden"

Grafana-Version ist wie folgt:

lvl=info msg="Starting Grafana" logger=Serverversion=5.0.4 commit=7dc36ae kompiliert=2018-03-28T20:52:41+0900

Ich verwende Firefox und lasse das Dashboard normalerweise mehrere Tage lang geöffnet und unberührt, wobei der Client-Rechner (nicht der Server-Rechner, der Grafana hostet) von Zeit zu Zeit in den Ruhemodus wechselt.

Das passiert mir mit grafana 5.x nicht mehr

Ich habe immer noch genau das gleiche Problem mit Grafana 5.0.4, die gleichen Nachrichten des Benutzers, die nicht im Protokoll gefunden werden (dies ist mit einem einfachen lokalen Grafana-Benutzer).

Ich habe dieses Problem auch. Und das Thema ist sehr interessant. Dies kann passieren, wenn ich zwei Grafana-Seiten unterschiedlicher Version im selben Browser öffne und versuche, einige Operationen auszuführen.

Ich habe eine ältere Version von grafana (v4.3.2 (commit: ed4d170)) und läuft seit langem gut auf grafana.mydomain.com . Heute möchte ich mein grafana auf v5.0.4 upgraden. Statt Upgrade an Ort und Stelle. Ich wollte das neue Grafana auf demselben Computer einrichten, das gewünschte Dashboard kopieren und dann das alte abreißen.

Also was ich gemacht habe:

1. docker läuft grafana5 auf dem gleichen Rechner des alten mit Portmap auf 3005
2. habe das alte grafana4 auf grafana.mydomain.com in Safari geöffnet
   Und es funktioniert gut
3. Besuchen Sie Grafana5 auf grafana.mydomain.com:3005 in Safari
   Jetzt habe ich also zwei geöffnete Tabs von Grafana4 und Grafana5 auf meinem Bildschirm
4. Melden Sie sich bei Grafana5 an und versuchen Sie, einige Operationen auszuführen .... wie [Dashboard erstellen]
   Jetzt sind beide Grafana-Seiten abgestürzt

Beide Grafana erhalten Unauthorized Fehler und erhalten keine Datenpunkte

Update : Ich habe meinen Schritt 3 geändert, indem ich Grafana5 mit [ip]:3005 besucht habe. Es funktioniert vorerst gut.
Es sieht so aus, als könnten Konflikte beim Öffnen von zwei Grafana-Seiten innerhalb derselben Domain auftreten.

@kehao95 Ihr Anwendungsfall, im selben Browser zwei Grafana-Instanzen auf derselben Domain, aber mit unterschiedlichen Ports zu öffnen, wird nicht unterstützt. (Torkel hat das oben erwähnt).

@ajardan sind Ihre Instanzen in derselben Domain oder in unterschiedlichen?

@daniellee Ich

Ich bekomme auch von Zeit zu Zeit diese seltsamen "Unauthorized"-Probleme. Seitenaktualisierung "behebt" das Problem. Ich führe Grafana v5.1.0 (844bdc53a) vom offiziellen Docker-Image aus. Datenquelle ist InfluxDb. Ich habe in Grafana 2 Organisationen erstellt, verwende aber tatsächlich nur eine. Einzelner 'admin'-Benutzer.

Habe diesen Fehler gerade noch einmal mit einer neuen Fehlermeldung "Annotation query failed. Unauthorized" erhalten.

Mein Grafana auf win10 x64 funktionierte einige Tage einwandfrei, bis ich die Warnung "Unauthorized" erhalte. Das Verhalten ist das gleiche wie von @dogada beschrieben und ich verwende auch v5.1.0 mit influxdb. Sowohl grafana als auch influxdb befinden sich auf demselben Computer.

Gleicher Fehler. Eine Grafana 5.1-Instanz im Docker. Google auth für die Autorisierung.

Irgendwelche Aktualisierungen?

Gleiches Verhalten. Derzeit läuft v5.0.3 in Docker, interne Authentifizierung, einzelner Admin-Benutzer, Proxy über nginx, Datenquelle ist influxdb. Dashboard behebt sich selbst, wenn Daten automatisch aktualisiert werden. Passiert meistens, wenn Tab lange Zeit im Hintergrund ist

Dasselbe Problem tritt auf, wenn zwei Registerkarten für dieselbe Instanz geöffnet sind.

Update auf das neueste Docker-Image v5.1.2 (Commit: c3c690e21) behebt das Problem nicht

Ich habe das gleiche Problem mit Grafana 5.0.0 in Docker mit GitHub OAuth. Ich habe es auf Dashboards mit InfluxDB, CloudWatch und einer Mischung aus beiden Datenquellen gesehen. (Eine Instanz, ein Port, HTTPS, hinter einem ELB.)

Wie andere in diesem Thread scheine ich zu sehen, dass es durch eine automatische Aktualisierung ausgelöst wird und nach einem Neuladen der Seite verschwindet. Manchmal sehe ich die grundlegende Fehlermeldung "Unauthorized" (mit Fehlern beim Laden von Diagrammen) und manchmal (seltener) auch die Meldung "Annotation query failed. Unauthorized".

~Mein Verdacht deutet auf etwas mit den OAuth-Plugins hin?~ Es liegt fast definitiv am Session-Backend, siehe unten.

Um mehr Details hinzuzufügen, die ich gefunden habe, nachdem ich etwas tiefer eingegraben habe, sehe ich viele Fehler wie diesen in meinen Protokollen:

t=2018-05-16T16:55:39+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="User not found"

Der einzige Ort, an dem ich einen solchen Fehler sehe, ist in dieser Codezeile, die mit der Verwaltung von Sitzungen und Sitzungscookies zusammenhängt?

https://github.com/grafana/grafana/blob/0ad63366349db8781916a731387cd5e556280633/pkg/middleware/middleware.go#L97

Ich speichere meine Sitzungen mit dem standardmäßigen file Backend, aber über eine gemountete EFS-Freigabe frage ich mich, ob dies eine mögliche Komplikation ist.

Ich bin mit diesem Problem konfrontiert, als ich versuche, zwei verschiedene Grafana (die in einem anderen Port ausgeführt werden) im selben Browser zu öffnen.
Ich erhalte nicht autorisierte Fehler und werde manchmal abgemeldet

Es wäre wirklich interessant zu sehen, welche SQL-Abfragen ausgeführt werden, wenn Sie die Meldung Failed to get user with id log erhalten. Wenn Sie dies leicht reproduzieren können, wäre es sehr wertvoll, wenn Sie die Protokollierung von SQL-Abfragen aktivieren und Ihre Ergebnisse zurückmelden könnten:

[database]
# Set to true to log the sql calls and execution times.
log_queries = true

Dankeschön

@marefr Es scheint, als würden diese Fehler immer von einer dieser beiden Abfragen umgeben auftreten:

SELECT\n\t\tu.id as user_id,\n\t\tu.is_admin as is_grafana_admin,\n\t\tu.email as email,\n\t\tu.login as login,\n\t\tu.name as name,\n\t\tu.help_flags1 as help_flags1,\n\t\tu.last_seen_at as last_seen_at,\n\t\t(SELECT COUNT(*) FROM org_user where org_user.user_id = u.id) as org_count,\n\t\torg.name as org_name,\n\t\torg_user.role as org_role,\n\t\torg.id as org_id\n\t\tFROM `user` as u\n\t\tLEFT OUTER JOIN org_user on org_user.org_id = 1 and org_user.user_id = u.id\n\t\tLEFT OUTER JOIN org on org.id = org_user.org_id WHERE u.id=? []interface

UPDATE `user` SET `last_seen_at` = ? WHERE `id`=? []interface

Vollständige Beispielprotokolle:

t=2018-05-30T15:59:39+0000 lvl=info msg="[SQL] SELECT\n\t\tu.id as user_id,\n\t\tu.is_admin as is_grafana_admin,\n\t\tu.email as email,\n\t\tu.login as login,\n\t\tu.name as name,\n\t\tu.help_flags1 as help_flags1,\n\t\tu.last_seen_at as last_seen_at,\n\t\t(SELECT COUNT(*) FROM org_user where org_user.user_id = u.id) as org_count,\n\t\torg.name as org_name,\n\t\torg_user.role as org_role,\n\t\torg.id as org_id\n\t\tFROM `user` as u\n\t\tLEFT OUTER JOIN org_user on org_user.org_id = 1 and org_user.user_id = u.id\n\t\tLEFT OUTER JOIN org on org.id = org_user.org_id WHERE u.id=? []interface
{}
{2} - took: 54.517418ms" logger=sqlstore.xorm
t=2018-05-30T15:59:39+0000 lvl=info msg="[SQL] UPDATE `user` SET `last_seen_at` = ? WHERE `id`=? []interface
{}
{\"2018-05-30 15:59:39\", 2} - took: 42.957209ms" logger=sqlstore.xorm
t=2018-05-30T15:59:39+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="User not found"
t=2018-05-30T15:59:39+0000 lvl=info msg="[SQL] SELECT\n\t\tu.id as user_id,\n\t\tu.is_admin as is_grafana_admin,\n\t\tu.email as email,\n\t\tu.login as login,\n\t\tu.name as name,\n\t\tu.help_flags1 as help_flags1,\n\t\tu.last_seen_at as last_seen_at,\n\t\t(SELECT COUNT(*) FROM org_user where org_user.user_id = u.id) as org_count,\n\t\torg.name as org_name,\n\t\torg_user.role as org_role,\n\t\torg.id as org_id\n\t\tFROM `user` as u\n\t\tLEFT OUTER JOIN org_user on org_user.org_id = 1 and org_user.user_id = u.id\n\t\tLEFT OUTER JOIN org on org.id = org_user.org_id WHERE u.id=? []interface
{}
{2} - took: 69.013955ms" logger=sqlstore.xorm
t=2018-05-30T15:59:39+0000 lvl=info msg="[SQL] UPDATE `user` SET `last_seen_at` = ? WHERE `id`=? []interface
{}
{\"2018-05-30 15:59:39\", 2} - took: 5.593997ms" logger=sqlstore.xorm
t=2018-05-30T15:59:39+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="User not found"
t=2018-05-30T15:59:39+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="User not found"
t=2018-05-30T15:59:39+0000 lvl=info msg="[SQL] UPDATE `user` SET `last_seen_at` = ? WHERE `id`=? []interface
{}
{\"2018-05-30 15:59:39\", 2} - took: 46.673µs" logger=sqlstore.xorm
t=2018-05-30T15:59:39+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="User not found"
t=2018-05-30T15:59:39+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="User not found"
t=2018-05-30T15:59:39+0000 lvl=info msg="[SQL] UPDATE `user` SET `last_seen_at` = ? WHERE `id`=? []interface
{}
{\"2018-05-30 15:59:39\", 2} - took: 621.538µs" logger=sqlstore.xorm

Vielen Dank @bjacobel. Hier sieht meiner Meinung nach alles gut aus. Es gibt eine tatsächliche Benutzer-ID bis hinunter zur Datenbankabfrage. Wirklich seltsam. Wir beginnen zu denken, dass es einen Fehler mit unserer Drittanbieter-Datenbank-Lib xorm gibt.

Haben Sie etwas Bestimmtes unternommen, um diese Protokollmeldungen zu generieren?
Welche Datenbank verwendest du? Welcher Sitzungsspeicher?
Welche Anfrage zu nicht autorisierten führt, können Sie die Router-Protokollierung aktivieren, um alle Anfragen zu protokollieren:

[server]
router_logging = true

Wir haben den gleichen Fehler bei 5.1.4 in Kubernetes.

Hallo @marefr , Entschuldigung, ich habe vergessen, mit den zusätzlich angeforderten Details zu antworten.

Haben Sie etwas Bestimmtes unternommen, um diese Protokollmeldungen zu generieren?

Die Abfragen werden generiert, indem ein Dashboard geladen und dann auf eine automatische Aktualisierung gewartet wird. Es passiert nicht bei jeder automatischen Aktualisierung, und manchmal kann es durch einen manuellen Klick auf die Schaltfläche zum Aktualisieren des Dashboards ausgelöst werden (die in Grafana integrierte Schaltfläche, nicht die Schaltfläche zum Aktualisieren des Browsers), aber im Allgemeinen scheint es häufiger zu passieren, wenn der Benutzer dies tut inaktiv (zum Beispiel wird Grafana in einem Hintergrund-Tab belassen.)

Welche Datenbank verwendest du? Welcher Sitzungsspeicher?

Die Datenbank ist SQLite auf einer gemounteten NFS (EFS)-Freigabe, und der Sitzungsspeicher ist der Standard (Datei), obwohl ich auch den speicherbasierten Speicher ausprobiert habe und auch das gleiche Problem auftrat. Wir haben einen Grafana-Host hinter einem Load-Balancer, und ich habe die Session-Stickiness auf diesem Load-Balancer aktiviert.

Welche Anfrage führt zu einem Unbefugten?

Ich habe die Router-Protokollierung nicht aktiviert, weil ich die Anfrage sehen kann, die zu einer nicht autorisierten vom Browser führt:

[Einige sensible Informationen geschwärzt]

Request URL: https://[my grafana hostname]/api/tsdb/query
Request Method: POST
Status Code: 401 
Remote Address: [my load balancer IP]:443
Referrer Policy: no-referrer-when-downgrade
:authority: [my grafana hostname]
:method: POST
:path: /api/tsdb/query
:scheme: https
accept: application/json, text/plain, */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
cache-control: no-cache
content-length: 478
content-type: application/json;charset=UTF-8
cookie: _ga=GA1.2.1782868908.1520436196; __gads=ID=b1c7d78e4fd8b9fb:T=1520436200:S=ALNI_MYT2aRMJqYtHY-CkgaPWmuNtsGEtA; sailthru_hid=919b24e8c99698a8b1829b81eda7135a5956a753dd4c29265f8b45b3a11fb749fc11562ad2abbb1220b9ef37; grafana_sess=[16-char hexadecimal session string]; AWSALB=IUyH6LlTXI/TJlteL8pr838fC7nsvth7s63o5WzqOa6wsCPRpHg20vYurCrYpbIWci27fQtzQpoRxVlIc8Ud/rEPIJvqWvT21an4e9aQmZioTEAFHA3+iWv7bPHs
dnt: 1
origin: https://[my grafana hostname]
pragma: no-cache
referer: https://[my grafana hostname]/d/[dashboard path]?refresh=5m&orgId=1&from=now-1h&to=now
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
x-grafana-org-id: 1

Hallo @marefr , Entschuldigung, ich habe vergessen, mit den zusätzlich angeforderten Details zu antworten. ...

@bjacobel Dies hat wahrscheinlich nichts mit dem spezifischen Problem zu

Nebenbei bemerkt verwenden wir SQLite mit Sitzungsspeicher wie Sie es tun, jedoch auf einem lokalen Dateisystem. Wir haben das gleiche Problem nicht erlebt.

Wir haben auch die SQLite-Konfiguration in grafana optimiert, um den WAL-Modus (von dem ich irgendwann eine PR machen werde) für eine bessere Leistung zu verwenden.

_{Gesendet mit GitHawk}

Ich habe das gleiche Problem in meinem Docker Grafana- und InfluxDB-Stack.
Grafana v5.1.3 (Commit: 087143285)
InfluxDB 1.5.3

Grafana verwendet lokalen Speicher über Docker-Volumes mit SQLite-Datenbank. Volumes verwenden lokale SSD.
Ich erhalte die Fehlermeldung jedes Mal, wenn ich die Registerkarte länger als ein paar Minuten verlasse. Wenn ich die Entwicklungstools in Firefox lasse, sehe ich:

GET http://x.x.x.x:3000/api/datasources/proxy/1/query?db=(Redacted info)
{"message":"Unauthorized"}

Jede Art von Aktualisierung löscht die Fehler.

Ich bin auf das gleiche Problem gestoßen. Für mich hing es damit zusammen, dass "session_provider=memcahched" fehlte.

Weitere Konfigurationsoptionen finden Sie unter http://docs.grafana.org/installation/configuration/#provider -config

Das gleiche Problem ist auch hier. Mein Docker-Setup ist:

FROM grafana/grafana:5.1.0
FROM influxdb:1.5.3

Schließe dies, da es mit Setup/Konfiguration zu tun zu haben scheint

@torkelo Gibt es eine offensichtliche Lösung für dieses Problem? Oder einen Hinweis, um herauszufinden, was die mögliche Lösung sein könnte?

Stellen Sie sicher, dass die Sitzungseinrichtung für die HA-Einrichtung funktioniert oder die Sticky-Sitzungen im Load Balancer funktionieren

Load Balancer nutze ich allerdings nicht.

Gleiches Problem hier ohne mehrere Replikate
Habe gerade zufällig einen 401-Fehler auf /api/login/ping erhalten

Gleiches Problem hier (seit Jahren vor den 5.0 Tagen), SQLite auf ext4, einzelnes Replikat auf Kubernetes. Neuestes offizielles Docker-Image.

Anfragen schlagen nach dem Zufallsprinzip fehl, wenn Grafana automatisch aktualisiert wird, schließlich hören alle Widgets auf, irgendetwas zu melden. Relevante Protokolle:

t=2018-07-31T01:38:04+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="User not found"
t=2018-07-31T01:38:04+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="User not found"
t=2018-07-31T01:38:04+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="User not found"
t=2018-07-31T01:38:04+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/api/datasources/proxy/4/query status=401 remote_addr=192.168.1.72 time_ms=28 size=26 referer="REDACTED"

Ich werde versuchen, etwas zu debuggen, ich bin mir zu 99% sicher, dass dies ein Fehler in Grafana (oder einer seiner Bibliotheken) ist.

/cc @torkelo

Ich bin mir zu 95 % sicher, dass dies eine fehlende Wiederholung ist, falls die SQLite-Tabelle gesperrt ist. Ich werde einen Fix lokal bereitstellen und PR, wenn es funktioniert.

EDIT: Kratzen Sie das, das würde einen anderen Codepfad benötigen.

Hier ein Beispielfehler von mir.

grafana_1   | t=2018-07-31T09:23:06+0100 lvl=eror msg="Failed to get user with id" logger=context userId=1 error="User not found"
grafana_1   | t=2018-07-31T09:23:06+0100 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/api/login/ping status=401 remote_addr=192.168.33.1 time_ms=35 size=26 referer="http://192.168.33.10:3000/d/ZJ65a0Dmz/yowyow?refresh=5s&orgId=1&from=now-30d&to=now"
grafana_1   | t=2018-07-31T09:23:06+0100 lvl=info msg="Database table locked, sleeping then retrying" logger=sqlstore retry=0
grafana_1   | t=2018-07-31T09:23:06+0100 lvl=info msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=GET path=/api/login/ping status=401 remote_addr=192.168.33.1 time_ms=24 size=26 referer="http://192.168.33.10:3000/d/ZJ65a0Dmz/yowyow?refresh=5s&orgId=1&from=now-30d&to=now"

Ich lasse es über Nacht laufen um noch ein paar Ausfälle zu generieren und bin mir sicher das es nichts mit den Sessions ist. Es befindet sich in der ORM-Schicht, insbesondere in user.go GetSignedInUser() wo diese Schicht manchmal keine korrekte Antwort zurückgibt. Ich habe alle Anfragen auf einem fetten 50-Diagramm-Dashboard in 1 Minute über eine Nacht aufgezeichnet und ein sehr zufälliges Muster mit geclusterten Fehlern gesehen, alles deutet auf ein Parallelitäts- / Rennproblem hin. Ich führe derzeit einen Patch aus, der Fehler vom Zeilenleser ordnungsgemäß weiterleitet (der primäre Kandidat für dieses Problem). Ich werde sehen, ob ich eine andere Fehlermeldung erhalte.

Das war schnell. Mit meinem Fehlerausbreitungspatch habe ich die Ursache gefunden:

t=2018-07-31T17:26:46+0000 lvl=eror msg="Failed to get user with id" logger=context userId=2 error="database table is locked"

Wiederholungen werden irgendwo im SQLite-Ausführungstreiber falsch implementiert.

Ich habe es mir genauer angesehen und es gibt mehrere Probleme hier:

1. go-sqlite ist nicht als goroutine-sicher bekannt (was diese ganze Sache mit einer zentralen xorm-verwalteten Verbindung möglicherweise zu einer schlechten Idee macht).
2. SQLite unterstützt keine gleichzeitigen Abfragen für eine einzelne "Verbindung". Wir müssten xorm dazu bringen, mehrere Verbindungen zu SQLite zu öffnen. Andernfalls könnten Deadlocks oder diese Sperrfehler auftreten, da SQLite nicht versucht, Sperren aufzulösen, wenn sie von derselben Verbindung stammen.

Ich habe gesehen, wie Leute mehrere Dinge getan haben, um diese SQLite-Probleme zu vermeiden, einschließlich des Einschließens des gesamten SQLite-Zugriffs in einen einzigen Mutex und des Öffnens einer neuen SQLite-Instanz pro Anfrage. Am einfachsten ist es wahrscheinlich, go-sqlite3 zu hacken, um einen Mutex pro "Verbindung" zu enthalten und einfach den gesamten Zugriff darauf zu serialisieren (BEARBEITEN: Habe gerade festgestellt, dass dies wahrscheinlich nicht funktioniert, da die Sperren beim Lesen von einem Cursor angezeigt werden, was Sie können sich nicht sperren, ohne Deadlocks zu riskieren). So würde es ein C-Programm tun (wofür SQLite gemacht wurde). Es mag langsam sein, aber Leute, die die Leistung benötigen, sollten sowieso zu PostgreSQL wechseln.

Vielen Dank, @lorenz , für die

Für andere, die diese Problemumgehung ausprobieren möchten, habe ich pgloader mit den Standardeinstellungen verwendet und während der Migration keine Sitzungs- oder Benutzerdaten gelöscht.

Das Problem liegt definitiv nur beim SQLite-Backend, da die "größeren" Datenbanken alle MVCC haben, die dieses Problem lösen. Ich persönlich habe auch meine Produktionsinstanzen nach PostgreSQL verschoben. Das Problem bleibt immer noch, ob und wie wir dies für das SQLite-Backend lösen sollten. Ich sehe keine einfache Möglichkeit, dies zu tun, da Grafana (da es in Go geschrieben ist) stark von der Parallelität Gebrauch macht, was in SQLite eine besondere Sorgfalt erfordert, die über das hinausgeht, was Xorm derzeit bietet.

Es gibt bereits eine Reihe von Sperren und Wiederholungen im Code, die versuchen, dies zu umgehen, aber sie sind unzureichend. Da ich die Fehlerbehandlung für den Zeilenleser behoben habe (der derzeit Sperrfehler stillschweigend schluckt und somit unvorhersehbares Verhalten erzeugt, werde ich den Fix bald veröffentlichen) habe ich gesehen, dass die Sperrfehler an viel mehr Stellen als nur den Daten auftauchen Quell-Proxy, es ist nur der Endpunkt, der am häufigsten getroffen wird, und aufgrund der Wahrscheinlichkeit des Fehlers ist er für den Benutzer am sichtbarsten. Soweit ich sehen kann, erfordern alle Korrekturen das Hacken von Xorm oder go-sqlite3, was im Allgemeinen nicht wünschenswert ist.

Danke für die tolle Analyse @lorenz! Glauben Sie, dass die Rückgabe von 500 in diesem Fall eine vernünftige kurzfristige Problemumgehung wäre? Wie es jetzt ist, zwingt 401 den Browser (zumindest Chrome), das Passwort zu vergessen und fordert meine Benutzer auf, es erneut einzugeben. Manchmal muss es mehrmals eingegeben werden, bis das Passwort endgültig akzeptiert wird.

Meine aktuelle Problemumgehung besteht darin, die Datenbank von tmpfs aus auszuführen. Es verringert die Häufigkeit dieses Problems, aber es tritt immer noch von Zeit zu Zeit auf.

@kichik Wenn ich meine Änderung an der Fehlerbehandlung gepostet habe, könnten wir darüber nachdenken, HTTP 500 (oder 503) zurückzugeben. Aber die einzige gute Problemumgehung, die ich sehen kann, ist die Verwendung einer tatsächlichen MVCC-fähigen Datenbank wie PostgreSQL oder MySQL, die das Problem überhaupt nicht aufweisen. Wie ich in meinem vorherigen Kommentar erläutert habe, geht dieses Problem über nur Datenanfragen hinaus. Daher wird das Zurückgeben eines anderen Fehlercodes als HTTP 401 nur für diese das Problem nicht vollständig beheben.

Ich habe gerade meine Fehlerberichtsänderungen in Nr. 13007 PRed, dies sollte den Leuten helfen zu sehen, ob sie von dem Sperrproblem betroffen sind oder ob es nichts damit zu tun hat.

@torkelo Könnten wir dies wieder öffnen, da es sich eindeutig um ein Problem mit Grafana handelt?

Bei mir passiert es auf jeden Fall auf einer einzigen Registerkarte (und einem einzelnen Benutzer).
Auch mit sqlite3. Interessanterweise hatte ich dieses Problem vorher nicht. Nachdem ich nun einige schwere (abfrageweise) Panels hinzugefügt habe, erhalte ich häufig diesen Fehler, normalerweise nur für eines meiner schweren Panels.

Bestätigen, dass der Wechsel zu einer Nicht-Sqlite3-DB das Problem für mich behebt. Ich habe auch mit einem einzelnen Benutzer und einer einzigen Registerkarte gearbeitet, wobei sich schwerere / belebtere Bedienfelder ebenfalls schlechter verhalten.

Update: Sitzungen müssen umgeschaltet werden, damit sie in der separaten Datenbank gespeichert werden, um die vollständige Korrektur zu ermöglichen.

Ich verwende mysqldb mit dem gleichen Problem. Grafana Version 5.2.3 , Stickiness in Lb-Level aktiviert, aber das Problem besteht immer noch.

Erlebe dies auch, indem ich sqlite als Daten-Backend verwende, aber als Sitzungsspeicher auf grafana 5.2.3 redisiere
Ungefähr 150 Organisationen konfiguriert. Bei der internen Aktualisierung wird eine nicht autorisierte Warnung angezeigt, bei der manuellen Aktualisierung jedoch normalerweise nicht mehr.

Holen Sie dies von Zeit zu Zeit in die Protokolle:

t=2018-09-22T18:10:17+0000 lvl=info msg="Database table locked, sleeping then retrying" logger=sqlstore retry=0
t=2018-09-22T18:10:17+0000 lvl=info msg="Database table locked, sleeping then retrying" logger=sqlstore retry=0
t=2018-09-22T18:10:17+0000 lvl=info msg="Database table locked, sleeping then retrying" logger=sqlstore retry=0
t=2018-09-22T18:10:17+0000 lvl=info msg="Database table locked, sleeping then retrying" logger=sqlstore retry=0
t=2018-09-22T18:10:17+0000 lvl=info msg="Database table locked, sleeping then retrying" logger=sqlstore retry=1
t=2018-09-22T18:10:17+0000 lvl=info msg="Database table locked, sleeping then retrying" logger=sqlstore retry=1

Dieses Problem kann durch den Verlust der MySQL-Verbindung verursacht werden. Wenn ich den Wert von max_idle_conn und conn_max_lifetime verringere, passiert dies nicht mehr. Ich hoffe das hilft

@vishksaj @xiaochai Dies ist sehr wahrscheinlich ein anderes Problem, könnten Sie ein neues eröffnen?

https://github.com/oleh-ozimok/grafana/commit/b19e416549553f582dccfbcaa3f4d3f1a742a462 - mein Problem gelöst ( Bild mit Hotfix docker pull olegozimok/grafana:5.3.2 )

Grafana 5.3.2. HA-Konfiguration: 2 Grafana-Instanzen, MySQL-Haupt-DB, 2 Instanzen von Memcached für Sitzungen, Grafana-Verzeichnis und DB werden auf NFS gespeichert. Immer die gleichen "unerlaubten" Fehler, unvorhersehbar. Das gleiche war, als DB SQLite auf NFS war.

Gleiches Problem wie @dev-e, aber einfacheres Setup. Grafana 5.3.2, Einzelinstanz, InfluxDB auf demselben Host, Einzelorganisation, Einzelbenutzer. Die Meldung erscheint zufällig und verschwindet bei der nächsten Seitenaktualisierung.

Ich habe das gleiche Problem. Zufällig erhaltene nicht autorisierte Fehler.
Das Upgrade auf grafana 5.3.4 hat es irgendwie besser gemacht, aber immer noch ziemlich viele Fehler.

In Grafana-Protokollen:
t=2018-11-19T09:55:07+0200 lvl=eror msg="Fehler beim Abrufen des Benutzers mit ID" logger=context userId=1 error="Benutzer nicht gefunden"
t=2018-11-19T09:55:07+0200 lvl=eror msg="Fehler beim Abrufen des Benutzers mit ID" logger=context userId=1 error="Benutzer nicht gefunden"
t=2018-11-19T09:55:07+0200 lvl=eror msg="Fehler beim Abrufen des Benutzers mit ID" logger=context userId=1 error="Benutzer nicht gefunden"

Out-of-the-Box-Setup:
grafana/jetzt 5.3.4 amd64
influxdb/jetzt 1.6.0-1 amd64

Selbes Problem hier:

t=2018-12-03T09:28:21+0000 lvl=eror msg="Failed to update last_seen_at" logger=context userId=12 orgId=1 uname=ht error="database table is locked"
t=2018-12-03T10:02:03+0000 lvl=eror msg="Failed to get user with id" logger=context userId=12 error="User not found"
t=2018-12-03T10:02:03+0000 lvl=eror msg="Failed to get user with id" logger=context userId=12 error="User not found"
t=2018-12-03T10:02:03+0000 lvl=eror msg="Failed to get user with id" logger=context userId=12 error="User not found"
t=2018-12-03T10:02:03+0000 lvl=eror msg="Failed to get user with id" logger=context userId=12 error="User not found"
t=2018-12-03T10:46:54+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:46:54+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:46:54+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:46:54+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:46:54+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:46:54+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:46:54+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:46:54+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
2018/12/03 10:51:54 http: proxy error: unexpected EOF
2018/12/03 10:51:54 http: proxy error: unexpected EOF
2018/12/03 10:51:54 http: proxy error: unexpected EOF
t=2018-12-03T10:51:55+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:51:55+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:51:55+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:51:55+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:51:56+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:51:56+0000 lvl=eror msg="Failed to get user with id" logger=context userId=3 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"
t=2018-12-03T10:52:25+0000 lvl=eror msg="Failed to get user with id" logger=context userId=17 error="User not found"

Single Grafana 5.3.4, Speicher ist das Amazon EFS-Dateisystem (NFS-Mount)
Sitzung ist auf Datei gesetzt, Datenspeicherung ist sqlite ( /var/lib/grafana/grafana.db )
Grafana sitzt hinter einem HTTPS-terminierenden LB

Ich habe eine PR erstellt, die den Vorschlag von @oleh-ozimok implementiert. Probieren Sie es gerne aus. Ich werde es noch einmal ausprobieren, wenn ich aus dem Urlaub zu Hause bin, damit ich eine lang laufende Instanz haben kann :)

@oleh-ozimok Wenn Sie eine PR erstellen möchten, bin ich mehr als glücklich, diese anstelle meiner zusammenzuführen, um Ihnen die Anerkennung zu geben.

Übrigens tolle Arbeit

Dies wirkt sich auch auf unseren Einsatz aus. Wir erhalten ständig 401 nicht autorisierte Fehler, wenn zwei Amazon Auora MySQL-Datenbanken im HA/Multi Master-Modus ausgeführt werden. Ich habe überprüft, dass Sitzungen in beiden Datenbanken sind. Aber trotzdem habe ich alle Instanzen auf dieselbe Datenbank verwiesen, um zu sehen, ob das Problem dadurch behoben würde und dies nicht der Fall war. Es stimmt definitiv etwas nicht mit der korrekten Authentifizierung von Sitzungen. Dies geht mit unserem Oauth-Setup sogar noch weiter. Es kann vorkommen, dass sich der Benutzer mit dem konfigurierten Oauth-Anbieter anmeldet und die Anmeldung nach der Umleitung fehlschlägt. Wenn sie sich 2-3 Mal einloggen, funktioniert es.

Das ist sehr seltsam, vielleicht ist einer der Server anders konfiguriert?

Irgendwelche Log-Details?

Wir beseitigen die Notwendigkeit des Sitzungsspeichers und schreiben die Verwaltung von Anmeldesitzungen in v6 vollständig neu, sodass das Problem hoffentlich gelöst wird.

@buroa kannst du 6.0-

@bergquist hat mein Setup am 2019-02-01T09:58:20+0200 aktualisiert, dieser Fehler ist vorerst nicht aufgetreten.

@buroa kannst du 6.0-

Ich verwende den neuesten Build: https://github.com/buroa/grafana/tree/us-iso-regions

Hat das die nötige Änderung?

@buroa ja, aber ich würde Ihnen trotzdem vorschlagen, den neuesten Master zusammenzuführen, da wir seit 6.0-Beta1 einige Änderungen vorgenommen haben.

Heute ist ein Fehler aufgetreten
t=2019-02-08T10:05:58+0200 lvl=info msg="Fehler beim Suchen des Benutzers basierend auf dem Cookie" logger=context error="Benutzerauthentifizierungstoken nicht gefunden"
Browser-Tab wurde nicht geschlossen, nur jede Stunde automatisch aktualisiert, aber der PC war gesperrt.

@QuantumProjects würde es Ihnen etwas

@marefr Ok

@marefr Ich

• Gateway-Server mit traefik als Reverse-Proxy, der auf einen lokalen Server zeigt, der grafana hostet
• lokaler Server mit Grafana v5.4.3
• datasource ist eine influxdb v1.7.8 auf demselben lokalen Server
• Wie finde ich den angefragten Authentifizierungstyp heraus? Ich melde mich einfach als Admin-Benutzer an

Hinweis: Jeder Dienst ist ein Docker-Container, traefik x64, grafana und influxdb arm32v7

Dies geschieht auch in Grafana 6.0.0 (Commit: 34a9a62, Branch: HEAD). Die SQLite-Datenbank wird nicht verwendet, Grafana arbeitet hinter dem Nginx-Reverse-Proxy. Die LDAP-Authentifizierung ist konfiguriert. Auf dieser VM wird eine einzelne Grafana-Instanz ausgeführt.

Log-Eintrag zum Fehlerzeitpunkt:

t=2019-03-06T13:39:24+0100 lvl=eror msg="failed to look up user based on cookie" logger=context error="database is locked"

Nachdem ich nur einen Datenpunkt hinzugefügt hatte, wurden diese Fehler nicht mehr angezeigt, nachdem ich meine Datenbank von sqlite nach postgres verschoben hatte. Zuvor waren sie häufig genug aufgetreten, um die Verwendung des Systems ziemlich unangenehm zu machen. Ausführen eines einzelnen 5.4.3-Servers mit Google Oauth.

Passiert mir auf 5.4.3 in Verbindung mit Postgres, ziemlich zufällig, aber nur, wenn ich es automatisch aktualisieren lasse. Das Setup erfolgt in einem lokalen Netzwerk, in dem sich die Datenbank auf derselben Box wie Grafana befindet.

Ich erhalte eine Reihe dieser Arten von Fehlern im Syslog, wenn "Unauthorized" angezeigt wird:

...
...
grafana-server[12619]: t=2019-03-06T22:42:02+0100 lvl=info msg="Database table locked, sleeping then retrying" logger=sqlstore retry=0
grafana-server[12619]: t=2019-03-06T22:42:03+0100 lvl=eror msg="Failed to get user with id" logger=context userId=1 error="User not found"
...
grafana-server[12619]: t=2019-03-06T22:42:03+0100 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=POST path=/api/tsdb/query status=401 remote_addr=192.168.0.2 time_ms=17 size=26 referer="http://192.168.0.1:3000/d/.....
...

Es gibt einige Variationen der Anmeldung bei userId=1 oder 0 und bei retry=1 oder 0

Hallo,

Ich hatte heute das gleiche Problem. Wir haben Grafana 6.0.1 auf einem einfachen Debian-Stretch ein paar Tage zuvor aktualisiert. Grafana verbindet sich mit einem Load Balancer (proxysql) mit MariaDB 10.2 (Galera Cluster) als Backend (Sync-Modus mit drei Nodes).
Als Autorisierung verwenden wir LDAP (Windows AD).

Protokollmeldung:

lvl=eror msg="failed to look up user based on cookie" logger=context error="invalid connection"

Das einzige was funktioniert hat, war die direkte IP zu verwenden und nicht den Load Balancer.

Das einzige was funktioniert hat, war die direkte IP zu verwenden und nicht den Load Balancer.

Klingt jedoch nicht nach dem gleichen Problem, da unseres zeitweise auftritt - vielleicht schlägt eines der Panels in jedem Dutzend Aktualisierungen mit dem Fehler fehl, funktioniert aber im Allgemeinen

Das gleiche passiert mir am 6.0.2.

Aus dem Protokoll:
t=2019-03-23T12:04:22+0000 lvl=eror msg="failed to look up user based on cookie" logger=context error="database is locked"
und
t=2019-03-23T19:05:45+0000 lvl=eror msg="Failed to update last_seen_at" logger=context userId=1 orgId=1 uname=<username> error="database is locked"

Regelmäßige Docker-Installation mit Traefik für Reverse-Proxying.

Bei mir passiert das Gleiche
Version 6.02
"Fehler beim Suchen des Benutzers basierend auf dem Cookie" logger=context error="Datenbank ist gesperrt"

Wenn Sie mit Sqlite (Standard) "Datenbank gesperrt" bekommen, ist es wahrscheinlich ein guter Zeitpunkt, zu mysql/postgres zu migrieren, da sie mehr Transaktionen/s verarbeiten können

@bergquist Ich denke, das ist in der Tat die Lösung. Gerade zu MariaDB migriert und ich werde nicht mehr aus Grafana geworfen. Heftzwecke!

@bergquist Ich denke, das ist in der Tat die Lösung. Gerade zu MariaDB migriert und ich werde nicht mehr aus Grafana geworfen. Heftzwecke!

Zur Verdeutlichung könnte dies eine Lösung für "Datenbank ist gesperrt" sein, nicht "Datenbanktabelle gesperrt" - ich bin auf PostgreSQL und stehe vor der "Tabellensperre".

Für mich nach einem Raspbian-Upgrade gelöst, das mich zu Postgres 9.6 (von 9.4) führte. Grafana immer noch auf 5.4.3

Für mich nach einem Raspbian-Upgrade gelöst, das mich zu Postgres 9.6 (von 9.4) führte. Grafana immer noch auf 5.4.3

Vergiss was ich gesagt habe... es ist wieder da. Weniger oft würde ich sagen ... aber es passiert immer noch.

@ggggh irgendwelche Lösungen? Bei mir passierte es aus heiterem Himmel!

@ggggh irgendwelche Lösungen? Bei mir passierte es aus heiterem Himmel!

Nichts...! Es wurde mit dem Postgres-Versions-Upgrade gelöscht und scheint jeden Tag öfter zurückzukommen

@ggggh Danke!
Ich bin auf Postgres umgestiegen, aber das hilft auch nicht :(

Ich habe die gleichen Probleme mit Grafana 6.2.1 und Postgress 11, aber dies geschieht nur bei Dashboards, die ich aus JSON lade und dann versuche, darauf zuzugreifen.

Irgendwelche Updates dazu?

OK, ich habe das Problem in meinem Fall gefunden. Mein PG hatte eine begrenzte Anzahl von Verbindungen und in grafana wurde max_open_conn nicht gesetzt. Nachdem ich diese Option eingestellt habe, funktioniert es OK.

Dasselbe passiert für mich auf Grafana 6.1.6 und der im Paket enthaltenen SQLite DB. Dieses Problem unterbricht unsere internen Entwicklungsbemühungen zur Anpassung von Grafana. Das Ändern von max_open_conn funktioniert nicht (obwohl ich es nicht erwartet hatte, da es ein Fix für Postgres war).

Die Hauptursache dafür scheint zu sein, dass Grafana versucht, eine Verbindung zu den . herzustellen
zugrunde liegende DB bei der Authentifizierung, tut dies jedoch nicht. Mit SQLite ist das
wird oft und bei einer geringen Anzahl gleichzeitiger Nutzung passieren, da SQLite-Sperren
so aggressiv. In den meisten Fällen Migration zu einem echten RDBMS (ich mag Postgres)
wird das Problem lösen. Es ist möglich, dass es wieder auftaucht, wenn Sie auf einen stoßen
Verbindungslimit (oder ähnliches) Problem, aber das ist mehr als ein DB-Problem
Grafana besorgt. Wenn Sie Grafana für etwas anderes als eine Demo verwenden,
Sie sollten es mit einer echten DB unterstützen. Wenn diese DB richtig konfiguriert ist für
Ihre Verwendung, die dieses Problem lösen sollte.

Am Mo, 10.06.2019 um 11:20 syardumian-chc [email protected]
schrieb:

Dasselbe passiert für mich auf Grafana 6.1.6 und der im Paket enthaltenen SQLite DB. Dies
Problem unterbricht unsere internen Entwicklungsbemühungen zur Anpassung von Grafana. Ändern
max_open_conn funktioniert nicht (obwohl ich es nicht erwartet habe, da es ein
Fix für Postgres).

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/10727?email_source=notifications&email_token=AAAK6YSUDLXPF2E4436CEOTPZ2EMFA5CNFSM4EO23EH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTLXPF3-WW2GODXK197
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAK6YQLR3FSCNEQR7SNEKLPZ2EMFANCNFSM4EO23EHQ
.

Ich habe das Verbindungslimit und die maximalen Leerlaufverbindungen erhöht, stoße aber immer noch zufällig auf dieses Problem. Darüber hinaus scheinen Dashboards, die seit einiger Zeit geöffnet sind, immer langsamer zu werden, wobei das Lade-Gif auf jedem Panel sichtbar ist und langsam nacheinander verschwindet, wenn jedes Panel geladen wird. Es ist in Ordnung, wenn ich das Browserfenster schließe und ein neues öffne. Ich schätze, mein Dashboard ist komplexer geworden, aber das erklärt nicht, warum ein neues Laden der Seite "es behebt".

Ich bekomme auch einen zufälligen Fehler. Weiß wirklich nicht woran es liegt. Die Verwendung der IP-Adresse scheint in Ordnung zu sein, aber mit dem Kubeneters-Ingress wird die "Anmerkungsabfrage fehlgeschlagen" zufällig angezeigt.

FWIW, ich habe kürzlich meinen Ingress-Loadbalancer auf Fabio (von Traefik) umgestellt und Grafana (Docker-Image, keine zusätzlichen Datenbank-Backends) auf v6.4.2 aktualisiert, und die 401 nicht autorisierten Fehler scheinen bei der automatischen Aktualisierung verschwunden zu sein (Intervall auf 10 . eingestellt). Sekunden, läuft den ganzen Tag). Es ist unwahrscheinlich, dass der Wechsel zu Fabio das Problem behoben hat. Ich vermute, es war die neuere Version von Grafana, die geholfen hat, aber ich bin mir nicht 100% sicher.

Schließe dies, da in letzter Zeit keine neuen Berichte vorliegen. Wenn Sie denken, dass es immer noch ein Problem gibt, öffnen Sie bitte ein neues Problem

Ich habe vor kurzem Grafana auf meinem Kubernetes-Cluster installiert und bin auf ein ähnliches Problem gestoßen.
Ich verwende Docker-Image grafana/ grafana: 6.4.3

Als ich meine Pod-Logs überprüfte, fand ich diesen interessanten kleinen Leckerbissen:

t=2019-11-01T15:18:33+0000 lvl=info msg="Successful Login" logger=http.server User=--snip--
t=2019-11-01T15:19:09+0000 lvl=eror msg="Failed to look up user based on cookie" logger=context error="dial tcp: lookup postgres.databases.svc.cluster.local: no such host"
t=2019-11-01T15:19:09+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/api/datasources/proxy/1/query status=401 remote_addr=--snip-- time_ms=11 size=26 referer="https://--snip--/d/TuobtjoZz/--snip--?orgId=1&refresh=5s&from=now-12h&to=now"

DNS-Probleme sind in meinem Cluster noch nicht aufgetreten, aber ich habe etwas gegoogelt und dieses spezielle Problem gefunden: https://github.com/kubernetes/kubernetes/issues/30215

Wäre es für Grafana möglich, sowohl alpine als auch nicht-alpine Bilder zu versenden, wie es viele Docker-Bilder tun? Scheint, als würde das das Problem lösen.
Wenn ich etwas tun kann, um dies zu testen oder beim Debuggen zu helfen, lassen Sie es mich wissen. Ich werde die angeforderten Informationen bereitstellen.

Nach dem Downgrade auf 6.3.6 (was nicht alpinbasiert ist) verschwand das Problem auf meiner Seite vollständig.

Ich hatte das gleiche Problem, zwei separate Grafana (Container) öffnen sich im selben Browser
Wenn Sie sich beim zweiten anmelden, bittet mich der erste, mich erneut anzumelden, melden Sie sich beim ersten an, der zweite bittet mich, mich erneut anzumelden
kann nicht beide Login behalten
Die Lösung, die ich gefunden habe, besteht darin, eine der Grafana-Datei default.ini zu ändern
login_cookie_name = grafana_session
zu
login_cookie_name = grafana_session_1
Starten Sie den Container und den Browser neu, jetzt funktioniert es einwandfrei
Im Moment halte ich die Datei außerhalb des Containers
Sie müssen diesen Parameter beim Erstellen des Containers festlegen

@ikkerens bitte versuche dann das Ubuntu-basierte Image 6.6.2-ununtu

@n0-bs Es tut mir leid, aber wenn Sie mehrere Instanzen von Grafana ausführen, wird empfohlen, MySQL oder Postgres als Datenbank zu verwenden.

Entschuldigung, aber wie , die Verwendung von MySQL oder Postgres als Datenbank., den Cookie-Konflikt löst, wenn ich diese beiden verschiedenen Grafana-Instanzen im selben Browser öffne, spreche ich nicht von HA-Fall
Ich habe zwei verschiedene Grafana-Instanzen (Container) auf demselben Server

Ich sehe das immer noch mit 6.7.2. Ich habe von 6.5 auf 6.6 aktualisiert, dann 6.7. Mit Docker mit PostgreSQL versucht 6.7.2 Image dann 6.7.2-ubuntu.

Dies ist der Fehler, den ich in den Protokollen erhalte:
lvl=eror msg="Failed to look up user based on cookie" logger=context error="pq: remaining connection slots are reserved for non-replication superuser connections"

Behoben (zumindest vorerst) durch Neustart von postgres.

Ich verwende die neueste Version von Grafana und sehe immer noch das nicht autorisierte Problem, wenn ich darauf zugreife. Ich verwende Grafana in Kubernetes. Ich habe es in 3 verschiedenen Pods in 3 verschiedenen Knoten bereitgestellt. Ich verwende die native Datenbank davon. Irgendwelche Vorschläge, um das Problem zu beheben?

@emzfuu Wenn Sie mehrere Instanzen ausführen, müssen Sie alle auf dieselbe Datenbank verweisen. mysql/postgres

@bergquist gibt es eine andere Möglichkeit, das Problem zu beheben?

Um meine obige Frage auszuarbeiten, verwende ich 3 verschiedene Grafana (Standalone), auf die über einen einzelnen Load Balancer zugegriffen wird. Die 3 Grafana hat ihre eigene DB (sqlite3). Jedes Mal, wenn ich darauf zugreife, erhalte ich die Fehlermeldung "Unauthorize".

Ich habe das gleiche Problem, benutze nfs.