Grafana: Non autorisé

Pourrais-tu donner plus de détails :

• S'agit-il de deux instances distinctes ?
• Quelle action déclenche l'erreur non autorisée ?
• Êtes-vous en train de vous déconnecter ou certaines actions ne fonctionnent-elles pas ?

Sont-ils installés sur différents ips/noms de domaine ? si le nom de domaine est le même et seulement différent par port, vous devez avoir des cookies de session uniques et mémoriser les cookies

-Ce sont des instances distinctes
-Je ne sais pas quelle action déclenche le non autorisé, cela se produit simplement lorsque je regarde des graphiques ou lorsque j'accède à grafana
-Parfois je suis déconnecté
-Domaines séparés

Je rencontre cela sur Grafana 4.6.x avec oauth via Github. C'est apparemment aléatoire lorsque je change d'onglet et que je reviens à Grafana. Un rafraîchissement "corrigera" le problème, mais il revient parfois plus tard.

Je vois le même problème sur Grafana v4.6.2 (commit: 8db5f08), tout fonctionne comme prévu, et tout à coup, je reçois un avertissement non autorisé (et certains graphiques sont vides, mais certains s'affichent normalement).

J'utilise Prometheus comme source de données.

Je pense également que cela se produit principalement lorsque le tableau de bord est actualisé automatiquement, mais se corrige lorsque je l'actualise manuellement.

Problème similaire ici aussi, mais avec une seule instance Grafana avec HTTPS et source de données Postgres.

Lorsque le tableau de bord est ouvert, tous les graphiques sont bons. Mais parfois après, certains des graphiques commencent à afficher des erreurs "non autorisées" lors de l'actualisation automatique, mais au cours de la prochaine (ou des quelques prochaines) actualisations automatiques, ils reviennent à l'état normal, mais se transforment ensuite en état "non autorisé" parfois plus tard, en répétant ce comportement aléatoire à chaque actualisation automatique.

Je ne sais pas si c'est lié, mais j'ai trouvé les messages de journal suivants.

lvl=eror msg="Impossible d'obtenir l'utilisateur avec l'identifiant" logger=context userId=1 error="Utilisateur non trouvé"

La version Grafana est la suivante :

lvl=info msg="Démarrage de Grafana" logger=version du serveur=5.0.4 commit=7dc36ae compilé=2018-03-28T20:52:41+0900

J'utilise Firefox et je laisse généralement le tableau de bord ouvert et intact pendant plusieurs jours, la machine cliente (pas la machine serveur hébergeant Grafana) passant de temps en temps en mode veille.

Cela ne m'arrive plus avec grafana 5.x

J'ai toujours exactement le même problème avec Grafana 5.0.4, les mêmes messages d'utilisateur non trouvés dans le journal (c'est avec un simple utilisateur local de Grafana).

J'ai aussi ce problème. Et la question est très intéressante. Cela peut arriver lorsque j'ouvre deux pages grafana de version différente dans le même navigateur et que j'essaie d'effectuer certaines opérations.

J'ai une ancienne version de grafana (v4.3.2 (commit: ed4d170)) et j'ai bien fonctionné sur grafana.mydomain.com pendant longtemps. Aujourd'hui, je souhaite mettre à jour mon grafana vers la version 5.0.4. Au lieu de mettre à niveau en place. Je voulais installer le nouveau Grafana sur la même machine, copier le tableau de bord que je veux, puis démonter l'ancien.

Alors ce que j'ai fait :

1. docker lance grafana5 sur la même machine que l'ancienne avec la carte des ports vers 3005
2. ouvert l'ancien grafana4 sur grafana.mydomain.com dans Safari
   Et ça marche bien
3. visitez Grafana5 sur grafana.mydomain.com:3005 dans Safari
   Alors maintenant, j'ai deux onglets ouverts de Grafana4 et Grafana5 sur mon écran
4. connectez-vous Grafana5, en essayant de faire quelques opérations .... comme [créer un tableau de bord]
   Maintenant, les deux pages Grafana se sont écrasées

Les deux Grafana obtiendront des erreurs Unauthorized et n'obtiendront aucun point de données

Mise à jour : j'ai modifié mon étape 3 en visitant Grafana5 avec [ip]:3005. Cela fonctionne bien pour l'instant.
Il semble qu'il puisse y avoir des conflits lors de l'ouverture de deux pages Grafana dans le même domaine.

@kehao95 votre cas d'utilisation dans le même navigateur ouvrant deux instances Grafana sur le même domaine mais avec des ports différents n'est pas pris en charge. (Torkel a mentionné cela ci-dessus).

@ajardan vos instances sont-elles sur le même domaine ou sur des domaines différents ?

@daniellee Je

Je reçois également ces étranges problèmes "non autorisés" de temps en temps. L'actualisation de la page « résout » le problème. J'exécute Grafana v5.1.0 (844bdc53a) à partir de l'image officielle de Docker. La source de données est InfluxDb. J'ai créé 2 organisations à Grafana, mais n'en utilise qu'une en fait. Utilisateur unique « admin ».

Je viens de recevoir cette erreur une fois de plus avec un nouveau message d'erreur " Échec de la requête d'annotation. Non autorisé "

Mon grafana sur win10 x64 fonctionnait parfaitement bien pendant quelques jours jusqu'à ce que je reçoive un avertissement "Non autorisé". Le comportement est le même que celui décrit par @dogada et

Même problème. Une instance de grafana 5.1 dans docker. serment de Google pour l'autorisation.

Les mises à jour?

Même comportement. Exécutant actuellement la version 5.0.3 dans docker, authentification interne, utilisateur administrateur unique, proxy via nginx, la source de données est influxdb. Le tableau de bord se corrige lors de l'actualisation automatique des données. Cela se produit principalement lorsque l'onglet est long en arrière-plan

Même problème rencontré lorsque deux onglets sont ouverts sur la même instance.

La mise à jour vers la dernière image Docker v5.1.2 (commit: c3c690e21) ne résout pas le problème

J'ai ce que je pense être le même problème avec Grafana 5.0.0 dans Docker en utilisant GitHub OAuth. Je l'ai vu sur des tableaux de bord avec InfluxDB, CloudWatch et un mélange des deux sources de données. (Une instance, un port, HTTPS, derrière un ELB.)

Comme d'autres dans ce fil, je semble le voir déclenché par une actualisation automatique, et il disparaît après un rechargement de page. Parfois, je vois le message d'erreur de base "Non autorisé" (avec des échecs de chargement du graphique) et parfois (plus rarement) le message "Échec de la requête d'annotation. Non autorisé".

~ Mes soupçons pointent vers quelque chose avec les plugins OAuth ? ~ C'est presque certainement dû au backend de la session, voir ci-dessous.

Pour ajouter plus de détails que j'ai trouvés après avoir creusé un peu plus, je vois de nombreuses erreurs comme celle-ci dans mes journaux :

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

Le seul endroit où je vois une telle erreur est dans cette ligne de code, qui semble liée à la gestion des sessions et des cookies de session ?

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

Je stocke mes sessions en utilisant le backend file par défaut, mais via un partage EFS monté, je me demande s'il s'agit d'une complication potentielle.

J'ai été confronté à ce problème lorsque j'ai essayé d'ouvrir deux Grafana différents (qui s'exécutent dans un port différent) dans le même navigateur.
Je reçois des erreurs non autorisées et parfois je suis déconnecté

Il serait vraiment intéressant de voir quelles requêtes SQL sont exécutées lorsque vous recevez le message de journal Failed to get user with id . Si vous pouvez facilement reproduire cela, ce serait très utile si vous pouviez activer la journalisation des requêtes SQL et rendre compte de vos résultats :

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

Merci

@marefr Il semble que ces erreurs se produisent toujours entourées d'une de ces deux requêtes :

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

Exemples de journaux complets :

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

Merci beaucoup @bjacobel. Tout va bien ici selon moi. Un identifiant utilisateur réel est fourni jusqu'à la requête de la base de données. Vraiment étrange. Commencer à penser qu'il y a un bogue avec notre xorm lib de base de données tiers.

Avez-vous fait quelque chose de spécifique pour générer ces messages de journal ?
Quelle base de données utilisez-vous ? Quel stockage de session ?
Quelle demande est non autorisée, vous pouvez activer la journalisation du routeur pour enregistrer toutes les demandes :

[server]
router_logging = true

Nous avons la même erreur sur 5.1.4 dans Kubernetes.

Salut @marefr , désolé, j'ai oublié de répondre avec les détails supplémentaires demandés.

Avez-vous fait quelque chose de spécifique pour générer ces messages de journal ?

Les requêtes sont générées en chargeant un tableau de bord puis en attendant une actualisation automatique. Cela ne se produit pas à chaque actualisation automatique, et parfois il peut se déclencher avec un clic manuel sur le bouton d'actualisation du tableau de bord (celui intégré à Grafana, pas le bouton d'actualisation du navigateur) mais en général, cela semble se produire plus souvent lorsque l'utilisateur est inactif (en laissant grafana dans un onglet d'arrière-plan, par exemple.)

