All Posts by David Matar

ELK cómo generar alertas

Alertas en ELK

alertas en ELK : CÓMO GENERARLAS

El uso más común de ELK (Elasticsearch, Logstash and Kibana) es la generación dashboards para la visualización de métricas y tendencias, así como para el análisis forense o en procesos de debug. Pero este también puede usarse para generar alertas basadas en los cambios que se producen en la infraestructura. ELK por si mismo no dispone de un sistema de generación de alertas, pero hay herramientas para ello. Vamos ha analizar las diferentes opciones de alertas en elk.

Watcher

Watcher es el producto de Elastic para la generación y envío de alertas.

Este genera alertas en base a los cambios de la información guardada en Elasticsearch.

Este funciona en base a la definición de consultas en elastisearch, la definición de condiciones, definir cada cuando se realiza la consulta (scheduler) y que acción realizar si se cumple la condición definida.

Watcher se integra en ELK como una aplicación más i forma parte del paquete de aplicaciones de pago que  Elastic vende como añadidos a ELK.

 

Elastalert

Elastalert ha sido desarrollado por Yelp para uso interno y liberado bajo licencia Apache License, version 2.0. A diferencia de Watcher, Elastalert no se integra como un aplicación de ELK, sino que se ejecuta al margen de ELK.

Este realiza queries sobre Elasticsearch de forma periódica i permite definir un conjunto de reglas en base a la cuales se envían alertas hacia diferentes sistemas como Email, Slack o Hipchat entre otras.

 

Kaae

Kaae es un nuevo proyecto que pretende ser una alternativa opensource a Watcher. Este utiliza el mismo modelo que Watcher y se integra como una aplicación de ELK.

 

Logstash

A diferencia de Watcher Elastalert y Kaae, que se basan en la ejecución de queries para obtener y analizar la información, Logstash permite configurar eventos en tiempo real. Es decir, Logstash puede generar alertas cuando recibe los datos.

Todo y que es memos completo, ya que no podemos generar alertas en base a la correlación de datos, permite generar alertas justo cuando se recibe el datos de la fuente.

La entrada ELK cómo generar alertas aparece primero en Un cio como tu ….


Source: jmgriscom

El valor de Devops para un negocio

Print

Cuando hablamos de Devops, tenemos tendencia a centrarnos en las tecnología, herramientas y procesos utilizados. Básicamente es porque quién hablamos de ello somos gente que formamos parte de los equipos de desarrollo o de operaciones. Pero que valor aporta Devops para un negocio?

En el post anterior “Devops ROI” vimos los conceptos generales que permiten justificar la inversión en tecnología, el ahorro en costes de horas de trabajo y el ahorro en caídas del sistema. Pero Devops aporta otras ventajas o valor difícil de cuantificar en términos monetarios. Hoy en día, donde todos o la mayoría de los negocios son negocios basados en tecnología, este valor puede ser el hecho diferencial entre una empresa u otra.

La implantación de Devops nos permite impactar directamente en mejorar como distribuimos un producto al cliente, cambiar el producto rápidamente para satisfacer las necesidades del cliente o como recuperamos después de un fallo que afecta al cliente.

Un producto en si mismo no es nada hasta que un cliente lo utiliza. Es por ello que es importante reducir el tiempo de lanzamiento de un producto, y aquí es donde la automatización actúa como un multiplicador, permitiendo la colaboración de todos los equipos involucrados en la creación de un producto.

De la misma forma que un producto no sirve de nada si no lo utiliza un cliente, las mejores funcionalidades son aquella que utiliza el cliente. De nada sirve tener un producto con un montón de funcionalidades que no se utilizan. Es por ello que todos los esfuerzos deben focalizarse sobre las funcionalidades que utilizan los clientes, pero como sabemos que funcionalidades va a utilizar el cliente si aún no la hemos lanzado? Devops permite cambiar el enfoque en que priorizamos las funcionalidades de un producto. Pasamos de un enfoque basado en lo que el propietario o la gente de marketing quiere que tenga el producto a un enfoque basado en lo que el cliente quiere que tenga el producto. Para ello, la frecuencia de desarrollo y el uso de test A/B sobre grupos de clientes nos permiten conocer que funcionalidades y mejoras que quieren los clientes.

