Grafana: Неавторизованный

Не могли бы вы подробнее рассказать:

• Это два отдельных случая?
• Какое действие вызывает несанкционированную ошибку?
• Вы выходите из системы или просто некоторые действия не работают?

Они настроены на разные IP-адреса / доменные имена? если имя домена такое же и отличается только портом, вам необходимо иметь уникальные файлы cookie сеанса и файлы cookie запоминания меня

-Это отдельные экземпляры
-Я не знаю, какое действие запускает неавторизованное, это просто происходит, когда я смотрю графики или при доступе к графане
-Иногда я выхожу из системы
-Отдельные домены

Я сталкиваюсь с этим на Grafana 4.6.x с oauth через Github. Когда я переключаю вкладки и возвращаюсь в Grafana, это кажется случайным. Обновление «исправит» проблему, но иногда она возвращается позже.

Я вижу ту же проблему в Grafana v4.6.2 (commit: 8db5f08), все работает, как ожидалось, и внезапно я получаю предупреждение о несанкционированном доступе (и некоторые графики пустые, но некоторые отображаются нормально).

Я использую Прометей в качестве источника данных.

Я также думаю, что это в основном происходит, когда панель инструментов обновляется автоматически, но исправляется, когда я обновляю ее вручную.

Аналогичная проблема и здесь, но с одним экземпляром Grafana с HTTPS и источником данных Postgres.

Когда дашборд открыт, все графики хорошие. Но иногда после этого некоторые из графиков начинают показывать «Несанкционированные» ошибки при автообновлении, но в течение следующего (или нескольких следующих) автообновлений они восстанавливаются до нормального состояния, но затем переходят в «Несанкционированное» состояние, иногда позже снова, повторяя это случайное поведение при каждом автоматическом обновлении.

Не уверен, связано ли это, но нашел следующие сообщения журнала.

lvl = eror msg = "Не удалось получить пользователя с идентификатором" logger = context userId = 1 error = "Пользователь не найден"

Версия Grafana выглядит следующим образом:

lvl = info msg = "Запуск Grafana" logger = server version = 5.0.4 commit = 7dc36ae compiled = 2018-03-28T20: 52: 41 + 0900

Я использую Firefox, и обычно я оставляю панель управления открытой и нетронутой в течение нескольких дней, при этом клиентский компьютер (а не сервер, на котором размещена Grafana) время от времени переходит в спящий режим.

Со мной этого больше не происходит с grafana 5.x

У меня все еще такая же проблема с Grafana 5.0.4, те же сообщения пользователя, не найденные в журнале (это с простым локальным пользователем Grafana).

У меня тоже есть эта проблема. И вопрос очень интересный. Это может произойти, когда я открываю две страницы графаны разной версии в одном браузере и пытаюсь выполнить какие-то операции.

У меня более старая версия grafana (v4.3.2 (commit: ed4d170)), и она долгое время хорошо работала на grafana.mydomain.com . Сегодня я хочу обновить свою графану до версии 5.0.4. Вместо апгрейда на месте. Я хотел установить новую Grafana на той же машине, скопировать панель управления, которую я хочу, а затем разорвать старую.

Итак, что я сделал:

1. docker запустить grafana5 на той же машине, что и старый, с картой портов на 3005
2. открыл старую grafana4 на grafana.mydomain.com в Safari
   И это хорошо работает
3. посетите Grafana5 в grafana.mydomain.com:3005 в Safari
   Итак, теперь у меня на экране две открытых вкладки Grafana4 и Grafana5.
4. войдите в систему Grafana5, пытаясь выполнить некоторые операции .... например, [создать панель управления]
   Теперь обе страницы Grafana разбились

Обе Grafana получат ошибки Unauthorized и не получат точек данных.

Обновление : я изменил свой шаг 3, посетив Grafana5 с [ip]: 3005. Пока работает нормально.
Похоже, могут возникнуть конфликты при открытии двух страниц Grafana в одном домене.

@ kehao95 ваш

@ajardan , ваши экземпляры находятся в одном домене или в разных?

@daniellee На самом деле я все время использую только один экземпляр. И графики на панели инструментов, которые я просматриваю, взяты из двух разных источников данных (Prometheus и Cloudera).