Quelle base de données utilisez-vous ? Quel stockage de session ?

La base de données est SQLite sur un partage NFS (EFS) monté, et le stockage de session est la valeur par défaut (fichier), bien que j'ai également essayé le stockage basé sur la mémoire et qu'il ait également eu le même problème. Nous avons un hôte grafana derrière un équilibreur de charge, et j'ai activé la persistance de session sur cet équilibreur de charge.

Quelle demande est non autorisée ?

Je n'ai pas activé la journalisation du routeur, car je peux voir la demande qui est non autorisée à partir du navigateur :

[Certaines informations sensibles supprimées]

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

Salut @marefr , désolé, j'ai oublié de répondre avec les détails supplémentaires demandés. ...

@bjacobel, cela n'est probablement pas lié au problème spécifique, mais les développeurs de SQLite recommandent de ne pas exécuter SQLite sur NFS. Plus précisément, le processus Grafana ne doit pas accéder à la base de données via un montage NFS, et il n'est pas recommandé de s'exécuter à partir de n'importe quel système de fichiers en réseau sans une prise en charge solide du verrouillage de fichier.

En passant, nous utilisons SQLite avec le stockage de session comme vous le faites, mais sur un système de fichiers local. Nous n'avons pas connu ce même problème.

Nous avons également modifié la configuration SQLite dans grafana pour utiliser le mode WAL (dont je ferai éventuellement un PR) pour de meilleures performances.