Por otro lado, todo y que a todos nos gustaría que un producto nunca fallara, tenemos que asumir que en el mundo real el fallo forma parte del ciclo de vida de un producto, falla la tecnología y fallamos nosotros. Todo y que con la automatización de los procesos de testing y deploy se reduce el número de fallos, debemos entrenarnos en la gestión del fallo para reducir el tiempo de recuperación ante fallo o MTTR (Mean Time To Repair). La reducción del tiempo de recuperación ante un fallo mejora la satisfacción del cliente.

En resumen, aplicar Devops permite reducir el tiempo de lanzamiento de un producto, distribuir al cliente aquello que desea el cliente, y mejorar la satisfacción del cliente.


Source: jmgriscom

Retorno de la inversión (ROI) en Devops

design-process-thumb

El calculo de cualquier retorno de inversión se basa en el ahorro esperado. Cuando analizamos el retorno de inversión de implantar prácticas como DevOps, es difícil cuantificar este ahorro en términos monetarios. Hay dos aspectos que nos pueden ayudar a entender los ahorros que obtenemos al implantar DevOps: ahorro de costos en horas de trabajo y ahorro de costos de caídas del sistema.

Por lo que hace al ahorro de coste en las horas de trabajo, podemos clasificar el trabajo de cualquier departamento de TI o desarrollo en dos tipos, trabajos planificados y trabajos no planificados, donde los trabajos planificados son aquellos que están destinados a aportar valor a nuestros clientes, en cambio, los trabajos no planificados son aquellos que se realizan a causa de errores o incidencias que hay de resolver de inmediato. Implantar prácticas de Devops permite reducir el tiempo de trabajo no planificado. Pero cual es el coste del trabajo no planificado?

En el informe anual que publica Puppet “State of Devops Report” del 2016, se plantea la siguiente formula para calcular el exceso de coste que supone el trabajo no planificado.

Cost del exceso de trabajo = Personas * Salario medio * Beneficios * Porcentaje de tiempo dedicado a trabajo extra.

• Número de personas: total de personas del equipo técnico.
• Salario medio: según un artículo de computerworld, que hace referencia a un informe de Addeco, el sueldo medio del sector TIC en España oscila entre los 30.000 y 60.000 euros anuales.
• Beneficios: es el coste de los variables o incentivos que perciben los trabajadores a más a más del sueldo, como tickets restaurant, mutuas, etc.. Podemos estimar un factor de 1.2 sobre el sueldo medio.
• Porcentaje de tiempo de trabajo extra: según el informe de Pupper “State of Devops Report” del 2016, para una empresa media este está entre un 10% y un 32%.

Para poner un ejemplo del coste de trabajo extra o trabajo no planificado realizado, ponemos que tenemos un equipo de 10 personas. El cálculo seria el siguiente:

Coste de exceso de trabajo = 10 * 45.000,00€/año * 1.2 * 22% = 540.000,00€/año * 22% = 118.800,00€/año

A este coste, debemos añadir el coste de las caídas de servicio, coste que varia mucho en función de la naturaleza de la organización y que no es fácil de calcular. Todo y la dificultad de calcular el coste de las caídas, es interesante ver la aproximación que se hace en el informe de Puppet,donde se plantea una formula para estimar el coste de las caídas de servicios.

Coste del “downtime” = Frecuencia de Deploys * Porcentaje de caídas * Tiempo medio de recuperación * Coste por hora de caída

• Frecuencia de deploys o despliegues que se realizan en el entorno de producción y que pueden ser causa de caídas del sistema.
• Porcentaje de caídas producidas por cambios en el sistema.
• Tiempo medio de recuperación o MTTR (Mean Time To Recover) que corresponde al tiempo medio que el equipo de operaciones tarda en recuperar los sistemas ante una caída.
• Coste de por hora de caída. Este dependerá mucho de lo crítico que sea el sistema caído.

