Grafana: Tidak sah

Dibuat pada 2 Feb 2018  ·  105Komentar  ·  Sumber: grafana/grafana

Saya menjalankan grafana versi terbaru pada dua instance, tetapi saya menghadapi banyak kesalahan tidak sah saat mencoba mengakses kedua instance. Untuk auth saat ini saya menggunakan db bawaan, tanpa LDAP. Sumber data adalah influxdb.

Apakah ini bug atau perilaku buruk yang diketahui?

needs more info

Komentar yang paling membantu

screenshot 2018-03-08 15 09 30
Saya melihat masalah yang sama pada Grafana v4.6.2 (komit: 8db5f08), semuanya berfungsi seperti yang diharapkan, dan tiba-tiba saya menerima peringatan Tidak Sah (dan beberapa grafik kosong, tetapi beberapa muncul secara normal).

Saya menggunakan Prometheus sebagai DataSource.

Saya juga berpikir ini terutama terjadi ketika dasbor disegarkan secara otomatis, tetapi memperbaikinya sendiri ketika saya menyegarkannya secara manual.

Semua 105 komentar

Bisakah Anda memberikan beberapa detail lebih lanjut:

  • Apakah ini dua kasus yang terpisah?
  • Tindakan apa yang memicu kesalahan tidak sah?
  • Apakah Anda keluar atau hanya tindakan tertentu yang tidak berhasil?

Apakah mereka diatur pada ips/nama domain yang berbeda? jika nama domainnya sama dan hanya berbeda berdasarkan port, Anda harus memiliki cookie sesi yang unik dan cookie ingat saya

-Itu adalah contoh terpisah
-Saya tidak tahu tindakan mana yang memicu yang tidak sah, itu hanya terjadi ketika saya menonton grafik atau saat mengakses grafana
-Terkadang saya logout
-Domain terpisah

Saya menemukan ini di Grafana 4.6.x dengan oauth melalui Github. Tampaknya acak ketika saya beralih tab dan kembali ke Grafana. Penyegaran akan "memperbaiki" masalah, tetapi terkadang muncul kembali nanti.

screenshot 2018-03-08 15 09 30
Saya melihat masalah yang sama pada Grafana v4.6.2 (komit: 8db5f08), semuanya berfungsi seperti yang diharapkan, dan tiba-tiba saya menerima peringatan Tidak Sah (dan beberapa grafik kosong, tetapi beberapa muncul secara normal).

Saya menggunakan Prometheus sebagai DataSource.

Saya juga berpikir ini terutama terjadi ketika dasbor disegarkan secara otomatis, tetapi memperbaikinya sendiri ketika saya menyegarkannya secara manual.

Masalah serupa di sini juga, tetapi dengan satu instance Grafana dengan HTTPS, dan sumber data Postgres.

Saat dasbor dibuka, semua grafik bagus. Tetapi kadang-kadang setelah itu, beberapa grafik mulai menunjukkan kesalahan "Tidak Sah" pada penyegaran otomatis, tetapi dalam penyegaran otomatis berikutnya (atau beberapa berikutnya) mereka pulih ke keadaan normal, tetapi kemudian berubah menjadi keadaan "Tidak Sah" kadang-kadang nanti lagi, berulang perilaku acak ini pada setiap penyegaran otomatis.

Tidak yakin apakah itu terkait, tetapi menemukan pesan log berikut.

lvl=eror msg="Gagal mendapatkan pengguna dengan id" logger=konteks userId=1 error="Pengguna tidak ditemukan"

Versi Grafana adalah sebagai berikut:

lvl=info msg="Memulai Grafana" logger=versi server=5.0.4 commit=7dc36ae dikompilasi=28-03-2018T20:52:41+0900

Saya menggunakan Firefox, dan saya biasanya membiarkan dasbor terbuka & tidak tersentuh selama beberapa hari, dengan mesin klien (bukan mesin server yang menghosting Grafana) masuk ke mode tidur dari waktu ke waktu.

Ini tidak terjadi pada saya lagi dengan grafana 5.x

Saya masih mengalami masalah yang sama persis dengan Grafana 5.0.4, pesan pengguna yang sama tidak ditemukan di log (ini dengan pengguna Grafana lokal sederhana).

Saya mengalami masalah ini juga. Dan masalah ini sangat menarik. Ini mungkin terjadi ketika saya membuka dua halaman grafana dengan versi berbeda di browser yang sama dan mencoba melakukan beberapa operasi.


Saya memiliki versi lama dari grafana(v4.3.2 (commit: ed4d170)) dan telah berjalan dengan baik di grafana.mydomain.com untuk waktu yang lama. Hari ini saya ingin mengupgrade grafana saya ke v5.0.4. Alih-alih meningkatkan di tempat. Saya ingin mengatur Grafana baru di mesin yang sama, menyalin dasbor yang saya inginkan, dan kemudian membongkar yang lama.

