Grafana: Monitorando Grafana

++

: +1:

certifique-se de que o url de saúde não gera sessões

: +1:

+1, isso seria muito útil para executar grafana atrás do loadbalancer, loadbalancer irá chamar o HTTP / health para verificar se grafana retorna HTTP 200 OK.

Eu montei algo muito simples, mas não estou particularmente feliz com isso no momento.

Se alguém quiser dar uma olhada no estado atual vs master: https://github.com/grafana/grafana/compare/master...theangryangel : feature / health_check

Ele retorna algo como:

{"current_timestamp":"2016-06-04T18:43:49+01:00","database_ok":true,"session_ok":true,"version":{"built":1464981754,"commit":"v3.0.4+158-g7cbaf06-dirty","version":"3.1.0"}}

A verificação do banco de dados originalmente estava retornando algumas estatísticas, mas eu cortei isso. Eu poderia mudar a consulta para algo muito mais simples como "selecione 1" e verificar se não há erro. Não tenho certeza se vale a pena.

Não estou particularmente satisfeito com a verificação da sessão. Não parece ser fácil testar sem levantar um servidor de macaron de teste e se recuperar do pânico que seria lançado ao iniciar um provedor de sessão ou modificar o macaron / sessão para adicionar um recurso de teste a cada um dos fornecedores. Como está agora, é irritante retornar um cabeçalho Set-Cookie, que eu particularmente não quero. Eu gostaria de receber alguma contribuição de alguém mais experiente com macaron 😞

Verificar as fontes de dados não parece particularmente lógico tentar fazer isso, dada a forma como o grafana é escrito. Provavelmente mais sensato para adicionar ao seu sistema de monitoramento regular.

Eu estava enfrentando o mesmo problema e, como solução alternativa, uso uma chamada de API do balanceador de carga com uma chave de API de autenticação dedicada. Estou usando o HAProxy, que tem alguns recursos "ocultos" úteis de configuração de cabeçalhos HTTP personalizados em option httpchk :

option httpchk GET /api/org HTTP/1.0\r\nAccept:\ application/json\r\nContent-Type:\ application/json\r\nAuthorization:\ Bearer\ your_api_key\r\n

(Preciso usar HTTP / 1.0 em vez de 1.1, já que o último requer a configuração do cabeçalho do Host e não consigo obtê-lo dinamicamente na configuração do HAProxy).

/api/org parece ser a solicitação mais simples com pouca sobrecarga e retorna HTTP 200, que é exatamente o que o balanceador de carga precisa - e não cria novas sessões.

Algum progresso ou RP sobre esse assunto?

+1

Eu dividiria isso em um ponto de extremidade / liveness e / readiness separado, como é a prática recomendada em kubernetes. / liveness indica apenas se o próprio grafana está instalado e funcionando, / readiness indica se está pronto para receber tráfego e verificará se suas dependências estão acessíveis.

No kubernetes, o endpoint de ativação será testado e, ao falhar várias vezes para responder com 200 ok, o contêiner será eliminado e substituído por um novo. O ponto de extremidade de prontidão é usado para tornar o contêiner parte de um serviço e enviar tráfego para ele. Como adicionar e remover de um balanceador de carga.

+1

que tal adicionar um endpoint Prometheus / metrics?

+1

Para quem precisa de verificações de saúde em alguns serviços como Amazon ECS:
Use este hack: Caminho /public/img/grafana_icon.svg , Código HTTP: 200.

+1

Nesse meio tempo, se você estiver procurando apenas um simples HTTP code: 200 , use apenas /login . Meu colega e eu acabamos de implantar o Grafana em um cluster Kubernetes e usar esse endpoint funcionou muito bem para as sondagens de ativação / preparação. Também funciona para o balanceador de carga do Google Compute Engine.

Acho que todo mundo sabe como implicar isso tecnicamente, mas o objetivo é oferecer suporte explícito ao monitoramento da integridade do serviço, incluindo dependências externas.

Enviado do meu iPhone

Em 5 de dezembro de 2016, às 16h09, Hunter Satterwhite [email protected] escreveu:

Se você está procurando um código HTTP simples: 200, basta usar / login. Meu colega e eu acabamos de implantar o Grafana em um cluster Kubernetes e usar esse endpoint funcionou muito bem para as sondagens de ativação / preparação. Também funciona para o balanceador de carga do Google Compute Engine.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Eu gostaria de adicionar nosso caso de uso específico: precisamos de um ponto de extremidade HTTP simples para verificar se um usuário pode fazer login e exibir gráficos. Eu sei que podemos usar os recursos estáticos e endpoints como /login para contornar a ausência disso, mas realmente precisamos de algo que verifique se os componentes internos do Grafana estão funcionando conforme o esperado. Não precisamos necessariamente de verificações de status para recuperar dados de fontes de dados, pois temos verificações de saúde separadas para elas.

