1. Consignar las instrucciones comentadas para la instalación y configuración del stack de sensu (cliente, servidor, api, uchiwa dashboard y rabbitmq como bus de mensajería)
A continuacion se explica como instalar y configurar un stack de sensu, cuya configuracion basica presenta los elementos resaltados en el cuadro rojo de la siguiente imagen:
Desde el lado del servidor, un sistema de monitoreo de sensu cuenta con los siguientes elementos:
1.sensu-server: se encarga de publicar checks, para realizar monitoreo, a los cuales los clientes se subscriben. Los clientes ejecutan estos checks y envian los resultados. Sensu-server los almacena en una base de datos llamada redis.
2.redis: es una base de datos que se utiliza en sensu para guardar la informacion enviada por los clientes en formato JSON.
3.sensu-api: API REST utilizada para acceder a los datos de monitoreo de sensu
4.sensu-dashboard: Se utiliza para mostrar de forma grafica los resultados del monitoreo. En este caso se utilizara el dashboard uchiwa.
5.rabbitmq: es un bus de mensajeria, que recibe todos los resultados de los clientes y los suministra uno por uno al componente sensu-server. Su principal funcion es evitar saturar el componente sensu-server con gran cantidad de resultados de monitoreo provenientes de los clientes.
Para la instalacion de estos componentes en el servidor, se deben ejecutar los siguientes comandos.
echo '[sensu]
name=sensu
baseurl=https://sensu.global.ssl.fastly.net/yum/$releasever/$basearch/
gpgcheck=0
enabled=1' | sudo tee /etc/yum.repos.d/sensu.repo
yum install sensu -y
su -c 'rpm -Uvh http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm'
yum install erlang -y
yum install redis -y
yum install socat -y
su -c 'rpm -Uvh http://www.rabbitmq.com/releases/rabbitmq-server/v3.6.9/rabbitmq-server-3.6.9-1.el7.noarch.rpm'
service rabbitmq-server start
rabbitmqctl add_vhost /sensu
rabbitmqctl add_user sensu password
rabbitmqctl set_permissions -p /sensu sensu ".*" ".*" ".*"
rabbitmq-plugins enable rabbitmq_management
chown -R rabbitmq:rabbitmq /var/lib/rabbitmq/
rabbitmqctl add_user test test
rabbitmqctl set_user_tags test administrator
rabbitmqctl set_permissions -p / test ".*" ".*" ".*"
yum install uchiwa -y
firewall-cmd --zone=public --add-port=5672/tcp --permanent
firewall-cmd --zone=public --add-port=15672/tcp --permanent
firewall-cmd --zone=public --add-port=3000/tcp --permanent
firewall-cmd --reloadCada componente mencionado cuenta con un archivo de configuracion en formato json, cuya ubicacion es /etc/sensu/conf.d. De esta forma:
para sensu-server ---> client.json
{
"client": {
"name": "server",
"address": "127.0.0.1",
"subscriptions": [ "ALL" ]
}
}para redis ---> redis.json
{
"redis": {
"host": "127.0.0.1",
"port": 6379
}
}para sensu-api ---> api.json
{
"api": {
"host": "127.0.0.1",
"bind": "0.0.0.0",
"port": 4567
}
}para rabbitmq ---> rabbitmq.json
{
"rabbitmq": {
"host": "127.0.0.1",
"port": 5672,
"vhost": "/sensu",
"user": "sensu",
"password": "password"
}
}para uchiwa ---> uchiwa.json
{
"sensu": [
{
"name": "sensu",
"host": "localhost",
"ssl": false,
"port": 4567,
"path": "",
"timeout": 5000
}
],
"uchiwa": {
"port": 3000,
"stats": 10,
"refresh": 10
}
}Por otro lado, como ya se ha mencionado antes, el servidor de sensu se encarga de publicar checks a los cuales los clientes se subscriben. Para publicar estos checks hay que definir un archivo en formato json. En este caso, se definira un check para comprobar que un servicio web (documentado en el siguiente enlace: https://github.com/CarlosLlano/so-exam2/blob/master/A00170892.md) este funcionando.
Asi, el archivo check_apache.json define:
{
"checks": {
"servicioWeb_check": {
"command": "/opt/sensu/embedded/bin/ruby /etc/sensu/plugins/check_web.rb",
"interval": 15,
"subscribers": ["webservers"]
}
}
}El check establece que cada cliente, si se subscribe a "webservers", debe ejecutar el comando definido en "command". El comando consiste en ejecutar un script de ruby, por tanto, cada cliente suscrito debe tener dicho script en la carpeta /etc/sensu/plugins. Dicho script es el siguiente:
procs = `ps aux`
running = false
procs.each_line do |proc|
running = true if proc.include?('python web.py')
end
if running
puts 'OK - Api rest funcionado'
exit 0
else
puts 'WARNING - Api rest no esta funcionando'
exit 1
endDesde el lado del cliente, basta con instalar el paquete de monitoreo de sensu con los siguientes comandos:
echo '[sensu]
name=sensu
baseurl=https://sensu.global.ssl.fastly.net/yum/$releasever/$basearch/
gpgcheck=0
enabled=1' | sudo tee /etc/yum.repos.d/sensu.repo
yum install sensu -yLos archivos de configuracion son archivos en formato json almacenados en la carpeta /etc/sensu/conf.d
para identificar al cliente ante el servidor ---> client.json
{
"client": {
"name": "cliente-parcial3",
"address": "192.168.0.19",
"subscriptions": ["webservers"]
}
}para identificar al servidor ---> rabbitmq.json
{
"rabbitmq": {
"host": "192.168.0.21",
"port": 5672,
"vhost": "/sensu",
"user": "sensu",
"password": "password",
"heartbeat": 10,
"prefetch": 50
}
}Para poner en funcionamiento el servidor, ejecutar en el siguiente orden:
service redis start
service rabbitmq-server start
service sensu-server start & service sensu-api start
service uchiwa start Para poner en funcionamiento el cliente, ejecutar
service sensu-client start2. Evidencie la correcta instalación del stack de sensu por medio de la creación de un api rest de prueba y su check de sensu respectivo. Evidencie la generación de una alerta ante la caída del servicio
El api rest de prueba que se utilizo fue el implementado para el parcial 2 (https://github.com/CarlosLlano/so-exam2/blob/master/A00170892.md) Como se menciono antes, se definio un check que valida si este servicio esta funcionando o no.
3. Realice la instalación y configuración de un plugin de sensu para el monitoreo de infraestructura (disco, memoria ram, procesador)
se instalo un plugin de sensu para el monitoreo de cpu:
Se utilizará para la prueba el archivo check-load.rb. Para mayor facilidad, se hara una copia en /etc/sensu/plugins. Tambien se modifico el archivo de configuracion de checks del servidor:
{
"checks": {
"servicioWeb_check": {
"command": "/opt/sensu/embedded/bin/ruby /etc/sensu/plugins/check-load.rb",
"interval": 15,
"handlers": ["slack"],
"subscribers": ["webservers"]
}
}
}Evidencia del funcionamiento:
4. Crear un handler en slack para el envío de una notificación en caso de ocurrir una caída del servicio de prueba creado en el ítem anterior.
El servicio de prueba sera el servicio web utilizado anteriormente. Para el handler de slack se crea el archivo handler_slack.json en el servidor.
{
"handlers": {
"slack": {
"type": "pipe",
"command": "/opt/sensu/embedded/bin/ruby /opt/sensu/embedded/lib/ruby/gems/2.4.0/gems/sensu-plugins-slack-1.0.0/bin/handler-slack.rb -j slack-integration",
"severites": ["warning", "unknown"]
}
},
"slack-integration": {
"webhook_url": "https://hooks.slack.com/services/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",
"template" : ""
}
}En el archivo de checks del servidor se añade este handler de slack.
{
"checks": {
"servicioWeb_check": {
"command": "/opt/sensu/embedded/bin/ruby /etc/sensu/plugins/check_web.rb",
"interval": 15,
"handlers": ["slack"],
"subscribers": ["webservers"]
}
}
}Anteriormente se creo un team llamado "TestSO", al cual se le creo un canal llamado "service-alerts". De dicho canal se obtuvo el webhook_url presente en handler_slack.json.
Evidencia del funcionamiento:
5. Consignar las instrucciones comentadas para la instalación y configuración del stack de ELK (elasticsearch, logstash, kibana, filebeat en el client)
En este caso se utilizara un solo nodo para la instalacion de todo el stack ELK. El primer paso es instalar la llave publica
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearchPosteriormente, se procede a instalar cada uno de los componentes del stack. Para cada uno se crea un archivo que servira de repositorio y luego se procede a la instalacion.
elasticseach
repositorio
vi /etc/yum.repos.d/elasticsearch.repocontenido del repositorio
[elasticsearch-5.x]
name=Elasticsearch repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1 autorefresh=1 type=rpm-mdinstalacion
sudo yum install elasticsearchlogstash
repositorio
vi /etc/yum.repos.d/logstash.repocontenido del repositorio
[logstash-5.x]
name=Elastic repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1 autorefresh=1 type=rpm-mdinstalacion
sudo yum install logstashkibana
repositorio
vi /etc/yum.repos.d/kibana.repocontenido del repositorio
[kibana-5.x]
name=Kibana repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1 autorefresh=1 type=rpm-mdinstalacion
sudo yum install kibana*filebeat
repositorio
vi /etc/yum.repos.d/elastic.repocontenido del repositorio
[elastic-5.x]
name=Elastic repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1 autorefresh=1 type=rpm-mdinstalacion
sudo yum install filebeatUna vez terminada la instalacion, se debe proceder a la configuracion de cada uno de los elementos del stack. Para ello, es importante tener clara las funcionalidades de cada elemento:
elasticsearch = base de datos no relacional donde se guardan datos en formatos json
Kibana = herramienta de visualizacion de los datos de elasticsearch
filebeat = es un intermediario, envia logs desde el cliente hacia logstash.
logstash = es un collector, sirve para preprocesar la información (logs) enviada por los clientes antes de enviarla a elasticsearch
Dicho esto, las configuraciones son las siguientes:
*para elasticsearch
En el archivo /etc/elasticsearch/elasticsearch.yml.
network.host: 192.168.0.19
http.port: 9200para kibana
En el archivo /etc/kibana/kibana.yml.
server.port: 5601
server.host: "192.168.0.19"
elasticsearch.url: "http://192.168.0.19:9200"para filebeat
Dado que filebeat debe enviar logs, se debe especificar cual es el archivo que contiene esos logs. En este caso se utilizara el archivo de logs de httpd
En el archivo /etc/filebeat/filebeat.yml
input_type: log
paths:
- /var/log/httpd/access_logTambien se debe especificar el destino de esos logs.
output.logstash:
hosts: ["192.168.0.19:5044"]para logstash
Dado que logstash debe preprocesar una informacion antes de enviarla a elasticsearch, se debe especificar en un archivo cual es la entrada de la informacion (input), la manera de preprocesarla (filter), y una salida (output).
Para ello se crea el archivo /etc/logstash/conf.d/apache-logstash.conf con el contenido siguiente:
input {
beats {
port => "5044"
}
}
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}"}
}
}
output {
elasticsearch
{
hosts => ["192.168.0.19:9200"]
}
}El objetivo de este filtro en particular es preprocesar los logs de httpd, los cuales tienen una estructura en cierto grado desordenada...
...y darles un formato en el cual sean identificables los siguientes campos.
Finalmente para poner todo en funcionamiento se deben ejecutar los siguientes comandos:
service elasticsearch start
service kibana start
service logstash start
filebeat.sh -e -c filebeat.yml -d "publish"6. Evidencie la correcta instalación del stack ELK
