Build- és futásidejű naplók: Dockup-deployok hibakeresése

A build- és futásidejű naplók eltérő kérdésekre adnak választ. A build naplói azt mutatják meg, hogyan lett a forráskódból image, és miért hiúsult meg ez a folyamat. A futásidejű naplók pedig azt mutatják meg, mit csinált a buildelt alkalmazás a container vagy a Kubernetes workload elindulása után.

Ha nem a megfelelő streamet olvasod, időt pazarolsz. Egy image létrehozása közben fellépő hiányzó függőség soha nem jelenik meg a futásidejű naplókban, miközben egy sikeresen elkészült image induláskor összeomolhat teljesen hibamentes build kimenet mellett.

Mi a különbség a build- és a futásidejű naplók között?

A stream kiválasztásához azonosítsd a deployment fázisát:

Fázis	Tipikus állapot	Megfelelő napló	Gyakori hibák
Klónozás	cloning	Build	Repository-hozzáférés, branch
Függőségek telepítése	building	Build	Lockfile, registry, package
Fordítás/bundle készítése	building	Build	Típushibák, memória, hiányzó fájlok
Image indítása	deploying	Futásidejű és health	Indítási parancs, port, jogosultságok
Futó szolgáltatás	running	Futásidejű	Kivételek, függőségkiesések
Readiness gate	deploying	Futásidejű és health-konfiguráció	Hibás útvonal, lassú indulás

A legutóbbi build kimenetének lekérése:

dockup logs production/api --build --json

A futó szolgáltatás futásidejű kimenetének lekérése:

dockup logs production/api --json

Több futásidejű sor kérése, ha a releváns esemény régebben történt:

dockup logs production/api -n 500 --json

A JSON-válasz azonosítja a célt és a napló típusát, így egy agent elkerülheti a nem összetartozó streamek összevonását.

Hogyan működik a dockup logs --build --follow?

A follow mód az aktuális snapshot lekérdezésével streameli az új sorokat:

dockup logs production/api --build -f --json

JSON módban a kimenet NDJSON: soronként és batchenként egy objektumot tartalmaz. A fogyasztó minden sort inkrementálisan feldolgozhat.

Az utolsó batch jelzi a build végső eredményét. A parancs automatikusan leáll, amikor a deployment sikeresen befejeződik vagy meghiúsul, hiba esetén pedig nem nulla értékkel tér vissza. Ez alkalmassá teszi agentben vagy CI-feladatban való használatra kézzel írt állapotfigyelő ciklus nélkül.

A futásidejű follow hasonlóan működik:

dockup logs production/api -f --json

Minden batch tartalmazza a restarted mezőt. Ha restarted:true, akkor a container újraindult, vagy a megőrzött naplóbuffer újraindult, ezért a Dockup ismét elküldi a teljes aktuális snapshotot ahelyett, hogy csendben eldobná a sorokat.

Az alapértelmezett lekérdezési időköz 2 másodperc. A dokumentált --interval kapcsolót csak akkor használd, ha konkrét okból módosítani kell az ütemezést.

Hogyan diagnosztizálhatsz egy sikertelen buildet?

Kezdd a deployment végső eredményével:

dockup deploy production/api --wait --json

Ha a parancs deploy_failed állapottal lép ki, kérd le a build naplóját, és az első okot kiváltó hibát keresd meg, ne az utolsó, láncreakcióként megjelenő hibaüzenetet.

Hasznos lépéssor:

1. Ellenőrizd a célt és a deployment ID-ját.
2. Azonosítsd a klónozási, telepítési, fordítási vagy image-fázist.
3. Keresd meg az első nem újrapróbálható hibát.
4. Hasonlítsd össze a build-módszert a repository szándékával.
5. Ha lehet, reprodukáld a hibát tiszta klónból.
6. Végezz el egyetlen célzott módosítást.
7. Telepíts újra a --wait kapcsolóval.

A gyakori Nixpacks-hibák közé tartozik a projekt gyökerének felismerhetetlensége, a hiányzó lockfile, a hagyományos indítási script hiánya vagy egy natív package-függőség. A gyakori Dockerfile-hibák közé tartozik a hibás build context, a hiányzó bemásolt artifact, az elérhetetlen base image vagy egy sikertelen RUN utasítás.

A Nixpacks és Dockerfile összehasonlítása útmutató segít kiválasztani a buildrendszert.

Ne egy determinisztikus builderor javításaként növeld a 900 másodperces timeoutot. A timeout módosítása akkor segít, ha a build jogosan hosszú; egy hibával kilépő parancsot nem javít meg.

Hogyan diagnosztizálhatsz futásidejű összeomlást vagy health hibát?

Egy sikeresen elkészült image még a forgalom átváltása előtt is meghiúsulhat. Vizsgáld meg a szolgáltatás állapotát és a futásidejű kimenetet:

dockup status production/api --json
dockup logs production/api --json
dockup health production/api --json

Keresd az alábbiakat:

