Grafana: Surveillance de Grafana

++

: +1:

assurez-vous que l'URL de santé ne génère pas de sessions

: +1:

+1, ce serait très utile pour exécuter grafana derrière loadbalancer, loadbalancer appellera le HTTP / health pour vérifier si grafana renvoie HTTP 200 OK.

J'ai mis en place quelque chose de très simple, mais je n'en suis pas particulièrement satisfait pour le moment.

Si quelqu'un souhaite jeter un oeil à l'état actuel par rapport au maître: https://github.com/grafana/grafana/compare/master...theangryangel : feature / health_check

Il renvoie quelque chose comme:

{"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 vérification de la base de données Je renvoyais à l'origine des statistiques, mais j'ai supprimé cela. Je pourrais passer la requête à quelque chose de beaucoup plus simple comme "sélectionner 1" et vérifier qu'il n'y a pas d'erreur. Je ne sais pas si ça vaut le coup.

Je ne suis pas particulièrement satisfait du contrôle de session non plus. Il ne semble pas être facile de tester sans lever un serveur de test macaron et récupérer () de la panique qu'il déclencherait lors du démarrage d'un fournisseur de session, ou de modifier le macaron / session pour ajouter une fonctionnalité de test à chacun des fournisseurs. Dans l'état actuel des choses, il est irritant de renvoyer un en-tête Set-Cookie, ce que je ne veux pas particulièrement. J'apprécierais que quelqu'un de plus expérimenté avec le macaron puisse donner son avis sur ce sujet?

La recherche de sources de données ne semble pas particulièrement sensée d'essayer cela étant donné la façon dont grafana est écrite. Probablement plus sain d'esprit à ajouter à votre système de surveillance régulier.

J'étais confronté au même problème et comme solution de contournement, j'utilise un appel API de l'équilibreur de charge avec une clé API d'authentification dédiée. J'utilise HAProxy, qui a une fonction "cachée" utile pour définir des en-têtes HTTP personnalisés dans 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

(Je dois utiliser HTTP / 1.0 plutôt que 1.1, car ce dernier nécessite de définir l'en-tête Host et je ne peux pas l'obtenir dynamiquement dans la configuration HAProxy)

/api/org semble être la requête la plus simple avec peu de frais généraux et renvoie HTTP 200, ce qui est exactement ce dont l'équilibreur de charge a besoin - et ne crée aucune nouvelle session.

Des progrès ou des relations publiques sur cette question?

+1

Je diviserais cela en un point de terminaison séparé / viveness et / readiness, comme c'est le cas pour kubernetes. / liveness indique seulement si grafana lui-même est opérationnel, / readiness indique s'il est prêt à recevoir du trafic et vérifiera si ses dépendances sont accessibles.

Dans kubernetes, le point de terminaison de vivacité sera sondé et en cas d'échec à plusieurs reprises pour répondre avec 200 ok, le conteneur sera tué et remplacé par un nouveau. Le point de terminaison de disponibilité est utilisé pour intégrer le conteneur à un service et envoyer le trafic. Comme l'ajouter et le supprimer d'un équilibreur de charge.

+1

qu'en est-il de l'ajout d'un point de terminaison / metrics Prometheus?

+1

Pour tous ceux qui ont besoin de contrôles de santé sur certains services comme Amazon ECS:
Utilisez ce hack: Chemin /public/img/grafana_icon.svg , Code HTTP: 200.

+1

En attendant, si vous recherchez uniquement un simple HTTP code: 200 , utilisez simplement /login . Mon collègue et moi venons de déployer Grafana sur un cluster Kubernetes et l'utilisation de ce point de terminaison a très bien fonctionné pour les sondes de vivacité / préparation. Fonctionne également pour l'équilibreur de charge Google Compute Engine.

Pensez que tout le monde sait comment l'impliquer techniquement, mais le but est de prendre en charge explicitement la surveillance de l'intégrité du service, y compris les dépendances externes.

Envoyé de mon iPhone

Le 5 décembre 2016, à 16 h 09, Hunter Satterwhite [email protected] a écrit:

Si vous recherchez un code HTTP simple: 200, utilisez simplement / login. Mon collègue et moi venons de déployer Grafana sur un cluster Kubernetes et l'utilisation de ce point de terminaison a très bien fonctionné pour les sondes de vivacité / préparation. Fonctionne également pour l'équilibreur de charge Google Compute Engine.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

J'aimerais ajouter notre cas d'utilisation spécifique: nous avons besoin d'un simple point de terminaison HTTP pour vérifier si un utilisateur peut se connecter et afficher des graphiques. Je sais que nous pouvons utiliser les ressources statiques et les points de terminaison tels que /login pour contourner cette absence, mais nous avons vraiment besoin de quelque chose qui vérifie que les internes de Grafana fonctionnent comme prévu. Nous n'avons pas nécessairement besoin de vérifications d'état pour récupérer des données à partir de sources de données, car nous avons des vérifications d'état distinctes pour celles-ci.

+1 à cela.

Le lun 5 décembre 2016 à 23 h 51, Philip Wernersbach <
[email protected]> a écrit:

J'aimerais ajouter notre cas d'utilisation spécifique: nous avons besoin d'un simple point de terminaison HTTP pour
vérifier si un utilisateur peut se connecter et afficher des graphiques. Je sais que nous pouvons utiliser le
ressources statiques et points de terminaison tels que / login pour contourner l'absence
de cela, mais nous avons vraiment besoin de quelque chose qui vérifie que le Grafana
les composants internes fonctionnent comme prévu. Nous n'avons pas nécessairement besoin de contrôles de statut
pour récupérer des données à partir de sources de données, car nous avons des contrôles de santé séparés
pour ceux.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/grafana/grafana/issues/3302#issuecomment-265060171 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AIESgm7BZw3jqs8ElVWU9v7CjtcXBYFwks5rFOm-gaJpZM4Gm4T8
.

-

[image: TransLoc_logos_gear-blue_600x600.png]

Chasseur Satterwhite

Ingénieur en chef de la construction et des opérations, TransLoc

Cellulaire: 252.762.5177 | http://transloc.com http://www.transloc.com/

[image: icônes de médias sociaux-03.png] https://www.facebook.com/TransLoc/ [image:
icônes de médias sociaux-04.png] https://www.linkedin.com/company/transloc [image:
icônes de médias sociaux-02.png] http://www.twitter.com/transloc [image: social
media icons-01.png] http://www.instagram.com/transloc_inc

