Ejercicio: Implementación de Elastic en máquinas virtuales de Azure

  • 90 minutos

En este ejercicio, prepare un clúster de Elasticsearch autoadministrado en tres máquinas virtuales Azure e instale Kibana en una máquina virtual independiente. Utilice solicitudes HTTPS autenticadas y un documento sintético para confirmar que los nodos forman un clúster. Es un entorno de aprendizaje descartable, no una migración de producción. Los vínculos a las instrucciones a las que se hace referencia en este ejercicio se encuentran en la sección Más información del resumen.

A menos que un paso indique explícitamente la estación de trabajo de administrador, ejecute ejemplos de comandos en Bash en una sesión SSH en la VM de Ubuntu indicada, no en Windows PowerShell local. Ejecute cada bloque en orden y deténgase si un comando falla. Sustituya todos los marcadores de posición entre corchetes angulares por su propio valor. No utilice los comandos RPM de tutoriales de otros proveedores.

1. Preparar el laboratorio

Elastic 9.5.5 es la versión publicada seleccionada para esta revisión. Antes de empezar, compruebe la Elastic Support Matrix y la política de versiones; si esta versión ya no recibe mantenimiento, use una versión mantenida aprobada de forma coherente en la pila y vuelva a comprobar sus instrucciones de instalación.

Use la siguiente configuración de referencia solo con datos sintéticos:

Setting Valor de laboratorio
Grupo de recursos Un nuevo elastic-on-azure-vm-rg
Region East US 2 u otra región aprobada con las cuotas y tamaños necesarios
Imagen del sistema operativo Ubuntu Server 24.04 LTS, x64, Generación 2
Paquetes de Elastic Elasticsearch y Kibana 9.5.5
Máquinas virtuales es-node1, es-node2, es-node3 y kibana-node.
Tamaño de cada máquina virtual Standard_D2s_v5: 2 vCPU y 8 GiB RAM
Almacenamiento por máquina virtual Disco del SO administrado persistente de 64 GiB, SSD estándar LRS; no hay ningún disco del sistema operativo efímero
Network elastic-lab-vnet, espacio de direcciones 10.42.0.0/16; subred elastic-lab-subnet, 10.42.0.0/24
Direcciones privadas es-node1: 10.42.0.10; es-node2: 10.42.0.11; es-node3: 10.42.0.12; kibana-node: 10.42.0.20
Administrator azureuser, autenticado con una clave pública SSH
Conectividad saliente Puerta de enlace NAT estándar y su dirección IP pública estándar o una ruta de acceso de salida existente aprobada

Confirme los permisos de creación de recursos, al menos ocho vCPU regionales disponibles y la cuota suficiente de la familia Dsv5. Estos tamaños de máquina virtual son una configuración inicial para este pequeño laboratorio, no una garantía de rendimiento. En la calculadora de precios de Azure, estime el coste de cuatro máquinas virtuales, cuatro discos administrados, NAT Gateway, su dirección IP pública, procesamiento o transferencia de datos y cualquier recurso de conectividad de administrador. Registrar la región, la moneda, el tiempo de ejecución previsto y los tamaños sustituidos.

Necesita una estación de trabajo de administrador con SSH/SCP y la conectividad privada enrutada a esta subred, por ejemplo a través de una VPN existente aprobada. El navegador de la estación de trabajo también debe poder acceder a la dirección privada de Kibana. Obtenga el intervalo IP de origen de administrador que verá realmente la subred y confirme que el intervalo de red virtual propuesto no se superpone a las redes conectadas. Si se superpone, elija un intervalo diferente y reemplace las direcciones de ejemplo en todo este ejercicio.

Importante

Establezca una ruta de acceso de red de administrador aprobada antes de aprovisionar el laboratorio. NAT Gateway proporciona conectividad saliente a internet, no entrada administrativa. Un inicio de sesión de Azure portal, una sesión de Cloud Shell normal o una sesión SSH de Bastion por sí sola no proporciona a su explorador local una ruta a Kibana privada. No eluda la falta de conectividad exponiendo las VM de aplicación públicamente.

Para HTTPS del navegador, obtenga un certificado/clave privada aprobados cuyo nombre alternativo del sujeto (SAN) cubra la dirección IP privada de Kibana o siga el procedimiento de generación de certificados solo para laboratorio del paso 8. Su explorador debe confiar en su emisor. Si la política de su organización no permite una CA de laboratorio temporal, obtenga un certificado aprobado antes de continuar.