Я также время от времени получаю эти странные "Несанкционированные" проблемы. Обновление страницы «устраняет» проблему. Я запускаю Grafana v5.1.0 (844bdc53a) из официального образа Docker. Источник данных - InfluxDb. Я создал 2 организации в Графане, но на самом деле использую только одну. Один пользователь-администратор.

Только что получил эту ошибку еще раз с новым сообщением об ошибке «Ошибка запроса аннотации. Неавторизовано»

Моя графана на win10 x64 работала отлично пару дней, пока я не получил предупреждение «Неавторизовано». Поведение такое же, как описано в @dogada, и я также использую v5.1.0 с infxdb. И grafana, и Influxdb находятся на одном компьютере.

Та же проблема. Один экземпляр Grafana 5.1 в докере. Google oauth для авторизации.

Любые обновления?

Такое же поведение. В настоящее время выполняется версия 5.0.3 в докере, внутренняя проверка подлинности, пользователь с одним администратором, проксирование через nginx, источник данных - infxdb. Панель инструментов исправляется при автоматическом обновлении данных. В основном происходит, когда вкладка долгое время находится в фоновом режиме

Такая же проблема наблюдается, когда две вкладки открыты для одного и того же экземпляра.

Обновление до последнего образа докера v5.1.2 (фиксация: c3c690e21) не устраняет проблему

У меня возникла такая же проблема с Grafana 5.0.0 в Docker с использованием GitHub OAuth. Я видел это на дашбордах с InfluxDB, CloudWatch и смесью обоих источников данных. (Один экземпляр, один порт, HTTPS, за ELB.)

Как и другие участники этой ветки, я, кажется, вижу, что он запускается автоматическим обновлением и исчезает после перезагрузки страницы. Иногда я вижу базовое сообщение об ошибке «Неавторизовано» (с ошибками загрузки графа), а иногда (реже) также сообщение «Запрос аннотации не выполнен. Неавторизованный».

~ Мое подозрение указывает на что-то с плагинами OAuth? ~ Это почти наверняка связано с серверной частью сеанса, см. Ниже.

Чтобы добавить больше деталей, которые я обнаружил после более глубокого изучения, я вижу много таких ошибок в своих журналах:

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

Единственное место, где я вижу такую ​​ошибку, - это эта строка кода, которая, кажется, связана с управлением сеансами и файлами cookie сеанса?

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

Я сохраняю свои сеансы, используя бэкэнд file по умолчанию, но через смонтированный общий ресурс EFS, мне интересно, является ли это потенциальным осложнением.

Я столкнулся с этой проблемой, когда пытаюсь открыть две разные Grafana (которые работают в другом порту) в одном браузере.
Я получаю несанкционированные ошибки и иногда выхожу из системы

Было бы действительно интересно посмотреть, какие SQL-запросы выполняются, когда вы получаете сообщение журнала Failed to get user with id . Если вы легко можете воспроизвести это, было бы очень ценно, если бы вы могли включить ведение журнала запросов sql и сообщать о своих результатах:

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

Спасибо

@marefr Кажется, что эти ошибки всегда возникают в окружении одного из этих двух запросов:

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

Полные примеры журналов:

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

Большое спасибо @bjacobel. По мне, здесь все выглядит хорошо. Фактический идентификатор пользователя предоставляется вплоть до запроса к базе данных. Действительно странно. Начинаю думать, что есть ошибка с нашей сторонней базой данных lib xorm.

Вы делали что-нибудь конкретное для создания этих сообщений журнала?
Какую базу данных вы используете? Какая сессионная память?
Какой запрос стал несанкционированным, вы можете включить ведение журнала маршрутизатора для регистрации всех запросов:

[server]
router_logging = true

У нас такая же ошибка на 5.1.4 в Kubernetes.

Привет @marefr , извините, я забыл ответить с дополнительной запрошенной подробностью.

Вы делали что-нибудь конкретное для создания этих сообщений журнала?

Запросы создаются путем загрузки панели мониторинга и последующего ожидания автоматического обновления. Это не происходит при каждом автоматическом обновлении, и иногда оно может запускаться при ручном нажатии кнопки обновления панели инструментов (встроенной в Grafana, а не кнопки обновления браузера), но, как правило, это происходит чаще, когда пользователь неактивны (например, оставив графану на фоновой вкладке).