Jadi apa yang saya lakukan:

  1. docker menjalankan grafana5 pada mesin yang sama dengan yang lama dengan peta port ke 3005
  2. membuka grafana4 lama di grafana.mydomain.com di Safari
    Dan itu bekerja dengan baik
  3. kunjungi Grafana5 dengan grafana.mydomain.com:3005 di Safari
    Jadi sekarang saya memiliki dua tab Grafana4 dan Grafana5 yang terbuka di layar saya
  4. login Grafana5, mencoba melakukan beberapa operasi .... seperti [buat dasbor]
    Sekarang kedua halaman Grafana macet

Kedua Grafana akan mendapatkan kesalahan Unauthorized dan tidak mendapatkan poin data


Pembaruan : Saya mengubah langkah 3 saya dengan mengunjungi Grafana5 dengan [ip]:3005. Ini berfungsi dengan baik untuk saat ini.
Sepertinya ada beberapa konflik saat membuka dua halaman Grafana dalam domain yang sama.

@kehao95 kasus penggunaan Anda di browser yang sama membuka dua instance Grafana di domain yang sama tetapi dengan port yang berbeda tidak didukung. (Torkel menyebutkan itu di atas).

@ajardan apakah instance Anda berada di domain yang sama atau berbeda?

@daniellee Saya sebenarnya hanya menggunakan satu contoh sepanjang waktu. Dan grafik di dasbor yang saya lihat diambil dari 2 sumber data yang berbeda (Prometheus dan Cloudera)

Saya juga mendapatkan masalah "Tidak Sah" yang aneh ini dari waktu ke waktu. Penyegaran halaman "memperbaiki" masalah. Saya menjalankan Grafana v5.1.0 (844bdc53a) dari gambar Docker resmi. Sumber data adalah InfluxDb. Saya membuat 2 organisasi di Grafana, tetapi sebenarnya hanya menggunakan satu. Pengguna 'admin' tunggal.

Baru saja mendapatkan kesalahan ini sekali lagi dengan pesan kesalahan baru "Kueri anotasi gagal. Tidak sah"

Granana saya di win10 x64 berfungsi dengan baik selama beberapa hari sampai saya menerima peringatan "Tidak Diotorisasi". Perilakunya sama seperti yang dijelaskan oleh @dogada dan saya juga menjalankan v5.1.0 dengan influxdb. Baik grafana dan influxdb berada di komputer yang sama.

Masalah yang sama. Satu instance grafana 5.1 di buruh pelabuhan. Google oauth untuk otorisasi.

Ada pembaruan?

Perilaku yang sama. Saat ini menjalankan v5.0.3 di buruh pelabuhan, autentikasi internal, pengguna admin tunggal, diproksi melalui nginx, sumber data adalah influxdb. Dashboard memperbaiki dirinya sendiri saat auto-refresh data. Sebagian besar terjadi ketika tab lama di latar belakang

Masalah yang sama terlihat ketika dua tab terbuka untuk instance yang sama.

Perbarui ke gambar buruh pelabuhan terbaru v5.1.2 (komit: c3c690e21) tidak memperbaiki masalah

Saya mengalami apa yang saya yakini sebagai masalah yang sama dengan Grafana 5.0.0 di Docker menggunakan GitHub OAuth. Saya telah melihatnya di dasbor dengan InfluxDB, CloudWatch, dan campuran dari kedua sumber data. (Satu instance, satu port, HTTPS, di belakang ELB.)

Seperti orang lain di utas ini, sepertinya saya melihatnya dipicu oleh penyegaran otomatis, dan itu hilang setelah halaman dimuat ulang. Terkadang saya melihat pesan kesalahan "Tidak Sah" dasar (dengan kegagalan pemuatan grafik) dan terkadang (lebih jarang) pesan "Kueri anotasi gagal. Tidak sah" juga.

~Kecurigaan saya mengarah ke sesuatu dengan plugin OAuth?~ Ini hampir pasti karena backend sesi, lihat di bawah.

Untuk menambahkan lebih banyak detail yang saya temukan setelah menggali lebih dalam, saya melihat banyak kesalahan seperti ini di log saya:

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

Satu-satunya tempat saya melihat kesalahan seperti itu adalah di baris kode ini, yang tampaknya terkait dengan mengelola sesi dan cookie sesi?

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

Saya menyimpan sesi saya menggunakan backend file default, tetapi melalui share EFS yang dipasang, saya ingin tahu apakah itu merupakan komplikasi potensial.

Saya menghadapi masalah ini ketika saya mencoba membuka dua Grafana yang berbeda (yang Berjalan di Port yang berbeda) di browser yang sama.
Saya mendapatkan Kesalahan Tidak Sah dan Terkadang keluar

Akan sangat menarik untuk melihat kueri SQL apa yang dieksekusi ketika Anda menerima pesan Failed to get user with id log. Jika Anda dapat dengan mudah mereproduksi ini, itu akan sangat berharga jika Anda dapat mengaktifkan pencatatan kueri sql dan melaporkan kembali temuan Anda:

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

Terima kasih

@marefr Sepertinya kesalahan ini selalu terjadi dikelilingi oleh salah satu dari dua pertanyaan ini:

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

Contoh log lengkap:

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

