Grafana: Seguimiento de Grafana

++

: +1:

asegúrese de que la URL de salud no genere sesiones

: +1:

+1, esto sería muy útil para ejecutar grafana detrás de loadbalancer, loadbalancer llamará al HTTP / health para verificar si grafana devuelve HTTP 200 OK.

Hice algo muy simple, pero no estoy particularmente contento con eso en este momento.

Si alguien quisiera echar un vistazo al estado actual frente al maestro: https://github.com/grafana/grafana/compare/master...theangryangel : feature / health_check

Devuelve 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"}}

La verificación de la base de datos originalmente estaba devolviendo algunas estadísticas, pero lo he eliminado. Podría cambiar la consulta a algo mucho más simple como "seleccionar 1" y verificar que no haya errores. No estoy seguro de si vale la pena.

Tampoco estoy particularmente contento con el cheque de sesión. No parece ser fácil probar sin poner en marcha un servidor de macaron de prueba y recuperarse del pánico que generaría al iniciar un proveedor de sesión, o modificar macaron / sesión para agregar una función de prueba a cada uno de los proveedores. Como está ahora, devuelve un irritante encabezado Set-Cookie, que no quiero particularmente. Agradecería alguna información sobre dónde tomar esto de alguien más experimentado con macaron 😞

Buscar fuentes de datos no parece particularmente sensato para intentarlo, dada la forma en que está escrito Grafana. Probablemente sea más sensato agregarlo a su sistema de monitoreo regular.

Me enfrentaba al mismo problema y, como solución temporal, utilizo una llamada a la API del equilibrador de carga con una clave de API de autenticación dedicada. Estoy usando HAProxy, que tiene una función "oculta" útil para configurar encabezados HTTP personalizados en 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

(Necesito usar HTTP / 1.0 en lugar de 1.1, ya que este último requiere configurar el encabezado del host y no puedo obtenerlo dinámicamente en la configuración de HAProxy).

/api/org parece ser la solicitud más simple con poca sobrecarga y devuelve HTTP 200, que es exactamente lo que necesita el equilibrador de carga, y no crea ninguna sesión nueva.

¿Algún progreso o relaciones públicas en este tema?

+1

Dividiría esto en un punto final separado / liveness y / readiness como es la mejor práctica en kubernetes. / liveness solo indica si grafana está en funcionamiento, / readiness indica si está listo para recibir tráfico y verificará si sus dependencias son accesibles.

En kubernetes, se probará el punto final de vida y, si no responde varias veces con 200 ok, el contenedor se eliminará y se reemplazará por uno nuevo. El punto final de preparación se utiliza para hacer que el contenedor sea parte de un servicio y enviar tráfico a su manera. Como agregarlo y quitarlo de un balanceador de carga.

+1

¿Qué hay de agregar un punto final Prometheus / metrics?

+1

Para quien necesite controles de salud en algunos servicios como Amazon ECS:
Utilice este truco: Ruta /public/img/grafana_icon.svg , Código HTTP: 200.

+1

Mientras tanto, si solo está buscando un HTTP code: 200 simple, use /login . Mi colega y yo acabamos de implementar Grafana en un clúster de Kubernetes y el uso de ese punto final funcionó bien para las sondas de disponibilidad. También funciona para el balanceador de carga de Google Compute Engine.

Piense que todos saben cómo implicar técnicamente esto, pero el punto es apoyar explícitamente el monitoreo del estado del servicio, incluidas las dependencias externas.

Enviado desde mi iPhone

El 5 de diciembre de 2016, a las 4:09 p.m., Hunter Satterwhite [email protected] escribió:

Si está buscando un código HTTP simple: 200, simplemente use / login. Mi colega y yo acabamos de implementar Grafana en un clúster de Kubernetes y el uso de ese punto final funcionó bien para las sondas de disponibilidad. También funciona para el balanceador de carga de Google Compute Engine.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

Me gustaría agregar nuestro caso de uso específico: necesitamos un punto final HTTP simple para verificar si un usuario puede iniciar sesión y mostrar gráficos. Sé que podemos usar los recursos estáticos y los puntos finales como /login para solucionar la ausencia de esto, pero realmente necesitamos algo que verifique que los componentes internos de Grafana se estén ejecutando como se esperaba. No necesariamente necesitamos verificaciones de estado para recuperar datos de fuentes de datos, ya que tenemos verificaciones de estado separadas para ellas.

