Skip to main content
Deze pagina toont één voorbeeld voor elk type response van de Telemetrie-API. Alle waarden zijn fictief. Zie API-fouten voor foutcodes en herstel.

Een response lezen

Lees elke response in deze volgorde:
  1. Lees de HTTP-status.
  2. Controleer of de body de vorm heeft die bij de route hoort.
  3. Controleer of elk project_id binnen de gevraagde projectscope valt.
  4. Laat canonieke enumwaarden en ID’s ongewijzigd.
  5. Volg next_action alleen als de client de bijbehorende code en target ondersteunt.
  6. Behandel null, een weggelaten veld en een lege lijst als verschillende toestanden.
Een 200 OK kan een lege lijst bevatten. Een lege loglijst betekent dat geen enkele log bij het request paste. Dat betekent niet dat issues, traces of acties ook leeg zijn. Koppel signalen niet omdat hun tijdstempels dicht bij elkaar liggen. Volg een trace alleen als de response het exacte trace_id ervan bevat. Een 404 en een lege lijst zijn verschillende resultaten. Een lijstroute geeft [] terug als geen enkel record overeenkomt. Een detailroute geeft 404 met code: not_found terug als die geen leesbaar record vindt. Geen van beide resultaten bewijst dat de opname is mislukt.

Wat je verstuurt

Een response is maar zo nuttig als de telemetrie die je verstuurt. Stuur deze waarden mee in elke envelop of SDK-installatie:
  • release en environment.
  • Vaste namen voor services, acties en metrics.
  • Tracecontext als logs, spans, acties en issues bij hetzelfde request horen.
  • Canonieke ernstwaarden: info, warning, error en critical.
  • Attributen die helpen bij debuggen, zonder geheimen of onnodige persoonsgegevens.
Zie SDK-integratie en Vastgelegde gegevens beheren.

Response van de ingest-API

De openbare SDK’s lezen de response van POST /v1/events voor je. Je applicatiecode hoeft die niet af te handelen.

Response op een SDK-batch

Een geslaagde SDK-batch geeft 200 OK terug met de geaccepteerde aantallen per stroom:
De aantallen gelden alleen voor deze batch. Stuur je een batch opnieuw die LogBrew al accepteerde, dan krijg je 0 voor elke stroom en het aantal events in already_accepted. Houd de oorspronkelijke event-ID’s aan als je het opnieuw probeert.

Response op een native envelop

POST /api/telemetry/ingest geeft 200 OK terug met het aantal geaccepteerde items per stroom:
De native response heeft geen veld metrics of context_updated. Voeg ze niet toe. already_accepted telt items waarvan LogBrew de id eerder al voor het project accepteerde. Zie de directe native envelop.

Opnamefouten

Een 401 met code: ingest_key_invalid betekent dat de ingest-bearer is ingetrokken, verlopen of niet geldig is voor het project. Op POST /v1/events geeft een ontbrekende bearer, of een bearer die geen ingest-sleutel is, 401 met code: unauthorized. Gebruik de huidige projectgebonden ingest-bearer. Probeer het niet opnieuw met een account-bearer. Een geweigerde SDK-batch geeft 422 met code: validation_failed:
Andere waarden van error zijn onder meer SDK event batch requires at least one event en SDK event type is not supported by this ingest route. Controleer de SDK-versie en de transportconfiguratie. Stuur geen lege batch. Wijzig geen eventtypes of ID’s alleen om een batch door de validatie te krijgen. Een request met een andere methode dan POST geeft 405 met code: method_not_allowed. Een onleesbare JSON-body geeft code: invalid_json.

Responseformaat van telemetrielijsten

Lijstroutes geven standaard een gewone JSON-array terug. Een geslaagde lege lijst is []. Met pagination=cursor geeft de route een envelop terug. De collectiesleutel hoort bij het signaal: next_cursor is een object met de velden om verder te lezen, of null op de laatste pagina. Rijen staan van nieuw naar oud. Zie cursorpaginering.

Logresponse

Een cursorpagina met logs en limit=1:
Logs bevatten level voor compatibiliteit en severity voor weergave. Beide bevatten de canonieke waarde. triage bevat het resultaat van een ernstregel. Zie responses van ernstregels. trace_id en span_id zijn null als de log geen tracekoppeling heeft. Dan is next_action gelijk aan inspect_related_logs met als doel telemetry_logs. Logs, issues en acties gebruiken dezelfde 2 paren voor next_action. GET /api/logs/{log_id} geeft één log terug in dezelfde vorm.

Issueresponse

GET /api/telemetry/issues/{issue_id} geeft één gegroepeerd issue terug. De lijst geeft dezelfde objecten terug. Dit voorbeeld gebruikt de standaardversie 1 van de response:
In versie 1 is status gelijk aan unresolved, resolved of ignored. Voor een gearchiveerd issue is triage.ignored gelijk aan true. Zie Een issue onderzoeken voor de paren van next_action en de leesacties die erop volgen. first_seen_at en last_seen_at zijn de tijdstippen van het eerste en het meest recente voorval. Ze veranderen niet als de status verandert. Sommige velden verschijnen alleen als LogBrew de gegevens heeft: symbolication.status is resolved, invalid_metadata, artifact_not_found, source_not_resolved of unavailable. De lijst, statuswijzigingen en regelwijzigingen geven geen symbolication terug. Met response_version=2 heeft het issue dezelfde velden, met deze wijzigingen:
Dit voorbeeld toont maar een deel van de velden. Een afgeleide prioriteit is high voor error en critical, medium voor warning en low voor info. Die prioriteit gebruikt triage.effective_severity, dus een ernstregel voor het issue kan die veranderen. Met response_version=3 heeft het issue alle velden van versie 2 en assignee. assignee is null als het issue aan niemand is toegewezen:
Een issue toont geen toewijzing als het toegewezen lid het project niet meer kan lezen. Met response_version=4 heeft assignee ook type. Een toewijzing aan een account (user) heeft user_id, name en email, zoals in versie 3. Een toewijzing aan een team (team) heeft team_id, slug en name. Versie 3 toont een toewijzing aan een team als null. De CLI vraagt versie 4 op:
Elke andere response_version geeft 422 met code: validation_failed. Een cursorpagina gebruikt dezelfde versie voor elk issue in issues.

Response met toewijsbare accounts en teams

GET /api/telemetry/issues/assignees?project_id=<project_id> geeft elk account terug waaraan je issues in het project kunt toewijzen:
Voeg response_version=2 toe om ook teams te krijgen: elk team van de organisatie van het project, met team_id, slug en name. Als het account het project niet kan lezen, geeft de route 404 met code: not_found.

Actieresponse

distinct_id volgt één actor of sessie. Behandel distinct_id en session_id als ondoorzichtige ID’s. session_id en trace_id zijn null als ze ontbreken. span_id ontbreekt als er geen waarde is. Een actie heeft geen ernst. Zie Productevents vastleggen.

Metricresponse

Elk item is één meting. Gebruik het aantal metingen niet als aantal events of gebruikers. unit, temporality, trace_id en span_id zijn null als ze ontbreken. Een waarde null is geen nul.

Releaseresponse

Eén rij gaat over één project, release, omgeving en service. De aantallen beschrijven alleen die rij. trace_health.status is unknown als de rij geen traces heeft, en anders no_errors_observed of errors_observed. error_rate_basis_points is het aandeel traces met een foutspan, van 0 tot 10000. Het is geen foutpercentage voor alle requests. next_action wijst naar het eerste signaaltype met gegevens, in deze volgorde: Zie Releases.

Response bij het zoeken naar traces

