Bygg- og runtime-logger: Feilsøk Dockup-deployeringer

Bygg- og runtime-logger svarer på forskjellige spørsmål. Bygg-logger forklarer hvordan kildekode ble til et image, og hvorfor prosessen eventuelt mislyktes. Runtime-logger forklarer hva den bygde applikasjonen gjorde etter at containeren eller Kubernetes-workloaden startet.

Det er tidkrevende å lese feil loggstrøm. En manglende dependency under byggingen av et image vil aldri vises i runtime-logger, mens et image som er bygget uten feil, men krasjer ved oppstart, kan ha helt feilfrie bygg-logger.

Hva er forskjellen mellom bygg- og runtime-logger?

Bruk deployeringsstadiet til å velge riktig strøm:

Stadie	Typisk status	Riktig logg	Vanlige feil
Kloning	cloning	Bygg	Tilgang til repository, branch
Installasjon av dependencies	building	Bygg	Lockfile, registry, package
Kompilering/bundling	building	Bygg	Typefeil, minne, manglende filer
Oppstart av image	deploying	Runtime og health	Startkommando, port, tillatelser
Kjørende tjeneste	running	Runtime	Exceptions, bortfall av dependencies
Readiness-gate	deploying	Runtime pluss health-konfigurasjon	Feil path, treg oppstart

Les den nyeste bygg-outputen:

dockup logs production/api --build --json

Les runtime-output fra den kjørende tjenesten:

dockup logs production/api --json

Hent flere runtime-linjer når den relevante hendelsen ligger lenger tilbake:

dockup logs production/api -n 500 --json

JSON-responsen identifiserer mål og loggtype, slik at en agent unngår å slå sammen irrelevante strømmer.

Hvordan fungerer dockup logs --build --follow?

Follow-modus strømmer nye linjer ved å hente det gjeldende øyeblikksbildet med jevne mellomrom:

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

I JSON-modus er outputen NDJSON: ett objekt per linje og per batch. En konsument kan behandle hver linje trinnvis.

En siste batch markerer det endelige byggresultatet. Kommandoen stopper automatisk når deployeringen lykkes eller mislykkes, og avslutter med en non-zero exit-kode ved feil. Dette gjør den egnet for en agent eller CI-jobb uten en egendefinert statusloop.

Runtime follow fungerer på samme måte:

dockup logs production/api -f --json

Hver batch inkluderer restarted. Når restarted:true, har containeren startet på nytt eller den lagrede loggbufferen blitt rullet, slik at Dockup sender hele det gjeldende øyeblikksbildet på nytt i stedet for å forkaste linjer i stillhet.

Standardintervallet for polling er 2 sekunder. Bruk den dokumenterte --interval bare når det finnes et konkret behov for å endre frekvensen.

Hvordan diagnostiserer du et mislykket bygg?

Start med det endelige deployeringsresultatet:

dockup deploy production/api --wait --json

Når kommandoen avsluttes med deploy_failed, henter du byggloggen og finner den første årsaksgivende feilen – ikke den siste følgefeilen.

En nyttig fremgangsmåte er:

1. Bekreft mål og deployerings-ID.
2. Identifiser clone-, installasjons-, kompilering- eller imagestadiet.
3. Finn den første feilen som ikke kan løses med en retry.
4. Sammenlign byggmetoden med hensikten i repositoryet.
5. Gjenskap problemet fra en ren clone hvis mulig.
6. Gjør én målrettet endring.
7. Deploy på nytt med --wait.

Vanlige Nixpacks-feil inkluderer en prosjektrot som ikke gjenkjennes, manglende lockfile, manglende konvensjonelt startscript eller krav om en native package. Vanlige Dockerfile-feil inkluderer feil build context, manglende kopiert artifact, utilgjengelig base image eller en feilende RUN-instruksjon.

Guiden Nixpacks vs Dockerfile gir en beslutningsoversikt for byggsystemer.

Unngå å løse en deterministisk byggfeil ved å øke timeouten på 900 sekunder. En timeout-endring hjelper ved et legitimt langt bygg; den reparerer ikke en kommando som avsluttet med en feil.

Hvordan diagnostiserer du en runtime-krasj eller health-feil?

