Monitora tutta l'attività dell'IA utilizzando la tabella di traccia unificata

La tabella di tracciamento unificata ti offre un unico luogo dove monitorare, fare il debug, mettere in sicurezza e verificare tutte le attività tra i tuoi servizi Unity Gateway.

Un amministratore del metastore configura il tracciamento unificato una sola volta. Dopo di ciò, tutto il traffico Unity Gateway viene registrato automaticamente senza alcuna configurazione per endpoint.

Requirements

• Anteprima migliorata di Unity Gateway abilitata per il tuo account. Vedere Gestire le anteprime di Azure Databricks.
• Catalogo Unity abilitato per l'area di lavoro.
• Zerobus Ingest disponibile per il tuo spazio di lavoro. La tabella di traccia unificata scrive gli span su Unity Catalog tramite Zerobus Ingest. Per le regioni supportate, consulta Disponibilità dell'acquisizione.
• Ruolo di amministratore del metastore per configurare il tracciamento unificato.
• le autorizzazioni CREATE TABLE, USE CATALOG e USE SCHEMA nel catalogo e nello schema di destinazione di Unity Catalog.
• Per interrogare la tabella: SELECT privilegio sulla tabella di tracciamento. Per impostazione predefinita, solo l'amministratore del metastore può interrogarla. Per concedere accesso ad altri, vedi Permessi e controllo accessi.

Per utilizzare un catalogo supportato da uno storage predefinito, un amministratore dello spazio di lavoro deve anche abilitare Zerobus Ingest Default Storage nelle Anteprime delle Impostazioni>. Vedi Gestire le anteprime di Databricks.

Cos'è la tabella di tracciamento unificata?

La tabella di tracciamento unificata cattura ogni richiesta e risposta su tutti i servizi Unity Gateway in un'unica tabella Unity Catalog in formato OpenTelemetry ("OTel"). Offre tre vantaggi rispetto alle tabelle di inferenza:

• Completato. Tutta l'attività su ogni servizio si concentra in un unico posto, senza bisogno di configurazione per endpoint.
• Applicabile. Un amministratore del metastore crea la tabella una sola volta e il logging viene applicato a tutti i servizi, senza punti ciechi dovuti ai servizi che hanno il logging disabilitato.
• Apertura. Costruito sullo standard OpenTelemetry, quindi qualsiasi strumento può consumare i dati direttamente senza post-processing personalizzato.

Usi comuni:

• Debug: Filtra per trace_id per ripercorrere ogni passaggio di un'esecuzione non riuscita dell'agente. Filtra per service_name e status.code per trovare tutti gli errori su un endpoint specifico.
• Analisi per l'uso dell'IA: Usa le funzioni di IA per analizzare le interazioni con gli LLM (inclusi gli assistenti di codifica) per catturare i modelli tra i chiamanti e comprendere il valore che l'IA offre alla tua organizzazione.
• Ridurre l'uso dei token: Utilizzare funzioni di IA per analizzare i modelli di errore comuni nelle chiamate a LLM o MCP e capire come migliorare l'efficacia di agenti e assistenti di codifica.
• Sicurezza e conformità: Ogni span registra l'identità del richiedente, il nome dell'endpoint e il payload completo della richiesta, così puoi inserirli nei tuoi strumenti di sicurezza per il rilevamento e l'indagine delle minacce.
• Auditabilità: Esaminare l'attività dell'IA per un utente, un endpoint o un intervallo temporale.

Tabella di tracciamento unificata vs. tabelle di inferenza

La tabella di traccia unificata è l'approccio raccomandato per le nuove implementazioni. Le tabelle di inferenza rimangono disponibili ma sono progettate solo per il monitoraggio richiesta/risposta a un singolo endpoint modello-servizio. Per maggiori informazioni sulle tabelle di inferenza, vedi Richieste di log e risposte alle tabelle di inferenza.

Abilita la tabella di traccia unificata

Questa è un'operazione una tantum eseguita da un amministratore del metastore. La tabella si trova in un percorso di Unity Catalog scelto da te (ad esempio, <catalog>.<schema>.unity_gateway_otel_spans).