Какую базу данных вы используете? Какая сессионная память?

База данных - это SQLite на смонтированном общем ресурсе NFS (EFS), а хранилище сеансов - по умолчанию (файл), хотя я также пробовал хранилище на основе памяти, и у него также была такая же проблема. У нас есть один хост grafana за балансировщиком нагрузки, и я включил привязку сеанса для этого балансировщика нагрузки.

Какой запрос стал несанкционированным?

Я не включил ведение журнала маршрутизатора, потому что я вижу запрос, который является несанкционированным из браузера:

[Некоторая конфиденциальная информация удалена]

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

Привет @marefr , извините, я забыл ответить с дополнительной запрошенной подробностью. ...

@bjacobel, вероятно, это не связано с конкретной проблемой, однако разработчики SQLite рекомендуют не запускать SQLite через NFS. В частности, процесс Grafana не должен обращаться к БД через монтирование NFS, и запуск из любой сетевой файловой системы без сильной поддержки блокировки файлов не рекомендуется.

Кстати, мы используем SQLite с хранилищем сеансов, как и вы, но в локальной файловой системе. У нас не было такой проблемы.

Мы также настроили конфигурацию SQLite в grafana для использования режима WAL (о котором я в конечном итоге сделаю PR) для повышения производительности.

_{Отправлено с помощью GitHawk}

У меня такая же проблема в моем стеке докеров Grafana и InfluxDB.
Grafana v5.1.3 (фиксация: 087143285)
InfluxDB 1.5.3

Grafana использует локальное хранилище через тома докеров с базой данных sqlite. Тома используют локальный SSD.
Я получаю сообщение об ошибке каждый раз, когда выхожу из вкладки более чем на несколько минут. Если я оставлю инструменты разработчика в Firefox, я вижу:

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

Любое обновление устраняет ошибки.

Я столкнулся с той же проблемой. Для меня это было связано с отсутствием "session_provider = memcahched"

Вы можете обратиться к http://docs.grafana.org/installation/configuration/#provider -config для получения дополнительных параметров конфигурации.

Та же проблема здесь. Моя настройка докера:

FROM grafana/grafana:5.1.0
FROM influxdb:1.5.3

Закрытие, поскольку кажется, что это связано с настройкой / конфигурацией

@torkelo Есть очевидное решение этой проблемы? Или подсказка, которая поможет найти возможное решение?

Убедитесь, что настройка сеанса работает для настройки высокой доступности или липкие сеансы в балансировщике нагрузки работают

Но я не использую балансировщик нагрузки.

Такая же проблема здесь без нескольких реплик
Ошибка 401 на / api / login / ping иногда случайным образом

Такая же проблема здесь (в течение многих лет, до 5,0 дней), SQLite на ext4, единственная реплика на Kubernetes. Последний официальный образ Docker.

Запросы не выполняются случайным образом при автоматическом обновлении Grafana, в конечном итоге все виджеты перестают сообщать что-либо. Соответствующие журналы:

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"

Попробую немного отладить, я на 99% уверен, что это ошибка Grafana (или одной из ее библиотек).

/ cc @torkelo

Я на 95% уверен, что это пропущенная повторная попытка в случае блокировки таблицы SQLite. Я разверну исправление локально и PR, если оно сработает.

РЕДАКТИРОВАТЬ: Поцарапайте это, для этого потребуется другой кодовый путь.

Вот пример моей ошибки.

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"

Я позволил ему поработать на ночь, чтобы сгенерировать еще несколько сбоев, и уверен, что это не относится к сеансам. Он находится на уровне ORM, в частности в user.go GetSignedInUser() где этот уровень иногда не возвращает правильный ответ. Я записал все запросы на толстую панель инструментов с 50 графиками за 1 минуту в течение одной ночи и увидел очень случайный образец с кластеризованными ошибками, все указывает на некоторую проблему с параллелизмом / гонками. В настоящее время я использую патч, который правильно передает ошибки от средства чтения строк (основной кандидат на эту проблему). Я посмотрю, получу ли я другое сообщение об ошибке.

