Monitorización de Negocio con Centreon

/ , / , , , , , , , , , , , , , , , , , , , , /

Hace tiempo que no hablamos de este tema tan interesante, el tener una visualización operacional, un control sobre nuestro negocio, una manera de conocer el estado de los servicios que mantienen la empresa funcionando! Me apetecía hacer un post para compartiros las posibilidades a las que nos enfrentamos.

 

Como bien sabemos, gracias a sistemas de monitorización como pueda ser Centreon, podemos monitorizar nuestra infraestructura. Una monitorización exhaustiva, junto un profundo análisis nos permitirá conocer cualquier punto crítico de la infraestructura que presta un servicio. Estos servicios serán los que ofrecemos a nuestros propios usuarios, clientes o proveedores.

Pues la idea es esa, escalar una monitorización propia de infraestructura a un nivel superior, a un nivel, donde personas no técnicas, si no responsables o ejecutivos que necesiten conocer en tiempo real cómo está su negocio. Unos paneles web que le permitirán saber por qué un servicio operacional pueda verse afectado, que le permita bajar a las tripas y saber por qué las cosas funcionan, unos paneles que le permitan realizar simulaciones del estilo ‘qué pasa sí…’, que conozca el SLA que se le está ofreciendo por cada servicio de negocio…

Todo lo que veremos en este post se basa 100% en open source, aunque sí es cierto que Centreon u otros productos puedan ofrecer algo similar bajo productos de pago. En estos posts antiguos ya vimos la parte técnica, cómo montarlo.

Hoy se trata de ver un ejemplo práctico, y pondremos de ejemplo sencillito, mi empresa, «Open Services IT», una empresa que presta servicios de IT. Así que, sabiendo qué necesitamos para que la empresa pueda realizar su desempeño relacionaremos los servicios monitorizados entre sí para crear distintas dependencias.

 

Entendamos este primer panel, donde el responsable pueda conocer cómo se encuentra el negocio. En este caso, para que la empresa Open Services IT pueda ser productiva y funcional, necesitará:

  • Que los técnicos puedan atender a los clientes y satisfacer cualquier necesidad que tengan. Este será el servicio de negocio que llamaremos ‘Atención al Cliente’.
  • Que el dpto. de administración pueda facturar, si no, no comemos, este será nuestro servicio de negocio ‘Facturación’.
  • Tenemos también un ítem importante llamado ‘Continuidad de negocio’, que será cualquier servicio que prestamos para que ante cualquier desastre, la empresa pueda seguir trabajando; o anticiparnos a cualquier circunstancia que impida su desempeño.
  • Y nada, el último servicio importante, pero que aquí no os quiero aburrir sería que funcione el entorno ‘Domótico’, sin él, la empresa no abriría, perdería el control de ciertas automatizaciones, no se cobrarían las nóminas… Lo dicho, no le deis importancia a este ítem.

Adicionalmente lo dicho, podríamos indicar en la propia interfaz el SLA, en % o en tiempo de cada servicio que mostramos. Pudiendo ver cuánto tiempo se ha encontrado OK o perfecto, Warning o en peligro, así como Critical o pudiendo ser afectado el servicio.

 

El responsable podrá viajar entre los distintos paneles y conocer el SLA que están ofreciendo los distintos servicios. En este ejemplo vemos las dependencias que tenemos para que funcione el «Servicio de atención al cliente» y se compone de lo siguiente:

  • Que funcione el sistema de incidencias, para que el cliente o el técnico pueda gestionar, imputar…
  • Mediante el ‘Servicio de Reporting’ el técnico o cliente podrá conocer en tiempo real el estado de la infraestructura gestionada por nosotros, así como acceso a informes de usos de horas, facturas…
  • Tenemos un sistema que permite a los técnicos reunirse con los clientes, obviamente si esto se para, puede verse afectado el ‘Servicio de atención al cliente’. Igualmente lo usamos para las sesiones remotas con los clientes para conectarnos a su puesto…
  • Entregamos a nuestros usuarios aplicaciones y escritorios de manera centralizada, para que cualquier empleado pueda trabajar desde cualquier lugar. Si esto no funciona, nadie tiene apps, herramientas…
  • Obviamente los técnicos y los clientes necesitan comunicarse por correo electrónico. Aquí controlaremos todo lo necesario para que funcione el email, que los servidores estén ok, que no estemos en listas de spam…
  • Al igual que el correo, pasa con la telefonía, los técnicos han de poder comunicarse con los clientes (y viceversa). Si el servicio que presta la telefonía cae, pues no hay centralita, o no entran o salen llamadas…
  • Disponemos de un entorno Wiki donde los técnicos consultan a modo KB o documentan cualquier incidencia para no volver a perder tiempo en el futuro. Esto es necesario para el buen trabajo de los técnicos.
  • Para el intercambio de información con los clientes/proveedores disponemos de un sistema que debe funcionar, sin él no podrían acceder a los documentos que tenemos de ellos, facturas, intercambios temporales… 
  • ¡Y por supuesto que funcione Internet! sin Internet, los técnicos no somos nada 😉

 