_{Envoyé avec GitHawk}

J'ai le même problème dans ma pile docker Grafana et InfluxDB.
Grafana v5.1.3 (validation : 087143285)
InfluxDB 1.5.3

Grafana utilise le stockage local via des volumes docker avec la base de données sqlite. Les volumes utilisent un SSD local.
Je reçois l'erreur chaque fois que je quitte l'onglet pendant plus de quelques minutes. Si je laisse les outils de développement dans Firefox, je vois :

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

Toute sorte de rafraîchissement efface les erreurs.

Je suis tombé sur le même problème. Pour moi, c'était lié au manque de "session_provider=memcahched"

Vous pouvez vous référer à http://docs.grafana.org/installation/configuration/#provider -config pour plus d'options de configuration

Le même problème est ici aussi. Ma configuration de docker est :

FROM grafana/grafana:5.1.0
FROM influxdb:1.5.3

Fermer ceci car il semble être lié à la configuration/configuration

@torkelo Existe-t-il une solution évidente à ce problème ? Ou un indice pour aider à déterminer quelle pourrait être la solution possible ?

Assurez-vous que la configuration de session fonctionne pour la configuration HA ou que les sessions persistantes dans l'équilibreur de charge fonctionnent

Je n'utilise pas l'équilibreur de charge cependant.

Même problème ici sans plusieurs répliques
Je viens de recevoir une erreur 401 sur /api/login/ping parfois au hasard

Même problème ici (pendant des années, avant les jours 5.0), SQLite sur ext4, réplica unique sur Kubernetes. Dernière image officielle de Docker.

Les requêtes échouent de manière aléatoire lors de l'actualisation automatique de Grafana, finalement tous les widgets cessent de signaler quoi que ce soit. Journaux pertinents :

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"

Je vais essayer de faire du débogage, je suis sûr à 99% qu'il s'agit d'un bug de Grafana (ou de l'une de ses bibliothèques).

/cc @torkelo

Je suis sûr à 95% qu'il s'agit d'une nouvelle tentative manquante au cas où la table SQLite serait verrouillée. Je déploierai un correctif localement et PR si cela fonctionne.

EDIT: Grattez ça, cela prendrait un chemin de code différent.

Voici un exemple d'erreur de ma part.

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"

Je l'ai laissé tourner toute la nuit pour générer encore plus d'échecs et je suis sûr que ce n'est rien avec les sessions. C'est dans la couche ORM, en particulier dans user.go GetSignedInUser() où cette couche ne renvoie parfois pas une réponse correcte. J'ai enregistré toutes les demandes sur un tableau de bord à 50 graphiques gras à 1 minute sur une nuit et j'ai vu un schéma très aléatoire avec des erreurs groupées, tout indique un problème de concurrence / course. J'exécute actuellement un correctif qui propage correctement les erreurs du lecteur de lignes (le principal candidat pour ce problème), je vais voir si j'obtiens un message d'erreur différent.

C'était rapide. Avec mon correctif de propagation d'erreur appliqué, j'ai trouvé la cause première :

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"

Les tentatives sont incorrectement implémentées quelque part dans le pilote d'exécution SQLite.

J'ai regardé un peu plus et il y a plusieurs problèmes ici:

