Docker e Portainer

Trasforma Container Logs in tabelle interrogabili.

Ogni container avviato dal daemon scrive un log. Interrogali tutti insieme, mantenendo il nome effettivo del container, la sua immagine e il relativo servizio Compose, invece di ritrovarti con una cartella piena di ID di 64 caratteri.

Usa i risultati in Excel, Google Sheets, negli strumenti di IA e nelle tue app tramite l’API REST del database.

Ogni tipo di connettore è incluso nel piano Free. Inizia con 2 origini dati e 1 agente.

Collega Container Logs gratisDettagli di connessione
Registri dei containerFile letti direttamente nella loro posizione
All’interno della tua reteAgente di rete per i flussi di query

Leggi, organizza ed esegui query sulla tua macchina.

Query di sola lettura · connessione in uscita
ExcelFogli di GoogleLa tua IALe tue app

I file sorgente restano al loro posto. I tuoi strumenti ricevono i risultati delle query.

Origine → agente → risultati consentiti

Query Streams trasforma i log json-file di Docker, le esportazioni di docker logs salvate manualmente e il log server di Portainer in tabelle SQL dinamiche, leggibili da Microsoft Excel, Google Sheets, assistenti IA tramite MCP, REST API e Power BI. Il problema principale che risolve è l’identità: su disco questi file hanno il nome dell’ID del container, quindi l’agent riconduce ciascuno al nome effettivo del container, alla sua immagine e al servizio Compose prima di caricare le righe. Non viene caricato nulla: l’agent legge i file sull’host e solo i risultati delle query escono dalla tua rete.

  • Nomi effettivi dei container, non ID
  • Immagine e servizio Compose per ogni riga
  • stdout e stderr restano separati

Collega Container Logs con le impostazioni corrette.

Mantieni la connessione sul Network Agent. Ecco i dettagli specifici di Container Logs.

Cartella
La directory dei log del daemon sull’host dei container oppure una cartella contenente log esportati
Sorgenti
Log json-file di Docker, esportazioni di docker logs salvate e log server di Portainer
Identità
Nome del container, immagine e servizio Compose ricavati dal daemon, così le righe non sono associate a un ID di 64 caratteri
Rotazione
Seguiti durante la rotazione del daemon, oltre ai dieci modelli di rotazione denominati per i file esportati
Righe non corrispondenti
Conservate alla lettera in events_raw_lines, mai eliminate
Credenziali
Nessuno: l’agent legge i file direttamente sull’host
dialetto SQL
DuckDB: SQL standard, senza dover imparare nulla di specifico sui container

L’agent legge i file di log già scritti dal daemon. Non si collega ai container, non mantiene aperto il socket del daemon per lo streaming e non scrive mai in quei file né li ruota: un connettore lasciato in esecuzione non può quindi modificare il comportamento dell’host.

Progettato per il funzionamento di Container Logs.

La parte difficile è l’identità, non l’analisi

Il driver json-file di Docker scrive il log di ciascun container in una directory che porta il suo ID di 64 caratteri. Analizzare il JSON è semplice; sapere a quale container appartiene non lo è, ed è proprio questo che rende utilizzabile la tabella.

  • Ogni riga contiene il nome effettivo del container, la sua immagine e il servizio Compose, ricavati dal daemon anziché dedotti dal percorso.
  • Così, «errori nel servizio api stamattina» diventa una clausola WHERE, non una tabella di corrispondenza da aggiornare manualmente.
  • Viene conservato anche lo stream, così stdout e stderr restano distinguibili invece di essere uniti in un’unica colonna di testo.
  • Se un container viene rimosso, le righe che ha già prodotto restano: la cronologia non scompare insieme al container.
-- Quali servizi generano più rumore al momento
SELECT   service, stream, COUNT(*) AS lines
FROM     fileset.events
WHERE    stream = 'stderr'
GROUP BY service, stream
ORDER BY lines DESC

Tre cose, non una

I log json-file del daemon sono il caso principale, ma non sono gli unici log dei container che vale la pena interrogare: un’esportazione di docker logs salvata manualmente ha un formato diverso e Portainer scrive un proprio log server. Tutti e tre hanno profili dedicati, così puoi scegliere cosa leggere senza sperare che un unico parser riesca a gestire tutto.

Formati e comportamento, nel dettaglio.