Это было быстро. Применив мой патч распространения ошибки, я нашел основную причину:

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"

Повторы неправильно реализованы где-то в драйвере выполнения SQLite.

Я изучил это еще немного, и здесь есть несколько проблем:

1. go-sqlite, как известно, не является безопасным для горутин (что делает все это с центральным подключением, управляемым xorm, возможно, плохой идеей).
2. SQLite не поддерживает одновременные запросы по одному «соединению». Нам нужно получить xorm для открытия нескольких подключений к SQLite. В противном случае мы можем столкнуться с тупиками или этими ошибками блокировки, поскольку SQLite не будет пытаться разрешить блокировки, если они исходят от одного и того же соединения.

Я видел, как люди делали несколько вещей, чтобы избежать этих проблем с SQLite, в том числе заключали весь доступ к SQLite в один мьютекс и открывали новый экземпляр SQLite для каждого запроса. Проще всего, вероятно, взломать go-sqlite3, чтобы он содержал мьютекс для каждого «соединения» и просто сериализовал весь доступ к нему (РЕДАКТИРОВАТЬ: только что понял, что это, вероятно, не сработает, поскольку блокировки появляются при чтении из курсора, который вы не можете заблокироваться, не рискуя попасть в тупик). Именно так это сделает программа на C (для которой был создан SQLite). Это может быть медленным, но людям, которым нужна производительность, в любом случае следует перейти на PostgreSQL.

Большое спасибо, @lorenz , за то, что

Для других, заинтересованных в использовании этого обходного пути, я использовал pgloader с настройками по умолчанию и не удалял ни сеанса, ни пользовательских данных во время миграции.

Проблема определенно связана только с серверной частью SQLite, поскольку все «большие» базы данных имеют MVCC, который решает эту проблему. Я лично также перенес свои производственные экземпляры на PostgreSQL. Вопрос по-прежнему остается в том, должны ли мы решить эту проблему для бэкэнда SQLite и как это сделать. Я не вижу простого способа сделать это, поскольку Grafana (из-за того, что она написана на Go) интенсивно использует параллелизм, который требует особого внимания в SQLite, помимо того, что в настоящее время предоставляет Xorm.

В коде уже есть множество блокировок и повторных попыток, которые пытаются обойти это, но они неадекватны. Поскольку я исправил обработку ошибок для считывателя строк (который в настоящее время молча проглатывает ошибки блокировки и, таким образом, создает непредсказуемое поведение, я скоро буду предлагать исправление), я видел, что ошибки блокировки появляются во многих других местах, чем просто данные исходный прокси-сервер, чаще всего поражается именно конечная точка, которая из-за вероятностного характера ошибки делает ее наиболее заметной для пользователя. Насколько я понимаю, все исправления требуют взлома Xorm или go-sqlite3, что обычно нежелательно.

Спасибо за отличный анализ @lorenz! Как вы думаете, возврат 500 в этом случае будет разумным краткосрочным решением? Как и сейчас, 401 заставляет браузер (по крайней мере, Chrome) забыть пароль и требует, чтобы мои пользователи вводили его снова. Иногда его приходится вводить несколько раз, пока пароль не будет окончательно принят.

Мой текущий обходной путь - запустить базу данных из tmpfs . Это снижает частоту возникновения этой проблемы, но время от времени она все еще возникает.

@kichik Когда я напишу о своем изменении в обработке ошибок, мы могли бы подумать о возврате HTTP 500 (или 503). Но единственный хороший обходной путь, который я вижу, - это использование реальной базы данных с поддержкой MVCC, такой как PostgreSQL или MySQL, которые вообще не проявляют проблемы. Как я объяснил в своем предыдущем комментарии, эта проблема идет дальше, чем просто запросы данных, поэтому возврат кода ошибки, отличного от HTTP 401, только для них не решит проблему полностью.

Я только что сообщил об изменениях в сообщении об ошибках в № 13007, это должно помочь людям увидеть, затронута ли проблема с блокировкой или это что-то не связанное с этим.

@torkelo Не могли бы мы снова открыть это, поскольку это явно проблема с Grafana?

