En este blog pretendo explicar el proceso que trascurre desde que se realiza un backup en Azure  hasta que se genera el informe de dichos backups en Power BI.

Para que esto suceda, los datos correspondientes de cada uno de los Backups deben ser tratados por una herramienta ETL (Extract, Transform and Load) de Pentaho llamada Data Integration (PDI). Esta herramienta recogerá los datos de los backups de las distintas fuentes, los transformará y adaptará para posteriormente almacenarlos en sus tablas correspondientes dentro de una Base de Datos común que será la que alimente los datos mostrados en los informes de Power BI. Esta Base de datos se llama SQLR.

Azure: Tiene dos fuentes de datos de Backups.

  • Datos extraídos a través de servicios REST del api del propio Azure.
  • Ficheros csv generados por un script creado por los compañeros de Infraestructuras con la información sobre Backups de Máquinas virtuales, Bases de datos y Logs que no puede ser extraída a partir de los servicios REST. Esta información está extraída de la Base de datos de Azure.

Estas fuentes de datos serán recogidas por un proceso ETL creado para cada una y serán transformados para ser guardados en la base de datos de SQLR en sus tablas correspondientes.

Al finalizar la carga de datos en nuestra BDD de SQLR se generará un informe en formato PDF que consistirá en varias tablas que agrupan los resultados de los backups de las Máquinas virtuales, bases de datos y LOGS. Cada una de ellas estará agrupada, a su vez, por cada uno de los entornos (PRE y PRO).

Por último, se construirá un informe por cada fuente de datos en Power BI con la herramienta Power BI Desktop, la cual accederá a los datos almacenados en la propia base de datos de SQLR a través de un Datasource. Una vez elaborado el informe se publicará a la página de https://app.powerbi.com en su grupo correspondiente.

Desde el administrador de Power BI podrá programarse una actualización periódica de los datos de los informes. Para ello deberá configurarse en la máquina de SQLR un Gateway para que Power BI tenga acceso de forma externa a los datos de esa base de datos y así se pueda actualizar el contenido de los informes.

 

Tratamiento de datos de Backups

Para obtener el detalle de los backups realizados en Azure Crearemos un proceso ETL con la herramienta Pentaho Data Integration.

El esquema global del proceso será el siguiente:

Este proceso estará compuesto por un conjunto de pasos. El primero de ellos definirá las variables con los datos que compondrán la cabecera de las sucesivas llamadas al api REST de Azure.

Tras definir estos datos de entrada se procederá a logarse en la página de Microsoft invocando al servicio REST:

Este servicio nos proporcionará un token de acceso a los servicios Rest de Azure. Este token se utilizará para las sucesivas invocaciones a los demás servicios Rest que se van a necesitar durante el proceso.

Cada resultado de cada llamada rest será recogido en formato Json y transformado en un paso posterior en variables para poder ser transformadas y utilizadas en los demás pasos.

Tras obtener el token de acceso a Azure se procederá a obtener todos los Recovery Services del cliente con el que nos logamos inicialmente. Para ello invocaremos al servicio Rest siguiente:

De cada Recovery Service obtenido tenemos que extraer dos tipos de información.

Estos son los pasos para obtener ambos flujos de datos:

  • Por un lado, hay que extraer los Backup Items para conocer el número de puntos de restauración de cada uno.

Para esto invocaremos a dos servicios Rest consecutivamente:

  • Primero obtenemos los Backup Protected Items con la siguiente llamada:
  • Se filtrará para que se obtengan los Backups de tipo Máquinas Virtuales (AzureIaasVM)
  • Posteriormente, para cada Backup Item se extraerá su información detallada, entre la que se encuentra el número de Puntos de Restauración.
  • Por otro lado, hay que extraer los Backup Jobs de cada Recovery Service con el objetico de obtener el resto de los datos que necesitamos conocer de cada Backup. Tales como el estado, la duración la hora de comienzo…
    • Click aquí
    • Esta llamada Rest inclurá un filtro de todos los Backup Jobs iniciados y terminados durante los 2 días anteriores a la ejecución del proceso ETL con el fin de cubrir los Jobs que no hubieran podido finalizar durante el mismo día.

