Grafana: Grafana Logs "banco de dados está bloqueado"

Você pode descrever mais sua configuração, opções, número de usuários, alertas, painéis, painéis provisionados, frequência de avaliação de alerta etc.

Eu também tenho o mesmo problema.

t=2019-04-24T09:37:46+0300 lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"
t=2019-04-24T09:37:46+0300 lvl=dbug msg="Scheduling update" logger=alerting.scheduler ruleCount=0
t=2019-04-24T09:37:55+0300 lvl=eror msg="Failed to get system stats" logger=metrics error="database is locked"
t=2019-04-24T09:37:56+0300 lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"
t=2019-04-24T09:37:56+0300 lvl=dbug msg="Scheduling update" logger=alerting.scheduler ruleCount=0
t=2019-04-24T09:37:59+0300 lvl=dbug msg="auth token rotated" logger=auth affected=1 auth_token_id=46 userId=1
t=2019-04-24T09:37:59+0300 lvl=dbug msg="Updating last user_seen_at" logger=context userId=1 orgId=1 uname=admin user_id=1

Grafite, Grafana, Postgresql 9.6.

Outros serviços funcionando corretamente com o mesmo db.

Estou tendo um problema semelhante ao usar o influxdb. Grafana funciona bem por um tempo, então, de repente, trava e se desconecta. Grafana v6.1.6 (commit: cf9cb45), Ubuntu 16.04.

t = 2019-05-14T00: 36: 04-0600 lvl = eror msg = "Falha ao obter estatísticas do sistema" logger = erro de métricas = "banco de dados está bloqueado"
t = 2019-05-14T00: 36: 05-0600 lvl = eror msg = "Não foi possível carregar alertas" logger = alerting.ruleReader error = "banco de dados está bloqueado"

Mesmo problema aqui. Executando em uma instância EC2: prometheus, grafana e alguns de meus próprios serviços. Navegador aberto para grafana, e pronto. Nenhum outro serviço atingindo a grafana. Tudo está bem por alguns minutos, então em algum ponto o grafana se crava com erros de "banco de dados está bloqueado", e então não funciona, _e_ ele não inicializa novamente.

Quando diz que "banco de dados" está bloqueado, está se referindo à fonte de dados influxdb ou ao banco de dados grafana que acredito conter informações sobre o painel, configurações, etc. e é um banco de dados SQLite por padrão? Estou executando influxdb em uma VM KVM e grafana em uma VM KVM separada. Seria bom saber se devo tentar ajustar o influxo ou a grafana.

@cuxcrider Este é um problema com o banco de dados sqlite padrão da grafana.

Alguma ideia se mudar para postgres ou mysql resolverá o problema?

Não, e eu realmente não tenho nenhum interesse nisso, porque parte do que estou trabalhando é configuração zero-config (ou quase zero-config) para ambientes de desenvolvimento. Ter que configurar um banco de dados diferente como back-end é uma dificuldade para mim.

Eu ouço você aí. Preferiria que apenas "funcionasse". Posso tentar, encontrei algumas informações aqui:
https://community.hortonworks.com/articles/33401/how-to-set-up-grafana-to-use-mysql-database-rather.html

Fyi Acabei de configurar o grafana em uma nova VM e configurar o mysql usando o guia que colei acima. Em seguida, exportei meus painéis como JSON e os inseri em meu novo grafana e até agora, tudo bem. Sem bater. Você pode talvez converter seu SQLite para mysql se você tiver uma tonelada de coisas já configuradas, mas meu grafana era mínimo, então eu apenas exportei meus painéis como json e então reconectei manualmente às fontes de dados.