Apri la documentazione di riferimento che ti serve per Container Logs.

Una cartella contenente i log dei container diventa un'unica tabella.
La grande idea

Una cartella contenente i log dei container diventa un'unica tabella.

Query Streams legge i file già scritti dal daemon, identifica il formato e fornisce colonne tipizzate, indicando il nome del container accanto a ogni riga. Nessun sidecar, nessuna pipeline di acquisizione, nessun indice da mantenere; se una riga non può essere letta dal parser, viene conservata come riga con una motivazione invece di essere eliminata silenziosamente.

Cartella di registrosull'host
a3f9c1…-json.logDocker
Dockershopfront-stack_api.logesportare
portainer.logPortatore

Rotazioni, archivi compressi e file riletti: tutto gestito

noisy-containers.sqlSQL
SELEZIONARE app, compose_service,
       contare(*) AS linee
DA   set di file.eventi
DOVE  flusso = 'stderr'
GRUPPO PER app, compose_service
ORDINATO DA linee DESC
Risultatostderr per container
appserviziolinee
API della vetrinaAPI1,284
commesso/alavoratore417
sito web della vetrinaweb62
cache della vetrinacache3

Aggiungilo al database della tua applicazione nella stessa query

File che il demone scrive già, ora una tabella su cui puoi creare report

Due strumenti, tre formati, senza sidecar
Sorgenti

Due strumenti, tre formati, senza sidecar

Ogni scheda indica i file esatti letti da Query Streams e dove si trovano. Non devi cambiare il driver di logging perché funzioni: — file json è l'impostazione predefinita di Docker, e l'impostazione predefinita è quella supportata.

Log dei container supportati

3 formati · 2 strumenti
Logo Docker - Query Streams legge i log dei container Docker in formato json e le esportazioni dei log di Docker Dockerdriver di registrazione file json
  • Uno {"log","stream","time"} busta per riga, scritta dal demone
  • Il nome del container proviene direttamente da Docker config.v2.json accanto al tronco
  • Immagine e composizione del progetto/servizio durante il percorso come colonne
  • Generalmente /var/lib/docker/containers
  • Aggiunge; rotazioni numerate e .gz seguito
Logo Docker - Query Streams legge i log di Docker --timestamp esporta i file Dockeresportazione dei log di Docker
  • File salvati con log di docker --timestamps
  • Un timestamp RFC 3339 con nanosecondi, seguito dalla riga del container
  • Le righe relative ai banner dei container vengono omesse per dichiarazione, non per caso.
  • Qualsiasi cartella in cui conservi i file esportati
  • Un file per servizio; il nome deriva dalla radice del file
Logo Portainer - Query Streams legge i log della console zerolog del server Portainer PortatoreRegistro del server, console zerolog
  • portainer.log oppure dall’output del container
  • I codici colore ANSI vengono rimossi prima dell'analisi, quindi un livello è un livello
  • IL chiave=valore la coda diventa colonne; il resto atterra in dati
  • Vengono lette anche le righe, con un formato diverso, del server del tunnel integrato
  • I timestamp con risoluzione al minuto si leggono come UTC
Altro in arrivoQuesti sono l'inizio, non il limite.

Con ogni nuova versione dell'Agent vengono aggiunti nuovi formati di log per i container. Poiché gli Agent si aggiornano automaticamente, un formato aggiunto successivamente verrà visualizzato nel connettore senza che sia necessario accedere al server.

Tutti e tre i parser sono stati realizzati e testati su log reali di container: log json-file, di grandi dimensioni log di Docker esportazioni da un host Swarm e il log del server di Portainer CE 2.39.1. Una cosa da sapere subito: su Docker Desktop per Windows e Mac, i log json-file si trovano all’interno della macchina virtuale, dove un Agent in esecuzione come servizio non può raggiungerli. Esportali con log di docker --timestamps e utilizzare il secondo profilo.
Container in ogni area geografica, log letti dove si trovano
Ovunque funzioni

Contenitori in ogni regione, registri letti dove siedono

È raro che i container siano tutti in esecuzione nello stesso luogo. Un host in ufficio, un cluster Swarm in una regione cloud, un singolo server in un altro Paese. In ogni località è in esecuzione un Network Agent, che legge i file di log dove si trovano già e avvia una connessione in uscita verso Query Streams. Dal punto di vista del firewall, si tratta di una normale connessione in uscita: non c’è nulla da aprire e non serve configurare una VPN.