Terima kasih banyak @bjacobel. Semuanya terlihat bagus di sini menurut saya. Ada id pengguna aktual yang disediakan hingga ke kueri basis data. Sangat aneh. Mulai berpikir ada bug dengan database pihak ke-3 lib xorm kami.

Apakah Anda melakukan sesuatu yang spesifik untuk menghasilkan pesan log tersebut?
Basis data apa yang Anda gunakan? Penyimpanan sesi apa?
Permintaan apa yang menghasilkan tidak sah, Anda dapat mengaktifkan log router untuk mencatat semua permintaan:

[server]
router_logging = true

Kami memiliki kesalahan yang sama pada 5.1.4 di Kubernetes.

Hai @marefr , maaf, saya lupa menanggapi dengan detail tambahan yang diminta.

Apakah Anda melakukan sesuatu yang spesifik untuk menghasilkan pesan log tersebut?

Kueri dibuat dengan memuat dasbor dan kemudian menunggu penyegaran otomatis. Itu tidak terjadi pada setiap penyegaran otomatis, dan kadang-kadang dapat dipicu dengan klik manual tombol penyegaran dasbor (yang ada di dalam Grafana, bukan tombol penyegaran browser) tetapi umumnya tampaknya lebih sering terjadi ketika pengguna tidak aktif (meninggalkan grafana di tab latar belakang, misalnya.)

Basis data apa yang Anda gunakan? Penyimpanan sesi apa?

Basis datanya adalah SQLite pada share NFS (EFS) yang terpasang, dan penyimpanan sesi adalah default (file), meskipun saya juga telah mencoba penyimpanan berbasis memori dan juga memiliki masalah yang sama. Kami memiliki satu host grafana di belakang penyeimbang beban, dan saya telah mengaktifkan kekakuan sesi pada penyeimbang beban itu.

Permintaan apa yang menyebabkan tidak sah?

Saya tidak mengaktifkan logging router, karena saya dapat melihat permintaan yang mengakibatkan tidak sah dari browser:

[Beberapa informasi sensitif disunting]

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

Hai @marefr , maaf, saya lupa menanggapi dengan detail tambahan yang diminta. ...

@bjacobel ini kemungkinan tidak terkait dengan masalah spesifik, namun pengembang SQLite merekomendasikan untuk tidak menjalankan SQLite melalui NFS. Secara khusus, proses Grafana tidak boleh mengakses DB melalui pemasangan NFS, dan menjalankan dari sistem file jaringan apa pun tanpa dukungan kunci file yang kuat tidak disarankan.

Di samping catatan, kami menggunakan SQLite dengan penyimpanan sesi seperti yang Anda lakukan, tetapi pada sistem file lokal. Kami tidak mengalami masalah yang sama.

Kami juga telah mengubah konfigurasi SQLite di grafana untuk menggunakan mode WAL (yang akhirnya akan saya lakukan PR) untuk kinerja yang lebih baik.

Dikirim dengan GitHawk

Saya mengalami masalah yang sama di tumpukan buruh pelabuhan Grafana dan InfluxDB saya.
Grafana v5.1.3 (komit: 087143285)
InfluxDB 1.5.3

Grafana menggunakan penyimpanan lokal melalui volume buruh pelabuhan dengan database sqlite. Volume menggunakan SSD lokal.
Saya mendapatkan kesalahan setiap kali saya meninggalkan tab selama lebih dari beberapa menit. Jika saya membiarkan alat dev di Firefox saya melihat:

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

Segala jenis penyegaran menghapus kesalahan.

Saya menemukan masalah yang sama. Bagi saya itu terkait dengan kehilangan "session_provider=memcahched"

Anda dapat merujuk ke http://docs.grafana.org/installation/configuration/#provider -config untuk opsi konfigurasi lainnya

Masalah yang sama juga ada di sini. Pengaturan buruh pelabuhan saya adalah:

FROM grafana/grafana:5.1.0
FROM influxdb:1.5.3

untitled

Menutup ini karena tampaknya terkait dengan pengaturan/konfigurasi

@torkelo Apakah ada solusi yang jelas untuk masalah ini? Atau petunjuk untuk membantu mencari solusi apa yang mungkin?

Pastikan pengaturan sesi berfungsi untuk pengaturan HA atau sesi lengket di penyeimbang beban berfungsi

Saya tidak menggunakan penyeimbang beban sekalipun.

Masalah yang sama di sini tanpa banyak replika
Baru saja mendapat kesalahan 401 pada /api/login/ping terkadang secara acak

Masalah yang sama di sini (selama bertahun-tahun, sebelum 5,0 hari), SQLite di ext4, replika tunggal di Kubernetes. Gambar Docker resmi terbaru.

Permintaan gagal secara acak ketika Grafana disegarkan secara otomatis, akhirnya semua widget berhenti melaporkan apa pun. Log yang relevan:

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"

Saya akan mencoba melakukan debugging, saya 99% yakin ini adalah bug Grafana (atau salah satu perpustakaannya).

/cc @torkelo

Saya 95% yakin bahwa ini adalah percobaan ulang yang hilang jika tabel SQLite terkunci. Saya akan menerapkan perbaikan secara lokal dan PR jika berhasil.