1. go-sqlite n'est pas connu pour être sûr pour goroutine (ce qui fait que tout cela avec une connexion centrale gérée par xorm peut-être une mauvaise idée).
2. SQLite ne prend pas en charge les requêtes simultanées sur une seule "connexion". Nous aurions besoin de xorm pour ouvrir plusieurs connexions à SQLite. Sinon, nous pourrions rencontrer des blocages ou ces erreurs de verrouillage, car SQLite n'essaiera pas de résoudre les verrous s'ils proviennent de la même connexion.

J'ai vu des gens faire plusieurs choses pour éviter ces problèmes SQLite, notamment en encapsulant tous les accès SQLite dans un seul mutex et en ouvrant une nouvelle instance SQLite par requête. La chose la plus simple à faire est probablement de pirater go-sqlite3 pour contenir un mutex par "connexion" et de simplement sérialiser tous les accès à celui-ci (EDIT: Je viens de réaliser que cela ne fonctionnera probablement pas car les verrous apparaissent lors de la lecture à partir d'un curseur, ce qui vous ne pouvez pas verrouiller sans risquer des blocages). C'est ainsi qu'un programme C le ferait (pour lequel SQLite a été conçu). Cela peut être lent, mais les personnes qui ont besoin de performances devraient de toute façon aller à PostgreSQL.

Merci beaucoup, @lorenz , pour avoir creusé cela. Votre indication que cela est probablement causé par quelque chose au niveau sqlite m'a incité à déplacer la base de données de configuration de notre instance de SQLite vers Postgres (et à mettre également nos sessions dans Postgres, qui avait déjà été sauvegardée sur fichier). Ce n'est pas une preuve concluante, mais je n'ai pas vu les problèmes non autorisés depuis.

Pour les autres personnes intéressées à essayer cette solution de contournement, j'ai utilisé pgloader avec les paramètres par défaut et n'ai supprimé aucune session ou donnée utilisateur pendant la migration.

Le problème ne concerne définitivement que le backend SQLite, car les bases de données "les plus grandes" ont toutes MVCC qui résout ce problème. Personnellement, j'ai également déplacé mes instances de production vers PostgreSQL. Le problème reste de savoir si et comment nous devons résoudre ce problème pour le backend SQLite. Je ne vois pas de moyen facile de le faire puisque Grafana (en raison de son écriture en Go) fait un usage intensif de la concurrence, ce qui nécessite une attention particulière dans SQLite au-delà de ce que Xorm fournit actuellement.

Il y a déjà un tas de verrous et de tentatives dans le code qui tentent de contourner cela, mais ils sont inadéquats. Depuis que j'ai corrigé la gestion des erreurs pour le lecteur de lignes (qui absorbe actuellement en silence les erreurs de verrouillage et crée ainsi un comportement imprévisible, je vais bientôt corriger le correctif), j'ai vu les erreurs de verrouillage apparaître à beaucoup plus d'endroits que les données proxy source, c'est juste le point de terminaison qui est le plus souvent touché et en raison de la nature probabiliste du bogue, il est le plus visible par l'utilisateur. Autant que je sache, tous les correctifs à ce sujet nécessitent le piratage de Xorm ou de go-sqlite3, ce qui n'est généralement pas souhaitable.

Merci pour l'excellente analyse @lorenz ! Pensez-vous que le retour de 500 dans ce cas serait une solution de contournement raisonnable à court terme ? Dans l'état actuel des choses, 401 oblige le navigateur (au moins Chrome) à oublier le mot de passe et oblige mes utilisateurs à le saisir à nouveau. Parfois, il doit être tapé plusieurs fois jusqu'à ce que le mot de passe soit finalement accepté.

Ma solution de contournement actuelle consiste à exécuter la base de données à partir de tmpfs . Cela réduit la fréquence de ce problème, mais cela arrive encore de temps en temps.

@kichik Lorsque j'ai communiqué ma modification à la gestion des erreurs, nous pourrions penser à renvoyer HTTP 500 (ou 503). Mais la seule bonne solution de contournement que je peux voir consiste à utiliser une base de données réelle compatible MVCC comme PostgreSQL ou MySQL qui ne présente pas du tout le problème. Comme je l'ai expliqué dans mon commentaire précédent, ce problème va plus loin que les simples demandes de données, donc renvoyer un autre code d'erreur que HTTP 401 uniquement pour ceux-ci ne résoudra pas entièrement le problème.

Je viens de préparer mon erreur en signalant les modifications dans #13007, cela devrait aider les gens à voir s'ils sont affectés par le problème de verrouillage ou s'il s'agit de quelque chose sans rapport.

