Todos os produtos
Search
Central de documentação

Simple Log Service:Gerencie stores

Última atualização: Jul 03, 2026

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

  • Log: Registro de eventos ou alterações em um sistema ao longo do tempo. Os dados de log consistem em uma coleção ordenada de operações e seus resultados. Essa definição abrangente cobre a maioria dos tipos de dados, tornando o Logstore a escolha padrão.

  • Trace: Registra informações de processamento de uma única solicitação, incluindo chamadas de serviço e durações de processamento.

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 group

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 __topic__ para identificar o tópico do log e distinguir logs gerados por diferentes serviços, usuários ou instâncias. Por exemplo, se um sistema contém módulos de processamento de solicitações HTTP front-end, cache, processamento lógico e armazenamento, defina um tópico para os logs de cada módulo (como http_module, cache_module, logic_module e store_module). Após a coleta dos logs no mesmo logstore, use o tópico para identificar rapidamente sua origem. Geralmente, o tópico do log é definido na configuração global das Configurações do Logtail.

A relação entre logstore, tópicos e shards é a seguinte:

image

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 (__time__) identifica o horário do log. Para mais informações, consulte Campos reservados.

Timestamp UNIX.

Content

Conteúdo do log, composto por um ou mais pares Key:Value.

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 Key:Value:

  • Key: String UTF-8 de 1 a 128 bytes, composta por letras, dígitos e sublinhados (_). Não pode começar com um dígito. Não utilize os seguintes nomes de campos reservados:

    • __time__

    • __source__

    • __topic__

    • __partition_time__

    • _extract_others_

    • __extract_others__

  • Value: Qualquer string com tamanho máximo de 1 MB.

Source

O campo reservado (__source__) identifica a origem do log, como o endereço IP do servidor que o gerou.

String de 0 a 128 bytes.

Tags

Tags de log, que incluem:

  • Tags personalizadas: Adicione essas tags ao gravar logs chamando a operação da API PutLogs.

  • Tags de sistema: Tags que o SLS adiciona aos logs, incluindo __client_ip__ e __receive_time__.

Dicionário de pares chave-valor do tipo string. Em um log, as tags são exibidas com o prefixo __tag__:.

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 example

  • 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.

    Log example

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.

image

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: {key}#$#{value}|{key}#$#{value}|{key}#$#{value}.

Nota
  • As chaves dos rótulos devem ser classificadas em ordem alfabética.

  • Não grave rótulos com valores vazios (como app=""). Rótulos com valores vazios são inválidos no modelo de dados do Prometheus e causam erros durante agregações PromQL.

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

Nota

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

image

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

specversion

Sim

String

O valor padrão é 1.0, em conformidade com a especificação CloudEvents.

id

Sim

String

ID do evento. Use source+id para identificar exclusivamente o evento.

source

Sim

String

Contexto em que o evento ocorreu, como a origem do evento ou a instância que o publicou.

type

Sim

String

Tipo de evento, como sls.alert.

subject

Não

String

Assunto do evento. Este campo fornece informações adicionais ao campo source, como o objeto que acionou o evento.

datacontenttype

Não

String

Tipo de conteúdo do valor de dados. O padrão é application/cloudevents+json.

dataschema

Não

URI

Esquema ao qual o valor de data deve aderir. O valor padrão é vazio.

data

Não

JSON

Conteúdo específico do evento. O formato varia conforme a origem e o tipo do evento.

time

Sim

Timestamp

Timestamp do evento, formatado de acordo com a RFC 3339. Exemplo: 2022-10-17T11:20:45.984+0800.

Extensão

title

Sim

String

Título do evento.

message

Sim

String

Descrição do evento.

status

Sim

String

Status do evento. Valores válidos:

  • ok

  • info

  • warning

  • error

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.