O store é a unidade básica de armazenamento e consulta de dados no SLS. O SLS oferece três tipos de store para diferentes categorias de dados: Logstore, Metricstore e Eventstore.
Escolha um tipo de store
Cada tipo de store possui um modelo de dados subjacente distinto. Escolha o tipo correspondente à estrutura dos seus dados: logs, métricas ou eventos. Caso não tenha requisitos específicos, utilize o Logstore como padrão.
|
Tipo de store |
Descrição |
|
Logstore |
|
|
Metricstore |
Métrica: Série temporal composta por um identificador único e uma sequência de pontos de dados. Utilize um Metricstore para armazenar e consultar dados de séries temporais com eficiência. |
|
Eventstore |
Evento: Registro de uma ocorrência significativa, como um alerta de monitoramento ou o resultado de uma inspeção periódica. Use um Eventstore para armazenar dados discretos baseados em eventos. |
Logstore
O logstore é a unidade básica para armazenamento e consulta de dados de log. Cada logstore pertence a um projeto. Crie vários logstores em um projeto para isolar diferentes tipos de logs da mesma aplicação. Por exemplo, para coletar logs de operação, logs de aplicação e logs de acesso da aplicação A, crie um projeto chamado app-a. Nesse projeto, crie os logstores operation_log, application_log e access_log para armazenar cada tipo de log separadamente.
Especifique um logstore ao gravar, consultar, analisar, processar, consumir ou enviar logs:
Colete e grave logs em um logstore.
Armazene logs em um logstore para processamento, consumo ou entrega.
Crie índices em um logstore para consultar e analisar logs.
Metricstore
O metricstore é a unidade básica para armazenar e consultar dados de séries temporais (métricas). Cada metricstore pertence a um projeto. Crie vários metricstores em um projeto para separar diferentes tipos de dados de séries temporais. Por exemplo, para coletar dados básicos de monitoramento de host, dados de monitoramento de serviços em nuvem e dados de monitoramento de aplicações, crie um projeto chamado demo-monitor. Em seguida, nesse projeto, crie os metricstores host-metrics, cloud-service-metrics e app-metrics para armazenar esses tipos de dados separadamente.
Especifique um metricstore ao gravar, consultar, analisar ou consumir dados de séries temporais:
Colete dados de séries temporais em um metricstore como unidade de coleta.
Utilize um metricstore para armazenar dados de séries temporais destinados a análise e consumo.
Consulte e analise dados de séries temporais usando Prometheus Query Language (PromQL), SQL-92 ou sintaxe SQL+PromQL.
Eventstore
O eventstore é a unidade básica para armazenar e consultar dados de eventos. Cada eventstore pertence a um projeto. Crie vários eventstores em um projeto para separar diferentes tipos de eventos, como eventos de anomalia de infraestrutura, eventos de aplicações de negócios e eventos personalizados.
Especifique um eventstore ao gravar, consultar, analisar ou consumir dados de eventos:
Colete dados de eventos tendo o eventstore como unidade de coleta.
Armazene dados de eventos e execute operações de consumo tendo o eventstore como unidade de armazenamento.
Referências
Grupo de logs
Um grupo de logs agrupa vários logs como unidade básica de leitura e gravação. Logs no mesmo grupo compartilham metadados, como endereço IP e source. O agrupamento reduz operações de I/O e melhora a eficiência. Tamanho máximo do grupo: 5 MB.