Importante

Este laboratorio no es un destino de migración para datos de ventas en producción. Un diseño de producción necesita además una capacidad medida, planificación del dominio de errores, instantáneas con restauración probada, supervisión y un plan de actualización o recuperación.

2. Aprovisionar los recursos de Azure

Cree el grupo de recursos de solo ejercicio. Si el nombre ya existe, elija un nombre distinto en lugar de reutilizar el grupo. Cree la VNet y la subred del paso 1 y, a continuación, establezca la ruta administrativa enrutada aprobada. No coloque una VPN compartida ni otra infraestructura compartida en este grupo de recursos descartable.

Use la guía Crear una VM Linux en el portal de Azure para el flujo de creación, pero sustituya su configuración de ejemplo:

  1. Cree cada una de las cuatro máquinas virtuales con la imagen, el tamaño y el administrador del paso 1. Utilice la clave pública SSH aprobada y conserve la clave privada correspondiente en la estación de trabajo, no en una máquina virtual.
  2. En Discos, seleccione un disco de sistema operativo administrado de 64 GiB con almacenamiento SSD estándar . Este laboratorio usa el directorio de datos predeterminado /var/lib/elasticsearch del paquete en ese disco del sistema operativo persistente. Las cargas de trabajo de producción se deben dimensionar por separado, normalmente con discos de datos administrados dedicados.
  3. En Redes, seleccione elastic-lab-vnet y elastic-lab-subnet. Establezca Dirección IP pública en Ninguno y Puertos de entrada públicos en Ninguno. Aplique esta configuración a Kibana, así como a todos los nodos de Elasticsearch. No cree un equilibrador de carga, instale NGINX ni abra el puerto 80.
  4. Seleccione Revisar y crear, revisar la validación y los precios y, a continuación, seleccione Crear y complete cualquier confirmación de clave SSH. Espere a que finalice la implementación.
  5. Antes de instalar Elastic, abra en cada VM Redes>Configuración de red, seleccione su interfaz de red y, a continuación, Configuraciones de IP> su configuración de IP principal. Establezca la asignación de IP privada en Static y la dirección del paso 1 y, a continuación, guarde. Un cambio de dirección puede reiniciar la máquina virtual; espere a que finalice antes de conectarse. Deje la interfaz de red de Ubuntu configurada por DHCP en lugar de cambiar manualmente la IP del sistema invitado.

Consulte las instrucciones sobre la configuración de IP privada estática, los discos administrados y las rutas de acceso de datos de Elasticsearch. No coloque los datos del clúster en el almacenamiento temporal. Una implementación de Azure correcta aún no significa que Elasticsearch esté instalado.

3. Configurar la conectividad antes de descargar paquetes

Para un nuevo laboratorio basado en NAT, siga la sección Crear la puerta de enlace NAT de Crear una puerta de enlace NAT estándar. Cree elastic-lab-nat en el grupo de recursos y la región del laboratorio, cree su dirección IP elastic-lab-egress-ippública estándar y asocie la puerta de enlace a elastic-lab-subnet. No repita la implementación de la máquina virtual o de Bastion de este inicio rápido. La dirección IP pública pertenece a la puerta de enlace, no a ninguna máquina virtual. Si ya existe una ruta de firewall o salida aprobada, úsela en su lugar; no altere el enrutamiento compartido ni añada NAT de forma indiscriminada.

Permita la resolución DNS, la sincronización de tiempo y los repositorios de paquetes de Ubuntu y Elastic a través de esa ruta de acceso de salida. NAT solo no es un filtro de contenido saliente.

Note

No suponga que una nueva subred privada proporciona conectividad a Internet. Los valores predeterminados actuales del portal de Azure y el comportamiento aplicable de la API de red más reciente requieren conectividad de salida explícita. Las redes virtuales existentes no se cambian todas automáticamente. Consulte la guía de Azure sobre conectividad de salida.

Cree elastic-lab-nsg en el grupo de recursos del laboratorio y asócielo a elastic-lab-subnet. Agregue las siguientes reglas de entrada antes de conectarse. Use Direcciones IP para direcciones de origen/destino explícitas, Cualquiera para los puertos de origen y reemplace <administrator-source-CIDR> por el intervalo de origen enrutado aprobado. Cada lista separada por comas representa varias direcciones IP en una regla aumentada.