EDIT: Gores itu, itu akan membutuhkan jalur kode yang berbeda.

Berikut adalah contoh kesalahan dari saya.

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"

Saya membiarkannya berjalan semalaman untuk menghasilkan beberapa kegagalan lagi dan saya yakin tidak ada apa-apa dengan sesi. Itu ada di lapisan ORM, khususnya di user.go GetSignedInUser() mana lapisan itu terkadang tidak mengembalikan respons yang benar. Saya mencatat semua permintaan pada dasbor grafik 50 gemuk pada 1 menit selama satu malam dan melihat pola yang sangat acak dengan kesalahan berkerumun, semuanya mengarah ke beberapa masalah konkurensi / balap. Saat ini saya sedang menjalankan tambalan yang menyebarkan kesalahan dari pembaca baris dengan benar (kandidat utama untuk masalah ini), saya akan melihat apakah saya mendapatkan pesan kesalahan yang berbeda.

Itu tadi cepat. Dengan tambalan propagasi kesalahan saya diterapkan, saya menemukan akar penyebabnya:

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"

Percobaan ulang salah diterapkan di suatu tempat di pengandar eksekusi SQLite.

Saya memeriksanya lagi dan ada beberapa masalah di sini:

  1. go-sqlite tidak dikenal sebagai goroutine-safe (yang membuat semua ini dengan koneksi yang dikelola xorm pusat mungkin merupakan ide yang buruk).
  2. SQLite tidak mendukung kueri bersamaan pada "koneksi" tunggal. Kita perlu mendapatkan xorm untuk membuka banyak koneksi ke SQLite. Kalau tidak, kita mungkin mengalami kebuntuan atau kesalahan penguncian ini karena SQLite tidak akan mencoba menyelesaikan kunci jika mereka berasal dari koneksi yang sama.

Saya telah melihat orang melakukan banyak hal untuk menghindari masalah SQLite ini, termasuk membungkus semua akses SQLite dalam satu mutex dan membuka instance SQLite baru per permintaan. Hal termudah untuk dilakukan mungkin adalah meretas go-sqlite3 untuk memuat mutex per "koneksi" dan hanya membuat cerita bersambung semua akses ke sana (EDIT: Baru menyadari ini mungkin tidak akan berfungsi karena kunci muncul saat membaca dari kursor, yang Anda tidak dapat mengunci tanpa mempertaruhkan kebuntuan). Itulah cara program C melakukannya (yang dibuat untuk SQLite). Mungkin lambat, tetapi orang yang membutuhkan kinerja harus pergi ke PostgreSQL.

Terima kasih banyak, @lorenz , untuk menggali ini. Indikasi Anda bahwa ini kemungkinan disebabkan oleh sesuatu di tingkat sqlite mendorong saya untuk memindahkan database konfigurasi instance kami dari SQLite ke Postgres (dan juga menempatkan sesi kami di Postgres, yang sebelumnya telah didukung file). Ini bukan bukti konklusif, tetapi saya belum pernah melihat masalah Tidak Sah sejak itu.

Untuk orang lain yang tertarik mencoba solusi ini, saya menggunakan pgloader dengan pengaturan default dan tidak menghapus sesi atau data pengguna selama migrasi.

Masalahnya pasti hanya dengan backend SQLite karena database "lebih besar" semuanya memiliki MVCC yang memecahkan masalah ini. Saya pribadi juga memindahkan instance produksi saya ke PostgreSQL. Masalahnya masih ada adalah apakah dan bagaimana kita harus menyelesaikan ini untuk backend SQLite. Saya tidak melihat cara mudah untuk melakukan itu karena Grafana (karena ditulis dalam Go) menggunakan banyak konkurensi yang memerlukan perawatan khusus dalam SQLite di luar apa yang disediakan Xorm saat ini.

Sudah ada banyak kunci dan percobaan ulang dalam kode yang mencoba mengatasinya, tetapi itu tidak memadai. Karena saya telah memperbaiki penanganan kesalahan untuk pembaca baris (yang saat ini diam-diam menelan kesalahan penguncian dan dengan demikian menciptakan perilaku yang tidak dapat diprediksi, saya akan segera memperbaikinya) Saya telah melihat kesalahan penguncian muncul di lebih banyak tempat daripada hanya data proxy sumber, hanya titik akhir yang paling sering terkena dan karena sifat probabilistik dari bug menjadikannya yang paling terlihat oleh pengguna. Sejauh yang saya bisa lihat, semua perbaikan ini memerlukan peretasan Xorm atau go-sqlite3, yang umumnya tidak diinginkan.

Terima kasih atas analisisnya yang luar biasa @lorenz! Apakah menurut Anda mengembalikan 500 dalam kasus ini akan menjadi solusi jangka pendek yang masuk akal? Seperti sekarang, 401 memaksa browser (setidaknya Chrome) untuk melupakan kata sandi dan mengharuskan pengguna saya untuk mengetiknya lagi. Terkadang harus diketik berkali-kali sampai akhirnya password diterima.