Esta información obtenida de forma separada es unificada posteriormente a partir de un campo llamado Friendly Name que es utilizado a modo de Alias de cada Backup Item. De esta manera tendremos toda la información obtenida de los Backup Jobs y los Backup Items en el mismo flujo de datos.

Con esta información unificada invocaremos a un último servicio Rest que nos servirá para obtener el dato que nos faltaba, el tamaño del Backup (Backup Size)

Ya en la última fase del proceso etl se obtendrá la fecha del último Backup realizado correctamente. Para ello comprobaremos si el backup Jobs que se está recogiendo ha sido completado correctamente. Si es así, la fecha de finalización de este Backup será la fecha del último Backup completado con éxito.

Si no es así, se buscará en la tabla de Azure_Backup_Jobs donde almacenamos los datos recogidos de los servicios Rest la fecha del último backup realizado correctamente en ejecuciones anteriores.

Ya con toda la información que necesitamos recogida, ésta se guardará en la Base de datos de SQLR, dentro de la tabla Azure_Backup_Jobs, que será la que consuma el informe creado en Power BI para Azure.

Azure csv (origen BDD)

Existe cierta información que no es proporcionada por los servicios Rest de Azure y que se necesitan para añadir al informe de Power BI. Esta información permanece almacenada en la Base de datos que utiliza Azure y es extraída mediante sentencias de SQL-Server. El resultado de estas sentencias es guardado en archivos csv que son copiados en una carpeta compartida incluida en la máquina SQLR.

El proceso ETL encargado de tratar esta información tendrá como origen de datos esos ficheros csv ubicados en la carpeta compartida, que se trata de carpeta local para el proceso ETL.

Los ficheros contendrán la siguiente información repartida en la siguiente cabecera:

  • backup_set_id: identificador del Backup. Se trata de un Código interno para identificar unívocamente el backup referenciado en esa fila.
  • AlmacenJob: Nombre del almacén de Recovery Services.
  • EntityName: Nombre de la entidad. Sería el alias del Backup que comenté en el proceso anterior.
  • Operation: Operación realizada
  • Status: Estado del Backup
  • StartTime: Fecha y hora de comienzo.
  • Duration: Fecha y hora de finalización.
  • ProcessingRate: Rate de procesamiento.
  • BackupSize: Tamaño del Backup.
  • RecoveryPoints: Número de puntos d restauración.
  • LastSuccessBackup: Fecha de último Backup realizado correctamente.

Estos ficheros serán de dos tipos. Uno contendrá los Backups de Máquinas virtuales y el otro tipo de ficheros contendrá los Backups de los Logs.

El nombre fichero de los Backups de Máquinas virtuales tendrá el siguiente formato:

  • <NOMBRE SERVIDOR>-BCK-<FULL-DIFF>-<FECHA YYYYMMDD>.csv

Los ficheros de Backups de Logs se nombrarán con el formato siguiente:

  • <NOMBRE SERVIDOR>-BCK-<LOGS>-<FECHA YYYYMMDD>.csv

Además, el contenido de estos ficheros estará formado por los backups realizados el día anterior al indicado en el nombre del fichero.

El proceso de carga leerá el nombre de los ficheros y extraerá la información del Nombre del servidor, del tipo de Backup y de la fecha de extracción de esos datos. Además, clasificará el contenido dependiendo del tipo de fichero que sea.


Con la información obtenida del nombre del fichero, el proceso eliminará de la tabla Azure_Backup_Jobs los registros que coincidan con el nombre de servidor y fecha indicadas en el nombre del fichero, ya que se insertarán los valores del fichero es se esté procesando en un paso posterior.

Esto se hace así por si un fichero de un servidor y fecha concreta ha sido procesado anteriormente y se vuelve a procesar de nuevo con los mismos o distintos datos.

Tras alguna transformación y adaptación realizada sobre alguno de los valores recogidos se guarda la información en la tabla Azure_Backup_Jobs.

 

Informe PDF

Al finalizar la carga de la información sobre los Backups de Azure en nuestra Base de datos se generará un informe de Resumen diario de Backups. Este informe será enviado por email al cliente para que pueda revisar los resultados de los Backups del día anterior al instante.

