Log Analytics se factura por gigabyte ingerido, y nada en Azure te pregunta si un log vale un gigabyte. Una configuración de diagnóstico es una casilla. Alguien la marca durante un incidente, el incidente se cierra y tres años después esa tabla es una línea anual de cinco cifras que ninguna consulta ha tocado desde entonces.
Lo vemos en casi todos los entornos de Azure de cierto tamaño. En algunos era la mayor línea de la factura, por encima del cómputo. El arreglo no es "registrar menos". Es decidir, tabla a tabla, para qué sirve el dato.
Primero, averigua qué estás pagando
Una consulta responde a casi toda la pregunta:
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize GB = sum(Quantity) / 1000 by DataType
| order by GB desc
Lánzala en cada área de trabajo. El reparto es casi siempre brutalmente desigual: tres o cuatro tablas se llevan el 80 por ciento de la factura. Son las únicas que merecen tu atención.
Los sospechosos habituales, en el orden en que aparecen:
AzureDiagnosticsde recursos donde alguien activó todas las categorías en lugar de las dos que importan.ContainerLogInsightsde un clúster de AKS que recoge stdout de todos los contenedores de todos los namespaces, incluidos los sidecars parlanchines.AzureNetworkAnalytics_CLy los registros de flujo de NSG, que son enormes y, en crudo, casi nunca se consultan.AppTracesde una aplicación con el registro detallado encendido en producción después de una sesión de depuración.SecurityEventcon la recogida en "todos los eventos" en lugar de la común.
Los seis controles
1. Apaga categorías, no tablas. Vuelve a las configuraciones de diagnóstico de los recursos que más pesan y desmarca las categorías que nadie consulta. Es la hora más rentable de todo el ejercicio, y es reversible. Hazlo por tipo de recurso, no recurso a recurso, o te pasas la semana.
2. Filtra en la regla de recogida, antes de la ingesta. Las reglas de recopilación de datos admiten transformaciones en KQL que se ejecutan antes de que te facturen. Descarta las filas de nivel depuración, descarta las peticiones de sondas de salud en los registros de una puerta de enlace de aplicaciones, elimina las columnas que nunca lees. Una transformación que tira el 60 por ciento de las filas de una tabla baja la factura de esa tabla un 60 por ciento, y es un cambio en una sola regla.
3. Mueve a un nivel más barato las tablas de mucho volumen y poca consulta. Los registros básicos y auxiliares cuestan una fracción de la ingesta de análisis, a cambio de funciones de consulta limitadas y ninguna alerta sobre la tabla. Los registros de flujo de red, las trazas detalladas de aplicación y los logs crudos de cortafuegos son el caso de libro: los quieres disponibles para una investigación, no quieres pagar tarifa de análisis por tenerlos templados. Comprueba antes que no hay ninguna alerta sobre la tabla, porque eso es exactamente lo que se rompe.
4. Fija la retención por tabla, no por área de trabajo. El valor por defecto del área de trabajo se aplica a todo, así que unos 730 días elegidos por una tabla con relevancia de cumplimiento se están pagando en todas las demás. Pon la retención larga donde la pide el auditor y de 30 a 90 días en el resto. Más allá de la ventana interactiva, el archivo es mucho más barato que la retención, y los trabajos de búsqueda recuperan el dato cuando de verdad hace falta.
5. Compra un nivel de compromiso cuando el volumen sea real. Las áreas de trabajo que llegan a 100 GB al día o más acceden a precios por compromiso con un descuento apreciable sobre el pago por uso. Esto va al final, por la misma razón por la que las reservas van al final en la factura de Azure: un compromiso dimensionado contra la ingesta sin filtrar fija el ruido que ibas a borrar. El nivel es ajustable, así que empieza un escalón por debajo de tu volumen filtrado, no por encima.
6. Consolida áreas de trabajo, con cuidado. Muchas áreas pequeñas significan que no hay nivel de compromiso en ninguna y que las mismas tablas de plataforma se duplican en todas. Menos áreas y más grandes suele salir más barato. El contraargumento es el control de accesos y la residencia del dato, y es legítimo. Consolida donde la frontera sea costumbre organizativa, no un requisito.
El matiz de Sentinel
Si Microsoft Sentinel está activado en el área de trabajo, se factura el análisis además de la ingesta, así que cada gigabyte cuesta aproximadamente el doble. Eso cambia la aritmética de los seis controles anteriores y hace que filtrar valga mucho más. También hace que importe la lista de conectores gratuitos: algunas fuentes propias de Microsoft son gratis de ingerir para Sentinel y vale la pena conservarlas, mientras que el mismo volumen desde un dispositivo de terceros no lo es.
Sentinel tiene sus propios niveles de compromiso, separados de los de Log Analytics. Revisa los dos.
Qué esperar
Un área de trabajo que nunca se ha revisado suele bajar entre un 40 y un 60 por ciento, casi todo por los controles uno a tres, y sin perder nada que un equipo estuviera consultando de verdad. La forma de saberlo es comprobarlo: la tabla Usage te dice qué entra y los registros de auditoría de consultas te dicen qué pide alguien alguna vez. La diferencia entre ambos es la respuesta.
Es el mismo problema, con otra forma, que las facturas de BigQuery que se triplican: un sistema de observabilidad con precio por unidad de dato y sin contrapresión natural. Lo recorremos en la fase de costes de un proyecto cloud.
Qué hacer esta semana
Lanza la consulta Usage de arriba en tu área de trabajo más grande, coge la tabla que encabeza la lista y averigua quién la ha consultado en los últimos 90 días. Si la respuesta es nadie, has encontrado una línea que puedes cortar esta tarde con una casilla.