Et vellykket image kan fortsatt feile før trafikken flyttes over. Inspiser tjenestestatus og runtime-output:

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

Se etter:

• Prosessen avsluttes umiddelbart etter oppstart.
• Applikasjonen binder feil port.
• Applikasjonen lytter på 127.0.0.1 i stedet for alle interfaces.
• En nødvendig environment-nøkkel mangler.
• Tilkoblingen til databasen eller Redis mislykkes.
• Filtillatelser blokkerer oppstart.
• Health-pathen returnerer en status som ikke indikerer suksess.
• Oppstarten tar lengre tid enn det konfigurerte antallet retries tillater.
• En migration mislykkes eller kjører samtidig med en annen.

Health-konfigurasjonen kan inspiseres eller oppdateres:

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

Ikke svekk health-gaten bare for å få en ødelagt release gjennom. Hvis oppstarten legitimt trenger mer tid, endrer du policyen basert på dokumentasjon og beholder et endpoint som fortsatt bekrefter readiness.

Endringer i environment krever ny deployering. Hvis en manglende secret er rettet, deployerer du på nytt og venter; en restart av den gamle containeren tar ikke i bruk det nye ønskede miljøet.

Hvordan bør agenter parse NDJSON uten å miste exit-koden?

En agent eller et script bør lese hver JSON-linje samtidig som prosessstatusen bevares. Unngå å pipe til en kommando som skjuler den opprinnelige exit-koden uten pipefail.

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

Med pipefail forblir en feilet Dockup-kommando non-zero, selv om tee fullføres uten feil.

En konsument kan inspisere hvert objekt separat:

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

Ta vare på det rå NDJSON-artefaktet. Et lesbart utdrag er nyttig i en pull request eller en incident, men originalfeltene bevarer restart-markører, status og signaler om fullføring.

De generelle prinsippene for maskinelle grensesnitt er forklart i AI agent CLI design.

Hva er en repeterbar runbook for feilsøking av deployeringer?

Bruk denne beslutningsflyten:

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

Klassifiser deretter incidenten:

Klassifisering	Dokumentasjon	Neste handling
Kildekode/bygg	Feil i byggloggen	Rett repositoryet eller byggdefinisjonen
Konfigurasjon	Manglende/feil environment eller port	Rett konfigurasjonen og deployer på nytt
Readiness	Appen kjører, men health feiler	Rett endpointet eller begrunn tidsinnstillingen
Runtime-dependency	Connection exception	Kontroller database, nettverk og credentials
Regresjon	Forrige versjon fungerte	Vurder rollback til kjent ID
Plattformusikkerhet	Timeout, ingen endelig status	Inspiser status før du prøver på nytt

Rull bare tilbake etter at du har identifisert en kjent tidligere deployering:

dockup rollback <deploymentId> production/api --json

Ta først vare på ID-en og loggene fra den feilende deployeringen. En rollback gjenoppretter tilgjengeligheten til tjenesten; den forklarer ikke rotårsaken.

Artikkelen om zero-downtime-deployeringer forklarer hvorfor en feilende readiness-gate kan beskytte live-trafikk.

Hvordan gjør du produksjonslogger nyttige?

Dockup kan hente output, men det er applikasjonen som styrer loggkvaliteten. Foretrekk strukturerte poster med én hendelse per post, tidsstempel, alvorlighetsgrad, request- eller trace-ID-er, komponentnavn og en trygg feilbeskrivelse.

Logg aldri access tokens, database-URL-er, passord, komplette authorization headers eller personopplysninger som ikke er nødvendige for driften. Secret masking i Dockup-konfigurasjonen redigerer ikke vilkårlig output fra applikasjonen.

Logg oppstartsinformasjon som er trygg og egnet for diagnostisering:

• Applikasjonsversjon eller commit.
• Miljønavn.
• Lytteport.
• Aktiverte feature-navn uten secret-verdier.
• Database-klasse for hosten, ikke passordet.
• Migration-versjon.
• Readiness for health-endpointet.

Mal for incident-tidslinje

Registrer:

1. Deployeringens ID og kildecommit.
2. Tidspunkt for deployeringsstart og endelig status.
3. Den første årsaksgivende bygg- eller runtime-feilen.
4. Resultatet fra health-gaten.
5. Recovery-kommando og deployerings-ID.
6. Tidsrommet med brukerberørte.
7. Ansvarlig for oppfølging.

