Reactor

Reactor a démarré comme un fork du projet open source ElastAlert. Le mainteneur de ce projet doit suivre de près les modifications apportées à ElastAlert (à l'exception de leurs alerters supplémentaires) et s'assurer que tous les correctifs de bogues pertinents soient intégrés et que toute fonctionnalité utile soit portée.

Reactor est un moteur d'alerting qui prend un ensemble de règles avec des filtres personnalisés et alerte sur les correspondances. Reactor met automatiquement à jour les alertes silencieuses avec les informations d'alerte répétée.

Historique des correctifs depuis ElastAlert

Versions prises en charge

Actuellement, Reactor prend en charge ElasticSearch 5.x.x, 6.x.x et 7.x.x. Au fur et à mesure que de nouvelles versions d'elasticsearch deviennent disponibles, Reactor sera mis à jour pour les prendre en charge. Il n'est pas prévu d'ajouter la prise en charge des versions plus anciennes d'ElasticSearch. Actuellement, aucune date n'est fixée pour supprimer la prise en charge des versions plus anciennes d'ElasticSearch. Si la bibliothèque Python d'ElasticSearch supprime cette prise en charge, nous suivrons probablement le mouvement.

Compatibilité

Selon les recommandations de la bibliothèque Python d'ElasticSearch, il est recommandé d'installer la version de la bibliothèque ayant la même version majeure que le cluster.

Pour Elasticsearch 7.0 et versions ultérieures, utilisez la version majeure 7 (elasticsearch<8.0.0,>=7.0.0).

Pour Elasticsearch 6.0 et versions ultérieures, utilisez la version majeure 6 (elasticsearch<7.0.0,>=6.0.0).

Pour Elasticsearch 5.0 et versions ultérieures, utilisez la version majeure 5 (elasticsearch<6.0.0,>=5.0.0).

Veuillez noter qu'il existe un bug connu introduit dans la version 6.4.0 de la bibliothèque ElasticSearch, corrigé dans 7.0.4 mais pas dans la version majeure 6. Le bug place le scroll_id dans le paramètre de requête, ce qui peut amener Elasticsearch à renvoyer des codes de statut 400 pour des scroll ids valides.

Développement

Vous pouvez démarrer une instance elasticsearch dans docker pour le développement local en utilisant la commande suivante :

$ docker run -d -p 9200:9200/tcp --name elasticsearch docker.elastic.co/elasticsearch/elasticsearch:<version>

Et la configuration suivante dans config.yaml :

writeback_index: reactor
alert_alias: reactor_alerts

elasticsearch: &elasticsearch
  host: localhost
  port: 9200

# Global settings to be applied to every run
rule:
  elasticsearch: *elasticsearch

Hooks Git

Ce projet fournit des hooks git pour éviter les erreurs de l'utilisateur. Veuillez exécuter les commandes suivantes :

$ cp .git-hooks-pre-push .git/hooks/pre-push

Exécution des tests

Reactor est couvert par deux types de tests : unitaires et d'intégration. Les tests unitaires pour vérifier que les fonctions individuelles et les flux logiques fonctionnent correctement ; les tests d'intégration pour s'assurer que l'ensemble du système fonctionne de manière coordonnée.

Tests unitaires

Les tests unitaires sont écrits avec PyTest. Pour exécuter tous les tests, lancez la commande suivante :

$ py.test

Tests d'intégration

Les tests unitaires sont exécutés dans docker et nécessitent un fichier .env à la racine du projet. Les tests nécessitent le contenu suivant dans le fichier .env :

# The ElasticSearch version to be tested, reactor supports >= 5.x.x
ES_VERSION=6.3.2
# Basic configuration information so that reactor can query ElasticSearch
ES_HOST=elasticsearch
ES_USER=elastic
ES_PASSWORD=changeme

Le fichier Docker Compose d'intégration test.docker-compose.yml contient 3 variables d'environnement requises pour >= v7.x.x qui casseront les versions plus anciennes :

node.name=elasticsearch
discovery.seed_hosts=elasticsearch
cluster.initial_master_nodes=elasticsearch

Pour exécuter les tests d'intégration, lancez la commande suivante :

$ docker-compose -f docker-compose-test.yml up --abort-on-container-exit --build  reactor elasticsearch

Créer des certificats SSL pour le leadership RAFT

La série de commandes suivante (exécutée dans ./certs/) créera un ensemble de certificats CA et de certificats d'appareil pour exécuter le cluster simulé sur localhost :

# Only do once: generate the root CA key:
$ openssl genrsa -out transport-ca.key 4096

# Generate the root CA certificate:
## Country Name (2 letter code) []:GB
## State or Province Name (full name) []:.
## Locality Name (eg, city) []:.
## Organization Name (eg, company) []:.
## Organizational Unit Name (eg, section) []:.
## Common Name (eg, fully qualified host name) []:PyRaftLog
## Email Address []:.
$ openssl req -x509 -new -nodes -key transport-ca.key -sha256 -days 1024 -out transport-ca.pem

# Generate device certificates
# Only do once: generate device key:
$ openssl genrsa -out transport-consensus.key 4096

# Generate device certificate signing request:
## Country Name (2 letter code) []:GB
## State or Province Name (full name) []:.
## Locality Name (eg, city) []:.
## Organization Name (eg, company) []:.
## Organizational Unit Name (eg, section) []:.
## Common Name (eg, fully qualified host name) []:localhost
## Email Address []:.
$ openssl req -new -key transport-consensus.key -out transport-consensus.csr

# Generate a signed device certificate:
$ openssl x509 -req -in transport-consensus.csr -CA transport-ca.pem -CAkey transport-ca.key -CAcreateserial -out transport-consensus.crt -days 500 -sha256

Générer la documentation

Pour générer la documentation :

$ pip install -r requirements-docs.txt
$ cd docs
$ sphinx-build -b html -d build/doctrees -W source build/html

Publier sur PyPi

1. pip install --upgrade setuptools wheel
2. pip install --upgrade twine
3. python3 setup.py sdist bdist_wheel
4. twine check dist/*
5. twine upload --skip-existing dist/* --verbose