Priority Name Protocolo/puerto de destino Sources Destinos Action
100 AllowAdminSSH TCP / 22 <administrator-source-CIDR> 10.42.0.10,10.42.0.11,10.42.0.12,10.42.0.20 Permitir
110 AllowElasticsearchTransport TCP / 9300 10.42.0.10,10.42.0.11,10.42.0.12 10.42.0.10,10.42.0.11,10.42.0.12 Permitir
120 AllowElasticsearchHTTPS TCP / 9200 10.42.0.10,10.42.0.11,10.42.0.12,10.42.0.20 10.42.0.10,10.42.0.11,10.42.0.12 Permitir
130 AllowAdminKibana TCP / 5601 <administrator-source-CIDR> 10.42.0.20 Permitir
200 DenyOtherLabIngress Cualquiera / Cualquiera Any 10.42.0.0/24 Deny

La regla de denegación es esencial: en caso contrario, la regla AllowVNetInBound predeterminada de Azure permite otro tráfico de la VNet. Las prioridades numéricas más bajas se evalúan primero. Conservar las reglas de salida predeterminadas para este laboratorio descartable basado en NAT; El filtrado de salida de la organización es independiente. Haga coincidir cualquier regla de firewall del invitado con estos flujos e inspeccione las reglas efectivas tanto de la subred como de la NIC. Los grupos de seguridad de red tienen estado, por lo que el tráfico de respuesta para las conexiones salientes permitidas no necesita un permiso de entrada adicional. Estas reglas asumen el requisito previo de la estación de trabajo enrutada; un diseño de administración diferente necesita reglas correspondientes. Consulte las instrucciones sobre la evaluación de reglas de NSG.

Desde la estación de trabajo de administrador, conéctese a cada máquina virtual mediante su dirección privada, por ejemplo:

ssh -i "<ssh-private-key-path>" azureuser@10.42.0.10

Compruebe la identidad del host SSH a través de su proceso aprobado. En cada máquina virtual, ejecute sudo apt-get update y resuelva los errores de DNS, enrutamiento o repositorio antes de continuar.

4. Instalar e iniciar el primer nodo de Elasticsearch

En es-node1, configure el repositorio oficial de APT. Repita este bloque de repositorio más adelante en cada una de las otras tres máquinas virtuales antes de instalar su paquete. Estos comandos son para hosts ubuntu nuevos; no agregue un repositorio Elastic duplicado a una instalación existente.

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg unzip
curl --fail --silent --show-error https://artifacts.elastic.co/GPG-KEY-elasticsearch \
  -o /tmp/elastic-signing-key.asc
gpg --show-keys --with-fingerprint /tmp/elastic-signing-key.asc

Compare la huella de la clave primaria con 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4 en la guía de instalación de Debian. Si difiere, detenga y compruebe las instrucciones oficiales en lugar de importar una clave no comprobada.

sudo gpg --dearmor --output /usr/share/keyrings/elasticsearch-keyring.gpg \
  /tmp/elastic-signing-key.asc
sudo chmod 644 /usr/share/keyrings/elasticsearch-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/9.x/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/elastic-9.x.list
sudo apt-get update

Instale la versión exacta y registre la versión instalada:

sudo apt-get install -y elasticsearch=9.5.5
dpkg-query -W -f='${Package} ${Version}\n' elasticsearch

Utilice el JDK incluido. Si no se puede instalar la versión solicitada, detenga y compruebe la disponibilidad del paquete y la directiva de mantenimiento; no instale silenciosamente una versión diferente en un solo nodo.

Antes de iniciar cada nodo de Elasticsearch, revise las instrucciones de configuración del sistema. Deshabilite el intercambio para estos hosts de laboratorio dedicados con sudo swapoff -ay convierta en comentario las entradas de intercambio de /etc/fstab; también deshabilite cualquier mecanismo específico de la imagen que vuelva a crear el intercambio. Vuelva a comprobar swapon --show después de reiniciar el sistema operativo. Compruebe sysctl vm.max_map_count; si está por debajo de 1048576, establezca vm.max_map_count=1048576 en /etc/sysctl.conf, ejecute sudo sysctl --system y vuelva a comprobar. El paquete puede configurar esto automáticamente, por lo que debe inspeccionar el valor efectivo en lugar de agregar definiciones en conflicto.