+1 a esto.

El lunes 5 de diciembre de 2016 a las 11:51 p.m., Philip Wernersbach <
[email protected]> escribió:

Me gustaría agregar nuestro caso de uso específico: necesitamos un punto final HTTP simple para
comprobar si un usuario puede iniciar sesión y mostrar gráficos. Sé que podemos usar el
recursos estáticos y puntos finales como / login para solucionar la ausencia
de esto, pero realmente necesitamos algo que compruebe que el Grafana
los componentes internos funcionan como se esperaba. No necesitamos necesariamente verificaciones de estado
para recuperar datos de fuentes de datos, ya que tenemos controles de estado separados
para esos.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/3302#issuecomment-265060171 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AIESgm7BZw3jqs8ElVWU9v7CjtcXBYFwks5rFOm-gaJpZM4Gm4T8
.

-

[imagen: TransLoc_logos_gear-blue_600x600.png]

Cazador Satterwhite

Ingeniero jefe de construcción y operaciones, TransLoc

Móvil: 252.762.5177 | http://transloc.com http://www.transloc.com/

[imagen: iconos de redes sociales-03.png] https://www.facebook.com/TransLoc/ [imagen:
iconos de redes sociales-04.png] https://www.linkedin.com/company/transloc [imagen:
iconos de redes sociales-02.png] http://www.twitter.com/transloc [imagen: social
media icons-01.png] http://www.instagram.com/transloc_inc

Así que actualmente hay un punto final 4.0 a / api / metrics con algunas métricas internas.

Pero el problema solicita algo como esto

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

Sería bueno con una descripción más detallada de lo que se espera aquí. ¿Debería la llamada de estado de la API hacer una verificación en vivo con todas las fuentes de datos en todas las organizaciones? ¿Debería hacerse sobre la marcha a medida que se realiza la llamada / health api?
¿Qué significa autorización ok?

@torkelo va a lanzar una idea, pero definitivamente creo que / health debería permitir que tanto el servidor grafana como los complementos instalados registren cosas arbitrarias para informar:

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

De forma predeterminada, las comprobaciones de estado realizan comprobaciones en vivo de todas las cosas cuando se llama al punto final. Si las personas quieren aislar las comprobaciones de estado para cosas específicas, puede hacer algo como lo hace elasticsearch para el estado del clúster . Cuando se trata de un servicio externo (autorización, base de datos, etc.), entonces la prueba de conectividad se realiza al mínimo y cualquier otra verificación de cordura que sea razonable (por ejemplo, SELECT 1 para base de datos, prueba de vinculación LDAP para autorización, etc.).

Tener un resultado como este permitirá que las verificaciones de monitoreo verifiquen de manera integral los problemas mientras se encuentran problemas específicos y los resultados en consecuencia.

+1

@torkelo perdón por el retraso en la respuesta, acabo de ver tus preguntas.

TL; DR
@andyfeller hizo un buen trabajo en su comentario y es más o menos lo que tenía en mente

El punto final (o puntos finales) utilizado para monitorear Grafana debe responder 2 preguntas con detalles:
A) ¿Esta instancia de Grafana está activa y lista?
B) ¿Esta instancia de Grafana se está ejecutando como se esperaba de acuerdo con sus intenciones de configuración?

"Intentos de configuración" es clave aquí, lo que quiero decir con intención es que cuando, por ejemplo, el administrador agrega como fuente de datos, espera que esté disponible independientemente de si la configuración guardada es correcta o no. Por lo tanto, si una fuente de datos configurada no está disponible para Grafana, el punto final de monitoreo debería decirlo y por qué, de la misma manera, el botón de "prueba" extremadamente útil funciona.

Me ayuda a pensar en términos de un avión despegando, primero necesito saber que el avión terminó de despegar y está en el aire, luego necesito saber que el avión está volando hacia su destino como se esperaba (no entremos en qué " alcanzar la altitud de crucero "significa ;-))

Esto se puede comparar de alguna manera con / live / ready que otros han señalado o / health (1) / state (2) del modelo Elasticsearch o / health y / info de Sensu (3).
En mi humilde opinión, un punto final es suficiente, pero ver 2 puntos finales en la mayoría de las herramientas modernas es _kinda_ cambiar de opinión; digamos que aún no estoy convencido, ya que creo que B es un subconjunto de A, por lo que haría que el JSON devuelto refleje eso en lugar de tener 2 puntos finales. Entonces, un día cuando Grafana se pueda agrupar, se podrá agregar un "/ cluster_state".

