Ir al contenido principal

Entradas

Algunas configuraciones básicas en Riemann

A últimas fechas estaré hablando mucho de Riemann,un software que como espina dorzal, funciona muy bien en diferentes propósitos de monitoreo. Creo que su competidor, o alternativa, más cercana, es Nagios, solo que por Riemann, no se paga un solo peso. Riemann es muy flexible, puesto que por si mismo puede ser un agente de monitoreo  muy completo (tiene muchos plugins), pero su verdadero poder reside en los múltiples conexiones que tiene con otros proyectos, como Graphite, Collectd y  Grafana, por nombrar solo algunos. Por esta característica, es muy útil hacerlo funcionar como un event engine , el cual se encargará de dotar de un formato y un ruteo de métricas. En algún punto, también permite tomar decisiones sobre ellas. Es decir, en Riemann pueden recaer todas las  especificidades de alarmado y tomda de decisiones en función de los valores de las métricas. En este segundo post de Riemann abordaré como ejecutarlo y algunos de los primeros pasos para familiarizarse ...

Formateando salida de SAR

SAR es la herramienta por excelencia para el monitoreo de los sistemas operativos GNU/Linux. Cuenta con históricos, además de una gran cantidad de métricas relacionadas al desempeño de nuestro servidor, como cpu, memoria, I/O y red. Cada uno de estos hitos puede ser diseccionado con mayor granularidad, es decir, observar la parte que compone cada recurso. Algunas veces es necesario realizar reportes de desempeño a otras áreas o incluso para efectos de conocimiento de patrones de utilización de cada servidor. Por desgracia, las formas de llevar a un modelo de visualización más amable es tarea un poco más complicada y no está incorporada por defecto con SAR. Existen herramientas ex profeso, sin embargo, tienen que ser utilizadas con cierta complejidad y algunas veces no producen el resultado deseado, como por ejemplo, gráficas de muy pobre visualización. En lo personal me gusta graficar las métricas; son una manera muy simple de entender lo que sucede y enfocarnos en los momento...

Instalación de Riemann

El tema del monitoreo es por sí solo vasto y exige cierto nivel de especialización y comprensión. Como todas las soluciones de software , el establecimiento de una arquitectura y elección de productos conlleva un conocimiento profundo del las necesidades y las mejores opciones disponibles, no solo en términos de costos, sino de prestaciones y flexibilidad de los productos que están en el mercado. No es cosa fácil establecer un flujo y tratamiento adecuado de las métricas recolectadas. En lo que mi experiencia acontece, éste rubro de las TI apenas se le da importancia, se mira como un gasto que no tiene retorno. Los profesionales lo entienden como la manera en detectar problemas en los ambientes productivos, pero que si se detectan vía registros, el problema está cuasi resuelto, por tanto, la necesidad de un sistema complejo de monitoreo no es necesario.  No estoy a favor de acumular datos y sólo mantenerlos por si llegasen a requerirse en algún punto, si l...

Compilando un kernel

Esta nota no es nada nuevo, solo es un recetario muy básico de compilación de un kernel Linux con las especificaciones que usa la versión del kernel actual. Para mi es una lata estar cambiando constantemente las instalaciones de Fedora, por lo cual opto por compilar el kernel y así estar al último grito de la moda. Sé que conlleva más tiempo que si lo instalara desde cero. Ya sé que existe el particionamiento de volúmenes, y de hecho es como lo tengo, donde podemos instalar en el volumen específico del sistema operativo. Con esta opción no pierdo las adecuaciones de mi entorno gráfico, como las hotkeys, barras y distribuciones de mi XFCE y otras cosas que me han levado años configurar. Así que vamos a hacerlo. Lo primero es bajarse el kernel de linux de kernel.org.  Lo segundo es descomprimirlo. Yo lo hago en /usr/src/kernels.  Lo tercero es copiamos el archivo /boot/config-4.4.6-201.fc22.x86_64 (el nombre depende de la versión actual del kernel) a la ...

Descarga de logs

Muchas veces es necesario, como administrador de middleware o de plataforma hacer la descarga periódica de logs. Está demás decir para qué puede servirnos retenerlos, pero una forma simple y fácil es como la siguiente. #!/bin/sh ######################################################################################## # # # Descarga los los de las aplicaciones administradas. # Lo ideal es que esté ejecutándose en un escheduler, como cron. # # 08 Septiembre 2016 # ######################################################################################## # Variables globales DIR_NAME=`date +'%B'` LAST_MONTH=`date +'%B' -d 'last month'` LAST_MONTH_NUM=`date +'%m' -d 'last month'` SUFFIX_LOG=`date +'%Y-%m'` # APP1 USER="remoteuser" SERVER_1="172.23.100.xxx" LOCAL_LOG_PATH="/home/lyonn/produccion/app1/log/$DIR_NAME" SERVER_REMOTE_LOG_PATH="/opt/jboss/app/myapp1/production/log/*$SUFFIX_LO...

¿Cómo saber que nuestro sistema ha sido comprometido?

En este post no busco ahondar mucho sobre las formas y procedimientos que un profesional forense debe considerar. Solo quiero hacer un escrito lacónico que ayude a los neófitos como yo, a buscar la mejora ante las adversidades. Las ideas las tomé de Linux Hardening , un libro ya entrado en años pero que se mantiene vigente con la respectiva evolución de las herramientas que ilustra.  Cuando un sistema es vulnerado, o pensamos que lo ha sido; de alguna manera es tarde y ésto sólo nos ayudará a prevenir por medio de la rutinaria inspección de cada servidor (puede contarse con una automatización y paulatinamente con herramientas más profesionales). En medida de lo posible, recomiendo que prevengamos una cosa. Aseguremos que cada comando que utilicemos sea el que instalamos. Pienso que si un atacante puede comprometer nuestro sistema y sembrar piezas de software que lo mantengan oculto, no le será nada difícil manipular algunos de los comandos que nos permitirían reconocerlo. ...

Comenzando con DevOps

Si bien el concepto no es nuevo, se ha puesto de moda. Pocos son los empleos en los que no se hable de las "nuevas metodologías ágiles" para el ciclo de vida de desarrollo y operaciones IT. Me ha interesado nutrirme del tema con las voces que más experiencia tienen en el ramo.  El siguiente documento lo hallé en Internel, el cual me pareció que valía la pena por lo conciso que es y la explicación clara. Es ambicioso en muchos aspectos, que en mi experiencia rara vez se cumplen, pero aún así, como dije, no tiene desperdicio. En resumen y siendo muy simplistas, devops es una filosofía de ayudas mutuas de cara a los continuos cambios. Ya veremos si ésto es cierto en las empresas que lo consoliden, meta ambiciosa pero no por ello imposible. Descargar documento.