El paquete configura los límites de servicio. Inspeccione mediante systemctl show elasticsearch -p LimitNOFILE -p LimitNPROC; use la guía de configuración del sistema si fallan las comprobaciones de arranque. Mantenga el tamaño del montón automático y los roles de nodo predeterminados.

Abrir /etc/elasticsearch/elasticsearch.yml con sudoedit. Siguiendo la sección Configure un nodo como primer nodo de un clúster de la guía del paquete, edite la configuración existente en lugar de anexar claves duplicadas:

cluster.name: es-on-azure
transport.host: 10.42.0.10
transport.port: 9300
http.host: 0.0.0.0
http.port: 9200

Conserve el nombre de nodo predeterminado, la configuración de TLS/keystore generada por el paquete y la entrada de arranque inicial para este primer nodo. No reemplace todo el archivo ni establezca discovery.seed_hosts antes de este arranque inicial. La vinculación HTTP incluye la interfaz de loopback para comprobaciones locales y la interfaz privada para el registro y Kibana; es adecuada aquí solo porque ninguna máquina virtual tiene una dirección IP pública y el acceso a la red está restringido.

Habilite e inicie el servicio del paquete:

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service
sudo systemctl status elasticsearch.service --no-pager

Para una instalación de Debian/systemd, establezca o restablezca la contraseña de administrador integrada con la herramienta documentada; no espere un mensaje de contraseña de inicio interactivo:

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic

Almacene la credencial generada de forma segura. No lo pegue en el módulo, comandos, capturas de pantalla o un documento compartido. Compruebe el punto de conexión HTTPS local; curl solicita la contraseña:

sudo curl --fail --silent --show-error \
  --cacert /etc/elasticsearch/certs/http_ca.crt \
  --user elastic "https://localhost:9200/"

Confirme el nombre del clúster esperado y la versión instalada. Inspeccione la configuración y los registros generados para confirmar que la seguridad, HTTP TLS y TLS de transporte están habilitadas, con las entradas de almacén de claves o certificados necesarias presentes. Un punto de conexión HTTP en funcionamiento no demuestra que el transporte use TLS. Si fallan el inicio, la configuración de TLS o HTTPS, inspeccione los registros de Elasticsearch y las excepciones de configuración automática antes de continuar. No deshabilite la seguridad, agregue una configuración de TLS manual incompleta o descarte un directorio de datos existente para superar un error.

5. Registrar los demás nodos de Elasticsearch

En es-node2, repita la configuración del repositorio del paso 4, la instalación del paquete de versión exacta y las comprobaciones de requisitos previos del sistema operativo, pero no inicie su servicio ni copie la configuración de arranque del primer nodo. En el primer nodo en ejecución, cree un token de inscripción de nodo:

sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s node

En es-node2, utilice el token con la herramienta de reconfiguración Debian/RPM antes del primer inicio del servicio:

sudo /usr/share/elasticsearch/bin/elasticsearch-reconfigure-node \
  --enrollment-token "<node-enrollment-token>"

Revise y confirme la solicitud de reconfiguración. En elasticsearch.yml, establezca cluster.name: es-on-azure, transport.host: 10.42.0.11, transport.port: 9300, http.host: 0.0.0.0y http.port: 9200. Conserve el certificado, la confianza y la configuración de detección generadas. Utilice los comandos de servicio del paso 4 para habilitar e iniciar el servicio y, a continuación, confirme que se une al clúster original.

En cuanto se une el segundo nodo, realice el paso 6 en los dos primeros nodos antes de cualquier reinicio. A continuación, repita la secuencia de inscripción para es-node3, con transport.host: 10.42.0.12 y un token recién generado y aplique el paso 6 a los tres nodos. Los tokens expiran después de 30 minutos. Trátalos como credenciales temporales. Un token creado con -s kibana no puede inscribir un nodo de Elasticsearch. No arranque tres clústeres independientes ni intente combinar sus directorios de datos.

Consulte la sección Reconfigurar un nodo para unirse a un clúster existente de la guía de Debian.

6. Consolidar la configuración de detección

En cuanto se haya unido el segundo nodo, actualice la configuración de detección del primer nodo antes de cualquier reinicio. Una vez que se hayan unido los tres nodos, compruebe la configuración en cada nodo.

Quite cluster.initial_master_nodes de la configuración del clúster establecido y establezca en discovery.seed_hosts direcciones privadas estables de los tres nodos aptos para maestros:

