Démarrer avec Bosun

Exemple de fichier de configuration

Voici un exemple de fichier de configuration Bosun utilisé dans un environnement de développement :

tsdbHost = localhost:4242
httpListen = :8070
smtpHost = localhost:25
emailFrom = [email protected]
timeAndDate = 202,75,179,136
ledisDir = ../ledis_data
checkFrequency = 5m

notification example.notification {
        email = [email protected]
        print = true
}

Dans ce cas, le fichier de configuration indique que Bosun doit se connecter à une instance OpenTSDB locale sur le port 4242, écouter les requêtes sur le port 8070 (sur toutes les adresses IP liées à l’hôte), utiliser le système SMTP localhost pour le courrier électronique, afficher [fuseaux horaires supplémentaires] [1], utilisez Ledis intégré au lieu de Redis externe pour l’état du système et les alertes par défaut à un intervalle de 5 minutes.

La configuration définit également un example.notification qui peut être affecté aux alertes, qui serait généralement inclus à la fin du fichier de configuration (voir l’exemple d’exemple d’alerte).

[1] : http://stackoverflow.com/questions/34394387/how-to-specify-timezones-for-world-clock-in-bosun

Démarrage rapide de Docker

Le [guide de démarrage rapide] [1] comprend des informations sur l’utilisation de Docker pour mettre en place une instance Bosun.

$ docker run -d -p 4242:4242 -p 80:8070 stackexchange/bosun

Cela créera une nouvelle instance de Bosun à laquelle vous pourrez accéder en ouvrant un navigateur sur http://docker-server-ip. L’image docker inclut HBase/OpenTSDB pour stocker les données de séries chronologiques, le serveur Bosun et Scollector pour collecter les métriques à l’intérieur du conteneur bosun. Vous pouvez ensuite pointer des instances scollector supplémentaires sur le serveur Bosun et utiliser Grafana pour créer des tableaux de bord de métriques OpenTSDB ou Bosun.

L’image Stackexchange/Bosun est conçue uniquement pour les tests. Aucune alerte n’est définie dans le fichier de configuration et les données seront supprimées lorsque l’image docker sera supprimée, mais cela est très utile pour avoir une idée du fonctionnement de bosun. Pour plus de détails sur la création d’une instance de production de Bosun, voir http://bosun.org/resources

[1] : http://bosun.org/quickstart

Exemple d’alerte

Les alertes Bosun sont définies dans le fichier de configuration à l’aide d’un [DSL personnalisé][1]. Ils utilisent des fonctions pour évaluer les données de séries chronologiques et génèrent des alertes lorsque les expressions warn ou crit sont différentes de zéro. Les alertes utilisent des modèles pour inclure des informations supplémentaires dans les notifications, qui sont généralement un message électronique et/ou une requête HTTP POST.

template sample.alert {
    body = `<p>Alert: {{.Alert.Name}} triggered on {{.Group.host}}
    <hr>
    <p><strong>Computation</strong>
    <table>
        {{range .Computations}}
            <tr><td><a href="{{$.Expr .Text}}">{{.Text}}</a></td><td>{{.Value}}</td></tr>
        {{end}}
    </table>
    <hr>
    {{ .Graph .Alert.Vars.metric }}`

    subject = {{.Last.Status}}: {{.Alert.Name}} cpu idle at {{.Alert.Vars.q | .E}}% on {{.Group.host}}
}

notification sample.notification {
    email = [email protected]
}

alert sample.alert {
    template = sample.template
    $q = avg(q("sum:rate:linux.cpu{host=*,type=idle}", "1m"))
    crit = $q < 40
    notification = sample.notification
}

L’alerte enverrait un e-mail avec le sujet “Critique : sample.alert cpu inactif à 25 % sur le nom d’hôte” pour tout hôte dont l’utilisation du processeur inactif a été en moyenne inférieure à 40 % au cours de la dernière minute. Cet exemple est une alerte “à l’échelle de l’hôte”, mais Bosun prend également en charge les alertes de cluster, de centre de données ou à l’échelle mondiale (voir la série de vidéos fondamentales pour plus de détails).

[1] : http://bosun.org/configuration