Configuración de Elasticsearch

Elasticsearch se entrega con buenos valores predeterminados y requiere muy poca configuración. La mayoría de las configuraciones se pueden cambiar en un clúster en ejecución mediante la API de configuración de actualización del clúster.

El archivo de configuración debe contener configuraciones específicas del nodo (como nodo.nombre y ruta), o configuraciones que el nodo necesita para poder unirse al clúster, como clúster.nombre y red. anfitrión.

Elasticsearch tiene tres archivos de configuración:

Estos archivos se encuentran en el directorio de configuración y su ubicación predeterminada depende de si la instalación es desde una distribución de archivo (tar.gz o zip). o una distribución de paquetes (paquete Debian o RPM).

Para distribuciones archivadas, la ubicación del directorio de configuración por defecto es $ES_HOME/config. La ubicación del directorio de configuración se puede cambiar a través de la variable de entorno ES_PATH_CONF, como se muestra a continuación:

Alternativamente, puede exportar la variable de entorno ES_PATH_CONF a través de la línea de comando o el archivo de configuración del shell.

Para la distribución de paquetes, la ubicación del directorio de configuración por defecto es /etc/elasticsearch. La ubicación del directorio de configuración también se puede cambiar mediante la variable de entorno ES_PATH_CONF, pero tenga en cuenta que configurarla en el shell no es suficiente. En cambio, esta variable proviene de /etc/default/elasticsearch (para paquetes Debian) y /etc/sysconfig/elasticsearch (para paquetes RPM). Debe cambiar la ubicación del directorio de configuración editando la entrada ES_PATH_CONF=/etc/elasticsearch en uno de los archivos en consecuencia.

El formato de configuración es YAML. A continuación se muestra un ejemplo de cómo cambiar la ruta a los directorios de datos y registros:

La configuración también se puede aplanar de la siguiente manera:

En YAML, puede formatear valores no escalares como secuencias:

p>

Aunque es menos común, también puedes formatear valores no escalares como matrices:

El uso de la notación ${…} será reemplazado por el valor de la variable de entorno. Por ejemplo:

El valor de una variable de entorno debe ser una cadena simple. Utilice una cadena separada por comas para proporcionar valores que Elasticsearch analizará como una lista. Por ejemplo, Elasticsearch divide la siguiente cadena en una lista de valores para la variable de entorno ${HOSTNAME}

Las configuraciones de clúster y nodo se pueden clasificar según cómo estén configuradas:

Puede utilizar la API de configuración de actualización del clúster para configurar y actualizar la configuración dinámica en un clúster en ejecución. También puede utilizar elasticsearch.yml para configurar ajustes dinámicos localmente en un nodo que no está iniciado o que está inactivo.

Las actualizaciones realizadas mediante la API de configuración de actualización del clúster pueden ser persistentes (durante los reinicios del clúster de la aplicación) o efímeras (se restablecen después de un reinicio del clúster). También puede restablecer configuraciones temporales o persistentes asignándoles un valor nulo mediante la API.

Si configura las mismas configuraciones usando varios métodos, Elasticsearch aplicará las configuraciones en el siguiente orden de prioridad:

Por ejemplo, puede aplicar configuraciones transitorias para anular las configuraciones persistentes o elasticsearch Configuración de yml. Sin embargo, los cambios en elasticsearch.yml no sobrescribirán las configuraciones transitorias o persistentes definidas.

Es mejor usar la API de configuración de actualización del clúster para establecer configuraciones dinámicas en todo el clúster y usar elasticsearch.yml solo para la configuración local. Utilice la API de configuración de actualización del clúster para asegurarse de que la configuración sea la misma en todos los nodos.

Si configura accidentalmente diferentes configuraciones en elasticsearch.yml. En diferentes nodos, es difícil notar la diferencia.

La configuración estática solo se puede configurar usando elasticsearch.yml en nodos que no están iniciados ni cerrados.

Se deben establecer configuraciones estáticas en cada nodo relevante del clúster

Elasticsearch requiere muy poca configuración para comenzar, pero hay muchos aspectos necesarios antes de usar el clúster en un entorno de producción. :

