Registro e monitoramento de aplicativos Databricks

O registo e monitorização eficazes ajudam-no a detetar e responder a eventos de segurança nas Aplicações Databricks. Os aplicativos geram logs no nível do aplicativo e logs de auditoria da plataforma, que você pode usar para diagnóstico, rastreamento de desempenho e análise de segurança.

Logs de aplicativos

Para aceder aos logs na interface do Databricks Apps ou através da URL da sua aplicação, a sua aplicação deve escrever a saída em stdout e stderr.

Acesse os logs do aplicativo das seguintes maneiras:

Interface da Apps: Clique no separador Logs da aplicação para ver a saída padrão e o erro. Para obter detalhes, consulte Visualizar os detalhes de uma aplicação Databricks.
URL direto: anexe /logz ao URL do seu aplicativo. Por exemplo, se o URL da sua aplicação for https://my-app-1234567890.my-instance.databricksapps.com, os logs estarão disponíveis em https://my-app-1234567890.my-instance.databricksapps.com/logz.

Observação

O Azure Databricks não mantém registos persistentes quando a computação da aplicação desliga. Para registro persistente, integre-se a serviços de logging externos ou escreva logs em volumes ou tabelas do Unity Catalog.

As entradas do registo estão agrupadas por origem. No separador Logs, use o filtro Source para mostrar ou ocultar entradas de cada origem:

App: Saída padrão da tua app.
Sistema: Mensagens da plataforma sobre o ciclo de vida da aplicação, como implementação e arranque.
Build: Resultado da instalação de dependências e da compilação da sua aplicação.
HTTP: Registos de acesso HTTP para pedidos servidos pela sua aplicação. Consulte os registos de acesso HTTP.

Registos de acesso HTTP

O Databricks Apps regista uma entrada de registo de acesso HTTP para cada pedido servido pela sua aplicação. Estas entradas aparecem na fonte HTTP no separador Logs e na /logz URL, juntamente com a saída e erro padrão da sua aplicação.

Os registos de acesso capturam tanto pedidos autenticados como não autenticados, incluindo pedidos que são rejeitados antes de chegarem à sua aplicação, como pedidos que falham na autorização. Como os pedidos rejeitados são registados, pode auditar tentativas de autorização falhadas como eventos de segurança.

Os seguintes limites aplicam-se ao que é registado:

Para proteger dados sensíveis, as cadeias de consulta são removidas do caminho do pedido, pelo que tokens ou outros valores sensíveis passados como parâmetros de consulta não são registados.
Para reduzir o ruído, as solicitações internas da plataforma, como callbacks de autenticação e verificações de estado, são excluídas.

Sob carga pesada, o Azure Databricks pode deixar cair algumas entradas do registo de acesso. Quando as entradas são eliminadas, o registo inclui uma mensagem inline que indica o número de entradas eliminadas.

Formato de entrada de registo: Cada entrada utiliza o Apache Combined Log Format. Segue-se um exemplo de entrada:

203.0.113.10 - jane.doe@example.com [23/Jul/2026:15:04:05 +0000] "GET /api/data HTTP/1.1" 200 1234 "https://apps.example.com/" "Mozilla/5.0"

Cada entrada contém os seguintes campos, por ordem. Campos vazios aparecem como hífen (-).

Campo	Example	Descrição
IP do Cliente	`203.0.113.10`	Endereço IP do cliente que fez o pedido.
User	`jane.doe@example.com`	Utilizador autenticado, ou `-` para um pedido não autenticado.
Data e Hora	`[23/Jul/2026:15:04:05 +0000]`	Data e hora da receção do pedido.
Linha de solicitação	`"GET /api/data HTTP/1.1"`	método HTTP, caminho de pedido com a string de consulta removida, e protocolo.
Código de estado	`200`	Código de status da resposta HTTP.
Tamanho da resposta	`1234`	Tamanho do corpo da resposta, em bytes.
Referência	`"https://apps.example.com/"`	Valor do `Referer` cabeçalho do pedido.
Agente de usuário	`"Mozilla/5.0"`	Valor do `User-Agent` cabeçalho do pedido.

Integração com serviços de registo externos

Para logs persistentes e recursos avançados de monitoramento, use o seguinte:

Telemetria de aplicações (Beta): Recolha traços, registos e métricas diretamente para as tabelas do Catálogo Unity. Consulte Configurar telemetria para aplicações Databricks.
Ferramentas de Monitorização de Desempenho de Aplicações (APM): Utilize o New Relic, Datadog ou ferramentas semelhantes de monitorização de desempenho de aplicações para recolher e analisar logs, métricas e rastreios.
Persistência de registos personalizados: Escrever registos periodicamente em volumes ou tabelas do Catálogo Unity para armazenamento e análise a longo prazo.

Consulte Práticas de log recomendadas para obter orientações sobre formatação e conteúdo de log.

Práticas recomendadas de registro em log

Para integrar com sistemas externos de monitorização e alerta em tempo real:

Formate logs em JSON ou outros formatos analisáveis por máquina.
Registre eventos relevantes para a segurança com o contexto:
- Eventos de autenticação e autorização, incluindo identidade do usuário e resultado
- Detalhes sobre o acesso aos dados, como nomes de catálogo, esquema e tabela
- Erros relacionados à segurança, como tokens inválidos, recusas de permissão e atividades suspeitas
Transferir logs para sistemas externos. Integre com ferramentas de APM ou agregação de logs para suportar alertas em tempo real, resposta a incidentes de segurança, análises de utilização e desempenho, e correlação com os logs do sistema Azure Databricks.