Определенно происходит на одной вкладке (и на одном пользователе) для меня.
Также с помощью sqlite3. Интересно, что раньше у меня этой проблемы не было. Теперь, когда я добавил несколько тяжелых панелей (по запросу), я часто получаю эту ошибку, обычно только для одной из моих тяжелых панелей.

Подтверждение того, что переход на базу данных, отличную от sqlite3, решает проблему для меня. У меня тоже был один пользователь и одна вкладка, и более тяжелые / загруженные панели также вели себя хуже.

Обновление: сеансы необходимо переключить, чтобы они сохранялись в отдельной базе данных для полного исправления.

Я использую mysqldb и сталкиваюсь с той же проблемой. Grafana версии 5.2.3, включена липкость на уровне фунтов, но проблема все еще существует.

Также испытываю это, используя sqlite как серверную часть данных, но redis как хранилище сеансов на grafana 5.2.3
Настроено около 150 организаций. Предупреждение о несанкционированном доступе появляется при внутреннем обновлении, но обычно исчезает при обновлении вручную.

Время от времени попадая в журналы:

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

Эта проблема может быть вызвана потерей соединения mysql. Когда я уменьшаю значения max_idle_conn и conn_max_lifetime, этого больше не повторится. Надеюсь на эту помощь

@vishksaj @xiaochai Это, скорее всего, другая проблема, не могли бы вы открыть новую?

https://github.com/oleh-ozimok/grafana/commit/b19e416549553f582dccfbcaa3f4d3f1a742a462 - моя проблема решена (изображение с исправлением docker pull olegozimok/grafana:5.3.2 )

Графана 5.3.2. Конфигурация высокой доступности: 2 экземпляра Grafana, основная база данных MySQL, 2 экземпляра memcached для сеансов, каталог grafana и база данных хранятся в NFS. Все время одни и те же «Несанкционированные» ошибки, причем непредсказуемо. То же самое было, когда БД была SQLite на NFS.

Та же проблема, что и @ dev-e, но более простая настройка. Grafana 5.3.2, один экземпляр, InfluxDB на одном хосте, одна организация, один пользователь. Сообщение появляется случайным образом и исчезает при следующем обновлении страницы.

У меня точно такая же проблема. Случайное получение несанкционированных ошибок.
Обновление до grafana 5.3.4 вроде как улучшило его, но все еще довольно много ошибок.

В логах графана:
t = 2018-11-19T09: 55: 07 + 0200 lvl = eror msg = «Не удалось получить пользователя с идентификатором» logger = context userId = 1 error = «Пользователь не найден»
t = 2018-11-19T09: 55: 07 + 0200 lvl = eror msg = «Не удалось получить пользователя с идентификатором» logger = context userId = 1 error = «Пользователь не найден»
t = 2018-11-19T09: 55: 07 + 0200 lvl = eror msg = «Не удалось получить пользователя с идентификатором» logger = context userId = 1 error = «Пользователь не найден»

Заводская настройка:
grafana / сейчас 5.3.4 драм64
Influxdb / сейчас 1.6.0-1 amd64

Такая же проблема здесь:

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

Single Grafana 5.3.4, хранилище - файловая система Amazon EFS (монтирование NFS)
Сессия настроена на файл, хранилище данных - sqlite (/var/lib/grafana/grafana.db)
Grafana находится за HTTPS-терминалом LB

Сделал PR, реализовав предложение @ oleh-ozimok. Не стесняйтесь попробовать. Я попробую еще раз, когда вернусь домой из отпуска, так что у меня будет давно работающий экземпляр :)

@ oleh-ozimok Если вы хотите создать пиар, я буду счастлив объединить его вместо своего, чтобы отдать вам должное.

Кстати, отличная работа @lorenz !

Это также влияет на наше развертывание. Мы постоянно получаем 401 несанкционированную ошибку при использовании двух баз данных MySQL Amazon Auora, работающих в режиме HA / Multi Master. Я проверил сеансы в обеих базах данных. Но даже в этом случае я указал все экземпляры на одну и ту же базу данных, чтобы посмотреть, решит ли это проблему, но этого не произошло. Определенно что-то не так с правильной аутентификацией сеансов. Это даже идет дальше с нашей настройкой Oauth. Бывают случаи, когда пользователь входил в систему, используя настроенного поставщика Oauth, и он не мог войти в систему после перенаправления. Если они войдут в систему примерно 2-3 раза, это сработает.

