Conheça as regiões, projetos, Logstores, logs e outras estruturas de dados do Simple Log Service (SLS).
Os conceitos a seguir descrevem o modelo de dados do SLS.
Região
Uma região é um nó de serviço da Alibaba Cloud. Implante serviços em diferentes regiões para reduzir a latência de acesso dos seus usuários.
Projeto
O projeto é a unidade básica de gerenciamento no SLS para isolamento e controle de recursos. Use um projeto para gerencie todos os logs e fontes de log de uma aplicação.
Logstore
O Logstore é a unidade de coleta, armazenamento e consumo de logs no SLS. Cada Logstore pertence a um projeto, e um projeto pode conter vários Logstores. Como melhor prática, crie um Logstore por tipo de log. Por exemplo, para uma aplicação de jogos chamada big-game que gera logs de operação, logs de aplicação e logs de acesso, crie um projeto chamado big-game com três Logstores — um para cada tipo de log.
Log
O log é a menor unidade de dados no SLS. O SLS utiliza o seguinte modelo de dados semiestruturado:
| Campo | Descrição | Requisitos |
| time | Campo reservado. Momento de geração do log, geralmente extraído do timestamp do log. | Inteiro. Timestamp UNIX em segundos (segundos decorridos desde 00:00:00 UTC, 1º de janeiro de 1970). |
| topic | Campo personalizado para categorizar logs. Por exemplo, categorize logs de acesso por site. | Qualquer string, incluindo string vazia, com até 128 bytes. O padrão é uma string vazia. |
| source | Origem do log, como o endereço IP da máquina de origem. | Qualquer string codificada em UTF-8 com até 128 bytes. O padrão é uma string vazia. |
| content | Conteúdo do log, composto por um ou mais pares chave-valor. | Chave: string UTF-8 de até 128 bytes. Caracteres permitidos: letras, dígitos e sublinhados (_). Não pode começar com dígito. Chaves reservadas:
|
| tags | Tags de log:
|
Formato de dicionário. Tanto a chave quanto o valor são strings. No console, as tags aparecem com o prefixo __tag__:. |
Tópico
Categorize os logs de um Logstore por tópico. Especifique um tópico ao gravar logs e filtre por tópico nas consultas. Por exemplo, use o ID do usuário como tópico para que cada usuário visualize apenas seus próprios logs. Caso a categorização seja desnecessária, use o mesmo tópico para todos os logs.
Uma string vazia é um tópico válido e representa o padrão tanto para gravação quanto para consulta. Se não precisar de tópicos, use a string vazia padrão.
O exemplo a seguir mapeia um log de acesso bruto do Nginx para o modelo de dados do SLS. O endereço IP do servidor Nginx é 10.10.10.1:
10.1.1.1 - - [01/Mar/2012:16:12:07 +0800] "GET /Send?AccessKeyId=82251054** HTTP/1.1" 200 5 "-" "Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2"Este log bruto é mapeado para o modelo de dados do SLS da seguinte forma:
|
Campo |
Conteúdo |
Descrição |
|
topic |
Nenhum |
Usa-se o valor padrão (string vazia). |
|
time |
1330589527 |
Hora exata da geração do log em segundos, convertida a partir do timestamp do log bruto. |
|
source |
10.10.10.1 |
O endereço IP do servidor serve como origem do log. |
|
content |
Pares chave-valor |
Conteúdo específico do log. |
Extraia o conteúdo do log bruto em pares chave-valor conforme abaixo:
|
chave |
valor |
|
ip |
10.1.1.1 |
|
method |
GET |
|
status |
200 |
|
length |
5 |
|
ref_url |
- |
|
browser |
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 |
Logs
Conjunto de logs.
LogGroup
Grupo de logs.
LogGroupList
Coleção de LogGroups usada para retornar resultados.
Métodos de codificação
O SLS oferece suporte aos seguintes métodos de codificação. Especifique o método por meio do cabeçalho
Content-Type
na API RESTful.
|
Significado |
Descrição |
Content-Type |
|
Protobuf |
Modelo de dados codificado em Protobuf. |
application/x-protobuf |
Detalhes do formato Protobuf: Métodos de codificação de dados.
O Protobuf não exige pares chave-valor exclusivos, mas chaves duplicadas podem causar comportamento indefinido.
Codifique os campos na ordem de seus números de campo Protobuf. Campos fora de ordem podem falhar na análise.