Uptime-data gir tilgjengelighet og responstid på minuttnivå:

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

Resultatet inkluderer gjennomsnittlig responstid og p95-responstid. Kombiner dette med bygg- og runtime-logger for å skille en deployeringsincident fra en lengre ytelsesregresjon.

Bruk Dockup CLI-referansen for gjeldende loggflagg og beste praksis for sikkerhet for trygg logging av applikasjoner.

Korreler logger med deployeringshistorikk

En linje er bare nyttig når den kan knyttes til riktig release. Lagre deployerings-ID, commit-hash og starttidspunkt sammen med loggartefaktet. Når to releaser skjer tett etter hverandre, kan tidsstempler alene være misvisende.

dockup deployments production/api -n 20 --json

Deployeringhistorikken viser hvilken kilde som var aktiv, og hvilken release som nådde en endelig status. En agent bør ikke knytte en runtime-exception til den nyeste commiten før tjenestestatusen bekrefter at commiten faktisk ble deployert.

Unngå at logger eksponerer secrets

En mislykket tilkobling kan friste utviklere til å skrive ut hele URL-en. Logg i stedet protokoll, maskert host, databasenavn og feilkategori. For tokens logger du bare et trygt fingerprint som ble generert før lagring, når organisasjonen har en policy for dette.

Gå gjennom artefakter fra feilende bygg før du deler dem utenfor teamet. Output fra package-managere og Docker kan inneholde private repository-URL-er, registry-brukernavn eller kommandoargumenter, selv når Dockup maskerer lagrede environment-secrets korrekt.

Dette gjør bygg- og runtime-logger trygge nok for samarbeidende diagnostisering.

Bevar en minimal dokumentasjonspakke

For hver feilende release lagrer du JSON-resultatet fra deployeringen, byggloggen, et relevant runtime-utdrag, tjenestestatus og den valgte recovery-deployerings-ID-en. Denne pakken er liten nok til rutinemessig bruk og komplett nok til at en annen operatør kan fortsette uten å kjøre usikre mutasjoner på nytt.

Bekreft rettingen, ikke bare det nye bygget

Når den korrigerte deployeringen er vellykket, gjentar du forespørselen eller oppstartsforholdet som feilet, og følger med på runtime-output for å se om problemet kommer tilbake. Avslutt incidenten først når det opprinnelige symptomet er borte, health-gaten passerer og forventet produksjonsatferd er observert.

Lukk loopen

Dokumenter den verifiserte rettingen.

Start med en verifiserbar deployering

Tving ett testbygg til å feile, fang opp NDJSON-strømmen og exit-koden, og kontroller deretter at runbooken velger byggloggen i stedet for runtime-loggen.

Start gratis på app.dockup.ai. Free-planen koster $0 per måned, inkluderer $10 i startkreditt og støtter ett workspace, tre databaser og tre deployeringer.

FAQ

Hva er forskjellen mellom Dockup-bygglogger og runtime-logger?

Bygglogger dekker kloning, installasjon av dependencies, kompilering og opprettelse av image. Runtime-logger dekker den startede applikasjonscontaineren eller pods.

Hvordan følger jeg Dockup-bygglogger live?

Bruk dockup logs med --build og --follow, eller -f. Med --json sender kommandoen ut NDJSON-batcher og avsluttes når deployeringen når endelig status.

Hvorfor avsluttes build follow med non-zero?

Kommandoen bevarer deployeringsresultatet. Et mislykket bygg må feile i det kallende skallet, CI-jobben eller agentoppgaven, i stedet for å se ut som en vellykket loggstrøm.

Hva betyr restarted:true i output fra runtime follow?

Det betyr at containeren startet på nytt eller at den lagrede bufferen ble rullet, slik at Dockup sendte det gjeldende øyeblikksbildet på nytt i stedet for å miste linjer i stillhet.

Bør applikasjonslogger inneholde environment-secrets?

Nei. Dockup maskerer lesing av lagret konfigurasjon, men kan ikke gjøre vilkårlige secrets som applikasjonen skriver ut, trygge. Rediger credentials i applikasjonens logginglag.