Tenho um problema semelhante quando o garafana para de funcionar repentinamente e reiniciá-lo não corrige este problema :(

t=2019-05-17T05:40:30+0000 lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"
t=2019-05-17T05:40:40+0000 lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"
t=2019-05-17T05:40:50+0000 lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"
t=2019-05-17T05:40:59+0000 lvl=eror msg="failed to run garbage collect" logger=remotecache.database error="database is locked"
t=2019-05-17T05:40:59+0000 lvl=eror msg="Failed to get system stats" logger=metrics error="database is locked"
t=2019-05-17T05:41:00+0000 lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"
t=2019-05-17T05:41:10+0000 lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"
t=2019-05-17T05:41:20+0000 lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"
t=20

Mesmo problema aqui.
Grafana 6.1.6
CentOS 6.9

t = 2019-05-17T11: 41: 00-0300 lvl = eror msg = "falha ao procurar usuário com base no cookie" logger = erro de contexto = "banco de dados está bloqueado"

Começa a acontecer quando atualizado para o Grafana 6.

Eu tenho o mesmo problema.
O Grafana me enviou 2 alertas esta noite com a mensagem de erro "Não foi possível encontrar o banco de dados da fonte de dados bloqueado".

Grafana 6.1.6 @ Debian 4.9.168 no docker (imagem grafana / grafana: 6.1.6)
InfluxDB

Mesmo problema aqui v.6.1.6

Este parece ser um problema com o próprio sqlite, uma maneira de recuperar o banco de dados sqlite é seguir o procedimento aqui: https://community.grafana.com/t/database-is-locked-unable-to-use-grafana- mais / 16557/2

O erro “banco de dados está bloqueado” indica um problema com seu banco de dados sqlite. Isso pode acontecer se o banco de dados for deixado em um estado inconsistente após um travamento ou se houver problemas com o disco.

Uma coisa que você pode tentar é despejar os dados de seu arquivo db existente em um novo e trocá-lo. De dentro do seu diretório de dados Grafana (após desligar o Grafana):

sqlite3 grafana.db '.clone grafana-new.db'
mv grafana.db grafana-old.db
mv grafana-new.db grafana.db

Temos isso muito sinci grafana 6.2 (usamos auth proxy)

@roidelapluie veja # 17247 para problemas específicos de proxy de autenticação com banco de dados bloqueado

Ok, vamos atualizar para master;) desculpe pelo barulho, minhas habilidades no github me falharam desta vez!

@DanCech não há nada que possa ser feito no Grafana para evitar ou minimizar esse problema? Parece bastante inutilizável para mim deste ponto de vista.

6.2.1 (9e40b07) com backend sqlite, pode confirmar que a clonagem do banco de dados não parece ajudar. Consigo fazer login e salvar algum trabalho, mas sou desconectado intermitentemente com
t=2019-06-04T15:42:33+0000 lvl=eror msg="failed to look up user based on cookie" logger=context error="database is locked" .

Também vejo que meu monitor de saúde raspou no momento certo e atingiu um 503:
curl: (22) The requested URL returned error: 503 Service Unavailable

Fwiw, pareço ser capaz de reproduzi-lo de maneira confiável fazendo algo que gera muitas solicitações de uma vez, como mover vários painéis entre pastas.

Este é um problema que afeta muitos ...

Grafana depois desses erros está fechando a sessão sozinho.

Este é um erro muito grave porque não consigo colocar os monitores e tenho que iniciar a sessão a cada hora e meia.

Eu concordo, sqlite simplesmente não era uma solução utilizável. Grafana iria me desconectar
depois de apenas alguns minutos de uso. Continuaria funcionando, mas eu teria
para entrar novamente.

pelo que vale a pena eu mudei para mysql para grafana há mais de duas semanas e
não tive um único erro, mesmo com vários usuários e vários
fontes de dados.

Na terça, 4 de junho de 2019 às 10:25 juanvmedrano [email protected]
escrevi:

Este é um problema que afeta muitos ...

Grafana depois desses erros está fechando a sessão sozinho.

Este é um erro muito grave porque não consigo colocar os monitores e tenho que
inicie a sessão a cada hora e meia.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/16638?email_source=notifications&email_token=AB7553DCDWT2JP3PVEOJX3LPY2JQ5A5CNFSM4HGQUIUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW5DVLQ#issuecomment-498743982 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AB7553GPXYO2I7RLUVWBGILPY2JQ5ANCNFSM4HGQUIUA
.