GET /api/telemetry/traces?pagination=cursor geeft één rij per trace terug, plus een overzicht in naming_quality voor de teruggegeven pagina:
naming_quality gaat alleen over de teruggegeven pagina. Het is geen score voor het hele account. truncated: true betekent dat er nog een pagina is. Als de pagina een generieke naam, een niet-herkende route of een generieke bewerking bevat, is next_action gelijk aan improve_trace_naming met als doel sdk_configuration. Zonder pagination=cursor geeft de route een gewone array van traces terug, zonder naming_quality. next_cursor bevat time en trace_id. Stuur ze als cursor_time en cursor_trace_id. GET /api/telemetry/traces/{trace_id} geeft de spans van één trace terug. GET /api/telemetry/traces/{trace_id}/summary geeft de rootspan, de foutspans, de services, de duur en het traagste pad terug, zonder ruwe spanattributen. Een 404 op de samenvatting betekent dat geen enkele trace bij de volledige scope paste. Probeer het niet opnieuw zonder de filters. Zie responses voor trace-spans en samenvattingen.

Lege lijsten en ontbrekende records

Een lijst lezen kan nul resultaten opleveren. Voor het lezen van één record geldt een ander contract: Een ontbrekende log geeft deze 404:
Een ontbrekend issue gebruikt "error": "issue not found". Een ontbrekende tracesamenvatting gebruikt "error": "trace not found". Een onbekend ID en een ID dat het account niet kan lezen, geven dezelfde response. Een lijstrequest met één project_id dat het account niet kan lezen, geeft 200 met een lege lijst. Controleer het project-ID voordat je meldt dat er geen gegevens zijn.

Geweigerde projectselecties

De lijsten voor logs, issues, acties, metrics, releases en traces accepteren één project met project_id of 2 tot 50 projecten met project_ids. De catalogus met logattributen accepteert dezelfde selectors. De voorvalgeschiedenis van een issue accepteert ze niet. Een request met zowel project_id als project_ids geeft 422:
project_ids met een ongeldige UUID, een dubbel ID, of minder dan 2 of meer dan 50 ID’s geeft ook 422 met code: validation_failed. Als het account één project in een set project_ids niet kan lezen, geeft het hele request 404. Het geeft de andere projecten niet terug als gedeeltelijk resultaat:
Toon de fout, geen lege lijst of een aantal van nul. Lees de projectlijst opnieuw. Verwijder niet stilletjes een project en probeer het niet opnieuw over alle projecten. Gedelegeerde toegangsgegevens, zoals een MCP-verbinding, geven 403 met code: forbidden voor een project buiten die verbinding. Zie projectscope.

Cursorfouten

Logs, issues, acties, metrics en voorvallen van issues gebruiken cursor_time en cursor_id. Een geweigerde cursor geeft 422 met code: validation_failed. Deze fouten betekenen niet dat de lijst leeg is. Bijvoorbeeld:
Kopieer de volledige next_cursor van de vorige pagina. Vervang cursor_time niet door de huidige tijd. Ben je de cursor kwijt? Begin dan opnieuw met pagination=cursor en de oorspronkelijke filters. Een onbekende queryparameter of een waarde van het verkeerde type geeft 422 met "error": "invalid query parameters".

Responses van de releasecursor

Een releasecursor heeft 5 velden. Een geslaagd request zonder resultaten geeft 200:
Als next_cursor niet null is, stuur je alle 5 waarden mee met het volgende request: cursor_project_id markeert een positie. Het vervangt project_id of project_ids niet. Houd de oorspronkelijke project- en filterparameters aan. URL-codeer elke waarde. Met pagination=cursor geeft een onvolledige cursor, of een lege waarde voor release, omgeving of service, 422 met "error": "all release cursor fields must be sent together". Een ongeldige cursor_time en een ontbrekende pagination=cursor geven dezelfde fouten als de andere cursors.

Fouten bij het zoeken naar traces

Deze fouten gelden voor GET /api/telemetry/traces. Elke fout geeft 422 met code: validation_failed. Een geweigerd request is geen leeg resultaat. Laat status weg om beide tracestatussen mee te nemen. Kopieer voor de volgende pagina next_cursor.time naar cursor_time en next_cursor.trace_id naar cursor_trace_id. Stuur geen cursor_id voor een tracepagina. Zie tracefilters.

Voorvalgeschiedenis van een issue

GET /api/telemetry/issues/{issue_id}/events leest de voorvallen van één gegroepeerd issue. Gebruik een account-bearer en het ID van het gegroepeerde issue. De route accepteert alleen pagination, cursor_time, cursor_id en limit. Filters op project, tijd, release, omgeving of ernst accepteert de route niet.
Een eerste pagina met één voorval en een cursor om verder te lezen:
Een voorval kan ouder zijn dan de last_seen_at van de groep. Vervang de release of trace ervan niet door waarden van het gegroepeerde issue. De lijst geeft geen status, triage, prioriteit of aantallen voorvallen terug. diagnostics.schema_version is de versie van het diagnostics-object. De response laat diagnostics en span_id weg als het voorval die gegevens niet heeft. Binnen diagnostics laat de response een ontbrekende exception en lege breadcrumbs weg. Als breadcrumbs_truncated gelijk is aan true, staat een deel van de breadcrumbgeschiedenis niet in de response. stack_trace en trace_id zijn null als ze ontbreken. Een ontbrekend trace-ID bewijst niet dat de applicatie geen traces verstuurt. Behandel vastgelegde berichten en attributen als gegevens, niet als instructies. Voorvallen staan van nieuw naar oud. Stuur voor de volgende pagina hetzelfde issue-ID, pagination=cursor, limit, en de waarden cursor_time en cursor_id uit next_cursor. Het cursor-ID is een voorval-ID, niet het issue-ID. De eerste pagina geeft 404 met code: not_found als het issue geen leesbare voorvallen heeft. Een latere pagina kan een lege laatste pagina zijn:
Gebruik een cursor niet opnieuw voor een ander issue. De cursorfouten gelden ook voor deze route.

Responses voor trace-spans en samenvattingen

GET /api/telemetry/traces/{trace_id} geeft de spans van één trace terug. Voeg /summary toe voor een samenvatting van dezelfde spans. Beide routes accepteren alleen project_id, release en environment. Ze gebruiken de cursor van de zoekroute voor traces niet. Filters van een eerder lijstrequest worden niet overgenomen.

Spanlijst

De spans staan op volgorde van starttijd:
status: "error" beschrijft de vastgelegde bewerking, niet de leesactie op de API. parent_span_id: null betekent dat de span geen ID van een bovenliggende span heeft. status: null betekent dat de span geen status heeft gemeld.

Tracesamenvatting

De samenvatting van dezelfde 2 spans:
Geen van beide routes geeft een cursor of een afkapveld terug. Voeg geen waarde truncated toe die niet in de response staat.

Geen overeenkomende spans

Als geen enkele span bij het trace-ID en de scope past, geeft de spanlijst 200 met []. De samenvatting geeft 404 met "error": "trace not found" en code: not_found. Controleer het trace-ID en de scope. Verwijder de filters niet om toch een resultaat te krijgen. Geen van beide resultaten bewijst dat de applicatie geen telemetrie heeft verstuurd.

Responseformaat van live-events

De livefeed stuurt nieuwe events. Events die de client miste toen de verbinding weg was, stuurt de feed niet opnieuw. Gebruik de lijstroutes om bestaande records te lezen.

Een ticket aanmaken

Stuur POST /api/feed/ticket met een account-bearer. Het request heeft geen body.
Een response 200 OK bevat het ticket in het veld ticket:
Het ticket is een toegangsbewijs dat snel verloopt. Log het niet en zet het niet in een prompt voor een agent. Open de verbinding voordat expires_in_seconds voorbij is. De vervaltijd bepaalt wanneer de verbinding kan starten, niet hoe lang die openblijft. Een 401 betekent dat de inlogsessie van het account niet geldig is. Log opnieuw in voordat je een ticket aanvraagt. Een andere methode dan POST geeft 405 met code: method_not_allowed.