1. Nella barra laterale dell'area di lavoro fare clic su Gateway di intelligenza artificiale.
2. Clicca su Governa>Tracce>Imposta il tracciamento.
3. Seleziona il catalogo e lo schema dove verrà creata la tabella di tracciamento.
4. Clicca su Salva per creare la tabella delle tracce.

Consuma la tabella di traccia unificata

Visualizzare le tracce nell'interfaccia utente

1. Nella barra laterale dello spazio di lavoro, clicca sulla scheda AI Gateway>Govern>Traces .

La vista Traces fornisce i seguenti controlli:

• Ricerca: Ricerca nel testo completo tra i contenuti della schermata corrente.
• Intervallo di tempo: Filtra le tracce per finestra temporale (predefinito: ultime 24 ore).
• Filtri: Filtra per Servizio (nome endpoint), Principal (richiedente), Tipo di servizio, Stato o Tempo di Esecuzione.
• Colonne: Mostra o nascondi le colonne.
• Warehouse: Seleziona il SQL warehouse usato per eseguire query sulla tabella di tracciamento.

Scrivi query con Genie Code

Genie Code è disponibile in tutto lo spazio di lavoro. Apri Genie Code dalla barra laterale e chiedigli di scrivere query SQL sulla tua tabella di traccia. Genie Code comprende automaticamente gli schemi delle tabelle del Catalogo Unity.

Prompt di esempio:

• "Mostrami tutti gli errori del limite di velocità sull'endpoint del client support-bot nelle ultime 24 ore"
• "Quali utenti hanno avuto i tempi di risposta p99 più lunghi la scorsa settimana?"
• "Trova tutte le tracce in cui l'agente ha effettuato più di tre chiamate a valle"

Genie Code genera l'SQL, che puoi eseguire direttamente in un notebook o nell'editor SQL.

Esegui query con SQL o con un notebook

La tabella è raggruppata da time. Includi questa rubrica nella tua WHERE clausola per ottenere le migliori prestazioni.

Sostituisci <catalog>.<schema>.<table_name> con il percorso della tabella di tracciamento.

-- All spans for a specific trace
SELECT * FROM <catalog>.<schema>.<table_name>
WHERE trace_id = 'afdd29f3a069482f8b102380ba0fb3c8'
ORDER BY start_time_unix_nano;

-- All errors on a specific endpoint in the last 24 hours
SELECT trace_id, name, status, attributes
FROM <catalog>.<schema>.<table_name>
WHERE service_name = '<catalog>.<schema>.<model>'
  AND status.code = 'STATUS_CODE_ERROR'
  AND time >= current_timestamp() - INTERVAL 1 DAY;

-- Root spans only (one row per request), with requester and HTTP status
SELECT trace_id, name,
  attributes:`enduser.id`::string AS requester
  attributes:`http.response.status_code`::int AS status_code,
  status.code
FROM <catalog>.<schema>.<table_name>
WHERE parent_span_id IS NULL
  AND service_name = '<catalog>.<schema>.<model>';

Invia tracce lato client dalla tua applicazione

Le tue applicazioni possono inviare span OpenTelemetry lato client a Unity Gateway tramite il suo endpoint di ingestione OTLP, da qualsiasi SDK OpenTelemetry. L'SDK di Claude ha anche il supporto integrato per il tracciamento delle sue richieste API. Gli span applicativi si trovano nella stessa tabella di traccia unificata degli span di richiesta gateway (<catalog>.<schema>.<table_name>scelti all'installazione), così monitori cosa ha fatto la tua applicazione e cosa ha fornito il gateway in un unico posto.

Requisiti

• La tabella di tracciamento unificata è impostata per il tuo spazio di lavoro. Vedere Abilita la tabella di traccia unificata.
• L'ingestione span lato client è abilitata per il tuo spazio di lavoro.
• Un token di Azure Databricks, ad esempio un token di accesso personale. Gli span acquisiti sono attribuiti all'identità del token. Gli attributi identità nel payload, come enduser.id, vengono ignorati.
• L'entità del token ha accesso allo spazio di lavoro. Altrimenti le richieste vengono respinte.