• A folyamat közvetlenül az indulás után leáll.
• Az alkalmazás rossz porthoz bindol.
• Az alkalmazás a 127.0.0.1 címen figyel minden interfész helyett.
• Hiányzik egy szükséges környezeti kulcs.
• Sikertelen a kapcsolat az adatbázishoz vagy a Redishez.
• A fájljogosultságok megakadályozzák az indulást.
• A health útvonal nem sikeres státuszt ad vissza.
• Az indulás tovább tart, mint amennyit a beállított retry-k engedélyeznek.
• Egy migration sikertelen, vagy párhuzamosan fut.

A health-konfiguráció lekérdezhető vagy frissíthető:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Ne gyengítsd a health gate-et pusztán azért, hogy egy hibás release átmenjen. Ha az indulásnak ténylegesen több időre van szüksége, bizonyíték alapján módosítsd a policy-t, és tarts meg egy olyan endpointot, amely továbbra is igazolja a readiness állapotát.

A környezeti módosítások újradeploymentet igényelnek. Ha javítottál egy hiányzó secretet, telepíts újra és várd meg a végét; a régi container újraindítása nem alkalmazza az új kívánt környezetet.

Hogyan dolgozzák fel az agentek az NDJSON-t a kilépési kód megőrzésével?

Egy agentnek vagy scriptnek minden JSON-sort be kell olvasnia a folyamat státuszának megőrzése mellett. Kerüld az olyan parancsba történő pipe-olást, amely pipefail nélkül elfedi az eredeti kilépési kódot.

set -o pipefail
dockup logs production/api --build -f --json \
  | tee build-stream.ndjson

A pipefail használatával egy sikertelen Dockup-parancs akkor is nem nulla státusszal zárja a pipe-ot, ha a tee sikeresen befejeződött.

A fogyasztó minden objektumot külön feldolgozhat:

while IFS= read -r line; do
  printf '%s\n' "$line" | jq -r '.lines[]?'
done < build-stream.ndjson

Őrizd meg a nyers NDJSON artifactot. Egy ember által olvasható kivonat hasznos lehet pull requestben vagy incidens esetén, de az eredeti mezők megőrzik az újraindítási jelzőket, az állapotot és a befejezési jeleket.

Az általános gépi interfész alapelveit az AI agent CLI-tervezés ismerteti.

Milyen egy megismételhető deployment-hibakeresési runbook?

Használd ezt a döntési folyamatot:

dockup status production/api --json
dockup deployments production/api -n 5 --json
dockup logs production/api --build --json
dockup logs production/api --json

Ezután sorold be az incidenst:

Besorolás	Bizonyíték	Következő művelet
Forráskód/build	Hiba a build naplójában	Javítsd a repositoryt vagy a build definícióját
Konfiguráció	Hiányzó/hibás env vagy port	Javítsd a konfigurációt, majd telepíts újra
Readiness	Az alkalmazás fut, a health sikertelen	Javítsd az endpointot vagy indokolt esetben az időzítést
Futásidejű függőség	Kapcsolati kivétel	Ellenőrizd az adatbázist/hálózatot/credentialt
Regresszió	Az előző verzió működött	Fontold meg egy ismert ID-val történő rollbacket
Platformbizonytalanság	Timeout, nincs végső állapot	Újrapróbálás előtt vizsgáld meg az állapotot

Csak egy ismert korábbi deployment azonosítása után rollbackelj:

dockup rollback <deploymentId> production/api --json

Először őrizd meg a sikertelen deployment ID-ját és a naplókat. A rollback helyreállítja a szolgáltatás elérhetőségét, de nem magyarázza meg a kiváltó okot.

A zero-downtime deploymentekről szóló cikk bemutatja, miért védheti a live forgalmat egy sikertelen readiness gate.

Hogyan tehetők hasznossá az éles környezet naplói?

A Dockup le tudja kérni a kimenetet, de a naplók minőségét az alkalmazás szabályozza. Részesítsd előnyben az időbélyeggel, súlyossággal, request- vagy trace ID-val, komponensnévvel és biztonságos hibaleírással ellátott, strukturált, egyetlen eseményt tartalmazó rekordokat.

Soha ne naplózz access tokent, adatbázis-URL-t, jelszavakat, teljes authorization headereket vagy a működéshez nem szükséges személyes adatokat. A Dockup konfigurációjában beállított secret masking nem maszkolja az alkalmazás tetszőleges kimenetét.

Naplózd azokat az indulási információkat, amelyek biztonságosak és diagnosztizálhatók:

• Az alkalmazás verziója vagy a commit.
• A környezet neve.
• A figyelt port.
• Az engedélyezett feature-nevek secret értékek nélkül.
• Az adatbázis hostosztálya, a jelszó nélkül.
• A migration verziója.
• A health endpoint readiness állapota.

Incidens-idővonal sablonja

Rögzítsd az alábbiakat:

1. Deployment ID és forrás commit.
2. A deploy kezdési és végső időbélyege.
3. Az első kiváltó build- vagy futásidejű hiba.
4. A health gate eredménye.
5. A helyreállítási parancs és a deployment ID.
6. A felhasználói hatás időablaka.
7. A nyomon követésért felelős személy.

