Telemetria Lakebase em tabelas de sistema

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

Requirements

• A Observabilidade do Lakebase na prévia das Tabelas do Sistema ativada para seu espaço de trabalho.
• Um projeto Lakebase na AWS ou Azure. Consulte Obter um banco de dados postgres.

O que é capturado

O Lakebase registra os sinais que você precisa para explicar um banco de dados lento ou com falha, através das seguintes tabelas:

Os registros são mantidos por 7 dias. O restante desta página documenta cada coluna de cada tabela. Para saber onde essas tabelas se situam entre as outras tabelas do sistema, veja referência de tabela de sistema Lakebase.

Acesso

As system.lakebase tabelas são regidas pelo Catálogo Unity. Usuários com os papéis de administrador de conta e administrador da metastore podem ler a telemetria e gerenciar o acesso a ela. Consulte Gerenciar privilégios no Catálogo do Unity.

O Access se aplica no nível do esquema, então um usuário que consegue ler system.lakebase vê a telemetria de cada projeto na conta.

Texto da declaração mascarada

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

Colunas comuns a cada tabela

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

Tabelas com nomes que terminam _counters também incluem uma previous_ts coluna, marcando o início do intervalo em que os valores de uma linha foram acumulados. Esses são valores cumulativos para esse intervalo, não leituras pontuais. As tabelas que _gauges terminam são leituras pontuais e não têm .previous_ts

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

Atividade de sessão

Um instantâneo de cada back-end ativo, amostrado continuamente. Esse é o mesmo padrão que o AWS Performance Insights ou o ASH (Histórico de Sessão Ativa) da Oracle: se uma sessão estiver fazendo alguma coisa, incluindo esperar, ela aparecerá aqui.

active_session_history

Eventos de espera

Contagens de eventos de espera e tempo agregados, complementando a exibição por exemplo em active_session_history.

wait_event_counters

Planos de consultas

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

plan_history

Estatísticas de consulta

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

pg_stat_statements_counters

Alterações feitas no esquema

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

ddl_history

Logs do Postgres

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

postgres_logs

Métricas de computação

Uso de recursos de nível de computação: CPU, memória, E/S de disco e rede e o LFC (cache de arquivos local), o cache do lado da computação do Lakebase na frente do pageserver.

compute_counters

compute_gauges

Métricas de banco de dados

Atividade por banco de dados: linhas alteradas, transações, sessões e integridade do vácuo. É aqui que os sinais de bloat de tabela e de vácuo automático residem.

database_counters

database_gauges

Limitações

As seguintes limitações se aplicam:

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

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

• 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." Faça uma cruzada de referência com o ID na interface do Lakebase se precisar confirmar a qual branch ou endpoint uma linha de insight ou tabela se refere.

• Os GUCs que habilitam a captura de telemetria podem não se propagar automaticamente para uma computação existente. Se a telemetria não aparecer após a pré-visualização ser ativada, conecte-se ao projeto e verifique:

  SHOW neon_monitor.log_capture_enabled;
  SHOW databricks.o11y_exporter_enabled;
  

  Ambos devem retornar on. Se qualquer uma das opções retornar off, reinicie o endpoint de computação.

Configurações legadas de observabilidade

Antes da telemetria migrar para as tabelas de sistema, você podia criar uma configuração de observabilidade que capturasse a telemetria em um catálogo e esquema no seu próprio Catálogo Unity e fornecia dashboards pré-construídos. As configurações existentes continuam funcionando, e seus painéis continuam disponíveis. Você não pode mais criar novas configurações de observabilidade, e a captura para tabelas de sistema não cria dashboards.

Próximas Etapas 

• Detectar problemas com Insights: o agente que revisa essa telemetria em um cronograma.
• Investigue e corrija problemas com o Genie: faça perguntas sobre essa telemetria com suas próprias palavras.
• Referência de tabela do sistema Lakebase: onde essas tabelas se situam entre as outras tabelas do sistema.