O padrão do Grafana para o registro do SQLite é o Rollback Journal (modo DELETE da PRAGMA), que se origina de go-sqlite3. Além disso, go-sqlite3 força-o de volta ao modo DELETE, mesmo se você definir manualmente para WAL (coloque o DB offline e altere PRAGMA journal_mode = wal;)

Mudar para o modo WAL (Write Ahead Log) reduz muitas oportunidades de contenção de bloqueio no banco de dados e provavelmente proporcionaria um aumento de desempenho (https://www.sqlite.org/wal.html). Estamos fazendo isso com uma bifurcação para eliminar erros de bloqueio que aparecem com consultas pesadas do Grafana Alert. Pode valer a pena mudar para o modo WAL.

@davewat Você pode passar a string de conexão diretamente, então algo assim deve funcionar:

[database]
type=sqlite3
connection_string=file:data/grafana.db?cache=private&mode=rwc&_journal_mode=WAL

@davewat Você pode passar a string de conexão diretamente, então algo assim deve funcionar:

[database]
type=sqlite3
connection_string=file:data/grafana.db?cache=private&mode=rwc&_journal_mode=WAL

@DanCech Isso é excelente - obrigado! Isso é muito melhor do que executar uma versão personalizada apenas para o modo WAL! Percebi que você também usou cache privado em seu exemplo, mas a fonte mostra cache compartilhado (também estamos executando cache privado). Acho que privado seria um ambiente mais estável. Não tenho certeza se a escolha do cache compartilhado era para melhor suportar os testes, mas pareceria desnecessário na produção com apenas Grafana acessando o banco de dados.

Em 6.1.6 foi feito configurável e o padrão alterado para privado, mas se você usar a configuração connection_string que é passada diretamente para xorm e por meio de go-sqlite3 e qualquer coisa outra coisa no bloco [database] (além de type ) é praticamente ignorada.

sim, mudar para o jornal WAL fez uma grande diferença para mim. Além de não me desconectar, é muito, muito mais rápido.

@davewat Você pode passar a string de conexão diretamente, então algo assim deve funcionar:

[database]
type=sqlite3
connection_string=file:data/grafana.db?cache=private&mode=rwc&_journal_mode=WAL

Onde posso aplicar essa configuração?

Eu quero tentar isso.

@juanvmedrano você o incluiria em seu arquivo de configuração grafana

@davewat Você pode passar a string de conexão diretamente, então algo assim deve funcionar:

[database]
type=sqlite3
connection_string=file:data/grafana.db?cache=private&mode=rwc&_journal_mode=WAL

Bom, funcionou para mim, mas você tem que alterar o "connection_string = file: data / grafana.db " para o seu caminho grafana.db.

Mesmo problema aqui v.6.1.6 no nfs pv

O mesmo problema aqui em: versão = 6.2.5 commit = 6082d19 branch = HEAD compilado = 2019-06-25T17: 56: 19 + 0000

Mesmo com docker image grafana / grafana: 6.2.5 .

O mesmo aqui (desculpe pelo barulho)
Grafana v6.1.1 (eff01d2)
Sou totalmente novo no Grafana, acabei de adicionar um novo painel vazio + um painel. Esses erros me impedem de usar grafana.

Tentei mudar para WAL (Write Ahead Log) conforme sugerido por @davewat e até agora tudo bem :) (usando-o por 2 horas agora, criei painéis, painéis, sem problemas!)

O mesmo aqui, com grafana em kubernetes com imagem: 'grafana / grafana: 6.2.2 '

Enfrentando o mesmo problema de "banco de dados bloqueado" em minha configuração Grafana v6.4.2 instalada no SUSE 12SP3.
Percebi esse problema apenas depois de atualizar a versão do Grafana de v6.0.x para v6.4.2

-Avin