Direzione Un host Docker su disco locale, log json-file nella cartella del daemon chiama in uscita
eu-ovest Un cluster di sciami, uno log di Docker esportazione per servizio chiama in uscita
Stati Uniti orientali Portainer gestisce una manciata di host, il proprio registro server insieme chiama in uscita

Tre connessioni in uscita, un unico posto da cui interrogarle: nessuna porta in ingresso, nessuna VPN, nessuna modifica al firewall

Un agente per sede

Un Agent copre un intero sito, non una singola cartella: ogni formato di log che vuoi gestire in quel sito diventa un proprio connettore File Set sullo stesso Agent. La configurazione normale prevede un Agent per località. Il piano Free esegue un singolo Agent, mentre i piani a pagamento ne eseguono di più.

1 sito = 1 agente = molti connettori

Niente da aprire

L’Agent stabilisce un’unica connessione in uscita crittografata, su cui viaggiano sia la richiesta in uscita sia le righe di risposta. Nessuna porta in ingresso, nessuna VPN, nessuna modifica al firewall da richiedere; le credenziali restano nella tua rete.

un collegamento, in entrambe le direzioni

Una singola query tra i siti

Ogni fonte in un query federata assegna un nome al proprio Agent, così una singola istruzione può leggere un log in un Paese e un altro log in un altro, restituendo un unico risultato, oppure unire uno dei due a un database. Incluso nei piani Business ed Enterprise.

2 Paesi → 1 set di risultati

Si tengono aggiornati

Gli agenti si aggiornano automaticamente, quindi un formato di log del container aggiunto in una versione successiva raggiunge ogni sito senza che nessuno debba accedere a un server per installarlo. Questo è ciò che rende l'elenco precedente un punto di partenza piuttosto che un elenco fisso.

nuovi formati arrivano con l'Agente

Nomi, orologi e codici colore
La parte difficile

Nomi, orologi e codici colore

Il log di un container non è un file di testo con una data. Tre cose in genere non funzionano quando si cerca di trattarlo come un dato, e ognuna di esse viene gestita qui tramite una dichiarazione anziché per tentativi.

Nomi, non ID esadecimali

Docker assegna a ciascuna cartella di log il nome corrispondente all'ID del container, il che rende illeggibile una query raggruppata. Query Streams legge il record che Docker scrive accanto al log e ne estrae il nome reale, mantenendo l'ID come colonna a sé stante.

a3f9c1…-json.log → app = shopfront-api

L’orologio del daemon

Se credi al timestamp in secondi Unix stampato da un container, un evento finisce nel 1970. L’ora dell’evento è quella in cui il daemon lo ha acquisito; il timestamp del container viene conservato come colonna, invece di essere considerato attendibile.

ora dell’involucro → event_time

Codici colore nel file

I logger per console scrivono sequenze di escape del terminale direttamente nel log. Vengono rimosse prima dell’analisi, così il livello viene letto come tale e non come un livello racchiuso tra caratteri di escape; i byte originali restano inalterati.

codici di escape rimossi → level = INF

Nulla è stato contato due volte

Ogni file viene identificato tramite un'impronta digitale costituita dai suoi primi 4 KB, in modo che un file ruotato venga riconosciuto come lo stesso file anziché essere letto nuovamente dall'inizio. Una finestra di duplicazione scorrevole cattura la sovrapposizione quando un processo di scrittura riproduce la sua parte finale.

Hash del prefisso di 4 KB · finestra di 20.000 record

Le colonne che ottieni effettivamente
Lo schema

Le colonne che ottieni effettivamente

Non un blocco di testo con un timestamp accanto. Ogni formato viene analizzato in colonne tipizzate su cui puoi applicare direttamente filtri, raggruppamenti e aggregazioni; inoltre, quando un container registra JSON strutturato, anche i suoi campi vengono estratti in colonne.

Logo Docker
registro del contenitore del file jsondemone Docker
flussolivelloregistratoremessaggioospiteserviziodati
Logo Docker
esportazione dei log di DockerDocker CLI
messaggio
Logo del trasportatore
registro della console zerologPortatore
livellochiamantemessaggioerroredati

Ogni fila trasporta anche tempo_evento, il timestamp originale da cui è stato letto e il file da cui proviene. Ogni formato aggiunge la propria colonna identificativa: app per file json e Portainer, contenitore per un’esportazione; le righe json-file includono inoltre immagine, compose_project, servizio_di_composizione e container_id. Il singolo messaggio la colonna in un’esportazione è intenzionale: la riga originale del container viene conservata per intero, senza interpretazioni.

Ciò che questo deliberatamente non fa

Ciò che questo deliberatamente non fa

Non si tratta di un flusso di dati in tempo reale. Query Streams legge i file così come sono sul disco quando si esegue la query, quindi un ciclo di riavvio viene visualizzato come righe anziché come un flusso da monitorare. Se è necessario ricevere avvisi con una precisione inferiore al secondo su una riga durante la stampa, una pipeline di log è lo strumento più adatto.

L’output di un container è in formato libero, e c’è una conseguenza che vale la pena dichiarare chiaramente: nella tabella finisce tutto ciò che stampa l’applicazione. Se registra un token o l’indirizzo email di un cliente, quella stringa è già nel file di log e sarà presente anche nella colonna. Non esiste una mappatura delle intestazioni che consenta di escludere campi, come per i log di un server web: tratta la tabella risultante con la stessa cautela che useresti per il file.

Due limiti più piccoli, denominati anziché nascosti. Su un log di Docker nell’esportazione, la riga originale del container viene conservata per intero in un’unica messaggio colonna; la nuova analisi di quella riga interna secondo il suo formato specifico non è ancora implementata. Inoltre, gli attributi facoltativi che Docker può associare usando un tag di logging vengono riconosciuti solo in base alla loro struttura: nessun container nel corpus acquisito li utilizzava, quindi questo percorso è dichiarato ma non verificato.

Il resto segue il design standard. L'agente si connette in uscita e legge i file; nulla viene installato nel container, nulla viene scritto, il socket Docker e l'API non vengono mai utilizzati e l'accesso è in sola lettura. Il campo di conservazione predefinito è di 30 giorni per questa configurazione e può essere modificato dall'utente.

Dalla connessione a risultati utili.

  1. Installa il Network Agent sull’host del container, dove può accedere alla directory dei log del daemon.
  2. Indica al connettore di usare quella directory. Viene individuato il log json-file di ogni container; puoi restringere la selezione con dei pattern.
  3. L’Agent risale da ogni directory di 64 caratteri al container a cui appartiene — nome effettivo, immagine e servizio Compose — così le righe sono leggibili prima ancora di scrivere SQL.
  4. Ogni riga diventa una riga di dati, con il relativo stream (stdout o stderr) e il timestamp del daemon; vengono seguite anche le rotazioni, man mano che il daemon ruota i log.
  5. Esegui query sui log: errori di tutti i container in una volta sola, un singolo servizio isolato oppure un confronto prima e dopo un deploy.

Sfrutta i risultati di Container Logs.

Un’unica connessione serve i tuoi fogli di calcolo, le tue app e i tuoi strumenti di IA. Concedi l’autorizzazione a eseguire una query salvata; i destinatari vedono i risultati autorizzati, mentre l’SQL e le credenziali di accesso all’origine restano nascosti.

Per il tuo team, i fornitori e i partner

Container Logs in Excel

Importa direttamente in un foglio di lavoro i risultati aggiornati di Container Logs e aggiornarli quando vuoi: Excel desktop, Excel Online e Microsoft 365.

Scopri Excel

Container Logs in Data Viewer

Condividi i risultati aggiornati di Container Logs con chiunque — un collega, un fornitore o un partner — in una griglia accessibile tramite segnalibro, che esegue una nuova query all’apertura, da telefono, tablet o computer. Chi la apre vede i risultati, mai il codice SQL o i file.

Come funziona il visualizzatore di dati

Per app e sistemi

API REST dei log dei container

Pubblica una query di Container Logs come endpoint JSON autenticato, utilizzabile da qualsiasi applicazione, con una specifica OpenAPI 3.1 e raccolte Postman, Insomnia e Hoppscotch già pronte. Non viene aperta alcuna porta del database.

Esplora l’API REST

Container Logs in Power BI