discovery.seed_hosts:
  - "10.42.0.10:9300"
  - "10.42.0.11:9300"
  - "10.42.0.12:9300"

No vuelva a introducir cluster.initial_master_nodes al reiniciar o agregar nodos. Use la sección Actualizar los archivos de configuración de la guía de Debian. Esto es importante incluso cuando parece que la inscripción inicial se ha realizado correctamente.

7. Comprobación de la pertenencia y el estado del clúster

En es-node1, ejecute solicitudes HTTPS autenticadas:

sudo curl --fail --silent --show-error \
  --cacert /etc/elasticsearch/certs/http_ca.crt \
  --user elastic "https://localhost:9200/_cat/nodes?v"

sudo curl --fail --silent --show-error \
  --cacert /etc/elasticsearch/certs/http_ca.crt \
  --user elastic "https://localhost:9200/_cluster/health?pretty"

Espere tres nodos en el clúster previsto. Compruebe los roles, el maestro elegido y que no se está ocultando ninguna condición de estado. Para este laboratorio de tres nodos con réplicas asignables, requiera estado verde antes de declarar el éxito; investigue los shards sin asignar en lugar de tratar cualquier respuesta HTTP 200 como correcta.

En los demás nodos, compruebe lo mismo cluster_uuid con la solicitud raíz HTTPS local del paso 4 y la misma contraseña de administrador del clúster. Después de la consolidación de la detección, ejecute sudo systemctl restart elasticsearch.service en un nodo cada vez, dejando que cada uno vuelva a unirse y que el clúster se recupere antes de reiniciar otro. Esta es una comprobación de laboratorio, no un sustituto del procedimiento de reinicio gradual de producción.

8. Instalar Kibana y configurar HTTPS

En kibana-node, repita la configuración del repositorio del paso 4 y, después, instale Kibana, no Elasticsearch:

sudo apt-get install -y kibana=9.5.5
dpkg-query -W -f='${Package} ${Version}\n' kibana

Preparar el certificado del explorador

Si ya tiene un certificado de servidor aprobado y la clave privada correspondiente, transfieralos de forma segura a kibana-node y continúe con Instalar el certificado e inscribir Kibana. Incluya los certificados intermedios necesarios en el archivo de certificado de servidor. Su nombre alternativo del sujeto debe cubrir 10.42.0.20, o use su nombre DNS aprobado de forma consistente en el certificado y en la URL del explorador.

De lo contrario, con aprobación para confiar en una ENTIDAD de certificación de laboratorio temporal, ejecute lo siguiente en es-node1. Crea una CA independiente y de corta duración para HTTPS del explorador a Kibana; no reemplaza la CA configurada automáticamente de Elasticsearch ni los certificados de transporte.

sudo install -d -m 700 /root/elastic-lab-pki
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil ca --pem \
  --days 30 --out /root/elastic-lab-pki/kibana-ca.zip
sudo unzip /root/elastic-lab-pki/kibana-ca.zip -d /root/elastic-lab-pki
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil cert --pem \
  --name kibana-server --ip 10.42.0.20 --days 30 \
  --ca-cert /root/elastic-lab-pki/ca/ca.crt \
  --ca-key /root/elastic-lab-pki/ca/ca.key \
  --out /root/elastic-lab-pki/kibana-server.zip
sudo unzip /root/elastic-lab-pki/kibana-server.zip -d /root/elastic-lab-pki
install -d -m 700 "$HOME/kibana-tls"
sudo install -o azureuser -g azureuser -m 600 \
  /root/elastic-lab-pki/kibana-server/kibana-server.crt "$HOME/kibana-tls/"
sudo install -o azureuser -g azureuser -m 600 \
  /root/elastic-lab-pki/kibana-server/kibana-server.key "$HOME/kibana-tls/"
sudo install -o azureuser -g azureuser -m 600 \
  /root/elastic-lab-pki/ca/ca.crt "$HOME/kibana-tls/kibana-lab-ca.crt"
sudo openssl x509 -in /root/elastic-lab-pki/ca/ca.crt -noout -fingerprint -sha256

Mantenga la clave privada de ca en es-node1; nunca cópiela en la estación de trabajo o en la máquina virtual de Kibana. Este laboratorio usa claves de servidor PEM protegidas por el sistema de archivos y sin cifrar. Para producción, use la PKI y el proceso de protección de claves de su organización. La referencia de la utilidad de certificados describe las opciones.

