Diferencia entre revisiones de «Sensu»
(Página creada con «= Introducción = Herramienta para la monitorización de grandes plataformas y con posibilidad de desbordamiento y elasticidad. = Referencias = * Para la instalación exi...») |
|||
Línea 5: | Línea 5: | ||
* Para la instalación existe esta [http://joemiller.me/2012/01/19/getting-started-with-the-sensu-monitoring-framework/ página] que explica como comenzar | * Para la instalación existe esta [http://joemiller.me/2012/01/19/getting-started-with-the-sensu-monitoring-framework/ página] que explica como comenzar | ||
* La página oficial de [http://www.sonian.com/cloud-monitoring-sensu/ sonian] para el producto de monitorización | * La página oficial de [http://www.sonian.com/cloud-monitoring-sensu/ sonian] para el producto de monitorización | ||
+ | |||
+ | |||
+ | = Instalación = | ||
+ | En mi caso la instalación la he realizado con el modulo de puppet sensu/sensu. Este módulo contempla la instalación tanto del servidor como del cliente. | ||
+ | |||
+ | Tiene dependencia de Rabbitmq y de redis. Para ambos dos hay módulos para realizar la instalación. | ||
+ | |||
+ | En el caso del manifiesto que instala el servidor de sensu, en mi ejemplo es como sigue: | ||
+ | |||
+ | <pre> | ||
+ | sensu::server { "${::hostname}" : | ||
+ | rabbitmq_host => 'Centos1.ardemans.int', | ||
+ | rabbitmq_port => '5673', | ||
+ | rabbitmq_user => 'sensu-user', | ||
+ | rabbitmq_password => 'secret', | ||
+ | rabbitmq_vhost => 'sensu', | ||
+ | redis_host => 'Centos1.ardemans.int', | ||
+ | redis_port => '6379', | ||
+ | dashboard_host => '0.0.0.0', | ||
+ | dashboard_port => '8088', | ||
+ | </pre> | ||
+ | |||
+ | Donde se especifican los datos para conectar a rabbitmq y a redis. También levanta el servicio dashboard y le especificas el puerto por el que quieres acceder a él. | ||
+ | |||
+ | La instalación la realiza en /opt/sensu. La configuración la ubica en /etc/sensu y los logs en /var/log/sensu. | ||
+ | |||
+ | = Configuración = | ||
+ | |||
+ | La configuración está dividida en unos cuantos directorios. El fichero principal de configuracion es /etc/sensu/config.json y es como esta: | ||
+ | |||
+ | <pre> | ||
+ | { | ||
+ | "redis": { | ||
+ | "host": "Centos1.ardemans.int", | ||
+ | "port": 6379 | ||
+ | }, | ||
+ | "rabbitmq": { | ||
+ | "vhost": "sensu", | ||
+ | "host": "Centos1.ardemans.int", | ||
+ | "password": "secret", | ||
+ | "user": "sensu-user", | ||
+ | "port": 5673 | ||
+ | }, | ||
+ | "api": { | ||
+ | "host": "localhost", | ||
+ | "port": 4567 | ||
+ | }, | ||
+ | "dashboard": { | ||
+ | "host": "0.0.0.0", | ||
+ | "password": "~#@~|€~#", | ||
+ | "user": "admin", | ||
+ | "port": 8088 | ||
+ | } | ||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | Este fichero es el generado por el módulo de puppet. | ||
+ | |||
+ | Después hay un directorio /etc/sensu/conf.d donde hay varios ficheros con la configuración propia de las monitorizaciones. | ||
+ | |||
+ | <pre> | ||
+ | checks_cpu-metrics.json | ||
+ | checks_disk-capacity-metrics.json | ||
+ | checks_disk-metrics.json | ||
+ | client.json | ||
+ | handlers_default.json | ||
+ | handlers_graphite.json | ||
+ | handlers_stdout.json | ||
+ | </pre> | ||
+ | |||
+ | El fichero client.json es el que se usa cuando se levanta el servicio cliente de las máquinas que queremos monitorizar. Su contenido es sencillo: | ||
+ | |||
+ | <pre> | ||
+ | { | ||
+ | "client": { | ||
+ | "address": "192.168.2.52", | ||
+ | "name": "Centos3", | ||
+ | "subscriptions": [ | ||
+ | "generico" | ||
+ | ] | ||
+ | } | ||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | Se especifica el nombre y las subscripciones a las que está unido para monitorización | ||
+ | |||
+ | Después hay varios ficheros con chequeos y otros con los handler. | ||
+ | |||
+ | Los de chequeo solo los encontramos en el servidor de sensu, y son los que especifican que se va a ejecutar en el cliente: | ||
+ | |||
+ | <pre> | ||
+ | { | ||
+ | "checks": { | ||
+ | "cpu-metrics": { | ||
+ | "type": "metric", | ||
+ | "command": "/etc/sensu/plugins/system/cpu-metrics.rb --scheme cpu-metrics.:::name:::", | ||
+ | "interval": 60, | ||
+ | "handlers": [ | ||
+ | "graphite" | ||
+ | ], | ||
+ | "subscribers": [ | ||
+ | "generico" | ||
+ | ] | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | En este caso se le dice que es un chequeo de tipo métrica, y que forma parte de la suscripción "generico". Todos los clientes que estén unidos a esta subscripción ejecutarán este chequeo. | ||
+ | |||
+ | El servidor, cada cierto tiempo (interval) mandará a la cola de rabbitmq una petición de chequeo, que ejecutaran todos los subscriptores y devolverán los datos en la cola de resultados de rabbitmq. Sensu server los recogerá y procesara. | ||
+ | |||
+ | Para saber que hacer con los datos de respuesta están los handler. Uno muy típico es el que manda los datos a graphite: | ||
+ | |||
+ | <pre> | ||
+ | { | ||
+ | "handlers": { | ||
+ | "graphite": { | ||
+ | "type": "amqp", | ||
+ | "exchange": { | ||
+ | "type": "topic", | ||
+ | "name": "graphite", | ||
+ | "durable": "true" | ||
+ | }, | ||
+ | "mutator": "only_check_output" | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | En este caso le decimos que los datos de respuesta los mande a un exchange de rabbitmq que se llama graphite. Al otro extremo de la cola estará graphite recogiendo los datos y meteniendolos en su DB (Carbon) | ||
+ | |||
+ | Otro ejemplo más sencillo es mandar los resultados a un fichero | ||
+ | |||
+ | <pre> | ||
+ | { | ||
+ | "handlers": { | ||
+ | "stdout": { | ||
+ | "type": "pipe", | ||
+ | "command": "/etc/sensu/handlers/debug/stdout.sh", | ||
+ | "mutator": "only_check_output" | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | El mutator "only_check_output" es para que, de la respuesta que se manda a la cola de resultados, solo coja el campo que realmente tiene la salida del script, ya que además manda otros datos. |
Revisión de 09:01 15 mar 2013
Introducción
Herramienta para la monitorización de grandes plataformas y con posibilidad de desbordamiento y elasticidad.
Referencias
- Para la instalación existe esta página que explica como comenzar
- La página oficial de sonian para el producto de monitorización
Instalación
En mi caso la instalación la he realizado con el modulo de puppet sensu/sensu. Este módulo contempla la instalación tanto del servidor como del cliente.
Tiene dependencia de Rabbitmq y de redis. Para ambos dos hay módulos para realizar la instalación.
En el caso del manifiesto que instala el servidor de sensu, en mi ejemplo es como sigue:
sensu::server { "${::hostname}" : rabbitmq_host => 'Centos1.ardemans.int', rabbitmq_port => '5673', rabbitmq_user => 'sensu-user', rabbitmq_password => 'secret', rabbitmq_vhost => 'sensu', redis_host => 'Centos1.ardemans.int', redis_port => '6379', dashboard_host => '0.0.0.0', dashboard_port => '8088',
Donde se especifican los datos para conectar a rabbitmq y a redis. También levanta el servicio dashboard y le especificas el puerto por el que quieres acceder a él.
La instalación la realiza en /opt/sensu. La configuración la ubica en /etc/sensu y los logs en /var/log/sensu.
Configuración
La configuración está dividida en unos cuantos directorios. El fichero principal de configuracion es /etc/sensu/config.json y es como esta:
{ "redis": { "host": "Centos1.ardemans.int", "port": 6379 }, "rabbitmq": { "vhost": "sensu", "host": "Centos1.ardemans.int", "password": "secret", "user": "sensu-user", "port": 5673 }, "api": { "host": "localhost", "port": 4567 }, "dashboard": { "host": "0.0.0.0", "password": "~#@~|€~#", "user": "admin", "port": 8088 } }
Este fichero es el generado por el módulo de puppet.
Después hay un directorio /etc/sensu/conf.d donde hay varios ficheros con la configuración propia de las monitorizaciones.
checks_cpu-metrics.json checks_disk-capacity-metrics.json checks_disk-metrics.json client.json handlers_default.json handlers_graphite.json handlers_stdout.json
El fichero client.json es el que se usa cuando se levanta el servicio cliente de las máquinas que queremos monitorizar. Su contenido es sencillo:
{ "client": { "address": "192.168.2.52", "name": "Centos3", "subscriptions": [ "generico" ] } }
Se especifica el nombre y las subscripciones a las que está unido para monitorización
Después hay varios ficheros con chequeos y otros con los handler.
Los de chequeo solo los encontramos en el servidor de sensu, y son los que especifican que se va a ejecutar en el cliente:
{ "checks": { "cpu-metrics": { "type": "metric", "command": "/etc/sensu/plugins/system/cpu-metrics.rb --scheme cpu-metrics.:::name:::", "interval": 60, "handlers": [ "graphite" ], "subscribers": [ "generico" ] } } }
En este caso se le dice que es un chequeo de tipo métrica, y que forma parte de la suscripción "generico". Todos los clientes que estén unidos a esta subscripción ejecutarán este chequeo.
El servidor, cada cierto tiempo (interval) mandará a la cola de rabbitmq una petición de chequeo, que ejecutaran todos los subscriptores y devolverán los datos en la cola de resultados de rabbitmq. Sensu server los recogerá y procesara.
Para saber que hacer con los datos de respuesta están los handler. Uno muy típico es el que manda los datos a graphite:
{ "handlers": { "graphite": { "type": "amqp", "exchange": { "type": "topic", "name": "graphite", "durable": "true" }, "mutator": "only_check_output" } } }
En este caso le decimos que los datos de respuesta los mande a un exchange de rabbitmq que se llama graphite. Al otro extremo de la cola estará graphite recogiendo los datos y meteniendolos en su DB (Carbon)
Otro ejemplo más sencillo es mandar los resultados a un fichero
{ "handlers": { "stdout": { "type": "pipe", "command": "/etc/sensu/handlers/debug/stdout.sh", "mutator": "only_check_output" } } }
El mutator "only_check_output" es para que, de la respuesta que se manda a la cola de resultados, solo coja el campo que realmente tiene la salida del script, ya que además manda otros datos.