Gebruik LogBrew Swift 0.1.6 of later. Gebruik voor het uploaden van
debugartefacten de native LogBrew CLI 0.1.24 of later.
De vastlegging plannen
Controleer wanneer je app elk type fout via replay kan versturen.
Stel de releasewaarde in vóór de build. Die moet de appversie en de build
aanduiden. Gebruik dezelfde waarde in de SDK, bij de dSYM-upload en in het
issuefilter.
Voeg geen gebruikerspayloads, request-body’s of headers toe aan crashmetadata.
Het crashproduct toevoegen
Volg eerst SDK-integratie om SDK-telemetrie voor je app in te stellen. Replay gebruikt dieclient en transport.
Voeg de openbare SDK toe via Swift Package Manager.
LogBrew toe om telemetrie te versturen. Voeg LogBrewCrash
alleen toe als de app het vastleggen van native crashes of vastlopers
expliciet inschakelt.
De capture-integratie ondersteunt iOS 15 of later. Gebruik één
capture-object dat de app zelf beheert, want native handlers voor fatale
fouten gelden voor het hele proces.
Eén exacte identiteit configureren
Gebruik hetzelfde project, dezelfde release, dezelfde omgeving en dezelfde service bij het instellen van de runtime en bij het uploaden van artefacten. LogBrew leidt deze waarden niet af en vervangt ze niet.NativeCrashConfiguration heeft twee optionele limieten:
Bij een waarde buiten het bereik gooit de configuratie
crash_invalid_configuration.
Het vastleggen van vastlopers inschakelen
Het vastleggen van vastlopers staat uit alswatchdog nil is. Vervang de
declaratie van watchdog hierboven om het in te schakelen. Doe dat voordat je
install() aanroept:
artifactIdentity. Zonder die waarde gooit de configuratie
crash_invalid_configuration.
Gebruik één crashCapture-object zolang het proces draait. Een tweede
capture-object kan niet worden geïnstalleerd. De aanroep van install() gooit dan
crash_capture_owned. Wil je de drempel wijzigen, gebruik dan de nieuwe
waarde bij de volgende start van de app.
Een herstelde vastloper wordt via replay verstuurd met crash.handled op
true. Een vastloper die nog liep toen het proces werd beëindigd, wordt
verstuurd met crash.handled op false.
Beide vormen bevatten numerieke durationMs-metadata. Ze behouden dezelfde
artefactidentiteit als de frames van fatale crashes.
De watchdog pauzeert als de app inactief is of onder een debugger draait. Bij
ernstige thermische belasting legt hij ook niets vast.
Een korte drempel kan normaal werk op de hoofdthread als vastloper melden.
Test de drempel met de buildconfiguratie die je uitbrengt. De afgehandelde
status beschrijft het herstel. Die markeert het issue niet als opgelost. Een
afgehandelde vastloper heeft de interface toch geblokkeerd, dus bekijk die
ook.
Replay na het opstarten
Installeer eerst de vastlegging. Verstuur daarna openstaande rapporten met replay via je SDK-client.maxReplayBytes. Controleer alle drie de aantallen. Nul openstaande
rapporten bewijst op zichzelf geen aflevering.
Schakel persistente aflevering in vóór replay als een mislukt request nog een
herstart moet overleven. Roep purge() niet aan bij gewoon herstel van
netwerk of authenticatie.
De bijbehorende dSYM uploaden
Archiveer de app met ingeschakelde debuginformatie. Bewaar de dSYM van precies de build die gebruikers draaien. Bekijk de image-UUID’s ervan.--expect-image-uuid voor elke vereiste architectuur. De opdracht
mislukt als de gevonden set UUID’s afwijkt van de verwachte set.
Controleer de toegang tot je account. Voer daarna dezelfde opdracht uit
zonder --dry-run.
status in de JSON toont het resultaat:
Een buildmachine kan uploaden met een artefactsleutel van het project in
LOGBREW_TOKEN, in plaats van met accounttoegang. Maak de sleutel zoals
beschreven in
Een artefactsleutel maken.
Die upload meldt uploaded. Verifieer elke identiteit later met
accounttoegang:
status: "found" bevestigt het artefact. status: "missing" betekent dat
LogBrew geen artefact voor die identiteit heeft.
Frames worden herleid op basis van de image-UUID en de volledige
artefactidentiteit, niet op basis van de naam van het bronbestand. Een nieuwe
build van dezelfde broncode kan andere UUID’s hebben. Upload precies de
dSYM-bundel, niet een hele buildmap.
Controleren wat LogBrew teruggeeft
Filter de issuelijst met dezelfde runtime-scope. Dit voorbeeld selecteertunresolved issues. Een opgelost of gearchiveerd issue verschijnt niet.
symbolication-object toe. Dit voorbeeld toont
geselecteerde velden van een issue met een herleid frame, niet de volledige
response.
Crashbewijs lezen
Elk frame heeft een eigenstatus. Het veld symbolication.status gebruikt
dezelfde waarden:
Noteer een niet-herleid frame in je notities ook als niet-herleid. Meld het
niet als een lege stack.
LogBrew herleidt frames wanneer je het issue leest. Een later geüploade dSYM
kan frames van een eerder event herleiden. Hij kan geen frames toevoegen die
het event niet heeft vastgelegd.
Een applicatieframe beperkt de zoektocht in de code, maar bewijst de
oorzaak niet. Lees het issueonderzoek voor breadcrumbs, de exceptionketen en
tracebewijs:
source: "symbolicated" uit een geüpload
artefact. Een frame met source: "captured" is de locatie die de app
verstuurde. Zie Een issue onderzoeken voor
de responsevelden.
Houd bij elke leesactie de volledige scope van project, release, omgeving en
service aan. Verbreed een mislukte zoekactie niet naar andere projecten.
De productie-installatie verifiëren
Gebruik een goedgekeurde testfout in de gedeployde build. Gebruik nooit een actie van een klant als trigger. Controleer elk punt op volgorde en stop bij de eerste fout:- De runtime-identiteit komt overeen met de identiteit van het geüploade artefact.
- Een latere start verstuurt via replay één bevestigd event, met nul weggegooide en nul openstaande rapporten.
- De afgebakende issuelijst geeft het testissue terug met de verwachte afgehandelde status.
- Het verwachte applicatieframe wordt herleid.
- Een latere schone start voegt geen nieuw voorval toe.
Veilig herstellen
Gebruik voor algemeen issueonderzoek
Een issue onderzoeken met de API.
