Cloud Logging y Cloud Storage, por dónde se va el dinero callado en Google Cloud

Dos líneas de una factura de Google Cloud crecen sin que nadie decida que deban hacerlo. El registro crece porque todo escribe en él por defecto y nada lo detiene. El almacenamiento crece porque borrar datos exige una decisión y conservarlos no.

Las dos se arreglan en una tarde cada una, y las dos son con frecuencia mayores que la línea de cómputo que tienen al lado.

Averigua qué se está ingiriendo

Cloud Logging factura por volumen ingerido en un cubo de registro, con una franquicia antes de empezar a cobrar, más el almacenamiento más allá de la retención por defecto.

Antes de cambiar nada, encuentra la forma. El panel de uso de registros desglosa la ingesta por tipo de recurso y nombre de registro, y el reparto siempre es desigual. Tres o cuatro nombres de registro se llevarán casi todo el volumen.

Los sospechosos habituales:

• Registros de auditoría de acceso a datos. Los de actividad administrativa son gratis y obligatorios. Los de acceso a datos no son gratis, están desactivados por defecto en la mayoría de los servicios, y son enormes cuando alguien los enciende en toda la organización por un motivo de cumplimiento que nadie revisó. Es la mayor sorpresa de registro que encontramos.
• Registros de contenedor de GKE de todos los contenedores de todos los namespaces, incluidos los sidecars parlanchines y la salida de las comprobaciones de salud.
• Registros de petición del balanceador con muestreo al máximo, incluidas las comprobaciones de salud.
• Registros de flujo de red con muestreo completo en subredes con tráfico.
• Registros de aplicación en nivel de depuración dejados encendidos tras un incidente.

El filtro de exclusión es el control que importa

Los receptores encaminan registros a destinos. El receptor por defecto envía al cubo de registro por defecto, y eso es lo que se te factura. Un filtro de exclusión en ese receptor descarta las entradas que coincidan antes de almacenarlas, es decir antes de cobrarlas.

Es el cambio de mayor retorno disponible, porque es una edición de configuración y surte efecto de inmediato. Exclusiones típicas: peticiones de comprobación de salud en los registros del balanceador, sondas de disponibilidad correctas, severidad de depuración en producción, y los nombres de registro de mucho volumen que nadie ha consultado.

Dos refinamientos. Las exclusiones admiten un porcentaje, así que puedes conservar una muestra en vez de descartarlo todo, lo que preserva la capacidad de ver un patrón quitando el grueso. Y puedes excluir del receptor por defecto y a la vez encaminar esas mismas entradas a un destino más barato como el almacenamiento de objetos, de modo que el dato siga existiendo para una investigación sin estar en el nivel consultable.

Antes de excluir nada, comprueba que no depende nada de ello: una métrica basada en registros, una política de alertas, o un receptor que montó alguien para un equipo de seguridad. Perder una alerta es la forma en que este cambio sale mal.

Cubos, retención y la exportación que mueve el coste

Los cubos de registro tienen una retención por defecto, y el almacenamiento más allá se cobra por gigabyte y mes. Crea cubos separados por clase en vez de aceptar una retención para todo: registros de auditoría, lo que diga el requisito de cumplimiento; registros de aplicación, treinta días; salida de depuración, días.

El análisis de registros sobre un cubo los hace consultables con SQL, lo que es útil y cambia el perfil de coste, así que actívalo a conciencia en los cubos donde de verdad consultas y no en todos.

Exportar a BigQuery es el patrón al que recurren los equipos, y mueve el coste en vez de eliminarlo. Dejas de pagar almacenamiento de registro y empiezas a pagar almacenamiento de BigQuery más coste de consulta, y una tabla sin particionar escaneada por un panel es exactamente el fallo que describe facturas de BigQuery que se triplican. Particiona la tabla destino por fecha, siempre.

Exportar a almacenamiento de objetos es el archivo barato. Úsalo para los registros de mucho volumen y poca lectura, con una regla de ciclo de vida asociada.

Clases de almacenamiento y los mínimos que muerden

Estándar, nearline, coldline y archivo intercambian precio de almacenamiento por precio de recuperación. Bajar de clase los datos que se leen poco es obviamente correcto, y es donde los equipos pierden dinero, porque cada clase tiene una duración mínima de almacenamiento con un cargo por borrado anticipado si borras o mueves el objeto antes de que pase.

Nearline son treinta días, coldline noventa, archivo trescientos sesenta y cinco. Una regla de ciclo de vida que mueve objetos a coldline el primer día y los borra el sesenta paga un cargo por borrado anticipado en cada objeto, y la factura sube.

Dos reglas que funcionan. Haz que la edad de la regla de borrado sea mayor que el mínimo de la clase destino, siempre. Y haz la transición con una condición que refleje el acceso real y no solo la edad, cuando el patrón de acceso sea desigual.

La clasificación automática mueve objetos entre clases según el acceso, sin cargos por borrado anticipado en las transiciones, a cambio de una cuota de gestión por objeto. Para un cubo con patrón de acceso impredecible suele merecer la pena. Para un cubo del que sabes que se escribe una vez y no se lee nunca, una regla manual es más barata.

Los cargos de recuperación y de operaciones son la otra mitad. Coldline y archivo cobran más por operación y por gigabyte recuperado. Una carga que hace lecturas pequeñas frecuentes contra coldline puede pagar más en recuperación de lo que ahorra en almacenamiento, que es la forma más común en que una política bienintencionada sale por la culata.

Lo que se va acumulando

• Versionado de objetos sin regla de ciclo de vida. Activado por seguridad, y después se conservan todas las versiones de todos los objetos para siempre. Añade una regla que caduque las versiones no vigentes a los treinta o noventa días.
• Borrado temporal, que retiene los objetos borrados durante un periodo por defecto y se factura. Revisa el ajuste en cubos con mucha rotación.
• Cubos multirregión elegidos por defecto. Multirregión cuesta más que regional y es la elección correcta solo cuando lo necesitas. Un cubo que sirve a una carga regional no lo necesita.
• Discos persistentes e instantáneas huérfanos de instancias y clústeres borrados.
• Cargas por partes incompletas, que facturan y no aparecen en ningún listado de objetos. Una regla de ciclo de vida las limpia.
• Imágenes de contenedor viejas en el registro de artefactos, que también es almacenamiento y crece con cada compilación.

La transferencia de datos, brevemente

La entrada es gratis. La salida a internet va por tramos de volumen y de destino. El tráfico entre regiones se factura, y el tráfico entre zonas dentro de una región se factura a una tarifa menor, que es el efecto que aparece dentro de un clúster multizona como se describe en el coste de GKE.

Pon una CDN delante de todo lo que sirva los mismos bytes repetidamente. Usa conectividad privada para que el tráfico hacia servicios de Google no recorra el camino de internet. Y comprueba el nivel de servicio de red: el estándar cuesta menos que el premium y encamina de otra forma, lo cual es un intercambio aceptable en algunas cargas y no en las sensibles a la latencia.

Qué hacer esta semana

Abre la vista de uso de registros, coge el nombre de registro que encabeza la lista y averigua si alguna política de alertas o métrica basada en registros depende de él. Si no depende nada, escribe hoy un filtro de exclusión. Después lista tus cubos con su clase de almacenamiento y sus reglas de ciclo de vida, y comprueba si alguna regla borra objetos antes del mínimo de la clase. Las dos comprobaciones llevan menos de una hora y las dos suelen encontrar dinero. Las hacemos en la fase de costes de un proyecto cloud.