Esto se realiza con la intervención de dos elementos. Por un lado un proceso ETL que extre la información de nuestra base de datos SQLR recién actualizada y, por otro lado, una librería Java que hemos creado que será la responsable de la generación del informe en formato PDF.

Esta librería Java recibirá toda la información extraída sobre los Backups de Azure realizados el día anterior a la generación del informe en formato JSON. Esta cadena JSON estará estructurada en un resumen de totales y en una lista ordenada de los backups realizados.

La cadena JSON resultante será enviada como parámetro a nuestra librería Java.

Como se puede observar, en este paso del proceso ETL se invocará al método constructPdf de nuestra librería Java y se le pasarán como parámetros la ruta donde se generará el Pdf, el nombre que tendrá (ya que depende de la fecha de ejecución del mismo) y la variable que contendrá la cadena JSON con los resultados de los bakcups. La librería se ubicará en la carpeta libext de la ruta de instalación de Pentaho Data Integration.

La cadena JSON será parseada a objetos Java y se generará el objeto PDF al que se le irán añadiendo tanto una tabla resumen, como cada una de las secciones que compondrán el informe:

  • Resumen
  • Máquinas Virtuales
    • PRO
    • PRE
  • BDD
    • PRO
    • PRE
  • LOGS
    • PRO
    • PRE

Como resultado se retornará una cadena con contenido en formato JSON que indicará el resultado final de la generación del informe y la ruta final del informe Pdf generado.

Con esta información se enviará ese informe por email a los clientes destinatarios que hayamos configurado.

El informe final tendrá el siguiente aspecto.

 

POWER BI

Ya con toda la información centralizada en la misma base de datos de SQLR, habrá un informe realizado en Power BI que los consuma y los muestre en dashboards con filtros y tablas dentro de su plataforma.

Para crear estos informes y publicarlos en la aplicación de Microsoft Power BI (https://app.powerbi.com) utilizaremos la aplicación “Power BI Desktop”.

Como comenté antes, cada informe consumirá los datos de las tablas creadas en la base de datos de sqlr. Para que esto sea posible se deberá crear un origen de datos, el cual será en este caso SQL-Server. También habrá que configurar los datos de conexión con dicha base de datos.

Seleccionaremos las tablas que contienen los datos que queremos mostrar en el informe:

Y nos mostrará un listado de columnas y los datos contenidos para poder operar con ellos y de esta manera poder elaborar el informe.

Con esta información ya se podrá empezar a configurar el informe. Para ello se añadirán elementos en el mismo, ya sean de tipo tabla, filtros, gráficas…

Cada elemento que incorporemos al informe mostrará unos valores dependiendo del campo de la tabla que seleccionamos en el origen de datos.

A los cuales se les puede aplicar unos filtros, añadir nuevas columnas, añadir medidas calculadas a partir de los valores de los campos ya existentes…

En el ejemplo de Azure se puede observar que hay 2 filtros y una tabla, pero se pueden añadir de otros tipos como diagramas, gráficas, etc…

Una vez creado o modificado el informe habrá que publicarlo para que el cliente tenga acceso al mismo desde la aplicación web de Power BI. Para ello haremos click sobre el icono de Publicar situado en la barra de herramientas:

Seleccionaremos en destino el área de trabajo en el que se ubicará el informe. Y en la aplicación web de Power BI se habrá añadido/actualizado el informe.

Para que los datos estén sincronizados con la ejecución de los procesos ETL que alimentan la base de datos y las tablas se deberá programar una actualización periódica de esos datos del informe.

Esto se consigue accediendo a las opciones de Conjunto de datos desde el panel de la aplicación web de Power BI.

Antes de esto, para hacer que la actualización funcione correctamente, habrá que configurar una puerta de enlace para que la aplicación web de Power BI tenga acceso a los orígenes de datos de los informes.

About Carlos Bonilla

Carlos is Technical Engineer in Computer Systems by Extremadura University. He started his professional career in 2003 as Java Consultant. After eight years, he moved to Indra, working as Systems Engineer and Java Consultant for different customers like BBVA, Gas Natural Fenosa or Bankia, during seven years. He joined Enimbos in 2018 as Vue JS.