Il existe donc actuellement un point de terminaison 4.0 a / api / metrics avec des métriques internes.

Mais le problème demande quelque chose comme ça

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

Ce serait bien avec une description plus détaillée de ce qui est attendu ici. L'appel de santé de l'API doit-il effectuer une vérification en direct avec toutes les sources de données dans toutes les organisations? doit-il être effectué à la volée lors de l'appel de / health api?
Que signifie autorisation ok?

@torkelo va lancer une idée mais pense définitivement que / health devrait permettre à la fois au serveur grafana et aux plugins installés d'enregistrer des éléments arbitraires à signaler:

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

Par défaut, les vérifications de l'état effectuent des vérifications en direct de toutes les choses lorsque le point final est appelé. Si les utilisateurs souhaitent isoler les vérifications de l'état de choses spécifiques, vous pouvez faire quelque chose comme elasticsearch fait pour l'intégrité du cluster . Quand une chose est un service externe (autorisation, base de données, etc.), alors le test de connectivité est effectué au minimum et tout autre contrôle de cohérence raisonnable pour la chose (par exemple SELECT 1 pour la base de données, test de liaison LDAP pour l'autorisation, etc.).

Avoir une sortie comme celle-ci permettra de surveiller les vérifications pour vérifier de manière holistique les problèmes tout en trouvant des problèmes spécifiques et en sortie en conséquence.

+1

@torkelo désolé pour la réponse retardée vient de voir vos questions.

TL; DR
@andyfeller a fait du bon travail dans son commentaire et c'est à peu près ce que j'avais en tête

Le point final (ou les points finaux) utilisé pour surveiller Grafana doit répondre à 2 questions avec des détails:
A) Cette instance Grafana est-elle prête et prête?
B) Cette instance Grafana fonctionne-t-elle comme prévu selon ses intentions de configuration?

«Les intentions de configuration» sont essentielles ici, ce que j'entends par intention est que lorsque, par exemple, l'administrateur ajoute comme source de données, elle s'attend à ce qu'elles soient disponibles, que la configuration enregistrée soit correcte ou non. Ainsi, si une source de données configurée n'est pas disponible pour Grafana, le point de terminaison de surveillance doit le dire et pourquoi, de la même manière, le bouton "test" extrêmement utile fonctionne.

Cela m'aide à penser en termes d'avion qui décolle, d'abord j'ai besoin de savoir que l'avion a fini de décoller et qu'il est en l'air, puis j'ai besoin de savoir que l'avion vole vers sa destination comme prévu (n'entre pas dans quoi " atteindre l'altitude de croisière "signifie ;-))