Invia span con un SDK OpenTelemetry

Puntare un esportatore OTLP a https://<workspace-url>/ai-gateway/otel/v1/traces. L'endpoint accetta solo OTLP su HTTP con codifica protobuf binaria (http/protobuf). JSON e gRPC non sono supportati. Invia il payload non compresso: non abilitare la compressione sull'esportatore (ad esempio, lascia OTEL_EXPORTER_OTLP_COMPRESSION non impostato).

I seguenti esempi inviano span da qualsiasi applicazione:

Python

1. Installa l'SDK OpenTelemetry e i pacchetti esportatore OTLP: opentelemetry-sdk e opentelemetry-exporter-otlp-proto-http.

2. Registra un provider tracer con un exporter di span OTLP puntato sull'endpoint di ingestione:

   import os
   
   from opentelemetry import trace
   from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
   from opentelemetry.sdk.resources import Resource
   from opentelemetry.sdk.trace import TracerProvider
   from opentelemetry.sdk.trace.export import BatchSpanProcessor
   
   DATABRICKS_TOKEN = os.environ.get('DATABRICKS_TOKEN')
   
   # service.name becomes the service_name of these spans in the trace table.
   provider = TracerProvider(
       resource=Resource.create({"service.name": "<your-application-name>"})
   )
   exporter = OTLPSpanExporter(
       endpoint="https://<workspace-url>/ai-gateway/otel/v1/traces",
       headers={"Authorization": f"Bearer {DATABRICKS_TOKEN}"},
   )
   provider.add_span_processor(BatchSpanProcessor(exporter))
   trace.set_tracer_provider(provider)
   

3. Crea span nel codice della tua applicazione:

   tracer = trace.get_tracer(__name__)
   
   with tracer.start_as_current_span("<span-name>"):
       # Your application code
       ...
   

BatchSpanProcessor esporta spans in modo asincrono. Negli script di breve durata, chiama provider.shutdown() (o provider.force_flush()) prima che il processo esca, in modo che vengano inviati gli span nel buffer.

TypeScript

1. Installa l'SDK OpenTelemetry e i pacchetti esportatore OTLP: npm install @opentelemetry/api @opentelemetry/sdk-trace-node @opentelemetry/exporter-trace-otlp-proto @opentelemetry/resources.

2. Registra un provider tracer con un exporter di span OTLP puntato sull'endpoint di ingestione:

   import { trace } from '@opentelemetry/api';
   import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-proto';
   import { resourceFromAttributes } from '@opentelemetry/resources';
   import { BatchSpanProcessor, NodeTracerProvider } from '@opentelemetry/sdk-trace-node';
   
   // service.name becomes the service_name of these spans in the trace table.
   const provider = new NodeTracerProvider({
     resource: resourceFromAttributes({ 'service.name': '<your-application-name>' }),
     spanProcessors: [
       new BatchSpanProcessor(
         new OTLPTraceExporter({
           url: 'https://<workspace-url>/ai-gateway/otel/v1/traces',
           headers: { Authorization: `Bearer ${process.env.DATABRICKS_TOKEN}` },
         }),
       ),
     ],
   });
   provider.register();
   

3. Crea span nel codice della tua applicazione:

   const tracer = trace.getTracer('<your-application-name>');
   
   tracer.startActiveSpan('<span-name>', (span) => {
     // Your application code
     span.end();
   });
   

BatchSpanProcessor esporta gli span in modo asincrono. Negli script di breve durata, chiama await provider.shutdown() prima che il processo esca in modo che vengano inviati gli span bufferizzati.

Per configurare l'exporter senza codice, usa le variabili di ambiente standard dell'exporter OpenTelemetry. Gli SDK OpenTelemetry che implementano la specifica OTLP exporter li leggono, ad esempio quando crei OTLPSpanExporter() in Python senza argomentazioni. Il valore dell'intestazione è codificato in percentuale, quindi lo spazio dopo Bearer è scritto come %20:

export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://<workspace-url>/ai-gateway/otel/v1/traces"
export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_TRACES_HEADERS="Authorization=Bearer%20<token>"
export OTEL_SERVICE_NAME="<your-application-name>"