Elasticsearch escribe los datos utilizados para crear el índice en el índice y el flujo de datos en el directorio de datos. Elasticsearch escribe sus propios registros de aplicaciones (que contienen información sobre el estado y las operaciones del clúster) en el directorio de registros

Para instalaciones de macOS .tar.gz, Linux .tar.gz y Windows .zip, los datos y log por defecto es un subdirectorio de $ES_HOME. Sin embargo, durante el proceso de actualización, los archivos en $ES_HOME corren el riesgo de ser eliminados.

En producción, recomendamos encarecidamente configurar path.data y path.logs en elasticsearch.yml en ubicaciones fuera de $ES_HOME. Las instalaciones .msi de Docker, Debian, RPM, macOS Homebrew y Windows escriben datos y registran en ubicaciones fuera de $ES_HOME de forma predeterminada.

Para evitar errores, solo Elasticsearch debe abrir archivos en el directorio path.data. Excluya el directorio path.data de otros servicios que puedan abrir y bloquear sus archivos, como antivirus o programas de respaldo.

Los valores de path.data y path.logs admitidos varían según la plataforma.

Un nodo puede unirse al clúster solo si comparte cluster.name con todos los demás nodos del clúster. El nombre predeterminado es elasticsearch, pero debe cambiarlo por un nombre apropiado que describa el propósito del clúster.

No reutilice el mismo nombre de clúster en diferentes entornos. De lo contrario, el nodo puede unirse al clúster incorrecto.

Elasticsearch utiliza node.name como identificador legible por humanos para una instancia específica de Elasticsearch. Este nombre se incluye en las respuestas a muchas API. Cuando se inicia Elasticsearch, el nombre de nodo predeterminado es el nombre de host de la máquina, pero se puede configurar explícitamente en elasticsearch.yml

De forma predeterminada, Elasticsearch solo se vincula a 127.0.0.1 y [::1] Espere la dirección de loopback . Esto es suficiente para el desarrollo y las pruebas con un clúster de uno o más nodos que se ejecutan en un único servidor, pero un clúster de producción resistente debe contener nodos en otros servidores.

Hay muchas configuraciones de red, pero generalmente solo necesita configurar network.host:

Cuando proporciona un valor para network.host. Elasticsearch supone que está pasando del modo de desarrollo al modo de producción y actualiza algunas comprobaciones de inicio del sistema de advertencias a excepciones. Eche un vistazo a la diferencia entre el modo de desarrollo y el de producción.

Antes de entrar en producción, configure dos ajustes importantes de descubrimiento y formación de clústeres para que los nodos del clúster puedan descubrirse entre sí y seleccionar un nodo maestro.

Elasticsearch se puede usar de inmediato sin ninguna configuración de red. Se vinculará a una dirección de loopback disponible y escaneará los puertos locales 9300 a 9305 para conectarse a otros nodos que se ejecutan en el mismo servidor. Este comportamiento proporciona una experiencia de agrupación en clústeres automática que no requiere configuración.

Utilice la configuración estática discover.seed_hosts cuando desee formar un clúster con nodos en otros hosts. Esta configuración proporciona una lista de otros nodos en el clúster que son elegibles para ser maestros y que probablemente estén activos y sean contactables. para iniciar el proceso de descubrimiento.

Esta configuración acepta una secuencia YAML o una matriz de direcciones en el clúster que coinciden con el nodo maestro. Cada dirección puede ser una dirección IP o un nombre de host que se resuelve mediante DNS en una o más direcciones IP.

Cuando inicia por primera vez un clúster de Elasticsearch, el paso de arranque del clúster determina el conjunto de nodos elegibles para el maestro que contarán los votos en la primera elección. En el modo de desarrollo, si no se configura ninguna configuración de descubrimiento, el propio nodo realizará este paso automáticamente.

Debido a que el arranque automático es intrínsecamente inseguro, al iniciar un nuevo clúster en modo de producción, debe enumerar explícitamente los nodos elegibles para el maestro y sus votos deben contarse en la primera elección. Puede configurar esta lista utilizando un clúster. configuración inicial_master_nodes.

