Telemetria Lakebase em tabelas de sistema

O Lakebase capta a sua telemetria de observabilidade no system.lakebase esquema, começando pelos sinais avançados do Postgres. A captura é automática. Com essa pré-visualização ativada, a telemetria fica nestas tabelas enquanto o cálculo do projeto é executado. Não há configuração a criar, nem destino a escolher, nem credenciais a fornecer. O Insights e o Genie leem as mesmas tabelas, e podes consultá-las com qualquer ferramenta do Azure Databricks.

Requirements

• A Observabilidade do Lakebase na pré-visualização das Tabelas do Sistema ativada para o seu espaço de trabalho.
• Um projeto Lakebase na AWS ou Azure. Veja Obter uma base de dados Postgres.

O que é capturado

O Lakebase regista os sinais necessários para explicar uma base de dados lenta ou com falhas, através das seguintes tabelas:

Os registos são mantidos durante 7 dias. O resto desta página documenta cada coluna de cada tabela. Para saber onde estas tabelas se situam em relação às outras tabelas do sistema, veja a referência da tabela do sistema Lakebase.

Access

As system.lakebase tabelas são governadas pelo Unity Catalog. Os utilizadores com funções de administrador de conta e de administrador da metastore podem ler a telemetria e gerir o acesso a ela. Consulte Gerenciar privilégios no Catálogo Unity.

O Access aplica-se ao nível do esquema, por isso um utilizador que consegue ler system.lakebase vê a telemetria de cada projeto na conta.

Texto da declaração mascarada

Colunas que contêm o texto do extrato retornam <REDACTED> , a menos que seja administrador de conta ou membro do databricks_pii_access grupo ao nível da conta. Um administrador de conta cria e gere esse grupo. Veja Criar e gerir o databricks_pii_access grupo e aceder ao texto da declaração mascarada.

Colunas comuns a todas as tabelas

Cada tabela abaixo inclui estas colunas, que identificam de onde veio uma linha:

Tabelas com nomes que terminam em _counters incluem também uma previous_ts coluna, marcando o início do intervalo sobre o qual os valores de uma linha acumulados. Estes são valores cumulativos para esse intervalo, não leituras em ponto no tempo. As tabelas que terminam em _gauges são leituras em ponto no tempo, e não previous_tstêm .

As tabelas abaixo listam apenas as colunas para além destas comuns.

Atividade da sessão

Um snapshot de cada backend ativo, amostrado continuamente. Este é o mesmo padrão do AWS Performance Insights ou do Histórico Ativo de Sessões (ASH) da Oracle: se uma sessão estiver a fazer algo, incluindo esperar, aparece aqui.

active_session_history

Eventos de espera

Contagens agregadas de eventos de espera e tempo, complementando a vista por amostra em active_session_history.

wait_event_counters

Planos de consulta

Um registo por execução dos planos de consulta, incluindo o plano completo e estatísticas de armazenamento específicas do Neon. Esta é a tabela mais detalhada, e normalmente onde termina uma investigação de consulta lenta.

plan_history

Estatísticas de consultas

Estatísticas agregadas por consulta, provenientes da extensão padrão pg_stat_statements .

pg_stat_statements_counters

Alterações de esquema

Alterações de esquema: o que mudou, quando e por quem. Isto é o que o Genie lê para rastrear um incidente até uma alteração de esquema, seja de uma implementação ou de uma edição manual.

ddl_history

Registos Postgres

Mensagens brutas do registo Postgres, incluindo o erro específico por detrás de uma falha.

postgres_logs

Métricas de computação

Utilização de recursos ao nível de computação: CPU, memória, I/O de disco e rede, e a cache local de ficheiros (LFC), a cache do lado de computação do Lakebase em frente ao pageserver.

compute_counters

compute_gauges

Métricas de base de dados

Atividade por base de dados: linhas alteradas, transações, sessões e saúde do vácuo. É aqui que vivem os sinais de inchaço da mesa e autovácuo.

database_counters

database_gauges

Limitações

Aplicam-se as seguintes limitações:

• COPY As operações não são registadas no histórico do plano de consulta.

• Uma consulta executada dentro de uma função ou procedimento PL/pgSQL não é registada na telemetria ao nível das consultas, a menos que também seja executada como uma instrução de nível superior. O rastreamento de instruções do próprio Postgres, por defeito, conta apenas instruções de nível superior.

• Ramos e endpoints aparecem em telemetria e insights por ID interno (por exemplo, br-odd-mud-y2icrn1h), e não por um nome de exibição como "production". Cruze o ID na interface do Lakebase se tiver de confirmar a que branch ou endpoint se refere uma linha de insight ou tabela.

• Os GUCs que permitem a captura de telemetria poderão não ser propagados automaticamente para uma instância de computação existente. Se a telemetria não aparecer depois de a pré-visualização estar ativada, ligue-se ao projeto e verifique:

  SHOW neon_monitor.log_capture_enabled;
  SHOW databricks.o11y_exporter_enabled;
  

  Ambos devem regressar on. Se algum deles devolver off, reinicie o endpoint de computação.

Configurações legadas de observabilidade

Antes de a telemetria passar para as tabelas de sistema, podias criar uma configuração de observabilidade que capturava a telemetria para um catálogo e esquema no teu próprio Unity Catalog e fornecia dashboards pré-construídos. As configurações existentes continuam a funcionar, e os seus painéis de controlo continuam disponíveis. Já não se podem criar novas configurações de observabilidade, e a captura para tabelas de sistema não cria dashboards.

Passos seguintes

• Detetar problemas com o Insights: o agente que revê esta telemetria num calendário.
• Investigue e resolva problemas com o Genie: faça perguntas sobre esta telemetria com as suas próprias palavras.
• Referência da tabela do sistema Lakebase: onde estas tabelas se situam entre as outras tabelas do sistema.