Что очень странно, может, один из серверов настроен иначе?

Какие-нибудь подробности журнала?

Мы устраняем необходимость в хранении сеансов и полностью переписываем управление сеансами входа в систему в версии 6, так что, надеюсь, это решит эту проблему.

@buroa есть шанс попробовать 6.0-beta1? Мы переписали токен аутентификации и полностью удалили большую часть использования токена сеанса (все еще используется при использовании auth_proxy) и надеемся, что большинство этих проблем исчезнет.

@bergquist обновил мою настройку в 2019-02-01T09: 58: 20 + 0200, на данный момент этой ошибки не было.

@buroa есть шанс попробовать 6.0-beta1? Мы переписали токен аутентификации и полностью удалили большую часть использования токена сеанса (все еще используется при использовании auth_proxy) и надеемся, что большинство этих проблем исчезнет.

Я использую последнюю сборку: https://github.com/buroa/grafana/tree/us-iso-regions

Требуются ли в этом изменения?

@buroa да, но все же предлагаю вам слить последний мастер, так как мы сделали несколько изменений с момента 6.0-beta1.

Сегодня произошла ошибка
t = 2019-02-08T10: 05: 58 + 0200 lvl = info msg = "не удалось найти пользователя на основе файла cookie" logger = context error = "токен аутентификации пользователя не найден"
Вкладка браузера не закрывалась, просто автоматически обновлялась каждый час, но компьютер был заблокирован.

@QuantumProjects не

@marefr Хорошо

@marefr Я получаю те же "Неавторизованные" всплывающие окна, возможно, мои настройки помогут разобраться в проблеме:

• Сервер шлюза с traefik в качестве обратного прокси-сервера, указывающий на локальный сервер, на котором размещается графана
• локальный сервер с Grafana v5.4.3
• источник данных - infxdb v1.7.8 на том же локальном сервере
• как узнать сомнительный тип аутентификации? Я просто вхожу в систему как администратор

Примечание: каждая служба представляет собой контейнер докеров, traefik x64, grafana и Influxdb arm32v7

Это происходит и в Grafana 6.0.0 (фиксация: 34a9a62, ветка: HEAD). База данных SQLite не используется, Grafana работает за обратным прокси-сервером nginx. Настроена аутентификация LDAP. На этой виртуальной машине работает один экземпляр Grafana.

Запись в журнале на момент ошибки:

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

Просто добавив точку данных, как только я переместил свой db из sqlite в postgres, я перестал видеть эти ошибки. Раньше они были достаточно частыми, чтобы пользоваться системой было довольно неудобно. Запуск одного сервера 5.4.3 с google oauth.

Это происходит со мной на 5.4.3, подключенном к postgres, довольно случайным образом, но только когда я позволяю ему автоматически обновляться. Установка выполняется в локальной сети, где база данных находится в том же ящике, что и Grafana.

Я получаю кучу этих типов ошибок в системном журнале в то время, когда появляется сообщение «Неавторизовано»:

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

Есть несколько вариантов входа в систему userId = 1 или 0 и при повторной попытке = 1 или 0

Привет,

У меня сегодня была такая же проблема. У нас есть Grafana 6.0.1 на простом Debian Stretch, обновленный за несколько дней до этого. Grafana подключается к балансировщику нагрузки (proxysql) с MariaDB 10.2 (кластер Galera) в качестве бэкэнда (режим синхронизации с тремя узлами).
Мы используем LDAP (Windows AD) в качестве авторизации.

Сообщение журнала:

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

Единственное, что сработало, - это использовать прямой IP-адрес, а не балансировщик нагрузки.

Единственное, что сработало, - это использовать прямой IP-адрес, а не балансировщик нагрузки.

Однако это не похоже на ту же проблему, поскольку наша проблема возникает периодически - возможно, одна из панелей в каждой дюжине или около того обновлений может давать сбой с ошибкой, но в целом работает.

То же самое происходит и со мной на 6.0.2.