Después de que el clúster se haya formado exitosamente por primera vez, elimine la configuración Initial_master_nodes en cada configuración de nodo. No utilice esta configuración al reiniciar un clúster o agregar nuevos nodos a un clúster existente.

El nodo maestro inicial se identifica mediante el nombre.nodo del nodo, que de forma predeterminada es el nombre de host del nodo maestro. Asegúrese de que el valor cluster.initial_master_nodes coincida exactamente con node.name. Si está utilizando un nombre de dominio completo (FQDN), como master-node-a.example.com como nombre de nodo, debe usar el FQDN en esta lista. Por el contrario, si node.name es un nombre de host simple sin ningún calificador final, también debe omitir el calificador final en cluster.initial_master_nodes si utiliza un nombre de dominio completo (FQDN), como master-node-a.example.com como su nombre de nodo, entonces debe usar FQDN en esta lista. Por el contrario, si node.name es un nombre de host simple sin ningún calificador final, también debe omitir el calificador final en cluster.initial_master_nodes.

Consulte arranque de un clúster y Configuración de formación de clústeres y descubrimiento.

De forma predeterminada, Elasticsearch establece automáticamente el tamaño del montón de JVM según la función del nodo y la memoria total. Para la mayoría de los entornos de producción, recomendamos utilizar el tamaño predeterminado.

El tamaño del montón automático requiere el JDK incluido y, si se utiliza una ubicación JRE personalizada, se requiere un JRE Java 14 o superior.

Si lo desea, puede anular el tamaño predeterminado configurando manualmente el tamaño del montón de JVM.

De forma predeterminada, Elasticsearch configura la JVM para volcar las excepciones de desbordamiento del montón en el directorio de datos predeterminado. En los paquetes RPM y Debian, el directorio de datos es /var/lib/elasticsearch. En las distribuciones de Linux, MacOS y Windows, el directorio de datos se encuentra en la raíz de la instalación de Elasticsearch.

Si esta ruta no es adecuada para recibir volcados de montón, modifique -XX:HeapDumpPath=… jvm.options

De forma predeterminada, Elasticsearch habilita el registro de recolección de basura (GC). Estos se configuran en jvm.options de jvm y se envían a la misma ubicación predeterminada que los registros de Elasticsearch. La configuración predeterminada rota los registros cada 64 MB, lo que puede consumir hasta 2 GB de espacio en disco.

Puede reconfigurar el registro de JVM utilizando las opciones de línea de comando descritas en JEP 158: Registro de JVM unificado. A menos que haya cambiado el jvm. Archivo de opciones, se aplicará la configuración predeterminada de Elasticsearch además de su propia configuración. Para deshabilitar la configuración predeterminada, primero deshabilite el registro proporcionando la opción -Xlog:disable y luego proporcione sus propias opciones de línea de comando. Esto deshabilitará todos los registros de JVM, así que asegúrese de verificar las opciones disponibles y habilitar todo lo que necesite.

Para ver opciones adicionales no incluidas en el JEP original, consulte Habilitación del registro mediante JVM Unified Logging Framework.

Cambie la ubicación de salida del registro de GC predeterminada a /opt/my-app/. gc.log creando $ES_HOME/config/jvm.options.d/gc.options con algunas opciones de muestra:

Configure un contenedor Docker de Elasticsearch para enviar registros de depuración de GC al error estándar ( stderr ). el orquestador del contenedor maneja la salida. Si usa la variable de entorno ES_JAVA_OPTS, especifique:

De forma predeterminada, Elasticsearch usa un directorio temporal privado creado directamente por el script de inicio en el directorio temporal del sistema.

En algunas distribuciones de Linux, las utilidades del sistema borrarán los archivos y directorios en /tmp si no se ha accedido a ellos recientemente. Este comportamiento puede provocar que el directorio temporal privado se elimine mientras se ejecuta Elasticsearch si la función que requiere el directorio temporal no se utiliza durante un período prolongado. Eliminar el directorio temporal privado puede causar problemas si posteriormente utiliza funciones que requieren este directorio.

Si instala Elasticsearch usando un paquete .deb o .rpm y lo ejecuta en systemd, el directorio temporal privado utilizado por Elasticsearch se excluirá de la limpieza periódica.