Aquí las prácticas de Devops nos ayudan a reducir el tiempo de recuperación de los sistemas ante caídas y a reducir el porcentaje de errores producidos por cambios en el sistema.

Podéis encontrar más información en el informe de Puppet “2016 State of Devops Report”


Source: jmgriscom

Provisionar entorno de desarrollo con Vagrant y Chef Zero

En el post Gestión de a configuración o Configuration Management (CM), características y beneficiosvimos que uno de los beneficios de los sistemas de gestión de la configuración como Chef o Puppet es que permiten replicar entornos de forma fácil y rápida, lo que nos permite establecer flujos de trabajo a través de los diferentes de entornos idénticos (desarrollo, test, … y producción).  Por otro lado, en el post anterior Tu primer entorno de desarrollo con Vagrant vimos como crear un entorno de desarrollo utilizando Vagrant. Hoy vamos a profundizar un poquito más en la creación de entornos viendo un ejemplo de como provisionar un servidor virtual Vagrant con Chef utilizando una herramienta llamada Chef-Zero. 

Chef-zero es un servidor Chef ligero que se carga en memoria RAM y que permite ejecutar el código Chef que hemos desarrollado, de la misma forma que haríamos sobre un servidor Chef.  No vamos a entrar en detalle en como funciona Chef-zero, sino que solo veremos como configurar Vagrant para que ejecute código chef durante el proceso de provisión.

Para empezar vamos a crear un pequeña estructura de carpetas y un fichero con código Chef que instalará el servidor web Apache.

Estructura de carpetas y ficheros a crear:

nodes/
cookbooks/micookbook/recipes/
cookbooks/micookbook/recipes/default.rb

El contenido del fichero cookbooks/micookbook/recipes/default.rb es el siguiente:

package ‘apache2’ do
action :install
end
service “apache2” do
action :start
end

en el fichero default.rb, el código chef describe dos acciones a realizar: primero utiliza el recurso llamado ‘package’ para indicar que se debe instalar el paquete apache2, y segundo, utiliza el recurso ‘service’ para indicar que el servicio apache2 debe estar arrancado.

Para provisionar un servidor Vagrant con Chef-zero tenemos que instalar en Vagrant un par de plugins, omnibus y vbguest. En caso de utilizar otros sistemas de provision, se deberían instalar los plugins correspondientes. Para instalar los plugins en Vagrant hay que ejecutar los comandos siguientes desde la consola:

vagrant plugin install vagrant-omnibus
vagrant plugin install vagrant-vbguest

Finalmente, tenemos que configura Vagrant para que utilice chef-zero para provisionar el servidor. Como vimos en el post anterior “Tu primer entorno de desarrollo con Vagrant” (Link al post), esto se hace en el fichero Vagrantfile.

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = “ubuntu/xenial64”
config.vm.provision “chef_zero” do |chef|
chef.cookbooks_path = “cookbooks”
chef.nodes_path = “nodes”
chef.add_recipe “micookbook”
end
end

En el fichero Vagrantfile del ejemplo configuramos que se utilice el sistema de provisión chef_zero. También configuramos en que carpeta se encuentran los cookbook – los cookbook contienen los ficheros con el código Chef -, y en que carpeta se guardara el fichero de definición del nodo o servidor virtual.  Finalmente, se indica que recipes – fichero con código Chef – se ejecutará durante el proceso de provisión.

Una vez creado el código Chef y configurado Vagrant, ya podemos arrancar el servidor virtual mediante el comando “vagrant up”. Durante el proceso de arranque, una vez creado el servidor virtual, Vagrant ejecuta el código Chef en instala el servidor web Apache. Si accedemos al servidor (vagrant ssh) podemos ver que se ha instalado apache y que el servicio de apache esta en ejecución.


Source: jmgriscom

Tu primer entorno de desarrollo con Vagrant

Vagrant es una herramienta que nos permite crear y configurar entornos virtuales de desarrollo de forma fácil. La ventaja de crear un entorno de desarrollo con Vagrant es que lo podemos ejecutar sobre nuestro portátil o estación de trabajo, sin necesidad de utilizar infraestructuras externas. Podemos arrancar y parar el entorno tantas veces como queramos y finalmente lo podemos compartir con el resto del equipo de sistemas y desarrollo para que estos lo puedan ejecutar en su portátil.

