Bosun HA et l'évolutivité

Question

J'ai une configuration de bosun mineur, et ses métriques de collecte de nombreux services, et nous prévoyons de mettre à l'échelle ces services sur le nuage. Cela signifie que plus de données arrivent dans le bosun et, par conséquent, la charge/efficacité/échelle de bosun est affectée.

J'ai peur de perdre des données, en raison de surcharge du réseau, et en cas de pannes.

Je suis à la recherche de rapports sur les performances de référence pour bosun, ou de toutes les entrées sur l'analyse comparative/test bosun pour échelle et HA.

En outre, toute contribution sur les bonnes pratiques à suivre pour mettre à l'échelle bosun sera utile. Ma pensée actuelle est d'exécuter de nombreux binaires bosun en tant que cluster, soutenu par une configuration distribuée opentsdb. En outre, je pense qu'il vaut la peine d'exécuter certains exécutants de bosun en tant que «collecteurs» de données de scollector (avec la commande bosun -n), et d'autres de simplement calculer les alertes.

Le problème avec cette approche est que les mêmes alertes peuvent être déclenchées à partir de plusieurs instances de bosun (en cours d'exécution sans l'option -n). Existe-t-il un meilleur moyen de dédupliquer les alertes?

Answer 1

Les meilleures pratiques actuelles sont:

1. Utilisez https://godoc.org/bosun.org/cmd/tsdbrelay de transmettre des mesures à opentsdb. Cela fait sortir le binaire bosun du "chemin critique". Il doit également transmettre les métriques à bosun pour l'indexation et dupliquer le flux de métriques vers plusieurs centres de données pour les sauvegardes/sauvegardes.
2. Assurez-vous que votre cluster hadoop/opentsdb possède au moins 5 nœuds. Vous ne pouvez pas effectuer de maintenance en direct sur un cluster à 3 nœuds, et hadoop fonctionne généralement sur une douzaine de nœuds ou plus. Nous utilisons Cloudera Manager pour gérer le cluster hadoop, et d'autres ont recommandé Apache Ambari.
3. Utilisez un équilibreur de charge tel que HAProxy pour diviser le trafic d'écriture/api/put sur plusieurs instances de tsdbrelay en mode actif/passif. Nous exécutons une instance sur chaque nœud (avec le transfert tsdbrelay vers l'instance locale opentsdb) et dirigeons tout le trafic d'écriture sur un nœud d'écriture principal (avec plusieurs nœuds secondaires/de sauvegarde). Diviser le trafic/api/requête sur les nœuds restants pointés directement sur opentsdb (pas besoin de passer par le relais) dans un mode actif/actif (aussi appelé round robin ou routage basé sur le hachage). Cela améliore les performances des requêtes en les équilibrant entre les noeuds non-write.
4. Nous n'exécutons qu'une seule instance de bosun dans chaque centre de données, le site DR utilisant l'indicateur de lecture seule (tout basculement serait manuel). Il n'est pas encore conçu pour la haute disponibilité, mais à l'avenir, il peut permettre à deux nœuds de partager une instance redis et de permettre l'accès actif/actif ou actif/passif.

En utilisant tsdbrelay pour dupliquer les flux métriques vous ne devez pas traiter avec la réplication opentsdb/HBase et au lieu peut configurer plusieurs systèmes de surveillance isolés dans chaque centre de données et dupliquer les paramètres pour les sites appropriés selon. Nous avons un site principal et un site de reprise après sinistre, et nous choisissons de dupliquer toutes les mesures dans les deux centres de données. J'utilise quotidiennement le site DR pour les requêtes Grafana car il est plus proche de l'endroit où je vis.

Vous trouverez plus de détails sur les configurations de production au http://bosun.org/resources, y compris des copies de tous les fichiers de configuration haproxy/tsdbrelay/etc que nous utilisons dans Stack Overflow.