Из журнала:
t=2019-03-23T12:04:22+0000 lvl=eror msg="failed to look up user based on cookie" logger=context error="database is locked"
а также
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"

Обычная установка докера с Traefik для обратного проксирования.

Для меня то же самое, что и происходит
версия 6.02
"не удалось найти пользователя на основе cookie" logger = context error = "база данных заблокирована"

Если вы получаете «база данных заблокирована» с помощью Sqlite (по умолчанию), вероятно, подходящее время для перехода на mysql / postgres, поскольку они могут обрабатывать больше транзакций / с

@bergquist Я думаю, что это действительно решение. Только что перешел на MariaDB, и меня больше не выкидывают из Grafana. Гвоздь!

@bergquist Я думаю, что это действительно решение. Только что перешел на MariaDB, и меня больше не выкидывают из Grafana. Гвоздь!

Чтобы уточнить, это может быть решение проблемы «База данных заблокирована», а не «Таблица базы данных заблокирована» - я использую PostgreSQL и сталкиваюсь с «блокировкой таблицы».

Решено для меня после обновления Raspbian, которое привело меня к Postgres 9.6 (с 9.4). Графана все еще на 5.4.3

Решено для меня после обновления Raspbian, которое привело меня к Postgres 9.6 (с 9.4). Графана все еще на 5.4.3

Забудь то, что я сказал ... оно вернулось. Я бы сказал, что реже ... но все же происходит.

@ggggh какие-нибудь решения? Для меня это начало происходить совершенно неожиданно!

@ggggh какие-нибудь решения? Для меня это начало происходить совершенно неожиданно!

Ничего такого...! Он исчез с обновлением версии postgres и, кажется, возвращается снова, все чаще с каждым днем.

@ggggh Спасибо!
Я перешел на Postgres, но это тоже не помогает :(

имеют те же проблемы с использованием Grafana 6.2.1 и Postgress 11, но это происходит только на дашбордах, которые я загружаю из JSON, а затем пытаюсь получить к ним доступ.

Есть обновления по этому поводу?

Хорошо, я нашел проблему в моем случае. У моего PG было ограниченное количество подключений и в графане max_open_conn не было установлено. После того, как я установил этот параметр, он работает нормально.

То же самое происходит со мной в Grafana 6.1.6 и в SQLite DB. Эта проблема нарушает наши внутренние усилия разработчиков по настройке Grafana. Изменение max_open_conn не работает (хотя я этого не ожидал, поскольку это было исправление для Postgres).

Основная причина этого, похоже, заключается в том, что графана пытается подключиться к
базовая БД при аутентификации, но не может этого сделать. С SQLite это
будет происходить часто и при небольшом количестве одновременного использования, поскольку SQLite блокирует
так агрессивно. В большинстве случаев переход на настоящую СУБД (мне нравится postgres)
решит вопрос. Возможно, это может произойти снова, если вы столкнетесь с
ограничение подключения (или аналогичная) проблема, но это проблема БД больше, чем
Концерн Grafana. Если вы используете Grafana не для демонстрации,
вы должны подкрепить его реальной БД. Если эта БД настроена правильно для
ваше использование, которое должно решить эту проблему.

В понедельник, 10 июня 2019 г., в 11:20 syardumian-chc [email protected]
написал:

То же самое происходит со мной в Grafana 6.1.6 и в SQLite DB. Этот
Проблема нарушает наши внутренние усилия разработчиков по настройке Grafana. Изменение
max_open_conn не работает (хотя я этого не ожидал, так как это был
исправление для Postgres).

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/grafana/grafana/issues/10727?email_source=notifications&email_token=AAAK6YSUDLXPF2E4436CEOTPZ2EMFA5CNFSM4EO23EH2YY3PNVWWK3TUL52HS4DFVREXG63LVMVO2
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAK6YQLR3FSCNEQR7SNEKLPZ2EMFANCNFSM4EO23EHQ
.

Я увеличил ограничение на количество подключений и максимальное количество неактивных подключений, но все равно продолжаю сталкиваться с этой проблемой случайным образом. Не только это, но и панели мониторинга, которые были открыты в течение некоторого времени, кажутся все медленнее и медленнее обновляться, при этом загружаемый gif отображается на каждой панели и постепенно исчезает по мере завершения загрузки каждой панели. Ничего страшного, если я закрою окно браузера и открою новое. Думаю, моя панель инструментов стала более сложной, но это не объясняет, почему новая загрузка страницы «исправляет».

Я тоже получаю случайную ошибку. На самом деле не знаю, в чем проблема. Использование IP-адреса кажется нормальным, но с входом kubeneters он случайным образом показывает "сбой запроса аннотации".

FWIW, я недавно переключил свой входящий балансировщик нагрузки на Fabio (от Traefik) и обновил Grafana (образ Docker, без дополнительных бэкэндов базы данных) до версии 6.4.2, и 401 несанкционированная ошибка, похоже, исчезла при автоматическом обновлении (интервал установлен на 10). секунд, работает весь день). Маловероятно, что переход на Fabio устранил проблему, я предполагаю, что помогла более новая версия Grafana, но я не уверен на 100%.