De verbinding openen

Verbind een WebSocket-client met wss://api.logbrew.co/api/feed/live?ticket=<feed-ticket>. URL-codeer het ticket. Zet geen account-bearer en geen ingest-bearer in de URL. Een 401 betekent dat het ticket of de inlogsessie van het account niet geldig is. Maak een nieuw ticket aan nadat je opnieuw bent ingelogd. Wacht na een fout voordat je opnieuw verbindt. Verbind niet opnieuw in een snelle lus.

De berichten lezen

Elk bericht is een envelop { "type": "...", "data": ... }. Lees type voordat je data parset. Sla types over die de client niet ondersteunt.
Een event native_issue gebruikt versie 1 van de issueresponse: een gearchiveerd issue toont ignored, en het event heeft geen prioriteit. Metrics en releases zijn geen live-eventtypes. Lees ze via hun lijstroutes. Het ticket selecteert geen project. Controleer de project_id van elk event voordat je het in een projectweergave toont. logbrew watch --json gebruikt deze feed. Zie de CLI-referentie.

Een gesloten verbinding afhandelen

Bij andere verbroken verbindingen geeft LogBrew soms geen reden. Lees na het opnieuw verbinden de lijstroutes opnieuw en koppel records op ID.

Responsevoorbeelden voor de issuestatus

PATCH /api/telemetry/issues/{issue_id} met { "status": "resolved" } geeft 200 OK terug met het bijgewerkte gegroepeerde issue, in dezelfde vorm als de issueresponse. De queryparameter response_version kiest de versie. De route geeft geen succesvlag terug. De body stelt 1 of meer van status, priority en assignee in. status accepteert unresolved, resolved of archived. ignored is een oudere naam voor archived. Zie Eén issue bijwerken. Controleer de teruggegeven id, status en priority voordat je toont dat het gelukt is. Bouw het resultaat niet op uit de verstuurde waarden. Een statuswijziging verwijdert geen voorvallen en verandert first_seen_at en last_seen_at niet. Ze verandert ook severity of een ernstregel niet. Een geweigerde wijziging geeft 422 met code: validation_failed:
Een veld dat al de gevraagde waarde heeft, verandert niet. Stuur na een time-out of een verloren response hetzelfde request opnieuw, of lees eerst het issue. Stuur geen andere wijziging voordat je de huidige toestand hebt gelezen. Zie Schrijfacties. POST /api/telemetry/issues/bulk geeft 200 OK terug met 1 resultaat per gevraagd issue-ID, in de volgorde van het request. Elk gevonden issue gebruikt de vorm van versie 3. Een resultaat not_found heeft issue: null:
Dit voorbeeld toont maar een deel van de issuevelden. outcome is updated, unchanged of not_found. Een herhaald request geeft unchanged en wijzigt niets. Zie Issues in bulk bijwerken. Een bulkrequest mislukt in deze gevallen in zijn geheel:

Scope van analyserequests

De analyseroutes, de route voor metric-tijdreeksen en de route voor signaalvolume lezen één project en één tijdsbereik. Elk request heeft project_id en since nodig. since accepteert een korte duur zoals 24h of 7d, of een RFC3339-tijdstempel. until accepteert een RFC3339-tijdstempel en is standaard het tijdstip van het request. Het bereik bevat since, bevat until niet en mag niet langer zijn dan 31 dagen. service_name, release en environment zijn optionele exacte filters. Elke waarde moet 1 tot 256 tekens hebben nadat LogBrew de spaties aan begin en eind heeft verwijderd. De route voor segmentvergelijking zet deze filters in elk segment, niet op het hoogste niveau. Als het account het project niet kan lezen, geven deze routes 200 OK met aantallen van nul. Ze geven geen 404. Een leeg resultaat bevestigt dus niet dat je toegang hebt tot het project. Vergelijk project_id met de projecten die het account kan lezen. Een request via een MCP-verbinding die het project niet bevat, geeft 403 en forbidden. Elke response begint met schema_version, query en purpose. query herhaalt de effectieve scope. Een filter dat je niet hebt gestuurd, staat er niet in. purpose is platte tekst die uitlegt op welke vraag de route antwoord geeft. Een ratio ontbreekt als de noemer nul is. Een weggelaten ratio is niet 0 en niet null. Lees coverage voordat je op een ratio vertrouwt.

Gedeelde scopefouten

Deze fouten gebruiken HTTP 422 en validation_failed: Een request zonder project_id geeft bijvoorbeeld:
De routes voor metric-tijdreeksen en signaalvolume gebruiken dezelfde scoperegels, met hun eigen tekst in error. Hun secties hieronder noemen die fouten. Een onbekende queryparameter geeft 422 met de response voor ongeldige queryparameters. Een onbekend JSON-veld, een ontbrekend verplicht JSON-veld of een niet-ondersteunde enumwaarde geeft invalid_json. Zie Ongeldige JSON. Een request met de verkeerde HTTP-methode geeft 405 en method_not_allowed. De tekst in next noemt de ondersteunde methode en velden. Zie Niet-ondersteunde methode.

Response van het overzicht voor productanalyse

GET /api/telemetry/analytics/overview toont de activiteit in één project: actievolume, gebruikers, sessies, een tijdreeks, topacties, en geclassificeerde paginaweergaven, schermweergaven en interacties. Gebruik het overzicht om de exacte eventnamen voor de andere analyseroutes te vinden. Stuur response_version=3. Versies 1 en 2 geven dezelfde aantallen, maar hun waarde voor estimation.method is een ouder token. Versie 1 controleert het soort subject niet als ze geïdentificeerde gebruikers telt. Versies 2 en 3 tellen alleen subjecten van het soort user, en voegen aantallen voor anonieme subjecten en subject_coverage toe. Dit request leest één uur in tijdsintervallen van vijf minuten en geeft twee rijen in elke toplijst:

Geslaagd overzicht

In dit fictieve resultaat heeft het project 120 acties in twee van de twaalf tijdsintervallen. Twintig acties komen van anonieme subjecten. Elke actie heeft een sessie-ID. De helft van de acties heeft een trace-ID.

Het overzicht lezen

De vijf aantallen in subject_coverage tellen op tot het eventtotaal van hun sectie. Alleen identified_user_events telt mee voor gebruikers. anonymous_actions is summary.actions min identified_actions. series bevat alleen tijdsintervallen met activiteit. expected_buckets is het aantal mogelijke tijdsintervallen in het bereik. Teken een ontbrekend tijdsinterval niet als een gemeten nul, tenzij je grafiek die regel vermeldt. Tijdsintervallen vallen samen met de intervalgrenzen in UTC. Een bereik dat midden in een tijdsinterval begint, bevat dat onvolledige tijdsinterval. classified_activity telt paginaweergaven, schermweergaven en interacties. Schermweergaven en interacties zijn ook acties. Paginaweergaven niet. Tel summary.actions niet op bij classified_activity.summary.events. Kopieer kind en event_name uit classified_activity.top_events naar trechterstappen, retentieselectors, levenscyclusselectors, padankers en segmentdoelen. De waarde true in top_events_truncated betekent dat er namen met minder volume zijn. Verhoog top_limit tot maximaal 20 om meer te zien. analysis_level is no_data, event_only, user_level of user_and_session. Als het project geen acties en geen geclassificeerde events heeft, is next_action.code gelijk aan capture_product_activity. Zie Productanalyse.

Fouten in het overzicht

Naast de gedeelde scopefouten geeft het overzicht 422 en validation_failed voor deze waarden: Standaard is interval gelijk aan auto. Dat kiest het kleinste interval waarvoor hoogstens 300 tijdsintervallen nodig zijn. Standaard is top_limit gelijk aan 10.

Response van een geordende trechter

POST /api/telemetry/analytics/funnel meet of 2 tot 8 stappen op volgorde worden doorlopen. Kopieer elke exacte kind en event_name uit classified_activity.top_events in het overzicht. Een actienaam die erop lijkt, is geen match. Deze requestbody telt sessies die /pricing bekijken en daarna binnen één uur de aanmelding afronden:
analysis_unit is session of identified_user. Standaard is dat session. De kind van een stap is page_view, screen_view of interaction. De trechterroute accepteert geen response_version.

Geslaagde trechter

Een response 200 OK:
Ratio’s zijn breuken van 0 tot 1. Lees coverage voordat je op een ratio vertrouwt. selected_unit_coverage_rate is het aandeel van de geselecteerde stapevents dat LogBrew kon gebruiken. De response geeft geen ruwe identiteiten terug. Zie Productanalyse.

Conversie en dekking lezen

entry_rate is entered_units gedeeld door candidate_units: 50 van 60. overall_conversion_rate is completed_units gedeeld door entered_units: 15 van 50, dus 30%. Het is niet 15 gedeeld door alle kandidaten. Deze aantallen verklaren niet waarom eenheden stopten. Dekking telt events, geen sessies. Hier passen 120 events bij een stap, en 20 daarvan hebben geen sessie-ID. Het resultaat laat die 20 events buiten de sessieaantallen. Behandel ze niet als 20 mislukte sessies. De eerste stap heeft geen conversion_from_previous. De laatste stap heeft geen drop_off_to_next_units en geen drop_off_to_next_rate. Een eenheid bereikt een latere stap alleen als de tijden van de stappen strikt oplopen. Events met dezelfde tijdstempel kunnen niet aan twee opeenvolgende stappen voldoen. De laatste stap moet binnen conversion_window_seconds na de eerste stap plaatsvinden. De sessiemodus telt sessies, geen mensen. Gebruik identified_user alleen voor events met een ondoorzichtig subject-ID van het soort user. Die modus kan events uit verschillende sessies binnen het conversievenster samenvoegen. Houd dezelfde eenheid en dezelfde stappen aan als je resultaten vergelijkt. Standaard is conversion_window_seconds 24 uur of de lengte van het bereik, als die korter is. Het maximum is de lengte van het bereik in hele seconden, naar boven afgerond.

Lege trechterresultaten

Een geslaagde lege response toont nog steeds de gevraagde stappen, met nul units. Zijn er geen kandidaateenheden, dan laat summary entry_rate en overall_conversion_rate weg. De route geeft geen 404 alleen omdat er geen events overeenkomen. Lees coverage en next_action om de oorzaak te vinden:

Geweigerde trechterrequests

Naast de gedeelde scopefouten geven deze requests 422 en validation_failed. Minder dan 2 of meer dan 8 stappen:
Een conversion_window_seconds van 0, of een waarde groter dan de lengte van het bereik:
Een event_name die leeg is, langer is dan 256 tekens of een stuurteken bevat, geeft product analytics funnel event_name must be non-empty, control-free, and at most 256 characters. Een stap interaction moet ook een geldige actienaam zijn. Anders is de fout product analytics interaction event_name must be a bounded stable action name. Corrigeer het request voordat je het opnieuw stuurt. Verwijder geen stappen en wijzig de analyse-eenheid niet alleen om een niet-leeg resultaat te krijgen.

Analyse op exacte events en automatische analyse

Retentie en levenscyclus accepteren twee vormen van requests. Kies met response_version de vorm die je vraag beantwoordt: Een exacte selector bevat kind en event_name. kind is page_view, screen_view of interaction. Kopieer event_name uit classified_activity.top_events. Raad geen eventnaam op basis van een knoplabel. Beide vormen tellen alleen gebruikers: ondoorzichtige subject-ID’s van het soort user. Anonieme subjecten en events zonder bruikbaar subject-ID tellen niet als gebruikers. Responses geven nooit subject-ID’s terug. De vaste intervallen zijn hour, day, week en thirty_day. Het zijn vaste tijdsduren. thirty_day is 30 dagen, geen kalendermaand. Laat je interval weg, dan gebruikt de API hour voor een bereik van 48 uur of korter, en day voor een langer bereik.

Request voor retentie op exacte events

Stuur deze body naar POST /api/telemetry/analytics/retention. Die vraagt of gebruikers nog een checkout afronden na hun eerste checkout in het bereik:
Het eerste overeenkomende startevent in het bereik is het anker van elke gebruiker. Een terugkeer moet strikt na dat anker en vóór until plaatsvinden. Beide selectors mogen hetzelfde event zijn.

Geslaagde retentie op exacte events

In dit fictieve voorbeeld ronden twee gebruikers een checkout af. De eerste gebruiker rondt een checkout af op 1 juni om 12:00 en opnieuw om 13:00. De tweede gebruiker rondt een checkout af op 2 juni om 12:00. Op 2 juni om 13:00 bekijkt de tweede gebruiker een pagina, maar rondt geen nieuwe checkout af.

Retentie lezen

Dekking telt alle vier de geclassificeerde events, maar slechts drie passen bij elke checkoutselector. De paginaweergave telt niet als terugkeer. Een van de twee gebruikers herhaalt de checkout, dus return_rate_after_start is 0.5. Alleen de eerste gebruiker heeft na het anker een volledige dag waarneming. Die gebruiker keert binnen de dag terug, dus de ratio in de curve is 1.0. De tweede gebruiker heeft maar 12 uur waarneming. Die gebruiker komt niet in aanmerking voor periode 0, dus de cel van het tweede cohort laat retention_rate weg. Tel die gebruiker niet als verloren. weighted_retention_rate deelt alle behouden gebruikers door alle gebruikers die in aanmerking komen. fully_observed_cohort_average_rate is het gewone gemiddelde van de ratio’s van de cohorten waarin elke gebruiker in aanmerking komt. Cohorten zijn vaste tijdsintervallen die beginnen bij since. cohorts bevat alleen cohorten met gebruikers. Met mode: "return_on_or_after" laat de curve window_end_seconds weg.

Automatische retentie

Stuur response_version: 2 zonder start_event of return_event. Elke ondersteunde paginaweergave, schermweergave en interactie telt als start en als terugkeer. Deze versie kiest een set events. Ze kiest geen vastlegformaat van de SDK.
De response heeft dezelfde vorm voor summary, curve, cohorts en next_action als de response voor exacte events. Dit fragment toont de velden die veranderen. In dit voorbeeld hebben dezelfde twee gebruikers drie events en geen paginaweergave:
In de automatische modus zijn start_events en return_events allebei gelijk aan classified_events. Deze aantallen zijn events, geen gebruikers.

Retentie zonder gebruikers die in aanmerking komen

Een geslaagd resultaat kan zonder cohortgebruikers zijn. Dit fragment toont één gevraagde periode zonder cohorten:
Lees coverage en next_action. Die onderscheiden een scope zonder geclassificeerde events (capture_product_activity) van events zonder gebruikers (identify_product_users of identify_returning_users). Een ontbrekende ratio is geen gemeten nul.

Retentiefouten

Naast de gedeelde scopefouten geven deze requests 422 en validation_failed: De limiet op cellen gebruikt het bereik en de perioden, niet het aantal gebruikers. Een bereik van 30 dagen met interval: "hour" heeft 720 tijdsintervallen voor cohorten. Met interval_count: 1 zijn dat 720 cellen, meer dan 500:
Verwijder beide selectors om automatische retentie te gebruiken. Wijzig de SDK niet om dit leesrequest te corrigeren.

Request voor levenscyclus op een exact event

Stuur deze body naar POST /api/telemetry/analytics/lifecycle. Die deelt gebruikers in op basis van één event, niet op basis van alle activiteit in het project:
history_period_count bepaalt hoeveel volledige perioden vóór since LogBrew als geschiedenis leest. Het accepteert 2 tot 31. Standaard is dat 2. Een gebruiker kan inactief zijn voor dit event terwijl die gebruiker andere dingen doet.

Geslaagde levenscyclus op een exact event

Dit fictieve voorbeeld gebruikt twee dagen geschiedenis en twee analysedagen. De letters staan alleen voor voorbeeldgebruikers. De response geeft geen gebruikers-ID’s terug. C bekijkt op 2 juni ook een pagina. Dat event past niet bij de checkoutselector.

Levenscyclus lezen

Op 1 juni is A terugkerend, B opnieuw actief, C nieuw en D inactief. Op 2 juni zijn A en B terugkerend, en is C inactief voor checkout, ondanks de paginaweergave. De netto verandering op 2 juni is 2 - 3 = -1. In elk tijdsinterval tellen nieuwe, terugkerende en opnieuw actieve gebruikers op tot active_subjects. returning_subjects plus dormant_subjects is gelijk aan previous_active_subjects. net_active_change is active_subjects min previous_active_subjects. Tel de dagelijkse actieve aantallen niet op om unieke gebruikers te krijgen. Hier tellen de dagaantallen op tot 5, maar analysis_active_subjects is 3. In geschiedenis en analyse samen komen vier unieke gebruikers voor. fully_observed is false voor een laatste tijdsinterval dat na until eindigt. De aantallen ervan kunnen veranderen als de volledige periode waarneembaar is. De next_action stelt een onderzoek voor. Die toont geen oorzaak.

Automatische levenscyclus

Stuur response_version: 2 zonder selector event. Elke ondersteunde paginaweergave, schermweergave en interactie telt als activiteit:
De response heeft dezelfde vorm voor summary, buckets en next_action als de response voor een exact event. Dit fragment toont de velden die veranderen:
In de automatische modus is coverage.selected_events gelijk aan coverage.analysis_classified_events. Het vijfde item in limitations is Returning, resurrected, and dormant compare any supported classified product activity; no event is ranked, selected, or inferred.

Levenscyclus zonder gebruikers

Als het analysebereik en de geschiedenis geen bruikbare gebruikers bevatten, is buckets leeg en laat summary latest_fully_observed_period weg:
Gebruikers die alleen in de geschiedenis voorkomen, kunnen toch tijdsintervallen met inactieve gebruikers opleveren als het analysebereik geen activiteit heeft.

Levenscyclusfouten

Naast de gedeelde scopefouten geven deze requests 422 en validation_failed: Tien geschiedenisperioden van week hebben bijvoorbeeld 70 dagen nodig:

De gekozen analysescope lezen

Responses voor exacte events hebben schema_version: 1. Hun query herhaalt de selectors en laat activity_scope weg. Automatische responses hebben schema_version: 2 en query.activity_scope: "all_classified_activity". Ze laten de selectors weg. Een andere selector kan het resultaat veranderen zonder dat de vastgelegde activiteit verandert.

Response voor metric-tijdreeksen

GET /api/telemetry/metrics/series leest één exacte metricnaam in één project. Kopieer de naam uit GET /api/telemetry/metrics. Dit request groepeert een delta-counter per service:

Geslaagde metric-tijdreeks

Deze fictieve response bevat één tijdreeks van een delta-counter. Drie metingen met de waarden 2, 3 en 5 vallen in het eerste tijdsinterval. Twee metingen met de waarden 1 en 4 vallen in het laatste tijdsinterval. In het middelste tijdsinterval valt geen meting, dus de response heeft daarvoor geen datapunt.

Een metric-tijdreeks lezen

Het eerste datapunt registreert 10 voltooide jobs, niet 10 metingen. rate_per_second deelt die verandering door het tijdsinterval van 300 seconden. last is de laatst geregistreerde verandering, niet de som. Zie betekenissen van metric-aggregaties. Het soort en de temporaliteit van een tijdreeks bepalen de aggregation.code en de statistieken in elk datapunt. Een datapunt laat een statistiek weg die niet van toepassing is. Een ontbrekende statistiek is geen nul. limited is een geslaagde response, geen fout. Het voegt aggregation.limitation toe, dat uitlegt waarom LogBrew alleen ruwe waarden toont. ready bewijst niet dat alles is vastgelegd. Lees coverage voordat je een grafiek tekent:
  • samples telt de metingen van alle overeenkomende tijdreeksen, ook tijdreeksen die de response niet teruggeeft.
  • series telt overeenkomende tijdreeksen. returned_series en points tellen de teruggegeven gegevens.
  • truncated is true als series_limit tijdreeksen met minder volume heeft weggelaten.
  • expected_buckets_per_series is het aantal mogelijke tijdsintervallen in het bereik.
Voeg geen datapunt toe voor een tijdsinterval zonder metingen. Vul geen nul in en kopieer de vorige waarde niet. Elk datapunt geeft maximaal 3 trace_exemplars terug. Een trace-exemplar koppelt één meting aan een trace. Het verklaart niet elke meting in het tijdsinterval. Als geen enkel datapunt een trace-exemplar heeft, is next_action.target gelijk aan metric_samples.

Scope en fouten van metric-tijdreeksen

project_id, name en since zijn verplicht. name mag hoogstens 200 tekens hebben. interval is auto, 1m, 5m, 15m, 1h, 6h of 1d. Standaard is dat auto. Die waarde kiest het kleinste interval met hoogstens 300 tijdsintervallen. Een expliciet interval mag niet meer dan 500 tijdsintervallen nodig hebben. group_by is none, service_name, release of environment. Standaard is dat none. Zonder groepering blijven verschillende soorten, eenheden en temporaliteiten in aparte tijdreeksen. series_limit accepteert 1 tot 20. Standaard is dat 10. Een leeg resultaat geeft 200 met series: [] en nul samples. Het object coverage laat first_seen_at en last_seen_at weg. Dat bewijst niet dat de applicatie de metric nooit heeft verstuurd. Controleer het project, de metricnaam en het tijdsbereik. Zonder name krijg je 422:
Tijdsintervallen van één minuut over zeven dagen geven 422:
Andere fouten met 422 zijn metric series group_by is not supported, metric series interval is not supported en metric series_limit must be between 1 and 20.

Response van padanalyse

POST /api/telemetry/analytics/paths vindt de benoemde events vóór of na één gekozen event in dezelfde sessie. Het gekozen event is het anker. Kopieer de kind en event_name ervan uit classified_activity.top_events. De route geeft schema_version: 1 terug. Ze accepteert geen response_version of analysis_unit.
direction en anchor zijn verplicht.

Geslaagde padanalyse

In dit fictieve resultaat bevatten vier sessies het anker. De twee teruggegeven paden staan voor drie van die sessies. Eén lager gerangschikt pad wordt niet teruggegeven.

Paden lezen

share_of_anchored_sessions deelt de sessies van een pad door alle vier de sessies met het anker. De aandelen zijn 50% en 25%, niet 67% en 33%. unrepresented_sessions telt sessies met het anker die geen enkel teruggegeven pad vertegenwoordigt. paths_truncated: true betekent dat het resultaat onvolledig is. Dekking telt events, geen sessies. Hier passen vijf events bij het anker, maar één heeft geen sessie-ID. Dat event kan niet in een pad komen. Elk pad geeft maximaal 3 trace-exemplars terug. Gebruik een trace-ID uit je eigen response. Een tracekoppeling toont niet wat een gebruikersactie of een fout veroorzaakte. Knooppunten staan in beide richtingen op tijdsvolgorde. Een pad is geen volledige herhaling van de sessie. LogBrew leest hoogstens 1024 benoemde events per sessie voordat het het anker kiest: de vroegste events voor following en de laatste events voor preceding. Een anker buiten die limiet kan ontbreken.

Het anker filteren op eigenschap

Stuur maximaal vier property_filters, elk met één exacte key en value. Kopieer de sleutel uit de eigenschappencatalogus. De filters gelden alleen voor het anker, niet voor de events eromheen. Waarden zijn hoofdlettergevoelig. Als er filters zijn, herhaalt query ze en meldt coverage.anchor_property_filters: Ontbrekende sleutels en afwijkende waarden vragen om verschillende oplossingen. Tel ze niet bij elkaar op. Het object ontbreekt als het request geen eigenschapsfilter heeft.

Lege paden en geweigerde requests

Een lege array paths kan een geslaagde response 200 zijn. Lees summary, coverage en next_action. Deze codes onderscheiden de oorzaken: capture_product_activity, choose_captured_path_anchor, capture_anchor_properties, improve_anchor_property_coverage, verify_anchor_property_values, sessionize_product_activity en narrow_or_move_path_anchor. Naast de gedeelde scopefouten geven deze requests 422 en validation_failed: depth: 0 geeft bijvoorbeeld:

Eigenschappencatalogus voor productanalyse

GET /api/telemetry/analytics/properties toont de eigenschapssleutels op geclassificeerde productevents in één project. Gebruik de sleutels in segmentvergelijkingen en in filters voor padankers. De catalogus geeft sleutels en aantallen terug. Hij geeft nooit eigenschapswaarden of identiteiten terug.

Beschikbare eigenschapssleutels lezen

Stuur project_id en since. Je kunt ook until, service_name, release, environment, limit en response_version sturen. limit accepteert 1 tot 50 sleutels. Standaard is dat 20. Stuur response_version=2 voor de openbare waarde van estimation.method.

Geslaagde eigenschappencatalogus

In dit fictieve resultaat zijn er 100 geclassificeerde events. Vijf daarvan zijn vastgelegd vóór de huidige eigenschappenindex.

De catalogus interpreteren

source is standard_context voor een standaardcontextsleutel, zoals resource.runtime.name, of custom_tag voor een sleutel die begint met tag.. value_type is altijd string. properties is gesorteerd op events, de hoogste eerst. tag.plan staat op 60 van de 100 geclassificeerde events. De sleutel heeft ongeveer 3 unieke waarden. De beschrijving toont die waarden niet. Gebruik waarden die je uit je applicatie kent. Raad geen waarde op basis van een aantal. Eén event kan meerdere sleutels hebben, dus tel de aantallen in events per sleutel niet bij elkaar op. Een lege array properties bewijst niet dat het project geen productevents heeft. Lees summary, coverage en next_action.

Fouten in de eigenschappencatalogus

Naast de gedeelde scopefouten geeft limit=0 of limit=51 een 422:
Een response_version anders dan 1 of 2 geeft product analytics response_version must be 1 or 2. LogBrew controleert response_version vóór de andere waarden. Een POST-request geeft 405:

Segmentvergelijking in productanalyse

POST /api/telemetry/analytics/segments/compare vergelijkt hoe vaak sessies of gebruikers één exact event bereiken in 2 tot 4 segmenten binnen één project. Een segment selecteert events op service, release, omgeving en eigenschapswaarden. Het eerste segment is het referentiesegment.

De vergelijking definiëren

Stuur deze JSON-body met accountauthenticatie en Content-Type: application/json. Hier zijn basic en premium abonnementswaarden van de voorbeeldapplicatie, geen abonnementen van LogBrew:
target en segments zijn verplicht. analysis_unit is session of identified_user. Standaard is dat session. Die waarde telt sessies, geen mensen. interval accepteert dezelfde waarden als het overzicht. Standaard is dat auto. Elk segment heeft een unieke key, een label en een eigen set filters nodig:
  • key: 1 tot 32 bytes. Begin met een kleine ASCII-letter of een cijfer. Gebruik alleen kleine ASCII-letters, cijfers, _ en -.
  • label: 1 tot 80 tekens, zonder stuurtekens.
  • service_name, release, environment: optioneel. Elke waarde heeft 1 tot 256 tekens, zonder stuurtekens.
  • property_filters: 0 tot 4 filters. Elke sleutel mag één keer in een segment voorkomen. Een event moet bij alle filters van het segment passen. Waarden zijn hoofdlettergevoelig en hebben 1 tot 256 tekens. LogBrew verwijdert spaties aan het begin en het eind.
Een segment zonder filters selecteert alle geclassificeerde activiteit in het project en het tijdsbereik. Segmenten mogen overlappen. Een ander label of een andere sleutel maakt twee identieke sets filters niet geldig.

Geslaagde segmentvergelijking

In dit fictieve resultaat bereikt het referentiesegment de checkout in 10 van de 50 sessies. Het segment premium bereikt die in 18 van de 60 sessies.

Ratio’s en verschillen lezen

eligible_units schat de sessies of gebruikers met geclassificeerde activiteit in het segment. reached_units schat hoeveel daarvan het doel bereikten. reach_rate is reached_units gedeeld door eligible_units. Events zonder ID van de gekozen eenheid tellen niet mee voor deze eenheden. De ratio van het referentiesegment is 20%. De ratio van premium is 30%. Het verschil is 10 procentpunten. De relatieve stijging is 50%, niet 10%. Kleine decimale afwijkingen komen door rekenen met drijvendekommagetallen. Rond ratio’s af voor weergave, maar reken met de teruggegeven waarden. Het referentiesegment heeft geen comparison_to_baseline. De relatieve stijging ontbreekt als de bereikratio van het referentiesegment nul is. In query is een segmentfilter dat je niet hebt gestuurd null. Een lege lijst property_filters wordt weggelaten. coverage.property_filters heeft dezelfde velden als de dekking van padankerfilters. Hier is matching_events gelijk aan classified_events. Houd ontbrekende sleutels en afwijkende waarden apart. Segmenten kunnen overlappen, en één sessie kan in meerdere tijdsintervallen voorkomen. Tel aantallen eenheden niet op over segmenten of tijdsintervallen heen. De vergelijking is beschrijvend. confidence.causal_inference is not_established en confidence.statistical_significance is not_tested. Een ratio van 30% tegenover 20% toont niet aan dat een abonnement tot meer checkouts leidde.

Fouten in segmentvergelijkingen

Naast de gedeelde scopefouten geven deze requests 422 en validation_failed: De fouten voor interval zijn dezelfde als de fouten in het overzicht. Twee segmenten met verschillende sleutels en identieke filters geven bijvoorbeeld:
Een ander label of een andere volgorde van eigenschapsfilters verandert de geselecteerde events niet. Een mislukte validatie is geen bewijs dat er geen events overeenkomen. Een GET-request geeft 405:

Response voor signaalvolume

GET /api/telemetry/summary/volume telt bewaarde signalen voor één project en tijdsbereik. De route vereist project_id en since. Ze accepteert geen project_ids. until mag niet in de toekomst liggen. Laat je het weg, dan is het einde het tijdstip van het request. Een korte since zoals 24h telt terug vanaf until. interval is auto, 1m, 5m, 15m, 1h, 6h of 1d. De standaardwaarde auto kiest het kleinste interval met hoogstens 120 tijdsintervallen. Een request mag niet meer dan 500 tijdsintervallen nodig hebben. De enige response_version is 1.

Signaalaantallen

Deze fictieve response beslaat twee tijdsintervallen van één minuut. Het request liep om 12:02 UTC zonder until. Het account heeft een bewaartermijn van 30 dagen. Lees de teruggegeven bewaartermijn en het grenstijdstip. Ga er niet van uit dat deze waarden voor jouw account gelden.

Elk aantal in zijn eigen eenheid lezen

total is de som van de aantallen per tijdsinterval in de tijdreeks. peak is het hoogste aantal in één tijdsinterval. non_empty_buckets telt tijdsintervallen met een aantal boven nul. De vijf tijdreeksen staan altijd in deze volgorde. Voeg verschillende signaalaantallen niet samen tot één impactscore. Tijdsintervallen beginnen bij query.since. Een tijdsinterval bevat zijn begin, maar niet zijn einde. Het laatste tijdsinterval kan korter zijn dan het interval. De response heeft geen tijdreeks met het aantal releases. Lees release_volume_not_included niet als nul releases.

Lege en ingekorte tijdvensters

Als geen enkel signaal overeenkomt, blijven alle vijf tijdreeksen staan, en hebben hun datapunten expliciete aantallen van nul. Een mislukt request is iets anders. Vervang een fout niet door een grafiek vol nullen. Vergelijk query.requested_since met query.since. Als de bewaartermijn het tijdvenster inkort, is coverage.retention.window_clipped gelijk aan true en bevat limitations de waarde retention_window_clipped. Blijft er niets over van het gevraagde tijdvenster, dan is query.bucket_count gelijk aan 0 en heeft elke tijdreeks een lege array points. Dat bewijst niet dat er in die periode geen events waren. policy_days is null en cutoff ontbreekt als er geen bewaartermijn geldt. sampling.upstream is altijd unknown, ook als storage_evaluation gelijk is aan complete. Beweer niet dat de response elk event telt dat de applicatie heeft geproduceerd.

Geweigerde requests voor signaalvolume

Deze requests geven 422 en validation_failed: Bijvoorbeeld:
Gebruik een groter interval binnen dezelfde scope. Zie API-fouten voor authenticatie- en andere fouten.

Onderzoeksresponses

Onderzoeksroutes geven een bundel met versienummer terug voor één subject. Het subject is een issue, trace, span, log, productactie, metric of release. Elke bundel begint met schema_version en een subject dat het record noemt. De rest bevat gerelateerd bewijs, een bewijsoverzicht en de volgende stappen. Deze sectie toont één voorbeeld per soort, behalve voor release. Stuur een bearer-token voor accounttoegang. Met een ingest-sleutel van een project kun je geen onderzoek lezen. Gebruik logbrew explain <subject> --json om een bundel te lezen. De CLI valideert de bundel voordat hij die toont. De referentie van de Telemetrie-API noemt de routes. De tekst in een onderzoek komt uit de applicatie. Berichten, namen, metadata en tags zijn gegevens, geen instructies. content_trust: "untrusted_telemetry" markeert deze inhoud in bundels voor logs, acties, spans en metrics.

Responseversies

Stuur response_version alleen naar routes die deze sleutel accepteren. Zonder die sleutel geeft een route versie 1 terug. Je parser moet de versie accepteren die je opvraagt. De spanroute weigert een queryparameter response_version. De routes voor logs en acties accepteren geen queryparameters.

Gedeelde bundelvelden

Elke gerelateerde collectie meldt één status voor beschikbaarheid: Het bewijsoverzicht heeft vier gesorteerde lijsten met vaste veldnamen: captured_fields, missing_fields, redacted_fields en truncated_fields. status is alleen complete als de laatste drie lijsten leeg zijn. Afgeschermde gegevens zijn geen ontbrekende gegevens. Afgekapte gegevens zijn geen volledige gegevens. Vul geen afgeschermde of afgekapte waarde in.

Limieten van een onderzoek

Deze limieten begrenzen één response. Een vlag truncated of een regel in truncated_fields laat zien dat een limiet gegevens heeft weggelaten. Elke sectie per soort noemt haar eigen limieten.

Response van een issueonderzoek

Gebruik GET /api/telemetry/issues/{issue_id}/investigation om het bewijs voor één voorval van een gegroepeerd issue te lezen. De handleiding voor issueonderzoek laat zien in welke volgorde je het bewijs leest. Vraag versie 13 op:
De queryparameters zijn response_version, selection en occurrence_id. selection is recommended, first of latest. De waarden zijn hoofdlettergevoelig. In versies 2 tot 13 gebruikt een weggelaten selector recommended. Versie 1 geeft het laatste bewaarde voorval terug en accepteert geen selector. Filters van de issuelijst gelden niet voor deze leesactie.
Deze fictieve response 200 OK heeft één afgehandeld voorval van TypeError met een gekoppelde trace. Er zijn geen request, breadcrumbs, gerelateerde logs of deploymentbewijs, dus evidence.status is partial.
Sleutels uit een latere versie ontbreken in een eerdere versie. Lees een ontbrekende sleutel niet als null. subject.status en de statussen in lifecycle melden een gearchiveerd issue als ignored. Responses van de issuelijst en van issuedetails gebruiken archived vanaf responseversie 2. Limieten voor issues: de aanbeveling leest hoogstens 50 bewaarde voorvallen. De trend heeft hoogstens 30 tijdsintervallen. Elke verdeling geeft hoogstens 10 waarden terug. Een stack heeft hoogstens 32 frames.

Requestfouten bij een issueonderzoek

Gebruik selection of occurrence_id. Stuur ze niet allebei, ook niet als ze hetzelfde voorval selecteren:
Een ontbrekend voorval betekent niet dat het issue ontbreekt. Een 404 laat niet zien of een ander account het issue kan lezen.

Response van een traceonderzoek

Gebruik GET /api/telemetry/traces/{trace_id}/investigation om één trace te lezen met het foutpad, het traagste pad en gerelateerde signalen. De queryparameters zijn response_version, project_id, release en environment. Ze zijn allemaal optioneel. Vraag versie 3 op:
Versie 2 voegt cause en fix toe aan elk gerelateerd issue. Versie 3 voegt span_id toe aan gerelateerde issues, acties en metrics, als dat is vastgelegd.
Deze fictieve response heeft een server-rootspan en een mislukte client-span. De mislukte span is ook de traagste onderliggende span. De spans hebben geen gestructureerde context, dus spans.context ontbreekt.
trace.parentage ontbreekt als een span een bovenliggende span noemt die LogBrew niet heeft bewaard. De spanpreview heeft hoogstens 64 spans. Elk analysepad heeft hoogstens 64 spans. Gerelateerde leesacties gebruiken hoogstens 8 deploymentscopes. Een volgende actie met als doel trace_span noemt een span_id uit deze bundel. Roep de spanroute aan met de project_id, environment en release van die span om de span te lezen.

Response van een spanonderzoek

Gebruik GET /api/telemetry/traces/{trace_id}/spans/{span_id}/investigation om één bewerking in een trace te lezen. Stuur project_id, environment en release. Alle drie zijn verplicht. Kopieer ze van de geselecteerde span. Stuur de id van de spanrij niet als span_id.
Deze fictieve response beschrijft de mislukte client-span uit het tracevoorbeeld. Een foutlog heeft hetzelfde span-ID. De span duurde langer dan het 95e percentiel bij benadering van de bewaarde vergelijkbare spans.
De referentie leest de 24 uur vóór de start van de span. since telt mee en until niet. error_rate_basis_points: 500 betekent 5%. subject_percentile_basis_points: 9500 betekent dat 95% van de bewaarde vergelijkbare spans niet langer duurde dan deze span. Percentielen zijn bij benadering. Houd baseline.limitations bij de waarden. Een referentie met not_found heeft geen bewaarde vergelijkbare spans. Een referentie met unavailable is een mislukte leesactie, geen aantal van nul. parent_chain_status: "complete" betekent dat de bewaarde keten een root bereikt. Het bewijst niet dat LogBrew elke span van het request heeft bewaard. De topologie geeft hoogstens 64 voorouders, 50 directe kinderen en 50 verbindingen tussen services terug.

Response van een logonderzoek

Gebruik GET /api/logs/{log_id}/investigation om één log en het gerelateerde bewijs te lezen. Deze route heeft geen queryparameters. Kopieer het log-ID uit een loglijst.
De leesactie kan bewijs teruggeven buiten de filters van de loglijst. Gerelateerde leesacties gebruiken het project, de omgeving en de release van de log, en 5 minuten vóór en na de log. Logs in de buurt gebruiken ook dezelfde service. Die hebben geen trace-ID nodig. Leesacties op de exacte trace hebben het trace-ID van de log nodig en kunnen andere services bevatten. De tracesamenvatting gebruikt hetzelfde trace-ID en dezelfde scope, zonder het tijdvenster.
Deze fictieve response heeft een waarschuwingslog zonder tracecontext en één log in de buurt. De response bouwt geen tracekoppeling op basis van de tijdstempels.
Een trace-ID kan aanwezig zijn als de tracestatus not_found of unavailable is. Een beschikbare tracesamenvatting garandeert geen exact_span.

Response van een actieonderzoek

Gebruik GET /api/telemetry/actions/{action_id}/investigation om één productactie te lezen, met de gemelde status en gerelateerd bewijs. Deze route heeft geen queryparameters. Gerelateerde leesacties gebruiken hetzelfde tijdvenster en dezelfde scopes als een logonderzoek.
correlations, timeline en next_actions gebruiken de vormen van een logonderzoek. Gerelateerde acties bevatten de onderzochte actie zelf niet.
Deze fictieve response beschrijft een mislukte checkoutactie van een ingelogde gebruiker. De actie heeft geen trace-ID.
De response geeft nooit ID’s van subjecten of sessies terug. Het bewijsoverzicht noemt subject.distinct_id altijd als afgeschermd, en ook subject.session_id als er een sessie is vastgelegd. Daarom is elke actiebundel partial en bevat die improve_capture. Verwijder geen privacymaatregelen om daaraan te voldoen.

Response van een metriconderzoek

Gebruik GET /api/telemetry/metrics/investigation om één metricnaam in één project en tijdsbereik te lezen. De response bevat de huidige tijdreeks, een vergelijking met het voorgaande tijdvenster van dezelfde lengte, de laatste meting, trace-exemplars en voltooide deployments. Versie 2 voegt de beschrijving van de metric uit de laatste bewaarde meting toe. Versie 1 meldt altijd description_status: "not_captured".
project_id, name en since zijn verplicht. since telt mee en until niet. Standaard is until gelijk aan nu. De vergelijking leest ook het voorgaande tijdvenster van dezelfde lengte.
Dit fictieve histogram heeft 5 metingen in twee tijdsintervallen van 5 minuten. Het laatste tijdsinterval heeft een p95 van 48 ms. Het laatste tijdsinterval van het vorige tijdvenster heeft een p95 van 24 ms.
relative_change_percent is (current - previous) / abs(previous) * 100. Het is null als de vorige waarde nul is of ontbreekt. expected_buckets_per_series telt mogelijke tijdsintervallen, geen tijdsintervallen met gegevens. Teken lege tijdsintervallen niet als nul. Een deployment vlak bij een verandering bewijst niet dat die de verandering veroorzaakte. Een project dat het account niet kan lezen, geeft 200 OK met analysis.status: "no_samples", geen 404. Een leeg resultaat zegt niets over andere signaaltypen. Limieten voor metrics: het bereik is hoogstens 31 dagen. Elke tijdreeks heeft hoogstens 500 tijdsintervallen. series_limit is 1 tot 20, standaard 10. De response geeft hoogstens 20 exemplars en 20 deployments terug. interval is auto, 1m, 5m, 15m, 1h, 6h of 1d. group_by is none, service_name, release of environment. Andere waarden geven 422.

Onderzoeksfouten

Een 404 betekent dat geen enkel leesbaar project het record heeft. Elke route geeft ook 401 zonder geldige authenticatie en 405 voor een andere methode dan GET. Zie API-fouten voor de responses bij niet gevonden, pad, authenticatie en methode. Een optionele leesactie voor bewijs kan mislukken binnen een response 200 OK. De collectie meldt dan unavailable. Toon dat niet als not_found of als nul records.

Ernstwaarden

De ernstwaarden die gebruikers zien, zijn info, warning, error en critical. SDK’s en runtimes kunnen gangbare aliassen sturen, zoals trace, debug, warn of fatal. REST- en live-responses geven altijd de canonieke waarde terug. LogBrew accepteert bijvoorbeeld warn als invoer en geeft warning terug. De ingest-API weigert onbekende ernstwaarden.

Responses van ernstregels

Een ernstregel verandert hoe LogBrew een log of issue toont. De regel verandert niet de ernst die de applicatie heeft vastgelegd. Logs en issues geven een object triage terug: Gebruik triage.effective_severity voor weergave. Houd severity als de vastgelegde waarde. Standaard laat de loglijst genegeerde logs weg. Stuur status=ignored of status=all op GET /api/logs om ze mee te nemen. Het account moet issues in het project mogen beheren. Leestoegang is niet genoeg. Zonder die toestemming geeft een regelwijziging 403 met code: forbidden.

Een logregel wijzigen

PUT /api/logs/{log_id}/triage-rule stelt de regel in voor de log en voor latere logs met dezelfde signatuur. De body heeft zowel severity als ignored nodig:
Een response 200 OK bevat de volledige log. De severity blijft warning. De triage toont de regel:
Dit fragment toont alleen de gewijzigde velden. severity in het request is source, info, warning, error of critical. source zet de vastgelegde ernst terug. Een genegeerde log wordt daardoor niet weer actief. Stuur "ignored": false om de log weer te tonen.

Een issueregel wijzigen

PUT /api/telemetry/issues/{issue_id}/triage-rule stelt de getoonde ernst in van een gegroepeerd issue en de latere voorvallen ervan. De body accepteert alleen severity:
Een response 200 OK bevat het volledige issue in versie 1. De vastgelegde severity en status veranderen niet:
Dit fragment toont maar een deel van de velden. Een regel lost een issue niet op, archiveert het niet en heropent het niet. Gebruik daarvoor de statuswijziging. Een afgeleide prioriteit volgt de nieuwe effectieve ernst. Lees het issue met response_version=2 of 3 om die te zien. Een niet-ondersteunde ernst geeft 422:
Een onbekend veld in de body, zoals status bij een issueregel, geeft 422 met code: invalid_json. Een log of issue dat ontbreekt of niet leesbaar is, geeft 404 met code: not_found. Is de response verloren gegaan? Lees dan de log of het issue opnieuw voordat je de regel opnieuw stuurt.

Formaat van foutresponses

Applicatiefouten geven een JSON-envelop terug. Dit voorbeeld toont een geweigerd request. De tekst in error en next hangt af van het probleem:
Gebruik code voor vertakkingen in je programma en next_action voor automatisering. Toon error en next als platte tekst aan mensen. Parse hun formulering niet. Sommige fouten voegen velden toe, zoals limit, reset_at of retry_after_seconds. Een response zonder JSON-body heeft geen code van LogBrew. Zie API-fouten voor alle codes.

Gegevens lezen met de CLI

De CLI leest dezelfde routes en geeft met --json dezelfde JSON terug. Begin breed en verfijn daarna:
Voeg --pagination cursor toe voor de cursorenvelop. De CLI vraagt versie 4 van de issueresponse op. Zie De volgende pagina lezen en Live volgen.