Incolla il codice Power Query M generato nell’Editor avanzato di Power BI e il report leggerà in tempo reale i risultati di Container Logs tramite HTTPS: nessun driver ODBC e nessuna porta del database aperta.

Esplora Power BI

Per gli strumenti di intelligenza artificiale

Server MCP di Container Logs

Fornisci a un assistente AI accesso in sola lettura a Container Logs e allo schema necessario per scrivere query SQL corrette, senza inserire credenziali nella chat.

Esplora MCP

Consegnato alle persone

Unisci Container Logs al resto dei tuoi dati.

Riunisci database, API aziendali, file e log in un’unica query di sola lettura. Ogni connettore supporta le query federate.

Indica le connessioni e le tabelle. Query Streams gestisce le query alle origini e combina i risultati.

Esplora le query federate
Esempio illustrativo di query tra origini
-- niente copiato, niente unito, niente programmato
SELEZIONARE   c.region, COUNT(*) AS ordini, SUM(i.amount_due) AS fatturati
DA     containerlogs.fileset.orders1 f
CONGIUNGERE     pg_crm.clienti pubblici2      c ON c.id = f.customer_id
CONGIUNGERE     fatturazione.stripe.invoices3      i ON i.customer = c.stripe_id
GRUPPO PER c.regione
ORDINATO DA fatturata DESCRIZIONE;

Usa i nomi delle tue connessioni, schemi, tabelle e colonne.

Condiviso tra tutti i connettori della famiglia.

Ogni connettore di log fornisce anche

  • events: una riga per ogni riga analizzata, con il timestamp, i campi definiti dalla grammatica e _source_file, che indica il file di provenienza.
  • events_raw_lines: righe che non corrispondono alla grammatica, conservate così come sono anziché eliminate, per permetterti di rispondere comunque a domande su formati imprevisti.
  • files_current e files_events: l’inventario aggiornato e la traccia di controllo, che mostrano cosa è comparso, cosa è stato ruotato, cosa è scomparso e cosa è stato trattenuto, con il nome del file e il motivo.
  • La rotazione è compresa, non aggirata: dieci schemi di rotazione denominati, oltre ai file non ruotati, così il log di ieri e il relativo archivio compresso sono la stessa tabella di quello di oggi.

Buono a sapersi

  • Sola lettura, garantita: una sola istruzione alla volta, solo SELECT e simili. Non scriviamo, spostiamo, ruotiamo né tronchiamo mai i tuoi log.
  • Non viene caricato nulla: le righe vengono analizzate e memorizzate nella cache, in forma crittografata, sul tuo computer, accanto all’agent. Solo il risultato di una query esce dalla tua rete.
  • Vengono letti solo i nuovi byte: l’agent riprende da dove si era fermato in ciascun file invece di rileggerlo, così un log molto attivo non costa di più ogni giorno.
  • Il dialetto SQL è DuckDB: lo stesso SQL che useresti con qualsiasi altro connettore.

Domande su Container Logs

Dove posso usare i risultati delle query Container Logs?

Usa i risultati di Container Logs in Excel, Google Sheets e Data Viewer, nelle tue app tramite Database REST API e negli strumenti di IA tramite MCP o Nova. I risultati salvati alimentano anche le destinazioni di automazione, i report e gli avvisi supportati. La disponibilità delle destinazioni e i limiti dipendono dal tuo piano.

Devo aprire una porta in ingresso per Container Logs?

No. Installa Network Agent su una macchina che possa raggiungere Container Logs. L'agent si connette in uscita a Query Streams; non serve alcuna porta in ingresso né una VPN. L'origine deve comunque consentire alla macchina dell'agent di connettersi in base alle proprie regole di accesso.

I miei file Container Logs vengono caricati?

Network Agent legge i file dove si trovano e conserva la propria cache sulla macchina con l'agente. I file sorgente non vengono caricati, spostati né riscritti. Solo i risultati delle query richiesti escono dalla rete tramite la connessione crittografata in uscita.

Di cosa ho bisogno per connettere Container Logs?

Cartella: directory dei log del daemon sull'host del container oppure una cartella che contiene log esportati. Fonti: log Docker json-file, esportazioni di docker logs salvate e log del server di Portainer. Identità: nome del container, immagine e servizio Compose ricavati dal daemon, così le righe non sono identificate da un ID di 64 caratteri. Rotazione: seguita mentre il daemon ruota i log, oltre ai dieci schemi di rotazione con nome per i file esportati