Az uptime-adatok perces pontosságú rendelkezésre állást és válaszidőt adnak:

dockup uptime production/api --hours 24 --json

Az eredmény tartalmazza az átlagos és a p95 válaszidőt. Kombináld a build- és futásidejű naplókkal, hogy megkülönböztesd a deployment-incidenst egy hosszabb ideje fennálló teljesítményregressziótól.

A jelenlegi naplókapcsolókért használd a Dockup CLI-referenciát, a biztonságos alkalmazásnaplózásról pedig olvasd el a biztonsági ajánlott gyakorlatokat.

Naplók összekapcsolása a deploymentelőzményekkel

Egy sor csak akkor hasznos, ha a megfelelő release-hez köthető. A deployment ID-ját, a commit hash-t és a kezdési időt a naplóartifact mellett tárold. Ha két release rövid időn belül követi egymást, az időbélyegek önmagukban félrevezetők lehetnek.

dockup deployments production/api -n 20 --json

A deploymentelőzmények megmutatják, melyik forrás volt aktív, és melyik release jutott el végső állapotba. Egy agent ne tulajdonítson futásidejű kivételt a legutóbbi commitnak, amíg a szolgáltatás állapota meg nem erősíti, hogy az a commit valóban telepítve lett.

A secret-ek naplók általi kiszivárgásának elkerülése

Egy sikertelen kapcsolat gyakran arra csábítja a fejlesztőket, hogy kiírják a teljes URL-t. Ehelyett naplózd a protokollt, a maszkolt hostot, az adatbázis nevét és a hiba kategóriáját. Tokenek esetén csak a tárolás előtt létrehozott biztonságos fingerprintet naplózd, ha erre a szervezetnek van megfelelő policy-je.

A sikertelen build-artifactokat ellenőrizd, mielőtt megosztanád őket a csapaton kívül. A package manager és a Docker kimenete privát repository-URL-eket, registry-felhasználóneveket vagy parancsargumentumokat is tartalmazhat akkor is, ha a Dockup megfelelően maszkolja a tárolt környezeti secret-eket.

Így a build- és futásidejű naplók elég biztonságosak lesznek a közös diagnosztizáláshoz.

Minimális bizonyítékcsomag megőrzése

Minden sikertelen release esetén mentsd el a deployment eredményének JSON-ját, a build naplóját, a releváns futásidejű kivonatot, a szolgáltatás állapotát és a kiválasztott helyreállítási deployment ID-ját. Ez a csomag elég kicsi a rutinszerű használathoz, ugyanakkor elegendő ahhoz, hogy egy második operátor bizonytalan mutációk újrafuttatása nélkül folytathassa a vizsgálatot.

A javítás ellenőrzése, nem csak az új buildé

Miután a javított deployment sikeresen befejeződött, ismételd meg a hibát okozó kérést vagy indítási feltételt, és figyeld a futásidejű kimenetet, hogy nem tér-e vissza a probléma. Csak akkor zárd le az incidenst, ha az eredeti tünet eltűnt, a health gate átment, és a várt éles működés megfigyelhető.

A folyamat lezárása

Dokumentáld az ellenőrzött javítást.

Kezdd ellenőrizhető deploymenttel

Kényszeríts ki egy tesztbuild-hibát, mentsd el az NDJSON-streamet és a kilépési kódot, majd ellenőrizd, hogy a runbook a futásidejű napló helyett a build naplóját választja.

Kezdd ingyen az app.dockup.ai oldalon. A Free csomag havi 0 $, 10 $ kezdő kreditet tartalmaz, és egy workspace-t, három adatbázist, valamint három deploymentet támogat.

GYIK

Mi a különbség a Dockup build- és futásidejű naplói között?

A build naplói a klónozást, a függőségek telepítését, a fordítást és az image létrehozását fedik le. A futásidejű naplók az elindított alkalmazás containereiről vagy podjairól szólnak.

Hogyan követhetem élőben a Dockup build naplóit?

Használd a dockup logs parancsot a --build és --follow, illetve a -f kapcsolóval. A --json kapcsolóval a parancs NDJSON-batcheket küld, és a deployment végső állapotánál fejeződik be.

Miért lép ki nem nulla értékkel a build follow?

Megőrzi a deployment eredményét. Egy sikertelen buildnek sikertelenné kell tennie a hívó shellt, CI-feladatot vagy agent-feladatot, ahelyett hogy sikeres naplóstreamnek tűnne.

Mit jelent a restarted:true a runtime follow kimenetében?

Azt jelzi, hogy a container újraindult, vagy a megőrzött buffer újraindult, ezért a Dockup ismét elküldte az aktuális snapshotot ahelyett, hogy csendben elveszítette volna a sorokat.

Tartalmazhatnak az alkalmazás naplói környezeti secret-eket?

Nem. A Dockup maszkolja a tárolt konfiguráció lekéréseit, de nem tudja biztonságossá tenni az alkalmazás által kiírt tetszőleges secret-eket. A credentialöket az alkalmazás naplózási rétegében maszkolással védd.