Pular para o conteúdo principal
Busque linhas de log com a API pública (V2). Esta é a forma de consultar logs programaticamente, incluindo dados de log estruturados (JSON). A API GraphQL não expõe linhas de log.
Se você está construindo um agente ou assistente de IA, o AppSignal MCP expõe a busca de logs e outros dados de monitoramento diretamente aos agentes, sem precisar chamar esta API por conta própria.

Encontrando seus IDs de site e fonte

Uma busca em logs precisa de um site_id e um ou mais source_ids. Ambos aparecem na URL de uma fonte de log na AppSignal. Abra uma fonte de log e leia-os no path:
https://appsignal.com/<organization>/sites/<SITE_ID>/logs/sources/<SOURCE_ID>

Buscar linhas de log

POST /api/v2/logs/lines

Corpo da requisição

CampoTipoObrigatórioDescrição
site_idstringSimSite a ser consultado.
source_idsstring[]SimIDs de fonte de log a serem buscados. Pelo menos um é obrigatório.
querystringSimString de query que filtra linhas de log. Veja linguagem de query.
use_expressionsbooleanNãoQuando true, parseia query com a linguagem de query baseada em expressões.
fromstring (ISO 8601)NãoInício do intervalo de tempo. Padrão é o limite inferior de retenção.
tostring (ISO 8601)NãoFim do intervalo de tempo. Padrão é o horário atual.
paginationobjectSimCursor e direção da paginação (veja a seção a seguir).
Defina use_expressions como true para usar a linguagem de query baseada em expressões documentada nesta página. pagination recebe per_page (número), order (ASC ou DESC) e um cursor com um campo time (um timestamp ISO 8601, ou null na primeira página). Para buscar a próxima página, envie o timestamp da última linha recebida como cursor.time da próxima requisição.

Exemplo de requisição

curl --request POST \
  --url "https://appsignal.com/api/v2/logs/lines" \
  --header "Authorization: Bearer YOUR-PERSONAL-API-TOKEN" \
  --header "Content-Type: application/json" \
  --data @body.json
{
  "site_id": "YOUR-SITE-ID",
  "source_ids": ["YOUR-LOG-SOURCE-ID"],
  "query": "severity=error status_code=401",
  "use_expressions": true,
  "from": "2026-06-22T00:00:00Z",
  "to": "2026-06-22T23:59:59Z",
  "pagination": {
    "per_page": 100,
    "order": "DESC",
    "cursor": { "time": null }
  }
}

Resposta

O endpoint retorna um array de linhas de log. Cada linha inclui estes campos:
CampoTipoDescrição
idstringIdentificador da linha de log.
timestampstring (ISO 8601)Quando a linha de log foi registrada.
source_idstringFonte de log a que a linha pertence.
severitystringNível de severidade, como info ou error.
messagestringO corpo da mensagem de log.
hostnamestringHost que produziu a linha.
groupstringGrupo de log.
jsonstringO corpo estruturado (JSON) bruto da linha de log, quando disponível.
attributesobjectAtributos chave-valor tipados legados. Sendo descontinuado — prefira json.
Campos estruturados como status_code, path ou detail vivem no campo json, não em attributes. Consulte-os pela chave exata como aparece no JSON do seu log (por exemplo, status_code=401 ou detail.message:"required").

Linguagem de query

Quando use_expressions é true, a string query suporta lógica booleana sobre campos da linha de log e o corpo json estruturado.

Operadores

OperadorNomeComportamento
=IgualCorrespondência exata.
!=DiferenteNão correspondência exata.
:ContémCorrespondência por substring.
!:Não contémNão correspondência por substring.
>Maior queComparação numérica.
>=Maior ou igualComparação numérica.
<Menor queComparação numérica.
<=Menor ou igualComparação numérica.
Operadores de string (=, !=, :, !:) comparam ambos os lados como strings. Operadores numéricos (>, >=, <, <=) convertem ambos os lados em número; se um valor não puder ser parseado como número, aquela linha de log é ignorada.

Combinando expressões

  • AND / OR: severity=error AND hostname:web, ou severity=info OR severity=warn.
  • AND implícito: um espaço entre expressões significa AND. severity=error hostname:web é o mesmo que severity=error AND hostname:web.
  • Aninhamento com parênteses: message:"API request" AND (severity=info OR severity=warn).
  • Precedência: AND tem precedência maior que OR.
Qualquer operador pode ser usado dentro de um grupo OR, não só igualdade — por exemplo, message:"API request" AND (user.id>1000 OR user.email:"example.com").

Campos

Dada uma linha de log com este corpo JSON:
{
  "message": "API request completed",
  "severity": "info",
  "duration": 156.7,
  "status_code": 200,
  "user": {
    "id": 12345,
    "roles": ["admin", "developer"],
    "location.country": "US"
  }
}
  • Campos base: message, severity, hostname e group correspondem aos campos de nível superior da linha de log.
  • JSON aninhado: use notação de ponto para alcançar dentro do corpo json, como status_code=200 ou user.id=12345.
  • Arrays JSON: indexe elementos do array, como user.roles.0=admin.
  • Pontos escapados: para corresponder a um ponto literal em um nome de chave, escape-o. user.location\.country=US corresponde à chave location.country dentro de user, em vez de um objeto country aninhado.
  • Campo padrão: um termo isolado sem campo corresponde a message com o operador contains. timeout é o mesmo que message:timeout.
Você não precisa prefixar com attributes. nem adicionar um sufixo de tipo para consultar um campo — referencie-o diretamente pelo nome. Veja sintaxe de query legada se você tem queries mais antigas.

Aspas em valores

Envolva valores que contêm espaços ou parênteses entre aspas duplas. Caso contrário, o espaço divide o valor em expressões separadas unidas por AND implícito.
message:"hello world"           matches message containing "hello world"
message:hello world             parsed as message:hello AND message:world
severity=error message:"oh no"  severity equals error AND message contains "oh no"
Apenas aspas duplas são reconhecidas. Dentro de um valor entre aspas, escape uma aspa com \" e uma barra invertida com \\. Por exemplo, message:"value with \"quotes\"" corresponde ao texto value with "quotes".

Sintaxe de query legada

Queries mais antigas armazenavam atributos como campos tipados, então precisavam prefixar attributes., adicionar um sufixo de tipo (_string, _int) e usar uma lista [ ] para múltiplos valores. A linguagem de query atual remove todas as três — referencie campos diretamente e use OR em vez de uma lista:
message:"API request" attributes.user_id_int=12345 severity=[info, warn]
Uma query que ainda usa a sintaxe legada retorna 422 com o slug de erro legacy_log_query_syntax.