Con Vagrant podemos ejecutar servidores virtuales con Windows, Linux o Mac OS X, y lo podemos hacer utilizando los hypervisores VMware Workstations, VMware Fusion o VirtualBox. Además Vagrant también dispone de conectores para ejecutar estos servidores virtuales sobre proveedores de infraestructura como AWS Amazon o Digitalocean entre otros.

Cuando utilizamos Vagrant con un sistema de gestión de configuración como Chef o Puppet, podemos desplegar una copia exacta de un entorno de producción sobre nuestro portátil. Donde podemos hacer cambios de configuración y probarlos antes de aplicarlos a producción.

A continuación veremos un ejemplo de como crear un entorno de desarrollo utilizando Vagrant con el hypervisidor Virtualbox para crear un servidor Linux con Ubuntu 16.04 LTS.

Antes de nada, hay que instalar tanto VirtualBox como Vagrant en nuestro portátil. Una vez instalado VirtualBox y Vagrant, debemos buscar la Vagrant Box (imagen de disco) del sistema operativo que queremos instalar,  en nuestro caso Ubuntu 16.04 LTS. En https://atlas.hashicorp.com/boxes/search buscamos la Vagrant Box de Ubuntu 16.04 LTS que se llama “ubuntu/xenial64”.

El siguiente paso es crear el fichero Vagrantfile. Este tiene la finalidad de establecer el directorio del proyecto y describir el entorno que vamos a instalar y su configuración. Para crear el fichero Vagrantfile con la Vagrant Box “ubuntu/xenial64” abrimos un terminal en el directorio donde queremos crear el servidor virtual y ejecutamos el comando siguiente:

vagrant init ubuntu/xenial64

Al ejecutar vagrant init se crear el fichero Vagratfile en el directorio desde donde hemos ejecutado vagrant init. Este se ha configurado con la Vagrant Box “ubuntu/xenial64”. Si editamos el fichero Vagrantfile veremos que ha configurado el parámetro “config.vm.box” con la Vagrant Box “ubuntu/xenial64”.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  config.vm.box = “ubuntu/xenial64”
end

Esta es la configuración basica del fichero Vagratfile, pero en el podemos configurar uno o más servidores virtuales que formaran nuestro entorno de desarrollo, y para cada uno de estos servidores podemos configurar sus recursos como la ram, ips, etc. En el fichero Vagrantfile también podemos configurar el método que vamos a utilizar para provisionar cada servidor.  Por ejemplo, podemos provisionar el servidor mediante un script bash o mediante un sistema de gestión de la configuración como Chef o Puppet. En otro post veremos como provisionar el servidor virtual mediante Chef.

Antes de arrancar el servidor descargamos la Vagrant Box y la guardamos en local para evitar que esta se descargue cada vez que arrancamos el servidor virtual.

vagrant box add ubuntu/xenial64

Cuando ya tenemos la Vagrant Box descargada ya podemos arrancar el servidor virtual, acceder por SSH y finalmente destruirlo cuando ya hemos finalizado el desarrollo.

Arrancar el servidor virtual:
vagrant up

Acceder por SSH al servidor virtual:
vagrant ssh

Destruir el servidor virtual:
vagrant destroy


Source: jmgriscom

DevOps con proveedores externos

 

Hay una pregunta que cualquier empresa puede hacerse cuando se plantea implantar prácticas de DevOps. ¿Puedo implantar prácticas DevOps cuando trabajo con proveedores externos ?

Son muchas las empresas que utilizan proveedores externos, ya sean estos desarrolladores, consultoras o proveedores de servicios. Y además, estos equipos externos realizan su trabajo remotamente desde diferentes lugares y zonas horarias. Para implantar Devops con proveedores externos hay un conjunto de pautas que ayudan a que la colaboración sea fluida.

 