Solusi saya saat ini adalah menjalankan database dari tmpfs . Ini mengurangi frekuensi masalah ini, tetapi masih terjadi dari waktu ke waktu.

@kichik Ketika saya telah melakukan PR perubahan saya pada penanganan kesalahan, kami dapat memikirkan untuk mengembalikan HTTP 500 (atau 503). Tetapi satu-satunya solusi bagus yang bisa saya lihat adalah menggunakan database aktual berkemampuan MVCC seperti PostgreSQL atau MySQL yang tidak menunjukkan masalah sama sekali. Seperti yang saya jelaskan di komentar saya sebelumnya, masalah ini lebih dari sekadar permintaan data, jadi mengembalikan kode kesalahan lain selain HTTP 401 hanya untuk itu tidak akan memperbaiki masalah sepenuhnya.

Saya baru saja melakukan PR perubahan pelaporan kesalahan saya di #13007, ini akan membantu orang untuk melihat apakah mereka terpengaruh oleh masalah penguncian atau jika itu adalah sesuatu yang tidak terkait.

@torkelo Bisakah kita membuka kembali ini karena ini jelas merupakan masalah dengan Grafana?

Pasti terjadi pada satu tab (dan satu pengguna) untuk saya.
Juga menggunakan sqlite3. Menariknya, saya tidak memiliki masalah ini sebelumnya. Sekarang saya telah menambahkan beberapa panel berat (bijaksana permintaan) saya sering mendapatkan kesalahan ini, biasanya hanya untuk salah satu panel berat saya.

Mengonfirmasi bahwa beralih ke DB non-sqlite3 memperbaiki masalah bagi saya. Saya mendapatkan dengan satu pengguna dan satu tab juga, dengan panel yang lebih berat/sibuk berperilaku lebih buruk juga.

Pembaruan: sesi harus dialihkan untuk disimpan di db terpisah untuk perbaikan lengkap.

Saya menggunakan mysqldb menghadapi masalah yang sama. Grafana versi 5.2.3 , Diaktifkan lengket di tingkat Lb tetapi masalah masih ada.

Juga mengalami ini, menggunakan sqlite sebagai backend data tetapi redis sebagai penyimpanan sesi di grafana 5.2.3
Sekitar 150 organisasi dikonfigurasi. Peringatan tidak sah muncul pada penyegaran internal tetapi biasanya hilang pada penyegaran manual.

Mendapatkan ini di log dari waktu ke waktu:

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

Masalah ini dapat disebabkan oleh koneksi mysql yang hilang. Ketika saya menurunkan nilai max_idle_conn dan conn_max_lifetime, ini tidak terjadi lagi. Semoga membantu

@vishksaj @xiaochai Ini kemungkinan besar merupakan masalah yang berbeda, dapatkah Anda membuka yang baru?

https://github.com/oleh-ozimok/grafana/commit/b19e416549553f582dccfbcaa3f4d3f1a742a462 - memecahkan masalah saya ( gambar dengan hotfix docker pull olegozimok/grafana:5.3.2 )

Grafana 5.3.2. Konfigurasi HA: 2 Instance Grafana, DB utama MySQL, 2 instance memcached untuk sesi, dir grafana dan DB disimpan di NFS. Kesalahan "Tidak Sah" yang sama sepanjang waktu, tidak terduga. Hal yang sama adalah ketika DB adalah SQLite di NFS.

Masalah yang sama seperti @dev-e tetapi pengaturannya lebih sederhana. Grafana 5.3.2, instans tunggal, InfluxDB pada host yang sama, organisasi tunggal, pengguna tunggal. Pesan muncul secara acak dan menghilang pada penyegaran halaman berikutnya.

Saya memiliki masalah yang sama. Secara acak mendapatkan kesalahan Tidak Sah .
Memutakhirkan ke grafana 5.3.4 agak membuatnya lebih baik, tetapi masih cukup banyak kesalahan.

Dalam log grafana:
t=2018-11-19T09:55:07+0200 lvl=eror msg="Gagal mendapatkan pengguna dengan id" logger=konteks userId=1 error="Pengguna tidak ditemukan"
t=2018-11-19T09:55:07+0200 lvl=eror msg="Gagal mendapatkan pengguna dengan id" logger=konteks userId=1 error="Pengguna tidak ditemukan"
t=2018-11-19T09:55:07+0200 lvl=eror msg="Gagal mendapatkan pengguna dengan id" logger=konteks userId=1 error="Pengguna tidak ditemukan"

Pengaturan di luar kotak:
grafana/sekarang 5.3.4 amd64
influxdb/sekarang 1.6.0-1 amd64

Masalah yang sama disini:

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 tunggal 5.3.4, penyimpanan adalah sistem file Amazon EFS (pemasangan NFS)
Sesi diatur ke file, penyimpanan data adalah sqlite ( /var/lib/grafana/grafana.db )
Grafana duduk di belakang HTTPS yang mengakhiri LB

Membuat PR yang mengimplementasikan saran @oleh-ozimok. Jangan ragu untuk mencobanya. Saya akan mencobanya lagi setelah saya pulang dari liburan sehingga saya dapat memiliki contoh yang berjalan lama :)