En la estación de trabajo del administrador, cambie a un directorio privado no sincronizado accesible solo para su cuenta. Descargue los tres archivos preparados a través de SSH y cargue solo el certificado del servidor y la clave privada del servidor en Kibana. Use la clave SSH correcta para cada máquina virtual:

scp -i "<es-node1-ssh-private-key-path>" azureuser@10.42.0.10:kibana-tls/kibana-server.crt .
scp -i "<es-node1-ssh-private-key-path>" azureuser@10.42.0.10:kibana-tls/kibana-server.key .
scp -i "<es-node1-ssh-private-key-path>" azureuser@10.42.0.10:kibana-tls/kibana-lab-ca.crt .
scp -i "<kibana-ssh-private-key-path>" kibana-server.crt kibana-server.key azureuser@10.42.0.20:

Confirme que la huella digital del certificado SHA-256 de la CA descargada coincide con la que se muestra en es-node1. Importe solo kibana-lab-ca.crt en el almacén de confianza usado por el explorador del laboratorio, siguiendo la directiva de su plataforma y organización. Registre ese cambio de confianza para la limpieza. Nunca importe una clave privada como raíz de confianza, omita una advertencia de certificado o distribuya esta CA de laboratorio para uso general.

Instalar el certificado e inscribir Kibana

En kibana-node, instale los archivos PEM:

sudo install -o root -g kibana -m 640 "$HOME/kibana-server.crt" /etc/kibana/kibana-server.crt
sudo install -o root -g kibana -m 640 "$HOME/kibana-server.key" /etc/kibana/kibana-server.key
rm -- "$HOME/kibana-server.crt" "$HOME/kibana-server.key"

Si usa un certificado organizativo, adapte los nombres de archivo de origen. Si su clave privada está cifrada, proporcione server.ssl.keyPassphrase mediante el almacén de claves de Kibana, en lugar de publicarla en un ejemplo. La referencia de configuración de frase de contraseña de clave privada de Kibana describe su propósito.

Abra /etc/kibana/kibana.yml con sudoedit y configure el agente de escucha privado y tls del explorador, editando las claves existentes en lugar de crear duplicados:

server.host: "10.42.0.20"
server.port: 5601
server.ssl.enabled: true
server.ssl.certificate: /etc/kibana/kibana-server.crt
server.ssl.key: /etc/kibana/kibana-server.key

Deje la configuración de conexión de Elasticsearch sin configurar hasta la inscripción. Vea la guía HTTPS de Kibana para los permisos del certificado y la confianza del explorador.

Genere un token de inscripción de Kibana nuevo en un nodo de Elasticsearch:

sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana

En kibana-node, inicie el servicio:

sudo systemctl daemon-reload
sudo systemctl enable kibana.service
sudo systemctl start kibana.service
sudo systemctl status kibana.service --no-pager

Registre el código de verificación de seis dígitos en el estado del servicio o inspeccione sudo journalctl -u kibana.service --no-pager si es necesario. En el explorador de estación de trabajo, abra https://10.42.0.20:5601 (o el nombre DNS aprobado). Proporcione el token de inscripción de Kibana, seleccione Configurar Elastic y proporcione el código de verificación si se le solicita. Si el token ha expirado, genere otro. Siga el flujo de inscripción de Debian. Inicie sesión con elastic para la administración inicial y, a continuación, cree usuarios con ámbito adecuado para el trabajo rutinario.

Confirme que Kibana se conecta al clúster previsto mediante HTTPS y confía en su CA HTTP de Elasticsearch. La confianza entre el navegador y Kibana y la confianza entre Kibana y Elasticsearch son independientes; no reemplace la CA de Elasticsearch del proceso de inscripción por la CA de laboratorio del navegador.

Después del registro, actualice la configuración existente elasticsearch.hosts para incluir los tres nodos:

elasticsearch.hosts:
  - "https://10.42.0.10:9200"
  - "https://10.42.0.11:9200"
  - "https://10.42.0.12:9200"

Conserve la autenticación de cuenta de servicio generada por la inscripción y la configuración de elasticsearch.ssl.certificateAuthorities. Reinicie Kibana con sudo systemctl restart kibana.service y confirme el acceso de nuevo. Consulte la guía de conexión de varios nodos.

Note

En este ejercicio se aprovisiona una máquina virtual de Kibana. Muestra la instalación, no la alta disponibilidad de Kibana. Una implementación de producción con varias instancias requiere la configuración compartida descrita en la unidad anterior.

