amazon-web-services - services - tipo de instancia amazon

Buena configuración en AWS para ELK

Question

Estamos buscando obtener una configuración de pila ELK en Amazon, pero realmente no sabemos lo que necesitamos de las máquinas para manejarlo sin problemas. Ahora sé que será obvio si no funciona bien, pero aún así esperábamos tener una idea de lo que necesitaríamos para nuestra situación.

Entonces nosotros 4 servidores que generan archivos de registro en un formato personalizado. Aproximadamente ~ 45 millones de líneas de registros cada día, generando aproximadamente 4 archivos de 600 mb (gzip), por lo que se necesitan alrededor de ~ 24 GB de registros por día.

Ahora estamos investigando la pila ELK y nos gustaría que los tableros de Kibana muestren datos en tiempo real, así que estaba pensando en iniciar sesión usando syslog para iniciar sesión.

4 Servidores -> Rsyslog (en esos 4 servidores) -> Logstash (AWS) -> ElasticSearch (AWS) -> Kibana (AWS)

Así que ahora tenemos que averiguar qué tipo de hardware necesitaríamos en AWS para manejar esto.

Leí en algún lugar 3 master para ElasticSearch y 2 datanodes como mínimo. Entonces, ¿eso sumaría 5 servidores + 1 servidor para Kibana y 1 para Logstash? Entonces, necesitaría un total de 7 servidores para comenzar, ¿pero parece un poco exagerado? Me gustaría conservar mis datos durante 1 mes, por lo que son 31 días como máximo, por lo que tendría aproximadamente ~ 1.4TB de datos de registro sin formato en Elastic Search (~ 45GB x 31)

Pero dado que realmente no tengo ni idea de cuál sería la mejor configuración, cualquier sugerencia / sugerencia / información sería bienvenida.

También podría ser útil un sistema o herramienta que pudiera manejar esto por mí (falla de nodo, etc.).

Gracias por adelantado,

Darkownage

Answer 1

Parece que necesitas algo para comenzar con ELK Stack en AWS

¿Has probado este par de scripts de CloudFormation? Facilitaría tu proceso de instalación y te ayudará a configurar tu entorno de una vez.

ELK-Cookbook - CloudFormation Script

ELK-Stack con Google OAuth en Private VPC

Comente a continuación si esto no resuelve su problema.

Answer 2

Así es como he estructurado mis clústeres en la nube:

3 nodos maestros: estos nodos coordinan el clúster y mantener tres ayuda a tolerar el error. Idealmente, estos se extenderán a través de las zonas de disponibilidad. Estos pueden ser bastante pequeños e, idealmente, no reciben ninguna solicitud; su único trabajo es mantener el clúster. En este caso, configure discovery.zen.minimum_master_nodes = 2 para mantener el quórum. Estas direcciones IP y estas IP solo son lo que debe proporcionar a todos los nodos del clúster en discovery.zen.ping.unicast.hosts

Índices: probablemente debería aprovechar los índices diarios; consulte https://www.elastic.co/guide/en/elasticsearch/guide/current/time-based.html Esto tendrá más sentido a continuación, pero también será beneficioso si comience a escalar: puede aumentar el recuento de fragmentos a lo largo del tiempo sin volver a indexar.

Nodos de datos: según la escala o los requisitos de rendimiento, existen algunas opciones: i2.xlarge o d2.xlarge funcionarán bien, pero r3.2xlarge también son una buena opción. Asegúrese de mantener el almacenamiento JVM <30 GB. Mantenga las rutas de datos en unidades efímeras locales a las instancias: EBS no es realmente tan ideal para este caso de uso, pero según sus requisitos podría ser suficiente. Asegúrese de tener múltiples nodos de datos para que los fragmentos de réplica puedan dividirse entre las zonas de disponibilidad. A medida que aumenten los requisitos de datos, amplíelos.

Caliente / Caliente: Dependiendo del caso de uso, a veces es beneficioso dividir los nodos de datos en Caliente / Caliente (SSD Rápido / HDD Lento). Esto se debe principalmente al hecho de que todas las escrituras son en tiempo real, y la mayoría de las lecturas son en las últimas horas. Si puede mover los datos de ayer en unidades más económicas y lentas, ayuda bastante. Esto es un poco más complicado, pero puede leer más en https://www.elastic.co/blog/hot-warm-architecture . Esto requiere agregar algunas etiquetas y usar el curador todas las noches, pero por lo general vale la pena debido a los ahorros en el costo de mover en gran medida los datos no procesados ​​de SSD más caros.

En producción, corro ~ 20 r3.2xlarge para la capa caliente y 4-5 d2.xlarge para la capa caliente con un factor de replicación de 2 - esto permite ~ TB por día de ingesta y una cantidad decente de retención. Escalamos caliente para el volumen y caliente para la retención.

En general, ¡buena suerte! Es una pila divertida de construir y operar una vez que todo funciona sin problemas.

PD: según el tiempo / los recursos que tenga disponibles, puede ejecutar el servicio de búsqueda elástica elástica en AWS, pero la última vez que lo vi era ~ 60% más caro que ejecutarlo en sus propias instancias, y YMMV.