@oleh-ozimok Jika Anda ingin membuat PR, saya lebih senang menggabungkannya daripada milik saya untuk memberi Anda kredit.

Btw kerja bagus @lorenz !

Ini juga memengaruhi penerapan kami. Kami terus-menerus mendapatkan 401 kesalahan Tidak Sah menggunakan dua database Amazon Auora MySQL yang berjalan dalam mode HA/Multi Master. Saya telah memverifikasi sesi di kedua database. Namun demikian, saya mengarahkan semua instance ke database yang sama untuk melihat apakah itu akan memperbaiki masalah dan ternyata tidak. Pasti ada yang salah dengan sesi yang diautentikasi dengan benar. Ini bahkan lebih jauh dengan pengaturan Oauth kami. Ada kalanya pengguna akan masuk menggunakan penyedia Oauth yang dikonfigurasi dan akan gagal masuk setelah dialihkan. Jika mereka masuk sekitar 2-3 kali itu berhasil.

Itu sangat aneh, mungkin di salah satu server dikonfigurasi secara berbeda?

Ada detail log?

Kami menghilangkan kebutuhan untuk penyimpanan sesi dan sepenuhnya menulis ulang bagaimana sesi login dikelola di v6, jadi semoga itu akan menyelesaikannya.

@buroa ada kemungkinan Anda dapat mencoba 6.0-beta1? Kami telah menulis ulang token auth dan menghapus sebagian besar penggunaan token sesi (masih digunakan saat menggunakan auth_proxy) sepenuhnya dan berharap sebagian besar masalah ini akan hilang.

@bergquist memperbarui pengaturan saya di 2019-02-01T09:58:20+0200, tidak terjadi kesalahan ini untuk saat ini.

@buroa ada kemungkinan Anda dapat mencoba 6.0-beta1? Kami telah menulis ulang token auth dan menghapus sebagian besar penggunaan token sesi (masih digunakan saat menggunakan auth_proxy) sepenuhnya dan berharap sebagian besar masalah ini akan hilang.

Saya menggunakan build terbaru: https://github.com/buroa/grafana/tree/us-iso-regions

Apakah ini membutuhkan perubahan?

@buroa ya, tetapi tetap menyarankan Anda untuk menggabungkan master terbaru karena kami telah melakukan beberapa perubahan sejak 6.0-beta1.

Hari ini ada kesalahan
t=2019-02-08T10:05:58+0200 lvl=info msg="gagal mencari pengguna berdasarkan cookie" logger=context error="Token auth pengguna tidak ditemukan"
Tab browser tidak menutup, hanya autorefresh setiap jam, tetapi pc terkunci.

@QuantumProjects maukah Anda membuka masalah baru karena ini Anda memiliki masalah dengan Grafana v6.0-pre. Harap berikan detail lebih lanjut tentang pengaturan Grafana Anda: basis data apa yang digunakan? versi grafiti? Beberapa contoh Grafana? Jenis otentikasi apa? Proksi terbalik? Terima kasih

@marefr Oke

@marefr saya mendapatkan Popup "Tidak Sah" yang sama, mungkin pengaturan saya dapat membantu memecahkan masalah:

  • Server gateway dengan traefik sebagai proxy terbalik yang menunjuk ke server lokal yang menghosting grafana
  • server lokal dengan Grafana v5.4.3
  • sumber data adalah influxdb v1.7.8 di server lokal yang sama
  • bagaimana cara mengetahui jenis otentikasi yang dipertanyakan? Saya baru saja masuk sebagai pengguna admin

Catatan: setiap layanan adalah wadah buruh pelabuhan, traefik x64, grafana dan influxdb arm32v7

Ini terjadi di Grafana 6.0.0 (komit: 34a9a62, cabang: HEAD) juga. Basis data SQLite tidak digunakan, Grafana bekerja di belakang proxy terbalik nginx. Otentikasi LDAP dikonfigurasi. Instance Grafana tunggal berjalan di VM ini.

Entri log pada saat kesalahan:

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

Hanya menambahkan titik data, setelah saya memindahkan db saya dari sqlite ke postgres, saya berhenti melihat kesalahan ini. Sebelumnya mereka cukup sering membuat penggunaan sistem menjadi tidak nyaman. Menjalankan server 5.4.3 tunggal dengan google oauth.

Terjadi pada saya di 5.4.3 terhubung ke postgres, cukup acak tetapi hanya ketika saya membiarkannya melakukan penyegaran otomatis. Setup berada di jaringan lokal di mana database berada di kotak yang sama dengan Grafana.

Saya mendapatkan banyak jenis kesalahan ini di syslog pada saat "Tidak Sah" muncul:

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

Ada beberapa variasi pada log di userId=1 atau 0 dan coba lagi=1 atau 0

Halo,

Saya memiliki masalah yang sama hari ini. Kami memiliki Grafana 6.0.1 pada Debian Stretch biasa yang ditingkatkan beberapa hari sebelumnya. Grafana terhubung ke load balancer (proxysql) dengan MariaDB 10.2 (Galera cluster) sebagai backend (mode sinkronisasi dengan tiga node).
Kami menggunakan LDAP (Windows AD) sebagai otorisasi.

