Salt (Saltstack) peut-il collecter et relayer des données pour Graphite, Ganglia ou Zenoss?


11

Je démarre un nouveau projet et envisage d'utiliser Ansible ou Salt pour l'automatisation du déploiement et, peut-être, une orchestration plus sophistiquée (gestion et fédération de serveurs).

Avec Salt, je me demande s'il y a une intégration entre Graphite ou Zenoss ou Ganglia ... en utilisant les connexions Salt 0mq pour relayer les données des "sbires" de Salt vers la base de données / collecteurs de surveillance / graphique.

Quelqu'un d'autre a-t-il examiné cela?


Pouvez-vous expliquer ce que vous cherchez à faire plus en détail, s'il vous plaît? De quel type d'interrogatoire avez-vous besoin?
jamieb

3
Il y a un nouveau projet appelé Salmon qui vise à être un système de surveillance à part entière utilisant Salt comme mécanisme de collecte de données et de transport de messages. Il utilise Whisper comme base de données, vous pouvez donc éventuellement l'intégrer dans Graphite si vous le vouliez vraiment.
jgoldschrafe

Réponses:


9

j'ai utilisé salt-stack depuis plus de 6 mois maintenant pour gérer plus de 40 nœuds.

dans ma configuration actuelle, j'utilise:

  • Icinga comme serveur de surveillance
  • NRPE pour l'exécution des contrôles sur les nœuds
  • le graphite collecte les données des nœuds collectés
  • collecté pour collecter et pousser les métriques vers le graphite
  • gdash pour un joli tableau de bord pour visualiser les métriques de grahite
  • salt-stack et enfin salt-stack pour déployer les configurations pour NRPE / Collectd sur chaque nœud

comme cela fonctionne sous CentOS 6.x

mon expérience jusqu'à présent est que la pile de sel est bonne pour tout inscrire. Mais en tant que démon à long terme sur les nœuds, ce n'est pas stable.

J'ai souvent des problèmes pour ne pas atteindre le maître ou les ballonnements de mémoire sur les sbires. Cela peut être corrigé avec une solution de contournement facile que vous redémarrez toutes les 24 heures / une fois par semaine les sbires.

mais ce problème dans salt-minion ne permet pas de collecter des données sur le framework 0mq.

ma configuration actuelle fonctionne en toute sécurité. Je peux enregistrer des modifications assez rapidement avec salt-stack et collectd sur les nœuds fait l'affaire.


Je ne voulais pas voter contre cela, mais l'honnêteté et la décence m'ont forcé à le faire. Ils sont certainement conscients de la formidable possibilité de fournir un transport généralisé pour les métriques. J'en fais déjà une partie via la mine de sel.
Dan Garthwaite

Pourquoi collecter sur [py] statsd?
Dan Garthwaite du

4

Je pense que Salt ou Ansible ne sont pas créés pour cette tâche et je pense qu'ils ne peuvent pas être utilisés à cette fin.

J'utilise Salt depuis plusieurs mois et je n'ai pas remarqué d'options de fonctions que vous souhaitez (dans les configs ni dans la documentation). Mais je pense que vous pouvez "ajouter" vos exigences car Salt est écrit en python - si c'est une option.

Le moyen le plus simple est de commander du sel pour installer collectd qui peut collecter des données sur le système (et dispose de connecteurs pour graphite)

EDIT: J'ai trouvé un projet qui implémente la surveillance à l'aide de sel - saumon - jetez un oeil.


collectd a également été ma première pensée.
J Adams

sel-moniteur n'est pas maintenu github.com/thatch45/salt-monitor
Itai Frenkel

3

Vous voudrez peut-être jeter un œil à Sensu , c'est une solution de surveillance enfichable avec de nombreux plugins de communauté, y compris le graphite entre autres.

Cependant, Sensu utilise une autre file d'attente de messagerie pour livrer les messages, RabbitMQ . Peut-être qu'un certain travail de codage est nécessaire, mais vous pouvez essayer de remplacer l'une des deux files d'attente de messagerie, car les deux devraient utiliser le protocole AMQ pour échanger des messages.