Tenere presente quanto segue:

• Imposta l'attributo resource service.name su ogni provider di tracciamento. Gli span senza di esso compaiono nella tabella di tracciamento sotto unknown_external_service.
• Gli span devono avere un ID traccia di 16 byte, un ID di span e di span genitore da 8 byte, e un orario di inizio. Gli intervalli che falliscono la validazione vengono rifiutati e conteggiati nel campo partial_success della risposta.

Correla le tracce lato client e gateway

Quando la tua applicazione propaga il contesto di traccia W3C (l'intestazione traceparent) nelle sue richieste a Unity Gateway, gli span delle richieste del gateway si uniscono al contesto della traccia propagata, così possono apparire nella stessa traccia degli span della tua applicazione. Con un SDK OpenTelemetry generico, propaga il contesto utilizzando la strumentazione OpenTelemetry per il tuo client HTTP o iniettando il contesto nelle intestazioni delle richieste. W3C TraceContext è il propagatore predefinito.

Il collegamento delle tracce gateway è in Beta ed è abilitato per ogni workspace, separatamente dall'ingestione dello span lato client. Per abilitarlo per il tuo spazio di lavoro, contatta il team dell’account Azure Databricks. Quando il collegamento delle tracce è abilitato, il gateway adotta il contesto del tracciato in entrata per i servizi modello Unity Catalog e le richieste MCP. Il gateway non inoltra il contesto di traccia al fornitore del modello upstream.

Comportamento di risposta e limiti

• L'endpoint restituisce un OTLP ExportTraceServiceResponse. HTTP 200 significa che il batch è stato accettato per la consegna, non che gli span siano conservati in modo duraturo. Le operazioni di scrittura sono asincrone.
• Gli span rifiutati, ad esempio span con ID malformati o inviati prima che il tracciamento sia abilitato per lo spazio di lavoro, vengono riportati nel campo della partial_success risposta. Ispeziona partial_success invece di riprovare interi lotti.
• L'endpoint restituisce HTTP 404 se l'ingestione span lato client non è abilitata per lo spazio di lavoro, HTTP 403 se il principale del token non ha accesso allo spazio di lavoro, e HTTP 400 se il corpo della richiesta non è valido OTLP protobuf, ad esempio un JSON o un corpo compresso.
• L'endpoint accetta fino a 32 MiB per richiesta e 100 richieste al secondo per ogni organizzazione. I valori degli attributi della stringa superiori a 3 MiB (3.145.728 byte) sono troncati. Gli attributi di array e mappa non vengono troncati, e gli span che superano il limite di dimensione del record possono essere eliminati. Vedere Limitazioni.

Tracciamento delle richieste Claude

Unity Gateway si integra con il supporto OpenTelemetry di Claude per registrare le richieste API dei messaggi Claude e le sessioni dei Claude Managed Agents come span nella tabella di tracce unificata. Ci sono due fonti di span Claude: l'SDK Claude emette span lato client dalla tua applicazione, mentre la Claude Console esporta span lato server per le richieste Messages API e le sessioni Managed Agents. Puoi usare una delle due sorgenti, o entrambe.

Puoi tracciare quanto segue:

• Richieste API dei messaggi: Ogni richiesta con il suo modello, latenza e utilizzo dei token. Se abiliti la cattura dei contenuti, gli span includono anche prompt e risposte.
• Sessioni di Claude Managed Agents: ogni turno dell'agente con le sue richieste di modello, l'uso degli strumenti e l'uso dei token, così puoi seguire passo dopo passo ciò che ha fatto un agente.

Per dettagli su ciò che ogni fonte registra, consulta la documentazione OpenTelemetry di Anthropic.

Claude SDK

L'SDK emette span lato client per le richieste API che la tua applicazione effettua. L'SDK utilizza il provider di tracer registrato della tua applicazione, quindi dopo aver configurato il provider di tracer in Inviare span con un SDK OpenTelemetry, non è necessario un esportatore specifico dell'SDK. Il token Azure Databricks in quella configurazione autentica solo lo span exporter. Le tue richieste Anthropic vanno direttamente su Anthropic e usano la chiave API di Anthropic.

Python

1. Installa o aggiorna al pacchetto più recente anthropic, ad esempio pip install --upgrade anthropic.

2. Installa i pacchetti OpenTelemetry e registra il provider tracer come descritto in Inviare gli span con un SDK OpenTelemetry.

3. Crea un client SDK Claude e invia una richiesta:

   import anthropic
   
   # Uses your Anthropic API key from the ANTHROPIC_API_KEY environment variable.
   client = anthropic.Anthropic()
   
   message = client.messages.create(
       model="claude-opus-5-5",
       max_tokens=256,
       messages=[
           {"role": "user", "content": "What is a mixture of experts model?"},
       ],
   )
   

TypeScript

1. Installa o aggiorna all’ultima versione del pacchetto @anthropic-ai/sdk, ad esempio npm install @anthropic-ai/sdk@latest.

2. Installa i pacchetti OpenTelemetry e registra il provider tracer come descritto in Send spans con un SDK OpenTelemetry.

3. Crea un client SDK Claude e invia una richiesta:

   import Anthropic from '@anthropic-ai/sdk';
   
   // Uses your Anthropic API key from the ANTHROPIC_API_KEY environment variable.
   const client = new Anthropic();
   
   const message = await client.messages.create({
     model: 'claude-opus-5-5',
     max_tokens: 256,
     messages: [{ role: 'user', content: 'What is a mixture of experts model?' }],
   });
   

Cosa registra l'SDK di Claude

Gli span seguono le convenzioni semantiche di OpenTelemetry GenAI: uno span per ogni richiesta API (ad esempio, anthropic.messages.create), con l'uso dei token registrato in gen_ai.usage.* attributi. Per le risposte in streaming, lo span delle richieste termina quando lo stream è completamente letto o chiuso.

L’SDK supporta le seguenti opzioni aggiuntive. Gli esempi utilizzano l'SDK Python:

• Modalità contenuto: di default, gli span trasportano solo metadati (metadata_only). Per includere prompt e risposte negli span, imposta traces.content_mode su content (ad esempio, Anthropic(open_telemetry={"tracer_provider": provider, "traces": {"content_mode": "content"}})). La tracer_provider key serve solo per inviare gli span di questo client a un provider diverso da quello registrato globalmente. Il contenuto di prompt e risposta finisce nella tabella dei tracciati, quindi limita l'accesso ad essa con politiche ABAC o redazione delle informazioni personali come descritto in Permessi e controllo accessi. I contenuti che superano il limite di contenuto per span dell'SDK vengono troncati, con i vecchi messaggi di input troncati per primi. Immagini e documenti contribuiscono solo con il loro tipo, non con i loro dati.
• ID conversazione: Per raggruppare le richieste in una conversazione, passa un ID conversazione per ogni richiesta: client.with_options(open_telemetry={**client.open_telemetry, "conversation_id": "<conversation-id>"}). with_options sostituisce l'intera impostazione open_telemetry, quindi integra le impostazioni esistenti del client per mantenere opzioni come la modalità contenuto.
• Disabilita il tracciamento: Passa open_telemetry=False per disabilitare il tracciamento per un client. La variabile ANTHROPIC_OPEN_TELEMETRY di ambiente controlla il tracciamento per tutti i client e ANTHROPIC_OPEN_TELEMETRY_TRACES_CONTENT_MODE imposta la modalità contenuto, ad esempio ANTHROPIC_OPEN_TELEMETRY_TRACES_CONTENT_MODE=content.

Claude Console

Per inviare gli span lato server della Console alla tabella di traccia unificata, aggiungi una destinazione di telemetria Azure Databricks. Gli span lato client della tua applicazione, come le chiamate SDK e gli strumenti eseguiti dalla tua app, provengono dal tracciamento Claude SDK.

1. Nella Claude Console, vai a destinazioni di telemetria.

2. Aggiungi una destinazione Azure Databricks, poi inserisci l'URL del tuo workspace e un token di accesso personale Azure Databricks.

I requisiti sopra riportati, inclusa l'attribuzione del token-principal, si applicano anche agli span della console.

Conteggio dei token

Se invii span sia dall'SDK Claude che dalla Claude Console alla stessa tabella di traccia, ogni richiesta produce due anthropic.messages.create span con lo stesso numero di token: uno SPAN_KIND_CLIENT span dall'SDK e uno SPAN_KIND_SERVER dall'API. Per contare ogni richiesta una singola volta, somma gli attributi gen_ai.usage.* su un solo tipo di span. La seguente query utilizza i client span dell'SDK. Se invii span solo dalla console Claude, usa kind = 'SPAN_KIND_SERVER' invece.

SELECT
  sum(attributes:`gen_ai.usage.input_tokens`::bigint) AS input_tokens,
  sum(attributes:`gen_ai.usage.output_tokens`::bigint) AS output_tokens
FROM <catalog>.<schema>.<table_name>
WHERE name = 'anthropic.messages.create'
  AND kind = 'SPAN_KIND_CLIENT';

Permessi e controllo degli accessi

Poiché tutto il traffico Unity Gateway arriva in un'unica tabella, gestisci l'accesso in un unico posto invece di mantenere permessi separati per ogni endpoint.

Di default, solo gli amministratori del metastore possono interrogare la tabella dei tracciati. L'amministratore del metastore che ha creato la tabella è il suo proprietario. Per dare accesso agli altri utenti alle query, il proprietario della tabella deve concedere SELECT sulla tabella, USE SCHEMA sullo schema e USE CATALOG sul catalogo. Senza un filtro a riga, qualsiasi utente con questi privilegi può vedere le tracce di tutti i servizi nello spazio di lavoro, quindi Databricks raccomanda di applicare una policy di filtro a riga ABAC prima di concedere l'accesso.

Definire l'accesso in base all'ambito tramite criteri ABAC

Databricks raccomanda il controllo di accesso basato sugli attributi (ABAC) per dare a ogni utente o team accesso solo alle righe che dovrebbero vedere. Una policy di filtro a riga ABAC collega una funzione SQL alla tabella di tracciamento (o al suo catalogo o schema genitore) che viene eseguita al momento della query. Quando un utente esegue SELECT *, ottiene automaticamente solo le proprie righe, senza dover specificare manualmente la clausola WHERE e senza il rischio di leggere le tracce di un altro team.

Il seguente esempio implementa una politica comune: gli amministratori vedono tutte le tracce; i proprietari degli endpoint vedono solo il proprio servizio; tutti gli altri non vedono nulla.

Questo esempio segue una convenzione in cui ogni servizio ha un gruppo di account corrispondente chiamato <service_name>-owners. Questi gruppi non vengono creati automaticamente. Come parte della configurazione dell'accesso, un amministratore deve creare ogni gruppo e aggiungere i membri appropriati, e deve ripetere ogni volta che viene aggiunto un nuovo endpoint. La funzione di filtro e la policy non cambiano quando vengono aggiunti gruppi.

1. Crea la funzione filtro. Riceve un nome di servizio per ogni riga e restituisce TRUE se l'utente attuale è autorizzato a vederlo.

   CREATE OR REPLACE FUNCTION <catalog>.<schema>.ai_traces_filter(svc STRING)
   RETURNS BOOLEAN
   RETURN is_account_group_member('admins')
       OR is_account_group_member(svc || '-owners');
   

2. Etichetta la service_name colonna così la policy può essere collegata ad essa. Le policy ABAC passano le colonne alla funzione filtro tramite un tag governato.

   ALTER TABLE <catalog>.<schema>.<table_name>
   ALTER COLUMN service_name SET TAGS ('ai_trace_service' = '');
   

3. Crea la policy di filtro per righe nella tabella delle tracce.

   CREATE POLICY ai_traces_filter
   ON TABLE <catalog>.<schema>.<table_name>
   COMMENT 'Restrict trace visibility to service owners and admins'
   ROW FILTER <catalog>.<schema>.ai_traces_filter
   TO `account users`
   FOR TABLES
   MATCH COLUMNS has_tag('ai_trace_service') AS svc
   USING COLUMNS (svc);
   

4. Crea il <service_name>-owners gruppo di account per ogni servizio (se non esiste già), aggiungi i suoi membri e concedigli i privilegi necessari per interrogare la tabella: USE CATALOG sul catalogo, USE SCHEMA sullo schema e SELECT sulla tabella.

   GRANT USE CATALOG ON CATALOG <catalog> TO `customer-support-bot-owners`;
   GRANT USE SCHEMA ON SCHEMA <catalog>.<schema> TO `customer-support-bot-owners`;
   GRANT SELECT ON TABLE <catalog>.<schema>.<table_name> TO `customer-support-bot-owners`;
   

Con questa politica in vigore, i risultati vengono automaticamente filtrati in base a chi esegue la query:

• Un membro di customer-support-bot-owners che esegue SELECT * FROM <table> vede solo le righe in cui service_name = 'customer-support-bot'.
• Un membro del gruppo admins vede tutte le righe.
• Qualsiasi altro utente non vede righe.

Quando viene aggiunto un nuovo endpoint, ripeti l'ultimo passaggio: crea il gruppo corrispondente <service_name>-owners e concedigli SELECT. La policy e la funzione filtro non cambiano.

Vedi Controllo degli accessi basato su attributi in Unity Catalog per il riferimento completo per ABAC e Pattern comuni per il filtraggio delle righe e il mascheramento delle colonne per altri pattern di filtraggio delle righe.

Accesso con ambito definito e oscuramento dei dati personali

Un altro approccio per aprire l'accesso è materializzare una versione della tabella con le informazioni personali oscurate. La tabella con dati omessi può prevedere un'autorizzazione più ampia SELECT che si applica a più utenti. Il compromesso è che le tracce vengono materializzate due volte: una volta nella loro forma non oscurata nella tabella originale, che mantiene requisiti di accesso rigorosi, e una volta nella loro forma oscurata in una tabella separata aperta a più consumatori.

Per una soluzione di riferimento che oscura le informazioni di identificazione personale (PII) dalle tracce OpenTelemetry in Unity Catalog, consulta Governare e oscurare le tracce in Unity Catalog.

Schema

Ogni riga della tabella unificata delle tracce è uno span OpenTelemetry. Per la lista completa delle colonne, le chiavi di attributo e i campi degli eventi di valutazione delle policy, vedi Unified trace table schema reference.

Limitations

• La dimensione massima dell'attributo registrata è di 3 MiB (3.145.728 byte). Gli attributi che superano questo valore vengono troncati. L'intervallo è contrassegnato con databricks.trace.payload_truncated e il relativo dropped_attributes_count viene incrementato.
• La consegna dei tracce log è il miglior sforzo. La maggior parte delle tracce arriva in pochi secondi, tuttavia per le nuove tabelle, le tracce possono impiegare fino a un'ora ad arrivare.
• I trace log non sono garantiti per errori 401, 403, 429 o 500.
• La tabella di tracciamento potrebbe smettere di ricevere i log o corrompersi se cambi lo schema della tabella, rinomini la tabella o la cancelli.
• Databricks non gestisce il ciclo di vita della tabella di tracciamento; senza una politica di retention, essa cresce indefinitamente. Per eliminare automaticamente le righe dopo un periodo prestabilito, abilita la scadenza automatica (Auto-TTL) per la tabella, che esegue DELETE e VACUUM in background. Per gestire autonomamente la conservazione, pianifica periodicamente DELETE per rimuovere le righe scadute, seguito da VACUUM per recuperare lo spazio di archiviazione. Eseguire VACUUM da solo rimuove solo i file già non referenziati; non elimina nessuna riga. Definisci una politica di retention prima di abilitare il tracciamento in produzione.
• Di default, solo gli amministratori del metastore possono interrogare la tabella dei tracciati. Un amministratore del metastore deve configurare i criteri ABAC di filtro delle righe e concedere SELECT, USE SCHEMA e USE CATALOG prima che i creatori di endpoint o i team di sicurezza possano accedere alle rispettive tracce.