Considerações de segurança para registro em log

Os aplicativos Databricks são projetados com os seguintes controles internos para evitar a exfiltração de dados:

Acesso apenas via API: As aplicações só podem aceder aos recursos do Azure Databricks através das APIs públicas do Azure Databricks. Essas APIs podem ser auditadas através dos logs das tabelas do sistema.
Comunicação criptografada: Todo o tráfego da API é criptografado usando TLS 1.2 ou superior para garantir a transferência segura de dados.

Monitoramento de segurança com tabelas do sistema

Azure Databricks captura registos de auditoria para atividades relacionadas com aplicativos na tabela system.access.audit. Você pode consultar esses logs para rastrear ações do usuário, alterações na configuração do aplicativo e eventos de segurança.

Use as consultas a seguir para monitorar atividades relacionadas à segurança e detetar possíveis problemas com seus aplicativos.

Monitorar alterações de permissão do aplicativo

Use esta consulta para detetar modificações de permissão do aplicativo:

-- Monitor all app permission modifications in the last 30 days
WITH permission_changes AS (
  SELECT
    event_date,
    workspace_id,
    request_params.request_object_id AS app_name,
    user_identity.email AS modified_by,
    explode(from_json(
      request_params.access_control_list,
      'array<struct<user_name:string,group_name:string,permission_level:string>>'
    )) AS permission
  FROM system.access.audit
  WHERE action_name = 'changeAppsAcl'
    AND event_date >= current_date() - 30
)
SELECT
  event_date,
  app_name,
  modified_by,
  permission.user_name,
  permission.group_name,
  permission.permission_level
FROM permission_changes
ORDER BY event_date DESC

Identificar apps com permissões de API do usuário

Use esta consulta para localizar aplicativos com escopos de API do usuário configurados:

-- Find apps created or updated in the last 30 days with user API scopes configured
SELECT
  event_date,
  get_json_object(request_params.app, '$.name') AS app_name,
  user_identity.email AS creator_email,
  get_json_object(request_params.app, '$.user_api_scopes') AS user_api_scopes
FROM system.access.audit
WHERE
  action_name IN ('createApp', 'updateApp')
  AND get_json_object(request_params.app, '$.user_api_scopes') IS NOT NULL
  AND event_date >= current_date() - INTERVAL 30 DAYS

Rastrear ações de autorização do usuário

Use esta consulta para listar as ações do aplicativo executadas com autorização do usuário:

-- List app actions performed on behalf of users in the last 30 days
WITH obo_events AS (
  SELECT
    event_date,
    workspace_id,
    audit_level,
    identity_metadata.acting_resource AS app_id,   -- OAuth App ID or name
    user_identity.email AS user_email,             -- Logged-in user
    service_name,
    action_name
  FROM system.access.audit
  WHERE event_date >= current_date() - 30
    AND identity_metadata.acting_resource IS NOT NULL
)
SELECT
  event_date,
  app_id,
  user_email,
  service_name,
  action_name,
  audit_level,
  COUNT(*) AS event_count
FROM obo_events
GROUP BY
  event_date, app_id, user_email, service_name, action_name, audit_level
ORDER BY event_date DESC;

Acompanhamento operacional

Use tabelas do sistema para monitorar aspetos operacionais de seus aplicativos, como custo e uso de recursos.

Monitore os custos do app

Monitore os custos do Databricks Apps usando a system.billing.usage tabela. Use a seguinte consulta para obter informações precisas de custo para aplicativos por dia ou mês:

-- Get Databricks Apps cost by app per day for the last 30 days
SELECT
  us.usage_date,
  us.usage_metadata.app_id,
  us.usage_metadata.app_name,
  SUM(us.usage_quantity) AS dbus,
  SUM(us.usage_quantity * lp.pricing.effective_list.default) AS dollars
FROM
  system.billing.usage us
LEFT JOIN system.billing.list_prices lp
  ON lp.sku_name = us.sku_name
  AND us.usage_start_time BETWEEN lp.price_start_time AND COALESCE(lp.price_end_time, NOW())
WHERE
  billing_origin_product = 'APPS'
  AND us.usage_unit = 'DBU'
  AND us.usage_date >= DATE_SUB(NOW(), 30)
GROUP BY ALL

O Databricks Apps suporta políticas de utilização para ajudar a acompanhar custos. Para obter informações sobre como configurar políticas de utilização, consulte Utilização de atributos com políticas de utilização serverless.

Monitorizar insights da aplicação

Importante

O separador Insights está em Beta.

O separador Insights na página de detalhes da aplicação mostra o envolvimento do utilizador e a disponibilidade da aplicação.

Monitorização do espectador

A tabela de Visualizadores acompanha quais os utilizadores que acedem à sua aplicação.

O Azure Databricks regista um evento de visualização quando um utilizador acede à aplicação através da URL da aplicação ou através do acesso à API. Armazena os dados como únicos por utilizador, por aplicação. Visitas subsequentes do mesmo utilizador sobrescrevem o seu registo anterior em vez de criar uma nova linha.

O último carimbo temporal visualizado segue um ciclo de atualização da sessão OAuth de 30 minutos. Múltiplas visitas dentro da janela da sessão mantêm o tempo inicial da visita, mas o primeiro acesso após o término da sessão substitui o carimbo de data/hora com o novo horário da visita.