2

Je vous recommande d'examiner deux choses: Salt Mine - http://docs.saltstack.com/topics/mine/ Salt Events - http://docs.saltstack.com/topics/event/index.html

Si vous les combinez avec votre propre configuration de configuration de retour pour stocker les résultats dans le graphite, ou l'un des autres que vous avez répertoriés. On pourrait imaginer utiliser Salt pour gérer le «sondage» de haut en bas et «l'événement» de bas en haut. Je ne serais pas en mesure de commenter l'efficacité d'un tel système, mais en principe, il semble y avoir une possibilité.


La caractéristique non encore réalisée de Salt est qu'il s'agit d'un bus d'événements de topologie en étoile sécurisé. J'utilise le mien de sel pour exécuter et stocker check_mk_agent, et un check_mk sur le serveur nagios le tire de la mine.
Dan Garthwaite

2

J'ai décrit mon parcours vers la surveillance des nagios en moins d'une seconde par hôte via la mine de sel et check_mk ici: http://garthwaite.org/saltmine_check_mk_agent.html

L'article passe en revue des semaines de bricolage pour que tout fonctionne. Je résume la solution:

Créez un module check_mk personnalisé pour tous les serviteurs:

#!/usr/bin/env python
''' Support for running check_mk_agent over salt '''
import os
import salt.utils
from salt.exceptions import SaltException

def __virtual__():
    ''' Only load the module if check_mk_agent is installed '''
    if os.path.exists('/usr/bin/check_mk_agent'):
        return 'check_mk'
    return False

def agent():
    ''' Return the output of check_mk_agent '''
    return __salt__['cmd.run']('/usr/bin/check_mk_agent')

Définissez l'intervalle de mine de Minion à une minute:

salt '*' file.append /etc/salt/minion.d/mine.conf "mine_interval: 1"

Configurez le serveur de surveillance pour extraire toutes les sorties check_mk_agent du serviteur dans un seul fichier json, puis configurez check_mk pour interroger ce fichier au lieu de toutes les requêtes réseau. Tout est accompli avec le script suivant sur le serviteur de surveillance:

#!/usr/bin/env python
import sys
import json
import fcntl

DATAFILE="/dev/shm/cmk.json"
NAG_UID = 105
NAG_GID = 107

def do_update():
    import os
    import salt.client

    caller = salt.client.Caller()
    data = caller.function('mine.get', '*', 'check_mk.agent')

    lockfile = open(DATAFILE+".lock", "w")
    fcntl.flock(lockfile, fcntl.LOCK_EX)

    datafile = open(DATAFILE, "w")
    datafile.write(json.dumps(data))

    for f in (DATAFILE, DATAFILE+".lock"):
        os.chmod(f, 0644)
        os.chown(f, NAG_UID, NAG_GID)

def get_agent(minion):
    lockfile = open(DATAFILE+".lock", "w")
    fcntl.flock(lockfile, fcntl.LOCK_SH)

    data = json.load(file(DATAFILE))
    return data[minion]

if __name__ == '__main__':
    if len(sys.argv) != 2:
        print "Usage: mine_agent.py --update | <minion id>"
    elif sys.argv[1] in ['--update', '-u']:
        do_update()
    else:
        minion = sys.argv[1]
        print get_agent(minion)

Mettre à jour chaque minute:

$ cat /etc/cron.d/retrieve_mined_minion_data
*/1 * * * * root /etc/check_mk/mine_agent.py --update

Enfin: changez la source de données pour toutes les cibles nagios dans /etc/check_mk/main.mk:

datasource_programs = [
  ( '/etc/check_mk/mine_agent.py <HOST>', ['mine'], ALL_HOSTS ),
]

dommage mine_interval est une configuration globale pas par mine_function, j'ai quelques fonctions de mine lourdes qui peuvent ne pas bien fonctionner si elles sont définies sur une minute.
jagguli
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.