Registro em Log e monitoramento para aplicativos do Databricks

O registro em log e o monitoramento eficazes ajudam você a detectar e responder a eventos de segurança nos Aplicativos do Databricks. Os aplicativos geram logs no nível do aplicativo e logs de auditoria de plataforma, que você pode usar para diagnóstico, acompanhamento de desempenho e análise de segurança.

Logs de aplicação

Para disponibilizar logs na interface do usuário do Databricks Apps ou por meio da URL do aplicativo, seu aplicativo deve gravar a saída em stdout e stderr.

Acesse os logs de aplicativos das seguintes maneiras:

Interface do Apps: Clique na aba Logs do app para visualizar a saída padrão e o erro. Para obter detalhes, veja detalhes de um app do Databricks.
URL direta: acrescente /logz à URL do aplicativo. Por exemplo, se a URL do aplicativo estiver 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

Azure Databricks não persiste os logs quando a computação do aplicativo é desligada. Para registro em log persistente, integre-se a serviços externos de registro em log ou grave os logs em volumes ou tabelas do Unity Catalog.

As entradas do registro são agrupadas por fonte. Na aba Logs , use o filtro Source para mostrar ou ocultar entradas de cada fonte:

App: Saída padrão do seu app.
Sistema: Mensagens da plataforma sobre o ciclo de vida do aplicativo, como implantação e inicialização.
Build: Saída da instalação de dependências e construção do seu app.
HTTP: Logs de acesso HTTP para requisições processadas pelo seu aplicativo. Veja os logs de acesso HTTP.

Logs de acesso HTTP

O Databricks Apps registra uma entrada de log de acesso HTTP para cada solicitação atendida pelo seu app. Essas entradas aparecem sob a origem HTTP na guia Logs e no endereço /logz, junto com a saída padrão e a saída de erro do seu app.

Os logs de acesso capturam tanto solicitações autenticadas quanto não autenticadas, incluindo requisições que são rejeitadas antes de chegarem ao seu app, como solicitações que não são autorizadas. Como solicitações rejeitadas são registradas, você pode auditar tentativas de autorização fracassadas como eventos de segurança.

Os seguintes limites se aplicam ao que é registrado:

Para proteger dados sensíveis, as strings de consulta são removidas do caminho da requisição, então tokens ou outros valores sensíveis passados como parâmetros de consulta não são registrados.
Para reduzir o ruído, solicitações internas da plataforma, como callbacks de autenticação e checagens de saúde, são excluídas.

Sob alta carga, pode haver perda de algumas entradas do log de acesso no Azure Databricks. Quando as entradas são eliminadas, o registro inclui uma mensagem inline que informa o número de entradas eliminadas.

Formato de entrada de registro: Cada entrada utiliza o Apache Combined Log Format. A seguir está 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, em ordem. Campos vazios aparecem como hífen (-).

Campo	Example	Description
IP do Cliente	`203.0.113.10`	Endereço IP do cliente que fez o a solicitação.
Usuário	`jane.doe@example.com`	Usuário autenticado, ou `-` por uma solicitação não autenticada.
Timestamp	`[23/Jul/2026:15:04:05 +0000]`	Data e hora do recebimento do pedido.
Linha de requisição	`"GET /api/data HTTP/1.1"`	Método HTTP, caminho de requisição com a string de consulta removida e protocolo.
Código de status	`200`	Código de status de resposta HTTP.
Tamanho da resposta	`1234`	Tamanho do corpo da resposta, em bytes.
Referer	`"https://apps.example.com/"`	Valor do `Referer` cabeçalho de solicitação.
Agente do Usuário	`"Mozilla/5.0"`	Valor do `User-Agent` cabeçalho de solicitação.

Integrar com serviços de log externos

Para logging persistente e monitoramento avançado, use o seguinte:

Telemetria do aplicativo (Beta): Colete rastreamentos, logs e métricas diretamente nas tabelas do Unity Catalog. Consulte Configuração de telemetria para Aplicativos do Databricks.
Ferramentas de Monitoramento de Desempenho de Aplicações (APM): Use ferramentas de monitoramento de desempenho de aplicações New Relic, Datadog ou similares para coletar e analisar logs, métricas e rastreios.
Persistência de logs personalizada: Grave logs periodicamente nos volumes ou nas tabelas do Unity Catalog para armazenamento e análise de longo prazo.

Consulte as práticas de registro em log recomendadas para obter diretrizes sobre formatação de log e conteúdo.

Práticas recomendadas de registro em log

Para integrar com o monitoramento externo e sistemas de alerta em tempo real:

Formatar logs em JSON ou em outros formatos analisáveis por computador.
Registrar eventos relevantes à segurança com contexto:
- Eventos de autenticação e autorização, incluindo identidade e resultado do usuário
- Detalhes de acesso a dados, como catálogo, esquema e nomes de tabela
- Erros relacionados à segurança, como tokens inválidos, negações de permissão e atividade suspeita
Encaminhe logs para sistemas externos. Integre-se às ferramentas de agregação de log ou APM para dar suporte a alertas em tempo real, resposta a incidentes de segurança, análise de desempenho e uso e correlação com os logs do sistema Azure Databricks.

Considerações de segurança para registro de logs

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

API-only access: os aplicativos podem acessar apenas os recursos da Azure Databricks por meio das APIs públicas da Azure Databricks. Essas APIs são auditáveis por meio de registros de tabelas do sistema.
Comunicação criptografada: todo o tráfego de API é criptografado usando o TLS 1.2 ou superior para garantir a transferência segura de dados.

Monitoramento de segurança com tabelas do sistema

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

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

Monitorar alterações de permissão do aplicativo

Use esta consulta para detectar 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 aplicativos com permissões de API do usuário

Use esta consulta para localizar aplicativos com escopos de API de 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

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

Use esta consulta para listar as ações de 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;

Monitoramento operacional

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

Monitorar os custos do aplicativo

Monitore os custos dos Aplicativos do Databricks usando a system.billing.usage tabela. Use a consulta a seguir 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

Os Aplicativos do Databricks dão suporte a políticas de uso para ajudar a controlar os custos. Para obter informações sobre como configurar políticas de uso, consulte o uso de atributos com políticas de uso sem servidor.

Monitorar insights do aplicativo

Importante

A guia Insights está na fase Beta.

A guia Insights na página de detalhes do aplicativo mostra a participação do usuário e a disponibilidade do aplicativo.

Rastreamento de visualizadores

A tabela Visualizadores controla quais usuários acessam seu aplicativo.

Azure Databricks registra um evento de exibição quando um usuário acessa o aplicativo por meio da URL do aplicativo ou por meio do acesso à API. Ele armazena dados como exclusivos por usuário, por aplicativo. As visitas subsequentes do mesmo usuário substituem seu registro anterior em vez de criar uma nova linha.

O carimbo de data/hora da última visualização segue um ciclo de atualização da sessão OAuth de 30 minutos. Várias visitas dentro da janela da sessão mantêm o horário da visita inicial, mas o primeiro acesso após a expiração da sessão substitui o carimbo de data/hora pelo horário da nova visita.