@torkelo Pourrions-nous rouvrir cela car il s'agit clairement d'un problème avec Grafana?

Cela se passe certainement sur un seul onglet (et un seul utilisateur) pour moi.
En utilisant également sqlite3. Fait intéressant, je n'avais pas ce problème avant. Maintenant que j'ai ajouté quelques panneaux lourds (en ce qui concerne les requêtes), j'obtiens fréquemment cette erreur, généralement uniquement pour l'un de mes panneaux lourds.

Confirmer que le passage à une base de données non-sqlite3 résout le problème pour moi. J'avais également un seul utilisateur et un seul onglet, avec des panneaux plus lourds/plus occupés se comportant également moins bien.

Mise à jour : les sessions doivent être commutées pour être stockées dans la base de données séparée pour le correctif complet.

J'utilise mysqldb face au même problème. Grafana version 5.2.3 , Adhérence activée au niveau Lb mais le problème est toujours là.

J'expérimente également cela, en utilisant sqlite comme backend de données mais redis en tant que magasin de session sur grafana 5.2.3
Environ 150 organisations configurées. Un avertissement non autorisé apparaît lors de l'actualisation interne, mais disparaît généralement lors de l'actualisation manuelle.

Obtenir ceci dans les journaux de temps en temps :

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

Ce problème peut être causé par la perte de la connexion mysql. Lorsque je baisse les valeurs max_idle_conn et conn_max_lifetime, cela ne se reproduit plus. J'espère que cette aide

@vishksaj @xiaochai C'est très probablement un problème différent, pourriez-vous en ouvrir un nouveau ?

https://github.com/oleh-ozimok/grafana/commit/b19e416549553f582dccfbcaa3f4d3f1a742a462 - a résolu mon problème (image avec correctif docker pull olegozimok/grafana:5.3.2 )

Grafana 5.3.2. Configuration HA : 2 instances Grafana, la base de données principale MySQL, 2 instances de memcached pour les sessions, le répertoire grafana et la base de données sont stockés sur NFS. Les mêmes erreurs « non autorisées » tout le temps, de manière imprévisible. Il en était de même lorsque DB était SQLite sur NFS.

Même problème que @dev-e mais configuration plus simple. Grafana 5.3.2, instance unique, InfluxDB sur le même hôte, organisation unique, utilisateur unique. Le message apparaît de manière aléatoire et disparaît lors de l'actualisation de la page suivante.

J'ai le même problème. Obtention aléatoire d'erreurs non autorisées .
La mise à niveau vers grafana 5.3.4 l'a un peu amélioré, mais il y a encore beaucoup d'erreurs.

Dans les journaux grafana :
t=2018-11-19T09:55:07+0200 lvl=eror msg="Impossible d'obtenir l'utilisateur avec l'identifiant" logger=context userId=1 error="Utilisateur non trouvé"
t=2018-11-19T09:55:07+0200 lvl=eror msg="Impossible d'obtenir l'utilisateur avec l'identifiant" logger=context userId=1 error="Utilisateur non trouvé"
t=2018-11-19T09:55:07+0200 lvl=eror msg="Impossible d'obtenir l'utilisateur avec l'identifiant" logger=context userId=1 error="Utilisateur non trouvé"

Configuration prête à l'emploi :
grafana/maintenant 5.3.4 amd64
influxdb/maintenant 1.6.0-1 amd64

Même problème ici:

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"

Grafana 5.3.4 unique, le stockage est le système de fichiers Amazon EFS (montage NFS)
La session est définie sur fichier, le stockage des données est sqlite ( /var/lib/grafana/grafana.db )
Grafana est assis derrière un LB de terminaison HTTPS

A fait un PR mettant en œuvre la suggestion @oleh-ozimok. N'hésitez pas à l'essayer. Je l'essaierai plus une fois que je serai de retour de vacances pour que je puisse avoir une instance de longue durée :)

@oleh-ozimok Si vous voulez créer un PR, je suis plus qu'heureux de le fusionner au lieu du mien pour vous en donner le crédit.

Au fait, excellent travail @lorenz !

Cela affecte également notre déploiement. Nous obtenons constamment des erreurs 401 non autorisées en utilisant deux bases de données Amazon Auora MySQL s'exécutant en mode HA/Multi Master. J'ai vérifié que les sessions sont sur les deux bases de données. Mais même ainsi, j'ai pointé toutes les instances vers la même base de données pour voir si cela résoudrait le problème et ce n'est pas le cas. Il y a certainement quelque chose qui ne va pas avec les sessions qui sont authentifiées correctement. Cela va encore plus loin avec notre configuration Oauth. Il arrive parfois que l'utilisateur se connecte à l'aide du fournisseur Oauth configuré et qu'il ne se connecte pas une fois redirigé. S'ils se connectent environ 2-3 fois, cela fonctionne.