9. Comprobar un documento sintético

Use la consola Dev Tools de Kibana durante la administración inicial. Cree un índice de laboratorio dedicado con una réplica explícita:

PUT module-lab-check
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1
  }
}

PUT module-lab-check/_doc/1?refresh=wait_for
{
  "message": "Azure VM lab connectivity check"
}

GET module-lab-check/_doc/1

GET _cluster/health/module-lab-check?wait_for_status=green&timeout=60s

GET _cat/shards/module-lab-check?v

Confirme que la respuesta del documento contiene "found": true y el mensaje esperado. La respuesta de estado debe tener "status": "green" y "timed_out": false. La respuesta de partición debe mostrar un primario (p) y una réplica (r), ambas STARTED en nodos diferentes. Una respuesta con HTTP 200 solo no es suficiente.

En Kibana, busque Vistas de datos mediante la búsqueda global, cree una vista de datos con el patrón module-lab-checkde índice y seleccione No quiero usar el filtro de tiempo porque el documento no tiene ningún campo de marca de tiempo. Abra Discover, seleccione esta vista de datos y busque el mensaje. Consulte la guía Crear una vista de datos.

No utilice transacciones reales, credenciales ni datos de cliente como carga útil. Un proyecto de ingesta opcional mediante Logstash es independiente de este ejercicio; consulte los pasos siguientes del resumen.

10. Solucione los problemas sin debilitar la configuración

Utilice las siguientes comprobaciones para solucionar problemas comunes sin deshabilitar los controles de seguridad:

Síntoma Activar
Se agota el tiempo de espera de la conexión SSH o del navegador Ruta de estación de trabajo, intervalo IP de origen real, reglas de NSG eficaces de subred o NIC, firewall invitado, dirección del listener y estado del servicio
La descarga del paquete falla Conectividad de salida DNS y explícita, repositorio correcto, clave de firma y disponibilidad de la versión exacta del paquete
Un nodo no se inicia /var/log/elasticsearch/es-on-azure.log, configuración del sistema, capacidad de memoria/disco, claves YAML duplicadas y configuración de arranque
La inscripción del nodo falla Un token nuevo delimitado por node, la accesibilidad HTTPS del primer nodo, la conectividad de transporte privado, las versiones coincidentes y el nombre del clúster
Error de certificado CA emisora correcta, expiración del certificado y nombre alternativo del sujeto, clave de servidor coincidente y permisos de lectura del servicio; nunca use curl -k
Kibana no se inicia sudo journalctl -u kibana.service --no-pager, formato y permisos de certificado/clave, hosts de Elasticsearch y configuración de inscripción
Salud amarilla/roja El estado de los shards y GET _cluster/allocation/explain en Dev Tools; corrija la causa de la asignación en lugar de establecer las réplicas en cero

11. Limpieza

Warning

La eliminación del grupo de recursos quita permanentemente los recursos y sus datos. Inspeccione primero el grupo y continúe solo si contiene recursos de ejercicio descartables exclusivamente. No elimine una red compartida, una implementación de producción ni los datos que necesite conservar.

En el portal de Azure, abra el grupo de recursos del ejercicio, revise su contenido, seleccione Eliminar grupo de recursos y complete el aviso de nombre y confirmación. Espere a que finalice la eliminación. Compruebe si hay recursos de laboratorio creados fuera de ese grupo, incluidos discos, instantáneas, direcciones IP públicas y recursos de salida. Quite solo los recursos que pertenezcan a este ejercicio. Haga que el administrador de red quite la configuración de conectividad específica del laboratorio si es necesario, sin eliminar los servicios de conectividad compartidos.

Quite de la estación de trabajo la clave privada del servidor descargada y otras copias temporales del certificado. Quite solo la entrada de confianza de la CA temporal del laboratorio que agregó, con su huella digital registrada; no quite los anclajes de confianza de la organización. Elimine claves privadas SSH específicas del laboratorio solo si no se usan en otro lugar. Al eliminar el grupo de recursos de máquina virtual, no se quitan los archivos de Workstation ni las entradas del almacén de confianza.

Detener un servicio o apagar el sistema operativo invitado no equivale a una limpieza completa de Azure. La desasignación detiene los cargos de proceso de la VM, pero no detiene necesariamente los cargos por el almacenamiento o las redes que se conserven. Vea la guía sobre los estados de facturación de las VM.