Lo primero y esencial es establecer una comunicación abierta. La comunicación entre todos los equipos de trabajo, internos y externos, debe establecerse en todas las etapas, desde la fase de planificación a las fases  de pruebas, despliegue o operación. Es importante que todos los actores conozcan y participen en la definición de los proyectos y en la planificación. Para ello, es altamente recomendable establecer reuniones periódicas presenciales si es posible. El contacto genera empatía, permite compartir conocimiento e ideas y permite entender al otro, uno de los aspectos en que pone énfasis DevOps. En caso de no ser posible hacer reuniones presenciales, pueden hacerse reuniones utilizando programas de video conferencia como Skype o Hangouts.

DevOpsConProveedoresExternos

También es importante integrar a los equipos externos en los sistemas de mensajería internos como listas de correo, sistemas de Chat y permitir el acceso a los espacios de trabajo compartido como los recursos de red.

Por otro lado, también se puede integrar a los equipos externos en los procesos operativos y en los sistemas de gestión utilizados como los repositorios de código fuente, aplicaciones de gestión de proyectos, sistemas de monitorización, sistemas de automatización, etc.

Otro aspecto que ayuda mucho a la colaboración entre equipos remotos, es utilizar sistemas de virtualización o en cloud para el despliegue de los entornos de desarrollo y testing. Los sistemas de virtualización permiten a los equipos externos reproducir las infraestructuras de forma fácil y económica, y sin necesidad de compartir los sistemas internos.

En definitiva, el hecho de utilizar proveedores externos no debe ser un problema para utilizar prácticas DevOps. Lo que si que hay que ver en cada caso es como establecer una comunicación fluida entro todos los equipos de trabajo y como integrar a estos proveedores externos en los procesos internos de la empresa.
Source: jmgriscom

 

Monitorización en tiempo real, Elasticsearch, Logstash y Kibana

Si analizamos la infraestructura que gestionamos veremos que tenemos multitud de datos en forma de logs o de emails de sistema. Normalmente cada uno de estos logs con su propia aplicación de acceso y o  formato y sin ninguna relación con el resto de sistemas. A menudo, solo utilizamos esta información para evaluar lo sucedido después de una incidencia. Pero la verdad, es que si pudiéramos disponer de todos estos datos dispersos centralizados y normalizados en un formato común, dispondríamos de una fuente de información muy valiosa para gestionar nuestra infraestructura.

Existen diferentes herramientas que permiten centralizar todos estos datos y normalizar su formato. Estas herramientas facilitan el acceso a estos datos y permiten la generación de métricas de gestión y también la generación de alertas. Una de estas herramientas es ELK (Elasticsearch, Logstash y Kibana). Esta herramienta nació de la unión de los proyectos open source Elasticsearch, Logstash y Kibana que gestiona la empresa elastic…

  • Elastisearch es un sistema distribuido de almacenamiento de documentos JSON con un sistema de búsqueda de datos basado en Apache Lucene.
  • Logstash es un sistema para la centralización de logs que permite procesar estos logs y almacenarlos en Elasticsearch entre otros sistemas de almacenamiento.
  • Kibana es un a interface web para acceder a los datos almacenados en Elasticsearch de forma rápida y ordenada.

Lo que inicialmente era una herramienta de gestión de logs centralizada a evolucionado hacia un sistema capaz de captar datos de cualquier fuente, en cualquier formato y analizarlos, establecer correlaciones y mostrarlos en tiempo real. Actualmente, el núcleo de la herramienta esta formado por Elasticsearch, Logstash, Kibana y Beats, todos open source. Este último, Beats, es una plataforma para la recolección y envío de datos a Elasticsearch, datos que podrán ser visualizados en Kibana de forma ordenada. De base existen cuatro tipos de Beats, Filebeats, Packebeats, Topbeats o Metricbeats y Winlogbeats.

  • Filebeats permite recoger ficheros de log, preprocesarlos y enviarlos a Elasticsearch.
  • Packetbeat permite recoger el tráfico de red de cualquier protocolo como por ejemplo http o mysql y enviarlo a Elastisearch para ser analizado.
  • Topbeats (Metricbeats en las siguientes versiones) recoge información de sistema como uso de ram, cpu, espacio de disco, etc. a intervalos definidos (10 segundos por ejemplo) y enviarlos a Elasticsearch para ser analizados.
  • Winlogbeats permite recoger información de sistema, de aplicación y de seguridad del registro de eventos de Windows y enviarlo a Elasticsearch.

La plataforma Beats, no se limita a Filebeat, Packetbeat, Topbeat y Winlogbeat, sino que dispone de una librería open source llamada Libbeat que permite definir nuestros propios Beats de recogida de datos para enviarlos a Elasticsearch.

elastic search

Top Dashboard: Fuente www.elastic.co

Este tipo de herramientas como ELK, permiten definir una nueva aproximación a la monitorización de  infraestructuras y aplicaciones, basada en la generación de gráficas en tiempo real, el disparo de alertas cuando se produce un evento y la correlación de datos de diferentes fuentes. A título de ejemplo, con Elasticsearch podemos disponer de estadísticas en tiempo real  de uso de los recursos (cpu, ram, disco, …) de lo servidores físicos, virtuales o en cloud, estadísticas de errores HTTP y de rendimiento del servidor web, estadísticas de rendimiento del servidor de base de datos, estadísticas de usuarios conectados, etc. Y todo esto con la posibilidad de correlar diferentes fuentes de información.

Source: jmgriscom

Continous, continous, continous

Continous integrations, Continous delivery, Continous deployment,  son conceptos que cada vez oímos más. Uno de ellos, continous delivery es de vital importancia para la gestión de cualquier cambio a aplicar en uno o un conjunto de servidores.

Los que hayan trabajado o colaborado con equipo de desarrollo de software seguramente el concepto continous integration o integración continua les sea familiar. La integración continua es una técnica utilizada por los equipos de desarrollo para detectar fallos en el código cuanto antes. Esta consiste en ejecutar de forma automática un conjunto de test cada vez que se sube un cambio al repositorio de código fuente. Estos test comprueban todas las funcionalidades de la aplicación para detectar si el nuevo cambio afecta a alguna de las funcionalidades de la aplicación. Este proceso protege de desplegar código erróneo a producción.

El concepto de continous delivery va un paso más allá. Continous delivery lleva la idea de integración continua a todos los actores y procesos  que participan en el flujo de despliegue de una aplicación o actualización de un sistema. El objetivo es desplegar todos los cambios, ya sea la instalación de nuevas funcionalidades, actualizar un bug o aplicar nuevas configuraciones a producción de forma segura y rápida.

La idea es establecer un conjunto de etapas o pipeline a través de las cuales pasa cada cambio antes de ser aplicado al entorno de producción. El objetivo de cada una de estas etapas es validar la calidad del cambio desde diferentes puntos de vista y prevenir los errores. No hay un pipeline único, sino que cada organización tienes su propio pipeline,  pero típicamente este puede estar formado por algunas es estas etapas:

  • Integración continua.
  • Ejecución de test funcionales.
  • Ejecución de test de seguridad.
  • Ejecución de test de rendimiento.
  • Despliegue a producción.
  • Operación.

El esquema siguiente muestra un pipeline para la gestión de cambios en los sistemas, donde lo deseado es que todas las etapas del pipeline sean automática, solo dejando el paso a producción con una acción manual, todo y que solo sea para activar el despliegue del cambio en el entorno de producción.

esquema continuos

Cada una de las etapas debe informar a los diferentes actores que intervienen en el proceso de continous delivery (desarrolladores, operadores, ingenieros de calidad, ingenieros de seguridad, gestores, …) del resultado de cada etapa. De esta forma, detectamos los problemas que pueda ocasionar un nuevo cambio antes que este se aplique sobre el entorno producción.

Para poder agilizar el proceso de aplicación de cambios y repetirlo tantas veces como sea necesarios, es básico automatizar los test ejecutados en cada una de estas etapas. Por otro lado, existen herramientas como Jenkins que permiten configurar y automatizar las etapas del pipeline.

Si os interesa, en https://continuousdelivery.com/ encontrareis recursos que profundizan en el tema.


Source: jmgriscom