Log
Um log registra eventos ou alterações em um sistema ao longo do tempo. Ele pode representar arquivos de texto, eventos de sistema, BinLogs de banco de dados ou dados de séries temporais. No SLS, um log utiliza um modelo semiestruturado com cinco campos: topic, time, content, source e tags. A tabela a seguir lista os requisitos de formato.
|
Campo |
Descrição |
Formato |
|
Topic |
O SLS usa o campo reservado A relação entre logstore, tópicos e shards é a seguinte: |
String de 0 a 128 bytes, incluindo string vazia. Se não for necessário distinguir logs dentro de um logstore, defina o tópico como uma string vazia durante a coleta. Uma string vazia é um tópico válido. |
|
Time |
O campo reservado ( |
Timestamp UNIX. |
|
Content |
Conteúdo do log, composto por um ou mais pares Ao usar o Logtail no modo simples (linha única ou múltiplas linhas) para coletar logs, o conteúdo não é analisado. Todo o log bruto é carregado no campo content. |
Formato
|
|
Source |
O campo reservado ( |
String de 0 a 128 bytes. |
|
Tags |
Tags de log, que incluem:
|
Dicionário de pares chave-valor do tipo string. Em um log, as tags são exibidas com o prefixo |
Exemplo
O exemplo a seguir utiliza um log de acesso a site para mostrar o mapeamento entre um log bruto e o modelo de dados no SLS.
-
Log bruto
127.0.0.1 - - [01/Mar/2021:12:36:49 0800] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 -
Log coletado no modo simples. Todo o log bruto é salvo no campo content.

-
Log coletado no modo de expressão regular. O conteúdo do log é estruturado pela extração de vários pares chave-valor com base na expressão regular configurada.

Métrica
Dados de séries temporais consistem em um identificador de métrica e pontos de dados. Pontos com o mesmo identificador formam uma série temporal. O modelo do SLS é compatível com o modelo de dados do Prometheus. Todos os dados do metricstore são armazenados como séries temporais.

Identificador de métrica
Cada série temporal é identificada exclusivamente pelo nome da métrica e por um conjunto de rótulos.
O nome da métrica é uma string que identifica seu tipo e deve corresponder à expressão regular [a-zA-Z_:][a-zA-Z0-9_:]*. Por exemplo, http_request_total representa o número total de solicitações HTTP recebidas.
Rótulos são um conjunto de pares chave-valor que identificam os atributos da métrica. A chave deve corresponder à expressão regular [a-zA-Z_][a-zA-Z0-9_]*. O valor não pode conter uma barra vertical (|). Por exemplo, method é POST e URL é /api/v1/get.
Ponto de dados
Um ponto de dados captura o valor de uma série temporal em um momento específico. Cada ponto consiste em um timestamp (precisão de nanossegundos) e um valor double.
Estrutura de dados
Dados de séries temporais usam o mesmo protocolo de gravação de codificação de dados Protobuf que os logs. O identificador e os pontos de dados são armazenados no campo content:
|
Campo |
Descrição |
Exemplo |
|
__name__ |
Nome da métrica. |
nginx_ingress_controller_response_size |
|
__labels__ |
Informações de rótulo. Formato: Nota
|
app#$#ingress-nginx|controller_class#$#nginx|controller_namespace#$#kube-system|controller_pod#$#nginx-ingress-controller-589877c6b7-hw9cj |
|
__time_nano__ |
Os timestamps suportam múltiplas precisões (s, ms, us, ns), mas são sempre normalizados para microssegundos (us) nos resultados da consulta para garantir cálculos consistentes. |
1585727297293000 |
|
__value__ |
Valor. |
36,0 |
Campos personalizados como Topic, Source ou LogTags não são armazenados no metricstore quando gravados via SDK. Para mais informações, consulte Enviar métricas com SDKs.
Exemplo
O exemplo a seguir mostra uma consulta de todos os dados brutos de séries temporais da métrica process_resident_memory_bytes em um intervalo de tempo especificado.
* | select * from "sls-mall-k8s-metrics.prom" where __name__ = 'process_resident_memory_bytes' limit all

Evento
Um evento é um registro de dados significativo, como um alerta de monitoramento ou o resultado de um trabalho de inspeção periódica. Os dados de eventos no SLS seguem a especificação CloudEvents, conforme descrito na tabela a seguir.
|
Tipo de campo |
Nome do campo |
Obrigatório |
Formato de dados |
Descrição |
|
Protocolo |
|
Sim |
String |
O valor padrão é |
|
|
Sim |
String |
ID do evento. Use |
|
|
|
Sim |
String |
Contexto em que o evento ocorreu, como a origem do evento ou a instância que o publicou. |
|
|
|
Sim |
String |
Tipo de evento, como |
|
|
|
Não |
String |
Assunto do evento. Este campo fornece informações adicionais ao campo |
|
|
|
Não |
String |
Tipo de conteúdo do valor de dados. O padrão é |
|
|
|
Não |
URI |
Esquema ao qual o valor de |
|
|
|
Não |
JSON |
Conteúdo específico do evento. O formato varia conforme a origem e o tipo do evento. |
|
|
|
Sim |
Timestamp |
Timestamp do evento, formatado de acordo com a RFC 3339. Exemplo: |
|
|
Extensão |
|
Sim |
String |
Título do evento. |
|
|
Sim |
String |
Descrição do evento. |
|
|
|
Sim |
String |
Status do evento. Valores válidos:
|
Exemplo
O exemplo a seguir mostra os dados de um evento de alerta:
{
"specversion": "1.0",
"id": "af****6c",
"source": "acs:sls",
"type": "sls.alert",
"subject": "https://sls.console.alibabacloud.com/lognext/project/demo-alert-chengdu/logsearch/nginx-access-log?encode=base64&endTime=1684312259&queryString=c3RhdHVzID49IDQwMCB8IHNlbGVjdCByZXF1ZXN0X21ldGhvZCwgY291bnQoKikgYXMgY250IGdyb3VwIGJ5IHJlcXVlc3RfbWV0aG9kIA%3D%3D&queryTimeType=99&startTime=1684311959",
"datacontenttype": "application/cloudevents+json",
"data": {
"aliuid": "16****50",
"region": "cn-chengdu",
"project": "demo-alert-chengdu",
"alert_id": "alert-16****96-247190",
"alert_name": "Nginx Access Error",
"alert_instance_id": "77****e4-1aad9f7",
"alert_type": "sls_alert",
"next_eval_interval": 300,
"fire_time": 1684299959,
"alert_time": 1684312259,
"resolve_time": 0,
"status": "firing",
"severity": 10,
"labels": {
"request_method": "GET"
},
"annotations": {
"__count__": "1",
"cnt": "49",
"desc": "Nginx has had 49 GET request errors in the last five minutes",
"title": "Nginx Access Error Alert Triggered"
},
"results": [
{
"region": "cn-chengdu",
"project": "demo-alert-chengdu",
"store": "nginx-access-log",
"store_type": "log",
"role_arn": "",
"query": "status >= 400 | select request_method, count(*) as cnt group by request_method ",
"start_time": 1684311959,
"end_time": 1684312259,
"fire_result": {
"cnt": "49",
"request_method": "GET"
},
"raw_results": [
{
"cnt": "49",
"request_method": "GET"
},
{
"cnt": "3",
"request_method": "DELETE"
},
{
"cnt": "7",
"request_method": "POST"
},
{
"cnt": "6",
"request_method": "PUT"
}
],
"raw_result_count": 4,
"truncated": false,
"dashboard_id": "",
"chart_title": "",
"is_complete": true,
"power_sql_mode": "auto"
}
],
"fire_results": [
{
"cnt": "49",
"request_method": "GET"
}
],
"fire_results_count": 1,
"condition": "Count:[1] > 0; Condition:[49] > 20",
"raw_condition": "Count:__count__ > 0; Condition:cnt > 20"
},
"time": "2023-05-17T08:30:59Z",
"title": "Nginx Access Error Alert Triggered",
"message": "Nginx has had 49 GET request errors in the last five minutes",
"status": "error"
}
Trace
Um trace registra o processamento de ponta a ponta de uma única solicitação, incluindo todas as chamadas de serviço e suas durações. Ele representa o caminho de execução de uma transação ou processo em um sistema distribuído. De acordo com o padrão OpenTracing, um trace é um Grafo Acíclico Direcionado (DAG) de spans, onde cada span representa um segmento de execução nomeado, cronometrado e contínuo. A estrutura completa de dados está definida em Formato de dados de Trace.