Telemetría Lakebase en tablas de sistemas

Lakebase captura su telemetría de observabilidad en el system.lakebase esquema, comenzando con señales avanzadas de Postgres. La captura es automática. Con esa vista previa activada, la telemetría aparece en estas tablas mientras el cálculo del proyecto se ejecuta. No hay configuración que crear, ni destino que elegir, ni credenciales que proporcionar. Insights y Genie leen las mismas tablas, y puedes consultarlas con cualquier herramienta de Azure Databricks.

Requirements

• La observabilidad de Lakebase en la vista previa de Tablas del Sistema habilitada para tu espacio de trabajo.
• Un proyecto de Lakebase en AWS o Azure. Consulte Obtención de una base de datos de Postgres.

¿Qué se captura?

Lakebase registra las señales que necesitas para explicar una base de datos lenta o defectuosa, a través de las siguientes tablas:

Los registros se conservan durante 7 días. El resto de esta página documenta cada columna de cada tabla. Para ver dónde se sitúan estas tablas entre las demás tablas del sistema, véase la referencia de la tabla del sistema Lakebase.

Access

Las system.lakebase tablas están gobernadas por el Catálogo Unity. Los usuarios con los roles de administrador de cuenta y administrador de metastore pueden leer la telemetría y gestionar el acceso a ella. Consulte Administración de privilegios en Unity Catalog.

Access se aplica a nivel de esquema, así que un usuario que puede leer system.lakebase ve la telemetría de cada proyecto en la cuenta.

Texto de la declaración enmascarada

Las columnas que contienen el texto del extracto regresan <REDACTED> , a menos que seas administrador de cuenta o miembro del databricks_pii_access grupo a nivel de cuenta. Un administrador de cuenta crea y gestiona ese grupo. Consulta Crear y gestionar el databricks_pii_access grupo y acceder al texto de la declaración enmascarada.

Columnas comunes a cada tabla

Cada tabla siguiente incluye estas columnas, que identifican de dónde procede una fila:

Las tablas con nombres que terminan en _counters también incluyen una previous_ts columna, lo que marca el inicio del intervalo en el que se acumulan los valores de una fila. Estos son valores acumulativos para ese intervalo, no lecturas a un momento dado. Las tablas que terminan en _gauges son lecturas a un momento dado y no previous_tstienen .

Las tablas siguientes enumeran solo las columnas más allá de estas comunes.

Actividad de sesión

Instantánea de cada back-end activo, muestreada continuamente. Este es el mismo patrón que AWS Performance Insights o el historial de sesiones activas de Oracle (ASH): si una sesión está haciendo algo, incluida la espera, se muestra aquí.

active_session_history

Eventos de espera

Recuentos de eventos de espera agregados y tiempo, complementando la vista por ejemplo en active_session_history.

wait_event_counters

Planes de consulta

Un registro por ejecución de los planes de consulta, incluidas las estadísticas de almacenamiento completas y específicas de Neon. Esta es la tabla más detallada y, normalmente, donde termina una investigación de consulta lenta.

plan_history

Estadísticas de consultas

Estadísticas agregadas por consulta, procedentes de la extensión estándar pg_stat_statements .

pg_stat_statements_counters

Cambios en los esquemas

Cambios de esquema: qué ha cambiado, cuándo y por quién. Esto es lo que Genie lee para realizar un seguimiento de un incidente a un cambio de esquema, ya sea desde una implementación o una edición manual.

ddl_history

Registros de Postgres

Mensajes de registro de Postgres sin procesar, incluido el error específico detrás de un error.

postgres_logs

Métricas de cálculo

Uso de recursos de nivel de proceso: CPU, memoria, E/S de disco y red, y caché de archivos local (LFC), caché del lado proceso de Lakebase delante del servidor de páginas.

compute_counters

compute_gauges

Métricas de base de datos

Actividad por base de datos: filas modificadas, transacciones, sesiones y estado de vacío. Aquí es donde se activan las señales de sobredimensionamiento de la tabla y autovacuo.

database_counters

database_gauges

Limitaciones

Se presentan las siguientes limitaciones:

• COPY Las operaciones no se capturan en el historial del plan de consulta.

• Una consulta ejecutada dentro de una función o procedimiento PL/pgSQL no se captura en la telemetría de nivel de consulta a menos que también se ejecute como una instrucción de nivel superior. De forma predeterminada, el seguimiento de instrucciones propias de Postgres solo cuenta las instrucciones de nivel superior.

• Las ramas y endpoints aparecen en telemetría e insights por ID interno (por ejemplo, br-odd-mud-y2icrn1h), no por un nombre de visualización como "production". Cruza el ID en la interfaz de Lakebase si debes confirmar a qué rama o endpoint se refiere una fila de insight o tabla.

• Las GUC que habilitan la captura de telemetría podrían no propagarse automáticamente a una instancia de cálculo existente. Si la telemetría no aparece después de activar la vista previa, conéctate al proyecto y comprueba:

  SHOW neon_monitor.log_capture_enabled;
  SHOW databricks.o11y_exporter_enabled;
  

  Ambos deben devolver on. Si cualquiera de los dos devuelve off, reinicie el extremo de proceso.

Configuraciones heredadas de observabilidad

Antes de que la telemetría pasara a las tablas del sistema, podías crear una configuración de observabilidad que capturara la telemetría en un catálogo y esquema en tu propio Catálogo de Unity y proporcionara paneles preconstruidos. Las configuraciones existentes siguen funcionando y sus paneles siguen disponibles. Ya no puedes crear nuevas configuraciones de observabilidad, y la captura en tablas de sistema no crea paneles.

Pasos siguientes

• Detectar problemas con Insights: el agente que revisa esta telemetría según un horario.
• Investiga y soluciona problemas con Genie: haz preguntas sobre esta telemetría con tus propias palabras.
• Referencia de la tabla del sistema Lakebase: dónde se sitúan estas tablas entre las demás tablas del sistema.