Pesan log:

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

Satu-satunya hal yang berhasil, adalah menggunakan IP langsung dan bukan penyeimbang beban.

Satu-satunya hal yang berhasil, adalah menggunakan IP langsung dan bukan penyeimbang beban.

Kedengarannya tidak seperti masalah yang sama, karena masalah kami terputus-putus - mungkin salah satu panel di setiap selusin penyegaran mungkin gagal dengan kesalahan, tetapi umumnya berfungsi

Hal yang sama terjadi pada saya di 6.0.2.

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

Instal buruh pelabuhan biasa dengan Traefik untuk proxy terbalik.

Bagi saya hal yang sama terjadi
versi 6.02
"gagal mencari pengguna berdasarkan cookie" logger=context error="database terkunci"

Jika Anda mendapatkan "database terkunci" dengan Sqlite (default) mungkin saat yang tepat untuk bermigrasi ke mysql/postgres karena mereka dapat menangani lebih banyak transaksi/s

@bergquist Saya pikir itu memang solusinya. Baru saja bermigrasi ke MariaDB dan saya tidak lagi dikeluarkan dari Grafana. Memakukan!

@bergquist Saya pikir itu memang solusinya. Baru saja bermigrasi ke MariaDB dan saya tidak lagi dikeluarkan dari Grafana. Memakukan!

Untuk memperjelas, itu mungkin solusi untuk "Database terkunci", bukan "Tabel database terkunci" - Saya menggunakan PostgreSQL dan menghadapi "kunci tabel".

Dipecahkan untuk saya setelah peningkatan Raspbian yang membawa saya ke Postgres 9.6 (dari 9.4). Grafana masih di 5.4.3

Dipecahkan untuk saya setelah peningkatan Raspbian yang membawa saya ke Postgres 9.6 (dari 9.4). Grafana masih di 5.4.3

Lupakan apa yang saya katakan ... itu kembali. Lebih jarang, saya akan mengatakan ... tapi masih terjadi.

@gggg ada solusi? Itu baru saja mulai terjadi tiba-tiba bagi saya!

@gggg ada solusi? Itu baru saja mulai terjadi tiba-tiba bagi saya!

Tidak...! Itu dihapus dengan peningkatan versi postgres, dan tampaknya akan kembali lagi, lebih sering setiap hari