Posso unire Container Logs ad altre origini connesse?

Sì. Le query federate supportano ogni tipo di connettore, inclusi database, API aziendali, file e log. Indica le connessioni e le tabelle in un’unica query di sola lettura. Query Streams traduce, quando necessario, le parti relative alle origini e combina i risultati. Scopri come funzionano le query federate.

Devo cambiare il driver di logging di Docker?

NO. file json è il driver predefinito di Docker ed è quello supportato. Se non hai mai configurato la registrazione dei log, i file sono già presenti e nel formato giusto.

Se sei passato a un driver diverso, log di docker --timestamps L'esportazione è il percorso di input: funziona indipendentemente dal driver, perché la CLI legge attraverso il demone.

Come fa a conoscere il nome del container e non solo il suo ID?

Docker scrive il proprio record di un container nella stessa cartella del log. Query Streams legge il nome da quel file e lo usa come colonna di identità, con l'immagine e il progetto e servizio Compose mantenuti come colonne accanto. L'ID della cartella di 64 caratteri viene mantenuto come container_id, quindi non si perde nulla.

Se il record manca, non è leggibile o non contiene un nome, viene usato il nome della cartella e l'analisi conta quante volte è successo: il fallback viene quindi mostrato come un numero che puoi controllare, non come una sostituzione silenziosa.

Utilizzo Docker Desktop per Windows o Mac. Funziona?

Non direttamente sui log in formato JSON. Docker Desktop li conserva all'interno della propria macchina virtuale e un agente in esecuzione come servizio sull'host non può accedervi.

La soluzione è il profilo di esportazione: docker logs --timestamps <container> reindirizzati a un file, in qualsiasi cartella che l’Agent possa leggere. È un formato supportato a tutti gli effetti, non un ripiego: è lo stesso metodo che si usa già per conservare una copia di un log dopo che un container è stato eliminato.

È in tempo reale?

È su richiesta, non in streaming. I file vengono letti così come sono quando viene eseguita la query, quindi le nuove righe compaiono man mano che i container le scrivono e il file viene rilevato: non secondo una pianificazione notturna fissa, ma neanche come flusso live.

Per porre una domanda relativa alle ultime settimane a tutti i contenitori e ottenere la risposta in un foglio di calcolo, questa è la forma utile e richiede molta meno attrezzatura rispetto a una catasta di tronchi.

Che ne dici di Kubernetes o Podman?

Nessuno dei due ha un profilo proprio al momento, e preferiamo dirlo piuttosto che sottintendere una copertura. Ciò che conta è il formato di esportazione: il profilo è associato alla forma esatta log di docker --timestamps scrive: un timestamp RFC 3339 con precisione al nanosecondo, uno spazio e poi la riga del container, un file per servizio. Gli strumenti che scrivono nello stesso formato possono leggerlo.

Il modo più affidabile per scoprirlo per i propri file è utilizzare il comando "Test connessione", che segnala ciò che ha rilevato prima di confermare qualsiasi operazione.

I miei container registrano file JSON. I loro campi vengono visualizzati come colonne?

Sì, per i log json-file. L'involucro del daemon viene rimosso e il JSON del container al suo interno viene suddiviso in colonne: level, logger, message, host e service, quando presenti. Tutto ciò che non corrisponde a una colonna denominata viene conservato in un dati colonna anziché essere scartata, in modo che un campo insolito sia comunque interrogabile.

L'unico dato non ricavato dal JSON del container è il timestamp. Proviene dal daemon, perché il timestamp dell'applicazione può essere in qualsiasi formato e interpretarlo in modo errato sposterebbe silenziosamente la riga nel tempo.

Che succede se il parser non riesce a leggere una riga?

Viene mantenuta, non eliminata. Una riga che non corrisponde al formato predefinito viene conservata come riga grezza con una motivazione allegata, in modo che una voce non valida o una modifica di formato imprevista risulti visibile e interrogabile, anziché come una lacuna silenziosa nei dati.

Usa Container Logs dove si svolge il lavoro.

Inizia con Free: ogni tipo di connettore, 2 origini dati e 1 Network Agent. Aggiungi le quote previste dal piano man mano che crescono le tue esigenze.

Ottieni il piano gratuitoConsulta le quote del piano