Si planea ejecutar una distribución .tar.gz en Linux o MacOS durante un período prolongado, considere crear un directorio temporal dedicado para Elasticsearch que no se encuentre en una ruta donde se purguen los archivos y directorios antiguos. . Los permisos en este directorio deben configurarse para que solo el usuario que ejecuta Elasticsearch pueda acceder a él. Luego, antes de iniciar Elasticsearch, configure la variable de entorno $ES_TMPDIR para que apunte a este directorio.

De forma predeterminada, Elasticsearch configura la JVM para escribir registros de errores fatales en el directorio de registros predeterminado. Para los paquetes RPM y Debian, este directorio es /var/log/elasticsearch. En las distribuciones de Linux, MacOS y Windows, el directorio de registros se encuentra en el directorio raíz de instalación de Elasticsearch.

Estos registros se generan cuando la JVM encuentra un error fatal (como un error de segmentación). Si esta ruta no es adecuada para recibir registros, modifique la entrada -XX:ErrorFile=... en jvm.options.

En caso de desastre, las instantáneas pueden evitar la pérdida permanente de datos. La gestión del ciclo de vida de instantáneas es la forma más sencilla de realizar copias de seguridad periódicas de su clúster. Para obtener más información, consulte Copia de seguridad de un clúster.

En caso de desastre, las instantáneas pueden evitar la pérdida permanente de datos. La administración del ciclo de vida de las instantáneas es la forma más sencilla de realizar copias de seguridad periódicas de su clúster. Para obtener más información, consulte Copia de seguridad de su clúster.

La única forma confiable y compatible de realizar una copia de seguridad de un clúster es utilizar instantáneas. No puede realizar una copia de seguridad de un nodo del clúster de Elasticsearch copiando su directorio de datos. No se admiten métodos para restaurar datos a partir de copias de seguridad a nivel del sistema de archivos. Si intenta restaurar un clúster a partir de dicha copia de seguridad, puede informar daños, archivos faltantes u otras inconsistencias en los datos, o puede parecer que ha perdido con éxito algunos datos de forma silenciosa.

Algunas configuraciones son sensibles y no es suficiente confiar únicamente en los permisos del sistema de archivos para proteger sus valores. Para este caso de uso, Elasticsearch proporciona un almacén de claves y la herramienta elasticsearch-keystore para administrar la configuración en el almacén de claves.

Todas las modificaciones en el almacén de claves entrarán en vigor solo después de reiniciar Elasticsearch.

Estas configuraciones son como las configuraciones normales en elasticsearch. El archivo de configuración Yml debe especificarse en cada nodo del clúster. Actualmente, todas las configuraciones de seguridad son específicas de cada nodo y deben tener el mismo valor en cada nodo.

Al igual que los valores de configuración en elasticsearch.yml, los cambios en el contenido del almacén de claves no se aplican automáticamente a los nodos de Elasticsearch en ejecución. Volver a leer la configuración requiere reiniciar el nodo. Sin embargo, algunas configuraciones de seguridad están marcadas como recargables. Dichas configuraciones se pueden volver a leer y aplicar en un nodo en ejecución.

Los valores de todas las configuraciones de seguridad (ya sean recargables o no) deben ser los mismos en todos los nodos del clúster.

Después de realizar los cambios necesarios en la configuración de seguridad, use el comando bin/elasticsearch-keystore add, llame a:

keystore-password: la contraseña utilizada para cifrar el almacén de claves de Elasticsearch

Esta API descifra y Vuelva a leer todo el almacén de claves en cada nodo del clúster, pero solo aplique configuraciones de seguridad recargables. Los cambios en otras configuraciones no tendrán efecto hasta el próximo reinicio. Una vez que regresa la llamada, la recarga se completa, lo que significa que se han cambiado todas las estructuras de datos internas que dependen de esta configuración. Todas las configuraciones deben tener valores nuevos desde el principio.

Al cambiar varias configuraciones de seguridad recargables, modifique todas las configuraciones de seguridad en cada nodo del clúster y luego emita una llamada reload_secure_settings en lugar de recargar después de cada modificación.

Hay configuraciones de seguridad recargables: