Archivo de la etiqueta: WSS_Logging

Consultar los logs de ULS de SharePoint 2010 en SQL Server

Es posible que se os haya dado el caso de tener que consultar los logs de SharePoint 2010 conocidos como Unified Logging System (ULS), en entornos formados por grandes granjas de servidores… Este proceso en este caso se convierte en algo tedioso, si no tienes forma de identificar en que servidor físico estas haciendo la petición, para consultar su Correlation ID.

Antes de nada indicar que Microsoft recomienda no acceder directamente a la información de la plataforma, desde la base de datos, sino que debe hacerse a través del modelo de objetos de SharePoint. Este seria el único caso excepcional, donde podemos acceder directamente a través de consultas SQL.

SharePoint 2010, a nivel de granja crea una base de datos llamada WSS_Logging, donde almacena toda la información de la plataforma SharePoint, como por ejemplo: información que envía al visor de eventos de Windows, información de los contadores de rendimiento, inventario de los sitios existentes, los logs de ULS… eso si con un periodo de antigüedad de 14 días, toda información que pase de ese tiempo sera eliminada.

La información de esta base de datos, también es usada para consolidar los datos de Web Analytics a través de los jobs Microsoft SharePoint Foundation Usage Data Import y Microsoft SharePoint Foundation Usage Data Processing.

También es importante remarcar, que la información se vuelca desde la granja a la tabla WSS_Logging, a través de varios timer job que se ejecuta cada varios minutos (este valor es diferente para cada uno de ellos). Aquí tenéis el listado de jobs que vuelca información a esta base de datos (estos datos pueden consultarse en la Administración Central):

El job en concreto, que actualiza la información en el ULS es: Diagnostic Data Provider: Trace Log y se ejecuta por defecto cada 10 minutos y esta es su configuración:

Si, como comentábamos anteriormente, queremos acceder a la misma información que existe en los logs de SharePoint, directamente, deberemos realizar consultas sobre la vista: [dbo].[ULSTraceLog]. Es importante remarcar que debes utilizar las vistas y no las tablas para realizar las consultas.

Los campos de esta vista son: [PartitionId], [RowId], [LogTime], [MachineName], [ProcessID], [ProcessName], [ThreadID], [Area], [Category], [Level], [EventID], [Message], [CorrelationId], [RowCreatedTime]. Estos campos son similares a la informacion que se almacenan en los archivos de ULS.

Como veis existe el campo  [CorrelationId] por el cual vamos a conseguir filtrar los datos, para cotar la información.

De este modo, podrás localizar registros de logs sin tener que buscar físicamente en varios archivos ULS, a través de la granja…

Como obtener el AggregationId para estadísticas en SharePoint 2010

El AggregationId es un parámetro necesario, a la hora de llamar a las diferentes funciones de SQL Server de bases de datos como  Web Analytics reporting y staging. Estas bases de datos, se crean al configurar la aplicacion de servicio de Web Analytics en SharePoint 2010.

Para obtener el AggregationId  de un sitio, lo único que has de ejecutar desde  “SQL Server Management Studio” es la siguiente consulta SQL:

--Obtiene el AggregationId por cada Site
SELECT DISTINCT DimensionName, AggregationId, SM.[Path]
FROM [WebAnalyticsReportingdb].[dbo].[WASiteInventorySnapshot] WASIS WITH (NOLOCK)
INNER JOIN [ConfigDB].[dbo].[SiteMap] SM
ON WASIS.DimensionName = SM.Id
WHERE WASIS.DimensionType=0
ORDER BY [Path]

 

PD. Puede que tengas que renombrar los nombres de las bases de datos de Configuración de SharePoint [ConfigDB] y de Web Analytics [WebAnalyticsReportingdb], ya que en mi granja se llaman así, pero no por este motivo se tienen que llamar igual en la tuya…

Aquí tienes un ejemplo de funciones que necesitan dicho parámetro:

En posteriores post explicare, como hacer uso de esta información para extender las estadísticas de SharePoint 2010, sin depender de las limitaciones, como por ejemplo: la del limite de 2000 registros por informe, o la de 14 días de antigüedad de los datos si hacemos uso de la tabla WSS_Logging.