Закрытие, так как в последнее время нет новых отчетов. если вы считаете, что проблема все еще существует, откройте новую проблему

Недавно я установил Grafana в свой кластер kubernetes и столкнулся с аналогичной проблемой.
Я использую docker image grafana / grafana: 6.4.3

Проверяя журналы своих модулей, я обнаружил этот интересный небольшой лакомый кусочек:

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

Проблемы с DNS - это не то, с чем я раньше сталкивался в моем кластере, но я немного погуглил и обнаружил эту конкретную проблему: https://github.com/kubernetes/kubernetes/issues/30215

Может ли Grafana отправлять как альпийские, так и неальпийские образы, как это делают многие образы докеров? Похоже, это решит проблему.
Если есть что-то, что я могу сделать для тестирования или помощи в отладке, дайте мне знать, я предоставлю информацию по запросу.

После перехода на версию 6.3.6 (которая не связана с альпинизмом) проблема полностью исчезла с моей стороны.

Я столкнулся с той же проблемой, два отдельных Grafana (контейнера) открыты в одном браузере
при входе во второй первый попросит меня войти снова, войдите в первый второй попросите меня снова войти в систему
не могу сохранить оба логина
решение, которое я нашел, - это изменить один из файлов Grafana default.ini
login_cookie_name = grafana_session
к
login_cookie_name = grafana_session_1
перезапустите контейнер и браузер, теперь он работает нормально
пока я храню файл вне контейнера
необходимо установить этот параметр при создании контейнера

@ikkerens, тогда попробуйте образ на основе Ubuntu, 6.6.2-ununtu

@ n0-bs Мне очень жаль, но если вы используете несколько экземпляров Grafana, рекомендуется использовать MySQL или Postgres в качестве базы данных.

Извините, но как использование MySQL или Postgres в качестве базы данных разрешит конфликт файлов cookie, когда я открываю эти два разных экземпляра Grafana в одном браузере, я не говорю о случае HA
У меня есть два разных экземпляра (контейнера) Grafana на одном сервере

Я все еще вижу это с 6.7.2. Перешел с 6.5 на 6.6, потом на 6.7. Используя докер с PostgreSQL, попробовал образ 6.7.2, затем 6.7.2-ubuntu.

Это ошибка, которую я получаю в журналах:
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"

Исправлено (по крайней мере, на данный момент) перезапуском postgres.

Я использую последнюю версию Grafana и все еще вижу несанкционированную проблему каждый раз, когда обращаюсь к ней. Я использую Grafana в кубернетах. Я развернул его в 3 разных модулях на 3 разных узлах. Я использую его собственную базу данных. Есть предложения по исправлению проблемы?

@emzfuu Если вы запускаете несколько экземпляров, вам нужно направить их все в одну и ту же базу данных. mysql / postgres

@bergquist есть ли другой способ решить проблему?

Просто чтобы уточнить мой вопрос выше, я использую 3 разных Grafana (автономных), доступ к которым осуществляется через один балансировщик нагрузки. У 3 Grafana есть собственная база данных (sqlite3). Каждый раз, когда я обращаюсь к нему, я получаю сообщение об ошибке несанкционированного доступа.

У меня такая же проблема, используйте nfs.