+1 para isso.

Na segunda-feira, 5 de dezembro de 2016 às 23h51, Philip Wernersbach <
notificaçõ[email protected]> escreveu:

Eu gostaria de adicionar nosso caso de uso específico: precisamos de um ponto de extremidade HTTP simples para
verificar se um usuário pode fazer o login e exibir gráficos. Eu sei que podemos usar o
recursos estáticos e endpoints como / login para contornar a ausência
disso, mas realmente precisamos de algo que verifique se o Grafana
internos estão funcionando conforme o esperado. Não precisamos necessariamente de verificações de status
para recuperar dados de fontes de dados, pois temos verificações de saúde separadas
para aqueles.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/3302#issuecomment-265060171 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AIESgm7BZw3jqs8ElVWU9v7CjtcXBYFwks5rFOm-gaJpZM4Gm4T8
.

-

[image: TransLoc_logos_gear-blue_600x600.png]

Hunter Satterwhite

Engenheiro líder de construção e operações, TransLoc

Célula: 252.762.5177 | http://transloc.com http://www.transloc.com/

[image: social media icons-03.png] https://www.facebook.com/TransLoc/ [image:
social media icons-04.png] https://www.linkedin.com/company/transloc [imagem:
social media icons-02.png] http://www.twitter.com/transloc [imagem: social
media icons-01.png] http://www.instagram.com/transloc_inc

Portanto, há atualmente em 4.0 a / api / metrics endpoint com algumas métricas internas.

Mas o problema exige algo assim

{ "date_sources_ok": True, "database_ok": True, "authorization_ok": True, "grafana_version": "2.5.1" }

Seria bom com uma descrição mais detalhada do que é esperado aqui. A chamada de integridade da API deve fazer uma verificação ao vivo com todas as fontes de dados em todas as organizações? deve ser feito em tempo real enquanto a chamada de api / health é feita?
O que significa autorização ok?

@torkelo vai lançar uma ideia, mas definitivamente acho que / health deve permitir que tanto o grafana-server quanto os plug-ins instalados registrem coisas arbitrárias para relatar:

{
    "ok": false,
    "items": [
        "datasources": {
            "ok": true,
        },
        "database": {
            "ok": false,
            "msg": "Cannot communicate ###.###.###.###/XXXXXXX"
        },
        ...
    ]
}

Por padrão, as verificações de saúde executam verificações ao vivo de todas as coisas quando o endpoint é chamado. Se as pessoas quiserem isolar as verificações de saúde para coisas específicas, você pode fazer algo como o elasticsearch faz para a saúde do cluster . Quando algo é um serviço externo (autorização, banco de dados, etc), então o teste de conectividade é feito no mínimo e qualquer outra verificação de sanidade que seja razoável para algo (por exemplo, SELECT 1 para banco de dados, teste de ligação LDAP para autorização, etc).

Ter uma saída como essa permitirá que as verificações de monitoramento verifiquem de forma holística os problemas enquanto encontram problemas específicos e geram resultados de acordo.

+1

@torkelo desculpe pela demora na resposta acabei de ver suas dúvidas.

TL; DR
@andyfeller fez um bom trabalho em seu comentário e é basicamente o que eu tinha em mente

O ponto final (ou pontos finais) usado para monitorar Grafana deve responder a 2 perguntas com detalhes:
A) Esta instância Grafana está ativa e pronta?
B) Esta instância do Grafana está funcionando conforme o esperado de acordo com seus objetivos de configuração?

"intenções de configuração" é a chave aqui, o que quero dizer com intenção é que quando, por exemplo, o administrador adiciona como uma fonte de dados, ela espera que esteja disponível independentemente de a configuração salva estar correta ou não. Assim, se uma fonte de dados configurada não estiver disponível para o Grafana, o ponto final de monitoramento deve dizer isso e por que, da mesma forma o botão "testar" extremamente útil funciona.

Isso me ajuda a pensar em termos de um avião decolando, primeiro eu preciso saber se o avião terminou de decolar e está no ar, então eu preciso saber se o avião está voando em direção ao seu destino como esperado (não vamos entrar no que " atingir a altitude de cruzeiro "significa ;-))