C'est très étrange, peut-être que l'un des serveurs est configuré différemment ?

Des détails sur le journal ?

Nous supprimons le besoin de stockage de session et réécrivons complètement la façon dont les sessions de connexion sont gérées dans la v6, donc j'espère que cela résoudra le problème.

@buroa avez-vous une chance d'essayer la version 6.0-beta1 ? Nous avons complètement réécrit le jeton d'authentification et supprimé la plupart des utilisations des jetons de session (toujours utilisés lors de l'utilisation de auth_proxy) et espérons que la plupart de ces problèmes disparaîtront.

@bergquist a mis à jour ma configuration au 2019-02-01T09:58:20+0200, cette erreur ne s'est pas produite pour le moment.

@buroa avez-vous une chance d'essayer la version 6.0-beta1 ? Nous avons complètement réécrit le jeton d'authentification et supprimé la plupart des utilisations des jetons de session (toujours utilisés lors de l'utilisation de auth_proxy) et espérons que la plupart de ces problèmes disparaîtront.

J'utilise la dernière version : https://github.com/buroa/grafana/tree/us-iso-regions

Est-ce que cela a le changement nécessaire?

@buroa oui, mais je vous suggère quand même de fusionner dans le dernier maître puisque nous avons apporté quelques modifications depuis la version 6.0-beta1.

Aujourd'hui j'ai eu une erreur
t=2019-02-08T10:05:58+0200 lvl=info msg="Impossible de rechercher l'utilisateur basé sur le cookie" logger=context error="Jeton d'authentification utilisateur introuvable"
L'onglet du navigateur ne se fermait pas, juste actualisé automatiquement toutes les heures, mais le PC était verrouillé.

@QuantumProjects voudriez-vous ouvrir un nouveau problème puisque vous avez un problème avec Grafana v6.0-pre. Veuillez fournir plus de détails sur votre configuration Grafana : quelle base de données est utilisée ? Version Grafana ? Plusieurs instances de Grafana ? Quel type d'authentification ? Proxy inversé ? Merci

@marefr D'accord

@marefr, je reçois les mêmes fenêtres contextuelles "non autorisées", peut-être que ma configuration peut aider à résoudre le problème :

• Serveur de passerelle avec traefik comme proxy inverse pointant vers un serveur local qui héberge grafana
• serveur local avec Grafana v5.4.3
• la source de données est un influxdb v1.7.8 sur le même serveur local
• comment connaître le type d'authentification en question ? Je viens de me connecter en tant qu'utilisateur administrateur

Remarque : chaque service est un conteneur docker, traefik x64, grafana et influxdb arm32v7

Cela se produit également dans Grafana 6.0.0 (commit : 34a9a62, branche : HEAD). La base de données SQLite n'est pas utilisée, Grafana travaille derrière le proxy inverse nginx. L'authentification LDAP est configurée. Une seule instance Grafana s'exécute sur cette VM.

Entrée de journal au moment de l'erreur :

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

Juste en ajoutant un point de données, une fois que j'ai déplacé ma base de données de sqlite vers postgres, j'ai cessé de voir ces erreurs. Auparavant, ils étaient assez fréquents pour rendre l'utilisation du système assez inconfortable. Exécution d'un seul serveur 5.4.3 avec google oauth.

Cela m'est arrivé sur 5.4.3 connecté à postgres, de manière assez aléatoire mais uniquement lorsque je le laisse s'actualiser automatiquement. L'installation est sur un réseau local où la base de données est sur la même boîte que Grafana.

Je reçois un tas de ces types d'erreurs sur syslog au moment où le message "Non autorisé" s'affiche :

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

Il existe quelques variations sur le journal sur userId=1 ou 0 et sur retry=1 ou 0

Bonjour,

J'ai eu aujourd'hui le même problème. Nous avons Grafana 6.0.1 sur une version simple de Debian Stretch mise à jour quelques jours auparavant. Grafana se connecte à un équilibreur de charge (proxysql) avec MariaDB 10.2 (cluster Galera) comme backend (mode de synchronisation avec trois nœuds).
Nous utilisons LDAP (Windows AD) comme autorisation.

Message de journal :

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

La seule chose qui a fonctionné était d'utiliser l'adresse IP directe et non l'équilibreur de charge.

La seule chose qui a fonctionné était d'utiliser l'adresse IP directe et non l'équilibreur de charge.

Cela ne ressemble cependant pas au même problème, car le nôtre est intermittent - peut-être que l'un des panneaux sur une douzaine d'actualisations peut échouer avec l'erreur, mais fonctionne généralement

La même chose m'arrive sur 6.0.2.

Depuis le journal :
t=2019-03-23T12:04:22+0000 lvl=eror msg="failed to look up user based on cookie" logger=context error="database is locked"
et
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"

Installation régulière de docker avec Traefik pour le proxy inverse.

Pour moi la même chose se passe
version 6.02
"échec de la recherche de l'utilisateur basé sur le cookie" logger=context error="la base de données est verrouillée"

Si vous obtenez "la base de données est verrouillée" avec Sqlite (par défaut), c'est probablement le bon moment pour migrer vers mysql/postgres car ils peuvent gérer plus de transactions/s

@bergquist Je pense que c'est effectivement la solution. Je viens de migrer vers MariaDB et je ne suis plus expulsé de Grafana. Clouer!

@bergquist Je pense que c'est effectivement la solution. Je viens de migrer vers MariaDB et je ne suis plus expulsé de Grafana. Clouer!

Pour clarifier, cela pourrait être une solution à "La base de données est verrouillée", pas à "Table de base de données verrouillée" - je suis sur PostgreSQL et face au "verrou de table".

Résolu pour moi après une mise à niveau de Raspbian qui m'a amené à Postgres 9.6 (à partir de 9.4). Grafana toujours en 5.4.3

Résolu pour moi après une mise à niveau de Raspbian qui m'a amené à Postgres 9.6 (à partir de 9.4). Grafana toujours en 5.4.3

Oubliez ce que j'ai dit... c'est de retour. Moins souvent, je dirais... mais ça arrive quand même.

@ggggh des solutions ? Cela a juste commencé à arriver à l'improviste pour moi!

@ggggh des solutions ? Cela a juste commencé à arriver à l'improviste pour moi!

Rien...! Il s'est effacé avec la mise à niveau de la version postgres et semble revenir, plus souvent chaque jour

@gggg Merci !
Je suis passé à Postgres, mais cela n'aide pas non plus :(

avoir les mêmes problèmes avec Grafana 6.2.1 et Postgress 11, mais cela ne se produit que sur les tableaux de bord que je charge à partir de JSON, puis j'essaie d'y accéder.

Des mises à jour à ce sujet ?

OK, j'ai trouvé le problème dans mon cas. Mon PG avait un nombre limité de connexions et dans grafana max_open_conn n'était pas défini. Après avoir défini cette option, cela fonctionne correctement.

La même chose se passe pour moi sur Grafana 6.1.6 et la base de données SQLite intégrée. Ce problème interrompt nos efforts de développement interne pour personnaliser Grafana. Changer max_open_conn ne fonctionne pas (même si je ne m'y attendais pas car c'était un correctif pour Postgres).

La cause première de cela semble être que grafana essaie de se connecter au
base de données sous-jacente lors de l'authentification, mais à défaut de le faire. Avec SQLite, cela
se produira souvent et à un faible nombre d'utilisations simultanées puisque SQLite se verrouille
si agressivement. Dans la plupart des cas, migrer vers un vrai SGBDR (j'aime postgres)
résoudra le problème. Il est possible que cela se reproduise si vous rencontrez un
problème de limite de connexion (ou similaire), mais c'est un problème de base de données plus qu'un
Inquiétude de Grafana. Si vous utilisez Grafana pour autre chose qu'une démo,
vous devriez le sauvegarder avec une vraie base de données. Si cette base de données est correctement configurée pour
votre utilisation, cela devrait résoudre ce problème.

Le lundi 10 juin 2019 à 11h20 syardumian-chc [email protected]
a écrit:

La même chose se passe pour moi sur Grafana 6.1.6 et la base de données SQLite intégrée. Cette
problème casse nos efforts de développement interne pour personnaliser Grafana. En changeant
max_open_conn ne fonctionne pas (même si je ne m'y attendais pas car c'était un
correctif pour Postgres).

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/10727?email_source=notifications&email_token=AAAK6YSUDLXPF2E4436CEOTPZ2EMFA5CNFSM4EO23EH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDNKTDN5WW2Z50YYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDNKTDN5WW2Z50Y
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAK6YQLR3FSCNEQR7SNEKLPZ2EMFANCNFSM4EO23EHQ
.

J'ai augmenté la limite de connexion et le nombre maximal de connexions inactives, mais je continue toujours à rencontrer ce problème de manière aléatoire. Non seulement cela, mais les tableaux de bord qui sont ouverts depuis un certain temps semblent être de plus en plus lents à actualiser, avec le chargement-gif évident sur chaque panneau et disparaissant lentement de manière séquentielle à mesure que chaque panneau termine le chargement. C'est bien si je ferme la fenêtre du navigateur et en ouvre une nouvelle. Je suppose que mon tableau de bord est devenu plus complexe, mais cela n'explique pas pourquoi un nouveau chargement de la page "répare".

Je reçois aussi une erreur aléatoire. Je ne sais vraiment pas quel est le problème. L'utilisation de l'adresse IP semble bien, mais avec l'entrée kubeneters, elle affiche la "requête d'annotation a échoué" de manière aléatoire.

FWIW, j'ai récemment basculé mon équilibreur de charge d'entrée sur Fabio (de Traefik) et mis à jour Grafana (image Docker, pas de backends de base de données supplémentaires) vers la v6.4.2, et les 401 erreurs non autorisées semblent avoir disparu lors de l'actualisation automatique (intervalle défini sur 10 secondes, fonctionnant toute la journée). Il est peu probable que le passage à Fabio ait résolu le problème, je suppose que c'est la nouvelle version de Grafana qui a aidé, mais je ne suis pas sûr à 100%.

Clôturez ceci car il n'y a pas de nouveaux rapports récemment. si vous pensez qu'il y a toujours un problème, veuillez ouvrir un nouveau problème

J'ai récemment installé grafana sur mon cluster kubernetes et j'ai rencontré un problème similaire.
J'utilise docker image grafana/ grafana:6.4.3

En vérifiant les journaux de mes pods, j'ai trouvé cette petite information intéressante :

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"

Les problèmes DNS ne sont pas quelque chose que j'ai rencontré auparavant dans mon cluster, mais j'ai fait quelques recherches sur Google et j'ai trouvé ce problème particulier : https://github.com/kubernetes/kubernetes/issues/30215

Serait-il possible pour grafana d'expédier à la fois des images alpines et non alpines comme le font beaucoup d'images docker ? On dirait que cela résoudrait le problème.
S'il y a quelque chose que je peux faire pour tester cela ou aider au débogage, faites-le moi savoir, je fournirai les informations demandées.

Après être passé à 6.3.6 (qui n'est pas basé sur l'alpin), le problème a complètement disparu de mon côté.

J'ai rencontré le même problème, deux Grafana (conteneurs) distincts ouverts dans le même navigateur
lorsque je me connecte au second, le premier me demande de me reconnecter, me connecte au premier, le second me demande de me reconnecter
ne peut pas garder les deux login
la solution que j'ai trouvée est de changer dans l'un des fichiers Grafana default.ini
login_cookie_name = grafana_session
à
login_cookie_name = grafana_session_1
redémarrez le conteneur et le navigateur, maintenant cela fonctionne bien
pour l'instant je garde le fichier hors du conteneur
besoin de définir ce paramètre lors de la création du conteneur

@ikkerens s'il vous plaît essayez l'image basée sur ubuntu puis, 6.6.2-ununtu

@n0-bs Je suis désolé mais si vous exécutez plusieurs instances de Grafana, il est suggéré d'utiliser MySQL ou Postgres comme base de données.

Désolé, mais comment, l'utilisation de MySQL ou Postgres comme base de données résoudra le conflit de cookies lorsque j'ouvrirai ces deux instances Grafana différentes dans le même navigateur, je ne parle pas du cas HA
J'ai deux instances Grafana différentes (conteneurs) sur le même serveur

Je vois toujours cela avec 6.7.2. Je suis passé de 6,5 à 6,6, puis à 6,7. En utilisant docker avec PostgreSQL, essayé l'image 6.7.2 puis 6.7.2-ubuntu.

Voici l'erreur que j'obtiens dans les logs :
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"

Corrigé (au moins pour l'instant) en redémarrant postgres.

J'utilise la dernière version de Grafana et je vois toujours le problème non autorisé à chaque fois que j'y accède. J'utilise Grafana dans kubernetes. Je l'ai déployé dans 3 pods différents dans 3 nœuds différents. J'utilise la base de données native de celui-ci. Une suggestion pour résoudre le problème ?

@emzfuu Si vous exécutez plusieurs instances, vous devez toutes les faire pointer vers la même base de données. mysql/postgres

@bergquist existe-t-il un autre moyen de résoudre le problème ?

Juste pour élaborer ma question ci-dessus, j'utilise 3 Grafana différents (autonomes) auxquels on accède via un seul équilibreur de charge. Les 3 Grafana ont leur propre db (sqlite3). Chaque fois que j'y accède, je reçois l'erreur de non-autorisation.

J'ai le même problème, utilisez nfs.