Cela peut être quelque peu comparé au / live / ready que d'autres ont souligné ou / health (1) / state (2) du modèle Elasticsearch ou / health et / info de Sensu (3).
IMHO un point de terminaison est suffisant, mais voir 2 points de terminaison dans la plupart des outils modernes est _kinda_ en train de changer d'avis; disons simplement que je ne suis pas encore convaincu car je pense que B est un sous-ensemble de A donc je ferais que le JSON retourné reflète cela au lieu d'avoir 2 points de terminaison. Puis un jour où Grafana peut être mis en cluster, un "/ cluster_state" peut être ajouté.

Maintenant, concernant les détails de chaque réponse, voici mes premières réflexions - non exhaustives -:
Un détail:

• État (par exemple rouge / jaune / vert)
• Commentaire d'état (par exemple "Tout va bien" / "Impossible de démarrer le composant Foo" / "Démarrage")
• Version (par exemple v4.1.1-1)

Détails B:

• État du DB (par ex. Rouge / jaune / vert)
• Détails de la base de données (par exemple "impossible de se connecter, mauvaise auth", ou connexion ok à mySQL v4.1 à xxx.yyy. Zzz : 3306 , version de schéma v34132, oui les schémas SQL doivent être versionnés (4))
• Authentification / Autorisation (par exemple connexion LDAP à xx.xx.xx: 389 ok)
• Sources de données (par exemple, source de données 1, type Graphite, état rouge, commentaire d'état "échec d'authentification, source de données 2, type Elasticsearch, état vert, commentaire d'état" tout bon ")

Il y a beaucoup plus qui peut aller dans B, c'est pourquoi diviser la surveillance en 2 points finaux pourrait avoir plus de sens, meh.

Quant à savoir comment gérer ce qui se passe lorsque le point final est interrogé (à la volée, API, etc.), je m'en remettrais à celui qui finira par implémenter.

Quelques conseils - évidents? - cependant:

• soyez très attentif aux ressources utilisées pour collecter les données de surveillance et soyez très «protecteur» avec le code d'instrumentation, aidez les administrateurs de Grafana à éviter les situations «ma surveillance de Grafana a fait tomber Grafana» ou «Grafana a ralenti de X% depuis que j'ai commencé à le surveiller» .

• soyez aussi sûr que possible des données de surveillance fournies, la fatigue d'alerte est un fléau

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

Donc 4.2.0 vient de sortir et il n'y a toujours aucun moyen de sonder le service? (pensez au cluster k8s)

@torkelo Je pense que @dynek a
S'il vous plaît, ne le prenez pas mal, je ne veux pas vous dire quelles devraient être les priorités, c'est juste qu'il est difficile de vendre une application "Enterprise Ready" sans une partie dédiée à la façon de la surveiller.

+1

Ajout d'un simple point de terminaison http pour vérifier l'état de santé de grafana:

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

Si la base de données (mysql / postgres / sqlite3) n'est pas accessible, elle retournera «échec» dans le champ database . Grafana répondra toujours avec le code d'état 200. Je ne sais pas ce qui est correct dans ce cas.

La chose la plus importante à propos de ce point de terminaison est qu'il ne provoquera jamais la création de sessions (ce que d'autres appels d'API pourraient faire si vous ne les appelez pas avec une clé API ou une authentification de base).

Ne serait-il pas préférable de revenir avec le code d'état 503 lorsque la base de données est inaccessible?

Kubernetes utilise:

Tout code supérieur ou égal à 200 et inférieur à 400 indique une réussite. Tout autre code indique un échec.

Oui, je pense que le code d'état 503 lorsque l'état de la base de données a échoué est le meilleur, sera mis à jour

Le 503 signifie que le point /api/health terminaison readiness dans Kubernetes. Si cette vérification est utilisée pour liveness un problème de base de données entraînera la destruction de tous les pods. Existe-t-il un paramètre de requête pour omettre la vérification de la base de données?

@JorritSalverda vous pourriez probablement utiliser tcpSocket check in livenessProbe

/metrics ne créera pas de sessions ou n'émettra pas de requête de base de données.

nous avons généralement des contrôles de préparation agressifs et des contrôles de vivacité détendus, 1 seconde, 1 échec pour la préparation, alors que c'est 60 secondes 10 échecs 1 succès pour la vivacité, cela permet un réacheminement réactif en cas de problème, mais en même temps si la récupération automatique est possible, empêche les redémarrages inutiles du pod. Mais un problème de base de données persistant entraînerait un redémarrage, ce qui pourrait en fait aider s'il était dû à un mauvais état du conteneur.