Ahora con respecto a los detalles de cada respuesta, aquí están mis pensamientos iniciales, no exhaustivos:
A detalles:

• Estado (por ejemplo, rojo / amarillo / verde)
• Comentario de estado (por ejemplo, "Todo está bien" / "No se pudo iniciar el componente Foo" / "Iniciando")
• Versión (por ejemplo, v4.1.1-1)

Detalles B:

• Estado de la base de datos (por ejemplo, rojo / amarillo / verde)
• Detalles de la base de datos (por ejemplo, "no se pudo conectar, autenticación incorrecta" o conexión correcta a mySQL v4.1 en xxx.yyy. Zzz : 3306 , versión de esquema v34132, sí, los esquemas de SQL deben tener una versión (4))
• Autenticación / Autorización (por ejemplo, conexión LDAP a xx.xx.xx: 389 ok)
• Fuentes de datos (por ejemplo, fuente de datos 1, tipo Graphite, estado rojo, comentario de estado "error de autenticación, fuente de datos 2, tipo Elasticsearch, estado verde, comentario de estado" todo bien ")

Hay mucho más que puede ir en B, por lo que dividir el monitoreo en 2 puntos finales podría tener más sentido, meh.

En cuanto a cómo hacer lo que sucede cuando se consulta el punto final (sobre la marcha, API, etc.), me referiría a quién termina implementando.

Sin embargo, un par de consejos, ¿obvios?

• Sea muy consciente de los recursos utilizados para recopilar datos de monitoreo y sea muy "protector" con el código de instrumentación, ayude a los administradores de Grafana a evitar situaciones de "mi monitoreo de Grafana derribó a Grafana" o "Grafana se ha ralentizado en un X% desde que comencé a monitorearlo" .

• Esté lo más seguro posible de los datos de monitoreo proporcionados, la fatiga de las alertas es una plaga.

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

Entonces, ¿4.2.0 acaba de salir y todavía no hay forma de probar el servicio? (piense en el clúster k8s)

@torkelo Creo que @dynek tiene razón, esto ya no es opcional. Ya sea que se trate de una nueva sección en los documentos dedicada a "cómo monitorear Grafana" donde se documenta lo que se puede hacer hoy con la instrumentación existente (por ejemplo, aprovechar el administrador o la página de métricas) o una API dedicada completa como en esta propuesta, necesitamos algo para ayer .
Por favor, no se lo tome a mal, no quiero decirle cuáles deberían ser las prioridades, es solo que es difícil vender una aplicación para estar "lista para empresas" sin una parte dedicada a cómo monitorearla.

+1

Se agregó un extremo http simple para verificar el estado de grafana:

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

Si la base de datos (mysql / postgres / sqlite3) no es accesible, devolverá "fallando" en el campo database . Grafana seguirá respondiendo con el código de estado 200. No estoy seguro de qué es correcto en ese caso.

Lo más importante de este punto final es que nunca hará que se creen sesiones (algo que podrían hacer otras llamadas de API si no las llama con una clave de API o autenticación básica).

¿No sería mejor regresar con el código de estado 503 cuando la base de datos es inaccesible?

Kubernetes utiliza:

Cualquier código mayor o igual a 200 y menor a 400 indica éxito. Cualquier otro código indica falla.

Sí, creo que el código de estado 503 cuando el estado de la base de datos falló es mejor, se actualizará

El 503 significa que el punto final /api/health se usa mejor solo para la verificación readiness en Kubernetes. Si esta verificación se usa para liveness un problema en la base de datos provocará la muerte de todos los pods. ¿Existe un parámetro de consulta para omitir la comprobación de la base de datos?

@JorritSalverda probablemente podrías usar tcpSocket cheque en livenessProbe

/metrics no creará sesiones ni emitirá una solicitud de base de datos.

Por lo general, tenemos controles de preparación agresivos y controles de vitalidad relajados, 1 segundo, 1 falla para la preparación, mientras que son 60 segundos 10 falla 1 éxito para la vivacidad, esto permite un cambio de ruta receptivo cuando hay un problema, pero al mismo tiempo si la auto recuperación posible, evita reinicios innecesarios del pod. Pero un problema persistente de la base de datos provocaría el reinicio, lo que en realidad podría ayudar si se debiera a un mal estado del contenedor.