Pour plus détails, voir [HowtoElasticsearch#plugins]().
### Configuration
## Utile
Préciser *node.name* dans le fichier `/etc/elasticsearch/elasticsearch.yml` :
* les logs sont dans `/var/log/elasticsearch/_cluster_name_.log`
* l'interface **Head** est disponible sur http://127.0.0.1:9200/_plugin/head/
* l'interface **Kopf** est disponible sur http://127.0.0.1:9200/_plugin/kopf/
~~~{.yaml}
node.name: bar
~~~
# Logstash
## Logstash
Logstash est un service qui récupère des données depuis des sources variées (ports TCP/UDP, fichiers…), les transforme et les renvois vers des sorties variées (fichiers, Elasticsearch, syslog…).
C'est un logiciel écrit en Ruby, qui tourne sur une JVM (grace à JRuby).
Pour que le démon soit géré automatiquement par systemd :
### Démarrage
~~~
# systemctl enable kibana
# systemctl start kibana
~~~
## Utile
* l'interface principale est disponible sur <http://127.0.0.1:5601/>
* l'interface **Sense** est disponible sur <http://127.0.0.1:5601/app/sense>
L'interface principale est disponible sur <http://127.0.0.1:5601/>
## Proxy
### Proxy
Kibana ne gère pas d'authentification. Pour le rendre accessible de manière sécurisée, il est conseillé de le placer derrière un reverse proxy, par exemple Nginx.
@ -150,6 +133,6 @@ server {
}
~~~
# Conseils
## Conseils
* utiliser des certificats SSL (nativement géré par les logiciels) pour que les données circulent de manière chiffrée (surtout entre filebeat et logstash, car ça passe par Internet).
* Forum : <https://discuss.elastic.co/c/elasticsearch>
[Elasticsearch](https://www.elastic.co/fr/products/elasticsearch) est un serveur de base de données écrit en Java disposant d’une interface REST HTTP. Elasticsearch est notammment utilisé dans [la stack Elastic avec Logstash et Kibana](HowtoELK).
@ -13,20 +13,45 @@ categories: web bdd nosql
Vu le développement actif d'Elasticsearch, nous préconisons l'installation des paquets Debian distribués par Elasticsearch :
Si vous faites la mise à jour depuis une verison inférieure à 5.0, il faut penser à supprimer tous les plugins de type "site" comme _head_ ou _kopf_ qu'il faudra réinstaller différemment. :
Created symlink from /etc/systemd/system/multi-user.target.wants/elasticsearch.service to /usr/lib/systemd/system/elasticsearch.service.
# systemctl start elasticsearch
~~~
## Configuration de base
Les paramètres système (répertoires utilisés, configuration JVM) se trouvent dans le fichier `/etc/default/elasticsearch`,
les options applicatives (nom du cluster, nom du nœud, mémoire, réseau) se trouvent dans le fichier `/etc/elasticsearch/elasticsearch.yml`.
Les paramètres système se trouvent dans le fichier `/etc/default/elasticsearch`, les paramètres liés à la JVM sont dans `/etc/elasticsearch/jvm.options` et les options applicatives (nom du cluster, nom du nœud, mémoire, réseau) se trouvent dans le fichier `/etc/elasticsearch/elasticsearch.yml`.
Il faut activer le redémarrage automatique en cas de mise à jour (classique sous Debian).
On peut aussi définir un *tmpdir* spécifique (utile quand `/tmp` est en _noexec_) dans `/etc/default/elasticsearch` :
Il faut activer le redémarrage automatique en cas de mise à jour (classique sous Debian) dans `/etc/default/elasticsearch` :
~~~
RESTART_ON_UPGRADE=true
~~~
On peut aussi définir un **tmpdir** spécifique (utile quand `/tmp` est en `noexec`) dans `/etc/default/elasticsearch` :
On conseille de ne pas activer le logging stdout vers la console, mais de conserver seulement les logs dans `/var/log/elasticsearch/`. On peut faire cela via le fichier `/etc/elasticsearch/logging.yml` :
~~~{.diff}
-rootLogger: ${es.logger.level}, console, file
+rootLogger: ${es.logger.level}, file
~~~
Les journaux intéressants sont dans `/var/log/elasticsearch/_cluster_name_.log`
## Configuration réseau
Par défaut, Elasticsearch écoute sur 127.0.0.1 sur TCP/9200 pour son interface REST HTTP.
@ -87,34 +105,15 @@ La directive de configuration suivante peut être positionnée pour qu'il écout
L'interface **Head** est ainsi disponible sur http://127.0.0.1:9200/_plugin/head/
Il active alors un certain nombre de "bootstrap checks" qui bloquent le démarrage s'ils ne sont pas tous respectés. Les éventuels échecs sont lisibles dans le fichier de log (généralement dans `/var/log/elasticsearch/_cluster_name_.log`).
## Configuration avancée
@ -141,11 +140,11 @@ On check sur la page `/_cat/health` si le status n'est pas en **red**.
Il faut définir un répertoire pour stocker les snapshots :
@ -155,7 +154,7 @@ Il faut définir un répertoire pour stocker les snapshots :
# chown elasticsearch: /home/backup-elasticsearch
~~~
*Note :* en cas de cluster multi-nœuds, le répertoire de snapshots doit impérativement être partagé entre chaque nœud, classiquement via NFS, car chaque nœud ne gère que ses propres données.
*Note* : en cas de cluster multi-nœuds, le répertoire de snapshots doit impérativement être partagé entre chaque nœud, classiquement via NFS, car chaque nœud ne gère que ses propres données.
On précise le répertoire des snapshots dans la configuration `/etc/elasticsearch/elasticsearch.yml` :
Si l'on compare à d'autres services (MySQL, PostgreSQL, MongoDB..) la gestion d'un cluster Elasticsearch est vraiment simple.
Il faut lancer plusieurs instances Elasticsearch sur un réseau avec le même **cluster.name** et un **node.name** différent, et il suffitd'indiquer une (ou plusieurs) adresse(s) IP qui va permettre à l'instance de communiquer avec un (ou plusieurs) autre(s) nœud(s) :
Si l'on compare à d'autres services (MySQL, PostgreSQL, MongoDB…) la gestion d'un cluster Elasticsearch est vraiment simple.
Il faut lancer plusieurs instances Elasticsearch sur un réseau avec le même **cluster.name** et un **node.name** différent, et il suffitd'indiquer une (ou plusieurs) adresse(s) IP qui va permettre à l'instance de communiquer avec un (ou plusieurs) autre(s) nœud(s) :