grafana 6.4.3 no amazon ami 2
nova instalação, usando sqlite padrão
t=2019-10-29T09:26:26+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX time_ms=0 size=29 referer= t=2019-10-29T09:26:38+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX time_ms=0 size=29 referer= t=2019-10-29T09:26:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2019-10-29T09:26:56+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX time_ms=0 size=29 referer= t=2019-10-29T09:27:08+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX time_ms=0 size=29 referer= t=2019-10-29T09:27:17+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX 1 time_ms=0 size=29 referer= t=2019-10-29T09:27:23+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2019-10-29T09:27:26+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX time_ms=0 size=29 referer= t=2019-10-29T09:27:38+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX time_ms=0 size=29 referer= t=2019-10-29T09:27:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2019-10-29T09:27:56+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX time_ms=0 size=29 referer= t=2019-10-29T09:28:03+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2019-10-29T09:28:03+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2019-10-29T09:28:08+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX time_ms=0 size=29 referer= t=2019-10-29T09:28:10+0000 lvl=info msg="Request Completed" logger=context userId=0 orgId=0 uname= method=GET path=/ status=302 remote_addr=XXXX time_ms=0 size=29 referer=
É bastante irritante, já que muitas vezes falha ao listar todos os painéis, exibindo apenas uma parte da lista; na outra ocasião, exibirá a lista, mas falhará ao carregar um painel com 404, após o recarregamento da página está tudo bem.
Usei a dica de https://github.com/grafana/grafana/issues/16638#issuecomment -498818278
mas não parece mudar muito no meu caso.
Quanto à configuração:
~ 30 painéis
~ 5 usuários (não simultâneos)
sem alertas
Vou tentar com o postgres, mas já foi mencionado que também tem problemas

@mbolek , tente usar o WAL conforme sugerido em https://github.com/grafana/grafana/issues/16638#issuecomment -537939123

@marefr hey, eu fiz e ainda tinha problemas. Consegui solucionar esse problema removendo o banco de dados (sem migração, etc.) e começar de novo

Estou vendo o mesmo erro ao implantar em instâncias de contêiner do Azure e montar um volume do compartilhamento de arquivos do Azure (consulte o problema vinculado por marefr). Tentei a solução de @DanCech [aqui]. Isso parece ter funcionado para várias pessoas neste tópico. Infelizmente, não está funcionando para mim. Vejo no log do contêiner que as configurações padrão são substituídas e o arquivo de banco de dados é criado com o nome do meu arquivo ini, mas ainda recebo o mesmo erro: _ "Falha no serviço de inicialização: Falha na migração, erro: banco de dados bloqueado" _.

Meu arquivo ini em sua totalidade:

[database]
type=sqlite3
connection_string=file:/var/lib/grafana/mygrafana.db?_journal_mode=WAL

Alguma indicação sobre o que fazer? Os volumes dos Arquivos do Azure são SMB3. Isso tem algo a ver com o problema?

Meu arquivo de implantação yaml: deploy-gvt-11.yaml.txt
Arquivo de registro de implantação: aci-grafana.log

Qualquer ajuda é muito apreciada!

Olá a todos,

Tenho um problema em que o provisionamento do painel não está funcionando corretamente.
Ele carrega alguns dos meus arquivos .json e não carrega outros, o que causa aleatoriamente uma mensagem de erro "Painel não encontrado". Tenho cerca de 25 arquivos .json.

Em minha investigação desse problema, notei que grafana.log está cheio de mensagens de log "Banco de dados bloqueado". Essa mensagem ocorre cerca de 10 vezes a cada 10 segundos.
Também estou observando que no grafana.db a tabela dashboard_provisioning é sempre atualizada, mas faltam alguns arquivos .json aleatoriamente.
Acho que o bloqueio do banco de dados está relacionado a esse problema. Estou errado ? Existe uma maneira de descobrir a causa do bloqueio do banco de dados?

Meio Ambiente:

Versão Grafana: Grafana v6.5.1
Grafana DB: sqlite
OS Grafana está instalado em: RHEL 7.4
Usuários: menos de 10

Qualquer ajuda é muito apreciada

@ Iziman95 pode estar relacionado ao uso do mesmo uid em vários painéis?

@ Iziman95 pode estar relacionado ao uso do mesmo uid em vários painéis?

obrigado, mas eu já verifiquei isso quando estava procurando uma resposta aqui, todos os meus uids são únicos

@marefr A documentação da grafana descreve como o provisionamento deve funcionar:
"Os painéis serão recarregados quando os arquivos json forem alterados".
Mas é como se eles fossem recarregados permanentemente a cada 5-10 segundos, enquanto não houvesse alterações nesses arquivos. Posso confirmar isso observando a tabela "dashboard_provisioning" e vendo que o "id" aumenta indefinidamente cada vez que faço uma seleção (o valor atual é 2005572) para as mesmas linhas.
Existe uma maneira de obter arquivos .json apenas no início do servidor grafana e não depois?

@ Iziman95 você deve ter configurado algo errado. Algum do seu painel tem um id com um valor numérico? Por acaso você tem vários caminhos configurados, onde um deles é um subdiretório do outro? Se isso não ajudar, sugiro abrir um novo problema com a configuração de provisionamento e os painéis fornecidos para que possamos analisá-lo separadamente deste problema.

@marefr ok, então fiz muitos testes com novos painéis em caminhos diferentes e verifiquei todas as minhas configurações e descobri que a causa raiz era o nome do provedor de propriedade, que era o mesmo em todos os meus arquivos yaml.
Depois de editar meus arquivos yaml para ter um nome exclusivo, meu problema foi resolvido e não tenho mais "banco de dados bloqueado" em meus logs. O tamanho do meu banco de dados também é enorme agora porque a tabela dashboard_version foi atualizada permanentemente com meu painel de +20 a cada 10 segundos.

obrigado pela ajuda

Tive o mesmo problema com o grafana 6.5.1 em um contêiner orquestrado por kubernetes. Eu fiz o seguinte dentro do contêiner:

mv /var/lib/grafana/grafana.db /var/lib/grafana/grafana.db.old
rm /var/lib/grafana/grafana.db
mv /var/lib/grafana/grafana.db.old /var/lib/grafana/grafana.db

após essas etapas funcionou bem.
Talvez meu problema seja porque o contêiner grafana mudou para um nó diferente do Kubernetes e, portanto, o banco de dados foi bloqueado

Se você estiver tentando implantar o Grafana por meio de um contêiner do Serviço de Aplicativo do Azure, isso pode ser útil.

Esse problema também foi apresentado à Microsoft em https://github.com/MicrosoftDocs/azure-docs/issues/47130.

Estou obtendo os mesmos logs de erros durante cargas de trabalho pesadas de E / S (posso reproduzi-los executando um dd no mesmo disco que o da grafana). Meu disco é um disco remoto (Ceph RBD) e durante um dd recebo 100% de utilidade e uma latência muito alta (espera> 10s).

lvl=eror msg="Failed to get system stats" logger=metrics error="database is locked" lvl=eror msg="failed to search for dashboards" logger=provisioning.dashboard type=file name=default error="database is locked" lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"

Estou obtendo os mesmos logs de erros durante cargas de trabalho pesadas de E / S (posso reproduzi-los executando um dd no mesmo disco que o da grafana). Meu disco é um disco remoto (Ceph RBD) e durante um dd recebo 100% de utilidade e uma latência muito alta (espera> 10s).

lvl=eror msg="Failed to get system stats" logger=metrics error="database is locked" lvl=eror msg="failed to search for dashboards" logger=provisioning.dashboard type=file name=default error="database is locked" lvl=eror msg="Could not load alerts" logger=alerting.ruleReader error="database is locked"

_journal_mode = WAL não funcionou para mim. Eu tive que adicionar _busy_timeout na string de conexão também.

Meio Ambiente:
Versão Grafana: Grafana v6.3.5
Grafana DB: sqlite

Com o Grafana como implantação do kubernetes, sem adicionar nenhuma fonte de dados ou painéis, o próprio contêiner do Grafana Docker está lançando msg = "Banco de dados bloqueado, dormindo e depois tentando novamente" logger = erro de sqlstore = "banco de dados está bloqueado" retry = 0

Esse problema observamos após a atualização de 4.6.3 para 6.3.5.

** Observação: o próprio contêiner do Grafana Docker está gerando um erro sem que nenhuma fonte de dados ou painel seja adicionado.

Além disso, o Grafana é implantado como uma implantação Kubernetes, portanto, está sendo programado em vários nós de trabalho com o mesmo erro.

t=2020-03-09T19:03:42+0000 lvl=info msg="HTTP Server Listen" logger=http.server address=0.0.0.0:3000 protocol=http subUrl=/grafana socket= t=2020-03-09T19:03:42+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:42+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=1 t=2020-03-09T19:03:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=1 t=2020-03-09T19:03:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:43+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=1 t=2020-03-09T19:03:44+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:44+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:44+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:44+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:44+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:44+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:44+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0 t=2020-03-09T19:03:44+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0

Tenho esse problema na minha implantação de kubernetes com grafana 6.0.1. Foi quase sistemático, com alguns alertas não carregando (bem aparecendo no painel, mas não na lista de alertas e permanecendo como inativos no painel). Mote: estamos usando painéis provisionados, alertas, etc ...

Alterado para a versão mais recente, grafana 6.7.1, e está muito melhor, problema não reproduzido até agora. Vou atualizar este comentário se o ver novamente no futuro próximo. Mas eu recomendaria a todos que estão tendo esse problema para atualizar grafana

Mesmo problema na imagem docker da grafana mais recente. Usando arquivos do Azure com a opção de montagem uid / gid 65534
msg="Server shutdown" logger=server reason="Service init failed: Migration failed err: database is locked"

Tentei connection_string=file:/var/lib/grafana/grafana.db?cache=private&mode=rwc&_journal_mode=WAL , não funciona.

@torkelo Alguma atualização?

Quase 1 mês e meio depois, https://github.com/grafana/grafana/issues/16638#issuecomment -606605113, com grafana 6.7.1 no cluster k8s criado com kops no AWS, ainda não reproduzido nem uma vez.

Tenho a versão 6.7.3 e ainda estou enfrentando esse problema.

este problema foi resolvido? Estamos enfrentando um problema semelhante.

mesmo problema montado EC2 + EFS.

mesmo problema aqui

Eu resolvi isso, movi temporariamente a pasta de dados para o armazenamento EBS e agora planejo mudar para o armazenamento de anúncios do banco de dados MySQL em EFS

Eu resolvi isso, movi temporariamente a pasta de dados para o armazenamento EBS e agora planejo mudar para o armazenamento de anúncios do banco de dados MySQL em EFS

o que é armazenamento EBS? Tenho o sqllite db da grafana no disco rígido externo com o raspberry, página de login desabilitada e usuário anônimo habilitado. sem resultado, mesmo problema!

O mesmo aqui no Azurefile (7.0.1)

Isso está acontecendo conosco também, mas não estamos usando armazenamento persistente, apenas um emptyDir

Em AKS

Eu encontro o mesmo problema com a versão 7.0.3.

t=2020-06-19T19:55:33+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0
t=2020-06-19T22:24:15+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0
t=2020-06-20T01:23:06+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0
t=2020-06-20T04:12:02+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0
t=2020-06-20T04:12:02+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=1
t=2020-06-20T07:42:16+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=0

O erro recebido no navegador:
A cookie associated with a resource at http://monitoring.sre.idemia.io/ was set with SameSite = Nenhum but without Seguro . A future release of Chrome will only deliver cookies marked SameSite = Nenhum if they are also marked Seguro . You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5633521622188032.

Você pode fornecer uma solução alternativa para esse problema?