Como vemos el entorno es 100% personalizable y totalmente corporativo, podremos por supuesto añadirle cualquier enlace (a productos…)… Y si seguimos bajando de nivel, podrán ir conociendo lo dicho, todas las dependencias de algo para que funcione. En el caso del ‘Servicio de Reporting’, qué necesitamos para saber que es funcional:

Por un lado debe funcionar internamente:

  • Pues primero, que el propio producto que ofrece el servicio funcione, en este caso se basa en un Grafana, pues que la(s) máquina(s) que ofrecen el servicio estén sanas, así como lo que necesite funcione (puertos, procesos, BBDD…).
  • Nuestro querido ‘Directorio Activo’ debe funcionar para que el sistema de autenticación y permisos funcione dentro del propio Grafana.
  • Debe funcionar el servicio de virtualización, sin él, no corren máquinas virtuales, y nuestro Grafana está virtualizado.
  • La red interna debe funcionar, si se caen las comunicaciones internas, los sistemas se verían afectados y no se podrían comunicar entre sí.
  • Y otros servicios críticos de infraestructura, como pueda ser el servicio DNS, sin él no habría resolución de nombres; o el servicio NTP tan crítico.

Y por el otro lado, al ser un servicio público a los clientes, pues también controlaremos que ciertas dependencias se cumplen:

  • El sitio público debe estar operativo, no sólo que responda, si no también que el puerto esté abierto, el certificado no caduque, no caduque el propio dominio, o lo ofrezcamos con seguridad certificada en SSLLABS (yo qué sé)…
  • Obviamente si se cae Internet (las WAN que sean), puede que no sea accesible el servicio de Reporting…
  • Al igual si disponemos de un balanceador público (en este caso utilizamos NetScaler), pues que funcione, que haga su labor.

 

Y por hacer el ejemplo más rápido que podía, si en el panel anterior pinchamos en Grafana, pues veríamos las máquinas que ofrecen dicho servicio. Lo comentado, este ejemplo es bastante directo, pero otros servicios permiten viajes más particulares e interesantes. Rollos a parte, vemos la máquina cómo se encuentra, con integraciones y visualizaciones de sus consumos… 

 

Análisis de Impacto de Negocio

Podremos tener también un Análisis de impacto de negocio, rápidamente podremos conocer la respuesta ante cualquier duda de ‘qué pasa sí’. Esto significa, por ejemplo, que podremos manualmente indicar que algo se cae, así podremos conocer los servicios afectados. Así podremos anticiparnos a cualquier problema, saber qué pasa si quitamos un cable, si nos caduca un certificado, si apagamos una máquina…

 

Accederemos a este análisis de impacto desde el Home de nuestra monitorización de negocio, si os fijáis en la primera imagen del post, abajo a la derecha disponemos de algunos vínculos con distintos accesos, uno será aquí.

La simulación la podremos realizar basándonos en el estado actual de la plataforma, o forzando todo a OK si fuere necesario.

 

Podremos viajar por los árboles de los procesos de negocio que hayamos definido hasta encontrar qué queremos tirar abajo.

 

Por seguir el ejemplo del post… qué pasa si se cae por ejemplo el puerto o proceso de Grafana, ¿a qué me afectaría y cómo?

 

Pues podremos ver cómo el ‘Servicio de Atención al cliente’ se ve afectado, ya que el servicio de Reporting estaría caído…

 

Bueno, imaginaros esto con cada proceso de tu empresa, saber cómo actuar, conocer en tiempo real el SLA o Acuerdo de nivel de servicio que estamos prestando a nuestros clientes, usuarios o proveedores. Interfaces de navegación sencilla para cualquier perfil no técnico de la empresa. Pensad que en un post es muy complicado hacer el ejercicio completo, pero pensad en vuestro árbol de dependencias y cómo se puede visualizar en tiempo real su estado.

Como siempre, esperando que os resulte de interés, que muchas gracias por compartir en redes sociales si os parece interesante y seguiremos con posts similares, ¡explotemos los datos y simplifiquemos su entrega!

 

Posts recomendados:

Héctor Herrero
Últimas entradas de Héctor Herrero (ver todo)