Isso pode ser um pouco comparado ao / live / ready que outros apontaram ou / health (1) / state (2) do modelo Elasticsearch ou / health e / info de Sensu (3).
IMHO um endpoint é suficiente, mas ver 2 endpoints na maioria das ferramentas modernas está _ meio_ mudando de ideia; digamos que ainda não estou persuadido, pois acho que B é um subconjunto de A, então faria o JSON retornado refletir isso em vez de ter 2 pontos finais. Então, um dia, quando Grafana puder ser agrupado, um "/ cluster_state" poderá ser adicionado.

Agora, em relação aos detalhes de cada resposta, aqui estão minhas - não exaustivas - idéias iniciais:
Detalhes A:

• Status (por exemplo, vermelho / amarelo / verde)
• Comentário de status (por exemplo, "Tudo está bom" / "Não foi possível iniciar o componente Foo" / "Iniciando")
• Versão (por exemplo, v4.1.1-1)

Detalhes B:

• Status do banco de dados (por exemplo, vermelho / amarelo / verde)
• Detalhes do banco de dados (por exemplo, "não foi possível conectar, autenticação inválida" ou conexão ok com mySQL v4.1 em xxx.yyy. Zzz : 3306 , versão do esquema v34132, sim, os esquemas SQL devem ter controle de versão (4))
• Autenticação / autorização (por exemplo, conexão LDAP para xx.xx.xx: 389 ok)
• Fontes de dados (por exemplo, fonte de dados 1, tipo Grafite, status vermelho, comentário de status "falha de autenticação, fonte de dados 2, tipo Elasticsearch, status verde, comentário de status" tudo bom ")

Há muito mais que pode ir em B, e é por isso que dividir o monitoramento em 2 pontos finais pode fazer mais sentido, meh.

Sobre como fazer o que acontece quando o ponto de extremidade está sendo consultado (em tempo real, APIs, etc.), eu recomendaria quem acabaria implementando.

Alguns conselhos - óbvios?

• esteja muito atento aos recursos usados ​​para coletar dados de monitoramento e seja muito "protetor" com o código de instrumentação, ajude os administradores do Grafana a evitar "meu monitoramento do Grafana derrubou o Grafana" ou "O Grafana diminuiu em X% desde que comecei a monitorar" situações .

• esteja o mais certo possível sobre os dados de monitoramento fornecidos, a fadiga do alerta é uma praga

(1) https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html
(2) https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state.html
(3) https://sensuapp.org/docs/0.23/api/health-and-info-api.html#the -info-api-endpoint
(4) https://blog.codinghorror.com/get-your-database-under-version-control/

Então 4.2.0 acabou de sair e ainda não há como testar o serviço? (pense no cluster k8s)

@torkelo Eu acho que @dynek tem
Por favor, não interprete mal, não quero dizer quais devem ser as prioridades. É apenas que é difícil vender um aplicativo para ser "Enterprise Ready" sem uma parte dedicada a como monitorá-lo.

+1

Adicionado um endpoint HTTP simples para verificar a integridade do grafana:

GET /api/health 
{
  "commit": "349f3eb",
  "database": "ok",
  "version": "4.1.0"
}

Se o banco de dados (mysql / postgres / sqlite3) não for alcançável, ele retornará "falha" no campo database . Grafana ainda responderá com o código de status 200. Não tenho certeza do que é correto nesse caso.

O mais importante sobre esse endpoint é que ele nunca fará com que as sessões sejam criadas (algo que outras chamadas de API podem fazer se você não as chamar com uma chave de API ou autenticação básica).

Não seria melhor retornar com o código de status 503 quando o banco de dados estiver inacessível?

O Kubernetes usa:

Qualquer código maior ou igual a 200 e menor que 400 indica sucesso. Qualquer outro código indica falha.

Sim, eu acho que o código de status 503 quando o status do banco de dados falhou é o melhor, atualizará

O 503 significa que o endpoint /api/health só é melhor usado para a verificação readiness no Kubernetes. Se esta verificação for usada para liveness um problema de banco de dados fará com que todos os pods sejam eliminados. Existe um parâmetro de consulta para deixar de fora a verificação do banco de dados?

@JorritSalverda você provavelmente poderia usar tcpSocket cheque em livenessProbe

/metrics não criará sessões ou emitirá uma solicitação de banco de dados.

normalmente temos verificações de prontidão agressivas e verificações de atividade relaxadas, 1 segundo, 1 falha para prontidão, enquanto é de 60 segundos 10 falha 1 sucesso para vivacidade, isso permite um redirecionamento responsivo quando há um problema, mas ao mesmo tempo se a auto-recuperação é possível, evita reinicializações desnecessárias do pod. Mas um problema persistente de banco de dados causaria a reinicialização, o que poderia realmente ajudar se fosse devido a algum estado inválido do contêiner.