Ola pessoal,
Estou executando o 7.0.3 como contêiner do docker diretamente do HUB do docker em um serviço de aplicativo do Azure, mas desde alguns dias ele parou de funcionar. Tenho o banco de dados salvo no Compartilhamento de Arquivos do Azure, mas sempre que me canso de fazer logon, recebo o erro de "Banco de Dados Bloqueado". Mais em detalhes:

2020-06-24T11: 20: 41.558497227Z t = 2020-06-24T11: 20: 41 + 0000 lvl = info msg = "Conectando ao banco de dados" logger = sqlstore dbtype = sqlite3
2020-06-24T11: 20: 41.559484232Z t = 2020-06-24T11: 20: 41 + 0000 lvl = info msg = "Iniciando migração do banco de dados" logger = migrador
2020-06-24T11: 20: 46.689980794Z t = 2020-06-24T11: 20: 46 + 0000 lvl = eror msg = "Server shutdown" logger = server reason = "Service init failed: Migration falhou err: database is locked"

Qualquer solução alternativa ??

@DSalvigni , também estamos enfrentando os mesmos problemas nos últimos dias ... Nenhuma solução alternativa ainda.

Então eu consertei dessa forma, mas antes de começar faça backup localmente do banco de dados sqlite3 (grafana.DB).

1) GF_DATABASE_TYPE = postgresql (ou você pode fazer o mesmo no MySQL)
2) Criou um banco de dados chamado grafana em um servidor postgresql
3) Configure os seguintes parâmetros para o contêiner (no Serviço de Aplicativo):
GF_DATABASE_HOST =
GF_DATABASE_NAME =
GF_DATABASE_PASSWORD =
GF_DATABASE_TYPE =
GF_DATABASE_USER =
3) Mudei o armazenamento persistente montado "/ var / lib / grafana" no Armazenamento de Arquivos do Azure (e me livrei do Blob COntainer).
5) Implementado a partir do Docker HUB a nova versão do Grafana

Agora você tem uma nova versão implantada do grafana clena em execução. Você precisa portar os dados do banco de dados antigo para o novo e para isso eu simplesmente despejei o conteúdo das tabelas de grafana, DB no novo banco de dados grafana criado no postgresql.

Para acessar o grafana.DB usei "SQLiteDatabaseBrowserPortable" e para mover os dados este " https://www.dbsofts.com/ ". A versão de teste limita o mudo a 10.000 linhas, mas mais do que o suficiente para mover a seguinte tabela:

alerta*
org *
painel * (não é necessário se você já tiver despejado seu painel como JSON)
data_source (o mais importante)

Avise-me se precisar de mais perguntas.

Enfrentando o mesmo problema. Grafana sai aleatoriamente e mostra apenas sua página de erro. Nos registros diz

2020-07-07T02:04:03.442792383Z t=2020-07-07T02:04:03+0000 lvl=info msg="Database locked, sleeping then retrying" logger=sqlstore error="database is locked" retry=8166

Reiniciar o contêiner traz Grafana de volta por um tempo.

Usando a imagem docker Grafana 7.0.5 implantada como um serviço de aplicativo no azure. / var / lib / grafana está conectado a um compartilhamento de arquivo.
GF_DATABASE_URL está definido como sqlite3:///var/lib/grafana/grafana.db?cache=private&mode=rwc&_journal_mode=WAL

GF_DATABASE_URL está definido como sqlite3:///var/lib/grafana/grafana.db?cache=private&mode=rwc&_journal_mode=WAL

Isso não funcionou corretamente para mim: o banco de dados permanece sempre bloqueado, então mudei diretamente para um banco de dados externo e o problema foi resolvido, e finalmente posso conectar o BI para vincular o SLA ao backlog de eventos 👍