@gggg Terima kasih!
Saya telah beralih ke Postgres, tetapi itu juga tidak membantu :(

memiliki masalah yang sama menggunakan Grafana 6.2.1 dan Postgress 11, tetapi ini hanya terjadi pada dashbaords yang saya muat dari JSON dan kemudian mencoba mengaksesnya.

Ada pembaruan tentang ini?

Oke, saya menemukan masalah dalam kasus saya. PG saya memiliki jumlah koneksi yang terbatas dan di grafana max_open_conn tidak disetel. Setelah saya mengatur opsi ini, itu berfungsi dengan baik.

Hal yang sama terjadi pada saya di Grafana 6.1.6 dan SQLite DB yang dikemas. Masalah ini mematahkan upaya pengembang internal kami untuk menyesuaikan Grafana. Mengubah max_open_conn tidak berfungsi (walaupun saya tidak mengharapkannya karena ini adalah perbaikan untuk Postgres).

Akar penyebab ini tampaknya adalah grafana yang mencoba terhubung ke
mendasari DB saat mengautentikasi, tetapi gagal melakukannya. Dengan SQLite, itu
akan sering terjadi dan dengan jumlah penggunaan bersamaan yang rendah sejak SQLite mengunci
begitu agresif. Dalam kebanyakan kasus, bermigrasi ke RDBMS nyata (saya suka postgres)
akan menyelesaikan masalah. Mungkin saja itu bisa muncul lagi jika Anda mengalami
masalah batas koneksi (atau serupa), tetapi itu lebih merupakan masalah DB daripada a
Kekhawatiran Grafana. Jika Anda menggunakan Grafana untuk apa pun selain demo,
Anda harus mendukungnya dengan DB asli. Jika DB itu dikonfigurasi dengan benar untuk
penggunaan Anda, itu harus menyelesaikan masalah ini.

Pada Senin, 10 Jun 2019 pukul 11:20 syardumian-chc [email protected]
menulis:

Hal yang sama terjadi pada saya di Grafana 6.1.6 dan SQLite DB yang dikemas. Ini
masalah mematahkan upaya pengembang internal kami untuk menyesuaikan Grafana. Mengubah
max_open_conn tidak berfungsi (walaupun saya tidak mengharapkannya karena itu a
perbaiki untuk Postgres).


Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/grafana/grafana/issues/10727?email_source=notifications&email_token=AAAK6YSUDLXPF2E4436CEOTPZ2EMFA5CNFSM4EO23EH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW500
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAK6YQLR3FSCNEQR7SNEKLPZ2EMFANCNFSM4EO23EHQ
.

Saya telah meningkatkan batas koneksi dan koneksi idle maksimal, tetapi masih terus mengenai masalah ini secara acak. Bukan hanya itu, tetapi dasbor yang telah dibuka untuk sementara waktu tampaknya semakin lambat untuk disegarkan, dengan loading-gif yang terlihat jelas di setiap panel dan perlahan menghilang secara berurutan saat setiap panel selesai memuat. Tidak apa-apa jika saya menutup jendela browser dan membuka yang baru. Saya kira dasbor saya menjadi lebih kompleks, tetapi itu tidak menjelaskan mengapa pemuatan halaman yang baru "memperbaikinya".

Saya mendapatkan kesalahan acak juga. Benar-benar tidak tahu apa masalahnya. Menggunakan alamat IP tampaknya baik-baik saja, tetapi dengan masuknya kubeneters, ini menunjukkan "kueri penjelasan gagal" secara acak.

FWIW, saya baru-baru ini mengalihkan loadbalancer ingress saya ke Fabio (dari Traefik) dan memperbarui Grafana (gambar Docker, tidak ada backend basis data tambahan) ke v6.4.2, dan 401 kesalahan tidak sah tampaknya telah hilang saat melakukan penyegaran otomatis (interval disetel ke 10 detik, berjalan sepanjang hari). Tidak mungkin beralih ke Fabio memperbaiki masalah, saya kira itu adalah versi Grafana yang lebih baru yang membantu, tetapi saya tidak 100% yakin.

Menutup ini karena tidak ada laporan baru baru-baru ini. jika menurut Anda masih ada masalah, silakan buka edisi baru

Saya baru-baru ini menginstal grafana di cluster kubernetes saya dan mengalami masalah serupa.
Saya menggunakan docker image grafana/ grafana:6.4.3

Memeriksa log pod saya, saya menemukan berita gembira kecil yang menarik ini:

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"

Masalah DNS bukanlah sesuatu yang saya temui sebelumnya dalam cluster saya, tetapi saya melakukan beberapa googling dan menemukan masalah khusus ini: https://github.com/kubernetes/kubernetes/issues/30215

Mungkinkah grafana mengirimkan gambar alpine dan non-alpine seperti yang dilakukan banyak gambar buruh pelabuhan? Sepertinya itu akan menyelesaikan masalah.
Jika ada yang bisa saya lakukan dalam menguji ini atau membantu debug, beri tahu saya, saya akan memberikan informasi seperti yang diminta.

Setelah menurunkan ke 6.3.6 (yang tidak berbasis alpine) masalah hilang sepenuhnya di pihak saya.

Saya menghadapi masalah yang sama, dua Grafana (wadah) terpisah terbuka di browser yang sama
saat login yang kedua yang pertama minta saya login lagi, login yang pertama yang kedua minta saya login lagi
tidak dapat menyimpan keduanya login
solusi yang saya temukan adalah mengubah salah satu file default.ini Grafana
login_cookie_name = grafana_session
ke
login_cookie_name = grafana_session_1
restart wadah dan browser, sekarang berfungsi dengan baik
untuk saat ini saya menyimpan file di luar wadah
perlu mengatur parameter ini saat membuat wadah

@ikkerens silakan coba gambar berbasis ubuntu, 6.6.2-ununtu

@n0-bs Maaf, tetapi jika Anda menjalankan beberapa instance Grafana, disarankan untuk menggunakan MySQL atau Postgres sebagai database.

Maaf, tetapi bagaimana, penggunaan MySQL atau Postgres sebagai database., akan menyelesaikan konflik cookie ketika saya membuka dua contoh Grafana yang berbeda ini di browser yang sama, saya tidak berbicara tentang kasus HA
Saya memiliki dua instance (wadah) Grafana yang berbeda di server yang sama

Saya masih melihat ini dengan 6.7.2. Saya memutakhirkan dari 6,5 ke 6,6, lalu 6,7. Menggunakan buruh pelabuhan dengan PostgreSQL, coba gambar 6.7.2 lalu 6.7.2-ubuntu.

Ini adalah kesalahan yang saya dapatkan di log:
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"

Memperbaiki (setidaknya untuk saat ini) dengan memulai ulang postgres.

Saya menggunakan Grafana versi terbaru dan masih melihat masalah yang tidak sah setiap kali saya mengaksesnya. Saya menggunakan Grafana di kubernetes. Saya menyebarkannya di 3 pod berbeda di 3 node berbeda. Saya menggunakan database asli itu. Adakah saran untuk memperbaiki masalah ini?

@emzfuu Jika Anda menjalankan beberapa instance, Anda harus mengarahkan semuanya ke database yang sama. mysql/postgres

@bergquist apakah ada cara lain untuk memperbaiki masalah ini?

Hanya untuk menguraikan pertanyaan saya di atas, saya menggunakan 3 Grafana berbeda (berdiri sendiri) yang diakses melalui penyeimbang beban tunggal. 3 Grafana memiliki db (sqlite3) mereka sendiri. Setiap kali saya mengaksesnya saya menerima kesalahan unauthorize.

Saya memiliki masalah yang sama, gunakan nfs.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat