422 e validation_failed, a menos que a matriz diga outra coisa. Aliases amigáveis como project, trace e user não são parâmetros de consulta. Não leve um filtro de uma rota para outra.
Monte uma requisição filtrada
Coloque a query string depois do caminho. Use--data-urlencode para que os caracteres reservados fiquem seguros. Esta requisição lê os logs críticos de um projeto nas últimas 24 horas:
- Selecione o projeto com
project_idouproject_ids. - Adicione um período com
sincee, se quiser, comuntil. - Adicione filtros de serviço, versão, ambiente, status ou filtros específicos do sinal.
- Defina
limitpara receber uma página menor. - Adicione os campos de cursor somente depois que uma resposta com cursor retornar esses campos.
GET /api/logs usa status=active quando você omite status.
Matriz de filtros
Os parâmetros da coluna “Obrigatórios” precisam estar na requisição. Todos os outros parâmetros são opcionais.
Na investigação de problemas,
selection é first, latest ou recommended. Envie selection ou occurrence_id, nunca os dois. Os dois precisam de response_version de 2 a 13. Com a versão 2 ou posterior e sem seletor, o LogBrew usa recommended. Obtenha um occurrence_id em GET /api/telemetry/issues/{issue_id}/events.
As rotas de análise com POST recebem um corpo JSON. Veja Análise de produto.
Filtros compartilhados e filtros de um sinal
service_name, release e environment restringem todas as listas de telemetria. Use exatamente os valores que o seu kit de desenvolvimento de software (SDK) envia.
Alguns filtros pertencem a um único sinal:
- Logs aceitam
search,trace_id,severityeattribute_filters. - Logs aceitam
status:active(padrão),ignoredouall.ignoredseleciona os logs que uma regra de log esconde da visualização ativa. - Problemas aceitam o
statusdo problema:unresolved,resolvedouarchived.ignoredé um nome antigo dearchivede seleciona os mesmos problemas. - Problemas aceitam
severity:info,warning,erroroucritical. - Problemas aceitam
priority:high,mediumoulow. - Problemas aceitam
assignee:mepara os problemas atribuídos à conta conectada,nonepara os problemas sem responsável,my_teamspara os problemas das suas equipes, um ID de usuário outeam:<team_id>. - Ações e métricas aceitam
name. - Ações aceitam
distinct_id. - Traces aceitam o
statusdo trace emin_duration_ms. - Implantações aceitam
status:succeededoufailed.
severity de logs e de problemas comparam a gravidade efetiva. Se uma regra mudou a gravidade, o filtro usa o valor definido pela regra. Veja Valores de gravidade.
Período
since aceita um número inteiro positivo de horas ou de dias, como 24h ou 7d, ou um timestamp RFC3339. Uma duração compacta é relativa ao horário de cada requisição.
until aceita apenas um timestamp RFC3339. Ele é um horário final exclusivo: uma linha exatamente em until não entra no resultado. since é inclusivo. Por exemplo, since=2026-10-01T00:00:00Z e until=2026-10-02T00:00:00Z selecionam 1 dia inteiro. O LogBrew compara os horários com precisão de milissegundos.
until precisa ser posterior a since. Se não for, ou se until não for um timestamp RFC3339, a requisição falha com 422 e validation_failed.
Em uma leitura de várias páginas, escolha um horário inicial em RFC3339 e mantenha esse valor em todas as páginas. Mantenha também o mesmo until em todas as páginas.
Esta requisição lê os logs de erro de 1 dia:
A lista de implantações usa regras de tempo diferentes. Nela,
since e until aceitam apenas timestamps RFC3339, e os dois são inclusivos. Eles comparam o horário em que a implantação terminou.Versão da resposta de problemas
A lista e o detalhe de problemas aceitamresponse_version=1, response_version=2, response_version=3 ou response_version=4. A versão 1 é a padrão. Outro valor falha com 422 e validation_failed.
- A versão 1 mostra o estado arquivado como
ignored. Ela não mostra a prioridade. - A versão 2 mostra o estado arquivado como
archived. Ela adicionapriorityepriority_source. - A versão 3 tem todos os campos da versão 2. Ela adiciona
assignee. - A versão 4 tem todos os campos da versão 3.
assigneetemtype:userouteam.
status=archived, priority e assignee. Veja a resposta de problema.
Filtro de gravidade
Useseverity=info|warning|error|critical em GET /api/logs. O parâmetro antigo level é um alias de compatibilidade. Os dois parâmetros aceitam os valores canônicos e os aliases trace, debug, warn e fatal. O LogBrew troca um alias pelo valor canônico antes de comparar.
Se uma requisição enviar severity e level, o LogBrew normaliza os dois primeiro. Valores conflitantes são rejeitados com:
Filtros de trace
Na busca de traces,status é error ou ok. Omita esse parâmetro para incluir os dois. min_duration_ms precisa ser zero ou maior. Ele vale apenas para a busca de traces.
Esta requisição encontra traces de erro que levaram pelo menos 500 milissegundos:
trace_id no caminho, com codificação percentual. Não envie esse valor como parâmetro de consulta.
Escopo do projeto
Useproject_id=<project-uuid> para ler um projeto. Nas rotas em que a matriz lista project_ids, use project_ids=<uuid>,<uuid> para um conjunto exato de 2 a 50 projetos. Nessas rotas, omita os dois parâmetros para ler todos os projetos que a conta pode ler. Uma rota que exige project_id aceita só 1 projeto.
422 e validation_failed:
- Uma requisição que tem
project_ideproject_idsao mesmo tempo. - Um valor de
project_idscom menos de 2 ou mais de 50 IDs. - Um ID duplicado ou um ID que não é um UUID.
project_ids for de um projeto que a conta não pode ler, a requisição falha com 404 e not_found. Não remova esse ID para continuar. Peça ao usuário para escolher um novo conjunto.
Mantenha o mesmo escopo de projeto em todas as páginas do cursor. Não remova o filtro de projeto depois de um resultado vazio, porque isso responde a uma pergunta diferente.
Séries por intervalo
GET /api/telemetry/metrics/series retorna uma métrica dividida em intervalos de tempo. GET /api/telemetry/summary/volume retorna contagens de sinais divididas em intervalos de tempo. As duas rotas seguem estas regras:
sinceé obrigatório.untilé opcional e, por padrão, é o horário da requisição.- O período de
sinceatéuntiltem no máximo 31 dias. intervaléauto,1m,5m,15m,1h,6hou1d. O padrão éauto. Um valor que gere mais de 500 intervalos no gráfico falha.service_name,releaseeenvironmentsão filtros exatos.
name é o nome exato da métrica em GET /api/telemetry/metrics. group_by é none, service_name, release ou environment. series_limit vai de 1 a 20.
No volume de sinais, until não pode estar no futuro, e response_version aceita apenas 1.
Filtre atributos de log
UseGET /api/logs/attributes para encontrar os caminhos e os tipos de atributo que você pode pesquisar. Depois envie attribute_filters para GET /api/logs. As duas requisições precisam de since.
Leia o catálogo de atributos
Esta requisição encontra os caminhos numéricos que contêmstatus em um projeto:
type é string, number ou boolean. observed_count é o número de logs do período que têm esse caminho e esse tipo. last_seen_at é o horário do log mais recente entre eles. Um log pode ter muitos caminhos. Não some as contagens para obter um número de logs.
coverage informa quais logs um filtro de atributo consegue pesquisar:
Os 3 grupos somam
total_logs. O type, o search e o cursor do catálogo não mudam a cobertura. Uma lista attributes vazia não significa que total_logs é zero.
O catálogo não tem o parâmetro status. O filtro de gravidade dele compara a gravidade capturada, não a gravidade efetiva.
search é um trecho de caminho de 1 a 128 bytes, sem caracteres de controle. limit define o número de atributos por página.
Continue o catálogo
O catálogo não usapagination=cursor. Repita todos os filtros e copie os 3 campos de next_cursor:
Pare quando
next_cursor for null.
Aplique um filtro tipado
Copie o caminho e o tipo do catálogo. Os caminhos usam a sintaxe JSON Pointer, não chaves separadas por pontos. Mantenha sem alteração qualquer escape~0 ou ~1 no caminho.
Esta requisição lê os logs cujo status numérico de resposta é 500 ou mais:
attribute_filters é um array JSON de 1 a 4 filtros. Um log precisa corresponder a todos os filtros. Cada filtro tem path, type, operator e value. O tipo JSON de value precisa corresponder a type: o número 500 não é a string "500".
ne só corresponde a logs que têm o caminho. Um log sem o caminho não corresponde a ne. Em string, case_sensitive é opcional e o padrão é false. O LogBrew rejeita "case_sensitive": true em number e boolean.
Estes limites se aplicam:
- O array JSON tem no máximo 4.096 bytes.
- Um valor de string tem no máximo 1.024 bytes.
containsestarts_withprecisam de uma string não vazia.- Um número precisa ser finito e estar entre -9.007.199.254.740.992 e 9.007.199.254.740.992.
attribute_filters. Para a resposta de log, veja Resposta de log.
Corrija erros de atributos
Cada erro abaixo retorna422 com validation_failed:
Corrija a requisição antes de tentar de novo. Não remova um filtro, porque isso muda o resultado.
Paginação por cursor
O modo cursor só funciona quando você o ativa. Sem ele, as rotas de lista retornam um array simples. Enviepagination=cursor sem campos de cursor para pedir a primeira página. Para cada página seguinte, repita todos os filtros e envie o conjunto completo de campos de cursor:
Passe os campos de
next_cursor retornados para a próxima requisição:
next_cursor.timevai paracursor_time.next_cursor.idvai paracursor_id.- Em traces,
next_cursor.trace_idvai paracursor_trace_id. - Em versões, adicione
cursor_antes do nome de cada campo retornado. Por exemplo,next_cursor.releasevai paracursor_release.
next_cursor for null. Não calcule um cursor a partir da última linha. O cursor de versões não muda os projetos selecionados. Mantenha o project_id ou o project_ids original.
limit define o tamanho da página. Uma página pode ter menos linhas. Estas rotas não aceitam page nem page_number.
Na maioria das rotas, o LogBrew troca um
limit acima do máximo pelo próprio máximo. A lista de implantações rejeita um limit fora do intervalo de 1 a 100 com 422. A lista de implantações sempre retorna um objeto de página com next_cursor, mesmo sem pagination=cursor.
O LogBrew rejeita estas requisições com 422 e validation_failed:
- Um valor de
paginationdiferente decursor. - Campos de cursor sem
pagination=cursor. - Um conjunto incompleto de campos de cursor.
- Um
cursor_timeque não é um timestamp RFC3339.
Diagnostique um resultado vazio
Uma lista vazia significa que nenhuma linha correspondeu a todos os filtros. Ela não diz nada sobre outros sinais. Confira a requisição nesta ordem:- Confirme o ID do projeto.
- Remova os filtros opcionais, um de cada vez.
- Amplie
sincese o evento esperado for mais antigo. Removauntilou mova esse horário para mais tarde se o evento esperado for mais recente. - Compare
service_name,releaseeenvironmentcom os valores que o seu SDK envia. - Em logs, adicione
status=allse uma regra de log puder estar escondendo o log esperado. - Confirme que a rota aceita cada filtro.
Corrija uma consulta rejeitada
Uma consulta rejeitada retorna o envelope de erro padrão. Um parâmetro desconhecido ou um valor do tipo errado retorna422:
- Troque um alias amigável pelo parâmetro que aparece na matriz de filtros.
- Envie todos os campos de cursor de continuação que a rota exige.
- Remova os campos de cursor da requisição da primeira página.
- Use apenas um seletor de projeto.
- Troque uma gravidade ou um status de trace não aceito por um valor canônico.