"O SQLite usa bloqueios de leitor / gravador para controlar o acesso ao banco de dados. (No Win95 / 98 / ME, que não tem suporte para bloqueios de leitor / gravador, uma simulação probabilística é usada em seu lugar.) Mas tenha cuidado: esse mecanismo de bloqueio pode não funcionar corretamente se o arquivo de banco de dados é mantido em um sistema de arquivos NFS. Isso ocorre porque o bloqueio de arquivo fcntl () é interrompido em muitas implementações NFS. Você deve evitar colocar arquivos de banco de dados SQLite no NFS se vários processos tentarem acessar o arquivo ao mesmo tempo. No Windows , A documentação da Microsoft diz que o bloqueio pode não funcionar nos sistemas de arquivos FAT se você não estiver executando o daemon Share.exe. Pessoas que têm muita experiência com o Windows me dizem que o bloqueio de arquivos de rede é muito problemático e não é confiável. Se o quê eles dizem que é verdade, compartilhar um banco de dados SQLite entre duas ou mais máquinas Windows pode causar problemas inesperados. " - esta informação está em https://www.sqlite.org/faq.html

Exibindo um painel com 10s de atualização (fonte de dados de grafite). Os logouts acontecem aleatoriamente, entre 10min e 2-3 horas.

Nova instalação de " https://packages.grafana.com/oss/deb stable main" do Grafana v7.3.0-test (98b94d3824) em um Ubuntu 20.04.1 LTS novo. Grafana está praticamente nas configurações padrão (sqlite).

hardware: 12core 3900x, 64 GB de RAM, HP EX950 nvme (velocidade de leitura / gravação de 2,9 GB / s).

entradas de registro: msg = "Falha ao procurar usuário com base no cookie" logger = erro de contexto = "token de usuário não encontrado"

update: talvez o seguinte erro no log esteja mais relacionado ao logout:

lvl = eror msg = "Erro de proxy de dados" logger = data-proxy-log userId = 2 orgId = 1 uname = xxxxx path = / api / datasources / proxy / 1 / render remote_addr = xxx.xxx.xxx.xxx referer = " http://xxx.xxx.xxx.xxx : 3000 / d / -G-7XccMz / xxxxxx? orgId = 1 & refresh = 10s & from = now-12h & to = now "error =" http: erro de proxy: contexto cancelado "

Atualização: aumentar a rotação do token (padrão de 10 minutos) para 10080 minutos (1 semana) parece ser uma solução alternativa.
--- grafana.ini ---
; token_rotation_interval_minutes = 10
token_rotation_interval_minutes = 10080
--- eof ---

No Azure, finalmente consegui fazê-lo funcionar executando este comando no banco de dados:

sqlite3 grafana.db 'pragma journal_mode=wal;'

Depois disso, substituí o banco de dados usando o explorador de armazenamento do Azure e tudo está funcionando bem a partir daí

mesmo problema aqui com grafana e influxdb

Eu resolvi isso, movi temporariamente a pasta de dados para o armazenamento EBS e agora planejo mudar para o armazenamento de anúncios do banco de dados MySQL em EFS

o que é armazenamento EBS? Tenho o sqllite db da grafana no disco rígido externo com o raspberry, página de login desabilitada e usuário anônimo habilitado. sem resultado, mesmo problema!

Este é o armazenamento em disco rígido para VM (EC2) na AWS, é chamado como EBS

Parece haver vários problemas aqui, na verdade. Um é o problema de bloqueio de banco de dados, que às vezes o Grafana falha em acessar seu banco de dados de usuário. Também existe um problema de tratamento de erros. Caso ocorra esse erro, o servidor retorna com um código de status 401, para o qual o cliente efetua o logout. Porém, este não deve ser um código de status 401, mas sim 500 ou algo semelhante, pois o problema não está na autenticação do cliente, mas no banco de dados do servidor. Então, o cliente ocasionalmente falhava em uma consulta, mas não fazia o logout.

+1

mesmo problema aqui, apenas atualizei para Grafana 7.3.4 de 5.xx e comecei a obter:
t=2020-12-05T14:00:00+0100 lvl=eror msg="Failed to look up user based on cookie" logger=context error="user token not found"
algum tempo depois de logado

Configurações padrão do Grafana com sqlite3
instalado em algum antigo Ubuntu 16.04