Las puertas de enlace de Power BI cumplen una función importante: cierran la brecha de datos entre el servicio de Azure que impulsa las ofertas en línea de Power BI, como los informes y los paneles de control basados en el navegador, o el acceso de los usuarios a los puntos finales de XMLA, por ejemplo, a través de «Analizar en Excel».
Sin puertas de enlace, el servicio Azure no sabría cómo comunicarse con sus fuentes de datos locales (como el servidor SQL en la red de su empresa). Las puertas de enlace reciben solicitudes del servicio de Azure, las procesan y devuelven los resultados al servicio.
Si tiene una puerta de enlace personal, o una sola instancia de una puerta de enlace Enterprise, entonces viva de forma peligrosa: su puerta de enlace personal puede estar instalada en una PC que no siempre está encendida, o su puerta de enlace Enterprise de instancia única puede desconectarse por una variedad de razones.
Si le preocupa la continuidad del negocio (y debería estarlo), entonces desea un clúster de puerta de enlace con varias instancias de puerta de enlace (idealmente en diferentes ubicaciones geográficas) combinadas en un clúster de puerta de enlace. De esa manera, si una de las instancias se cae, las otras instancias pueden continuar atendiendo las solicitudes de datos sin mucho impacto.
Configurar un clúster es una cosa, medir su eficiencia es algo completamente diferente. ¿Cómo saber si una puerta de enlace es parte de su problema de actualización lenta o no? ¿Puede la puerta de enlace manejar todas las solicitudes de actualización durante una semana normal? Si es así, ¿puede hacerlo a duras penas o con mucha o capacidad de sobra?
Una forma de ver esto es examinar los registros de la puerta de enlace. En la configuración predeterminada, estos registros se recopilan automáticamente tanto para información general como para errores. Los registros de información tienden a ser bastante detallados, por lo que la puerta de enlace solo los mantiene durante un día más o menos. Los errores son (con suerte) menos frecuentes y es posible que vea dos semanas o más de registros.
Los registros se almacenan en la carpeta «appdata» de la cuenta que ejecuta el servicio de puerta de enlace.
También puede habilitar el registro avanzado (necesita reiniciar el servicio de puerta de enlace para eso) para un registro aún más detallado y períodos de retención aún más cortos. Solo desea hacer eso por períodos cortos de tiempo cuando Microsoft le solicite que proporcione registros de puerta de enlace como parte de la investigación de un ticket que generó. Al hacer clic en el enlace «Exportar registros», básicamente se empaquetarán todos los archivos de texto en un archivo ZIP.
Sin embargo, entregar los datos de registro a Microsoft no es óptimo. Están investigando los problemas con una de las actualizaciones de su conjunto de datos, pero es posible que tenga cientos de actualizaciones que no están relacionadas (y que potencialmente contienen información sensible). La recopilación manual de los registros de la puerta de enlace también envejece muy rápidamente si tiene más de una o dos instancias (como debería, para la continuidad del negocio).
¿Y si pudiéramos examinar estos archivos de registro manualmente? No puede ser tan difícil, ¿verdad? Después de todo, estos son solo archivos de texto.
Aquí es donde se pone feo y rápido. Los archivos de registro son más como un flujo de flujo de conciencia de pensamientos aleatorios garabateados en una servilleta sobre una tabla mojada con una brisa fuerte.
Bueno, tal vez no exactamente, pero como puede ver, estos archivos de registro ciertamente carecen de una cosa: estructura. Y tienen mucho peso muerto, filas y filas de texto que aparentemente no tienen información.
No hay documentación (que yo sepa) sobre la estructura de los archivos de registro. Según mis observaciones, pueden tener tan solo una sola columna y hasta ocho columnas de datos, con muchas de estas columnas llenas de identificadores aparentemente sin sentido para procesos y subprocesos.
Hay algunas piezas identificables: marcas de tiempo, tipos de mensajes y el texto claro ocasional de un error.
Lo mejor que se me ocurrió es un franken-script de Power Query para tratar de domesticar los datos y solo dejar pasar la información. Estoy bastante seguro de que estoy malinterpretando algunos de los datos y me faltan otros elementos importantes.
Aquí está el script («GetLog») para procesar un archivo de texto individual. Tenga en cuenta que elegí agregar un índice para tener una idea de la secuencia de eventos, ya que a menudo hay muchos eventos con la misma marca de tiempo exacta. También tenga en cuenta que la información útil real puede estar en la columna 1 o en la columna 8, por lo que agrego una columna de «acción» que extrae los datos en consecuencia.
(Content) => let
Source = Csv.Document(Content,[Delimiter="#(tab)", Columns=8, Encoding=65001, QuoteStyle=QuoteStyle.None]),
#"Added Index" = Table.AddIndexColumn(Source, "Index", 0, 1, Int64.Type),
#"Added Conditional Column" = Table.AddColumn(#"Added Index", "Action", each if [Column8] = "" then [Column1] else [Column8]),
#"Added Conditional Column1" = Table.AddColumn(#"Added Conditional Column", "Timestamp", each if Text.StartsWith([Column1], "DM.") then Text.Middle([Column1],Text.PositionOf([Column1],":")+6,28) else null),
#"Removed Columns" = Table.RemoveColumns(#"Added Conditional Column1",{"Column1", "Column8"}),
#"Replaced Value" = Table.ReplaceValue(#"Removed Columns","",null,Replacer.ReplaceValue,{"Column2", "Column3", "Column4", "Column5", "Column6", "Column7", "Action", "Timestamp"}),
#"Filled Down" = Table.FillDown(#"Replaced Value",{"Column2", "Column3", "Column4", "Column5", "Column6", "Column7", "Action", "Timestamp"})
in
#"Filled Down"Luego, puede optar por tratar los registros de información y los registros de errores de manera diferente (aunque tienen la misma estructura) y centrarse en determinados tipos de acciones o contenido.
A continuación, se muestra un ejemplo de cómo leer todos los archivos de información de un miembro del clúster de puerta de enlace («GetInfo»):
(Machine) => let
Source = Folder.Files("\" & Machine & "c$UsersPBIEgwServiceAppDataLocalMicrosoftOn-premises data gateway"),
#"Filtered Rows" = Table.SelectRows(Source, each Text.StartsWith([Name], "GatewayInfo")),
#"Invoke Custom Function1" = Table.AddColumn(#"Filtered Rows", "Transform File", each GetLog([Content])),
#"Expanded Transform File" = Table.ExpandTableColumn(#"Invoke Custom Function1", "Transform File", {"Column2", "Column3", "Column4", "Column5", "Column6", "Column7", "Index", "Action", "Timestamp"}, {"Column2", "Column3", "Column4", "Column5", "Column6", "Column7", "Index", "Action", "Timestamp"}),
#"Removed Other Columns" = Table.SelectColumns(#"Expanded Transform File",{"Column2", "Column3", "Column4", "Column5", "Column6", "Column7", "Index", "Action", "Timestamp"})
in
#"Removed Other Columns"Ahora todo lo que queda es proporcionar una lista de máquinas (los miembros del clúster de su puerta de enlace) y ejecutar la recopilación de registros en toda la lista.
let
Source = Gateways,
#"Filtered Rows" = Table.SelectRows(Source, each [Active]=true),
#"Invoked Custom Function" = Table.AddColumn(#"Filtered Rows", "GetInfo", each GetInfo([Gateway])),
#"Expanded GetInfo" = Table.ExpandTableColumn(#"Invoked Custom Function", "GetInfo", {"Column2", "Column3", "Column4", "Column5", "Column6", "Column7", "Index", "Action", "Timestamp"}, {"Column2", "Column3", "Column4", "GatewaySessionID", "ClientPipelineID", "Column7", "Index", "Action", "Timestamp"}),
#"Changed Type" = Table.TransformColumnTypes(#"Expanded GetInfo",{{"Timestamp", type datetimezone}, {"Index", Int64.Type}})
in
#"Changed Type"Ahora podemos ejecutar informes sobre la utilización del clúster de puerta de enlace a lo largo del tiempo y podemos validar que todos los miembros del clúster de puerta de enlace hagan su parte en el procesamiento de las solicitudes de servicio.
A continuación, se muestra un ejemplo de la rampa de entrada de solicitudes contra los cuatro miembros del clúster de una puerta de enlace el lunes. Tenga en cuenta que el miembro del clúster principal (ancla) no pudo reiniciarse el sábado. Los otros tres miembros del grupo continuaron y el lunes cambié a un nuevo miembro principal.
Los registros de errores de la puerta de enlace ayudan a identificar las conexiones en las que las credenciales han caducado o en las que la fuente de datos está fuera de línea.
Descubrí que las puertas de enlace distribuyen solicitudes de actualización de fuentes de datos entre varios miembros del clúster, incluso para el mismo conjunto de datos. Eso es bastante impresionante. Después de muchas búsquedas, finalmente encontré cómo conectar los registros de la puerta de enlace a nuestros registros de auditoría de inquilinos: el ID del conjunto de datos se incluye en las filas «objectId» de los archivos de registro. Agregar una columna calculada
Ahora puedo identificar directamente al desarrollador con el que necesito trabajar para corregir un problema de conexión o cualquier solicitud de actualización excesiva que consuma todos los recursos de la puerta de enlace.
Ninguno de los anteriores es simple. Deseo que en el futuro Microsoft proporcione más información sobre la estructura de los registros de la puerta de enlace, más controles sobre qué registrar e, idealmente, algunas herramientas de monitoreo del rendimiento de la puerta de enlace en tiempo real que harían obsoleto el proceso descrito.
