Um LogStore é uma unidade de armazenamento no Simple Log Service (SLS) usada para coletar, armazenar e consultar dados de log.
Conceitos fundamentais
O que é um LogStore?
O LogStore é um contêiner de dados no Simple Log Service. Você pode criar vários LogStores em um Project para isolar e gerenciar logs de diferentes aplicações ou fontes.
Melhores práticas de planejamento de LogStore
Crie um LogStore separado para cada fonte ou tipo de log. Por exemplo, armazene logs de acesso e logs de erro do NGINX em LogStores distintos. Essa prática evita a mistura de logs e simplifica consultas futuras, análises, isolamento de permissões e auditorias de conformidade.
Para atender aos requisitos de proteção classificada de Nível 3 e normas similares, use um Project como limite unificado de controle de acesso. Crie LogStores separados nesse Project para cada tipo de log, como logs de servidor, logs de banco de dados e logs de operação do console. Essa organização facilita o armazenamento categorizado e a rastreabilidade de auditoria.
O LogStore não categoriza logs automaticamente por ano, mês, dia ou hora, nem cria pastas automaticamente. A consulta de logs depende inteiramente dos campos de tempo reais presentes no conteúdo do log.
Além disso, alguns services da Alibaba Cloud ou recursos do SLS criam automaticamente LogStores dedicados para finalidades específicas. Esses LogStores não aceitam outros tipos de dados. Confira os exemplos a seguir:
internal-operation_log: armazena detailed operation logs gerados pelo próprio Simple Log Service.oss-log-store: criado automaticamente ao configurar OSS access logs para arquivamento.
Comparação de especificações de LogStore
O Simple Log Service oferece dois tipos de LogStore — Standard e Query — que diferem em features e custo.
Tipo | Custo (Comparação de Taxa de Tráfego de Índice) | Cenários |
Standard | USD 0.0875/GB | Indicado para análises interativas, monitoramento em tempo real, visualização ou construção de sistemas de observabilidade. |
Tipo Query (Query) | USD 0.0146/GB | Este tipo não suporta análises. Use-o para arquivamento de logs, armazenamento de logs de auditoria ou cenários de troubleshooting em que apenas a busca rápida por palavras-chave seja necessária, sem análise. Casos de uso típicos incluem retenção de longo prazo (meses ou anos) com acesso pouco frequente. |
Escopo e permissões
Criar um LogStore básico
Console
Faça login no console do Simple Log Service. Na lista de Projects, clique em no Project desejado.
Na aba , clique em no ícone +.
-
Na página Create Logstore, configure as definições e clique em OK.
Tipo de LogStore: Standard por padrão.
-
Modo de faturamento:
Pay-by-feature: O faturamento ocorre separadamente para cada recurso usado (como armazenamento, indexação e operações de leitura/escrita). Você recebe uma cota gratuita mensal, o que ajuda a controlar custos em cenários de pequena escala.
Pay-by-ingested-data: O pagamento refere-se apenas ao volume bruto de dados ingeridos. O armazenamento e os recursos principais são gratuitos por 30 dias, oferecendo um modelo de preços mais simples e econômico.
Dica rápida: Quanto mais próximo seu período de retenção estiver de 30 dias e quanto mais campos você indexar (especialmente indexação full-text), mais vantajoso se torna o modelo pay-by-ingested-data.
Nome do LogStore: Deve ser único dentro do Project e não pode ser alterado após a criação.
Período de retenção de dados: 30 dias por padrão.
Mantenha todas as outras configurações com seus valores padrão.
API
Modificar configuração do LogStore
Você pode configurar os seguintes parâmetros durante a criação. Esta seção usa a modificação do LogStore como exemplo.
Clique em
Log Storage. Na página de LogStores, passe o mouse sobre o LogStore desejado e selecione .Nas propriedades do LogStore, modifique as configurações relevantes conforme seu cenário.
Excluir logs específicos ou definir período de retenção
Console
Em Basic Information, clique em Modify, ajuste o período de retenção de dados e clique em Save.
O Simple Log Service suporta a exclusão de entradas de log específicas por meio do recurso Log Soft Delete . Na página Query and Analysis do LogStore, insira as condições de consulta, selecione um intervalo de tempo e clique em Log Soft Delete para enviar uma tarefa de exclusão. As entradas de log excluídas não aparecem mais nas consultas subsequentes e são removidas permanentemente após o fim do período de retenção. Também é possível excluir logs expirados em lote alterando o período de retenção de dados ou stopping billing or deleting the LogStore para remover todos os logs.
Specified Days: Valores válidos: 1–3650. Definir como 3650 significa retenção permanente. Os logs são excluídos quando o período de retenção termina.
Permanent Storage: Retém os logs no LogStore indefinidamente.
As alterações entram em vigor imediatamente, mas a exclusão de dados expirados pode levar algum tempo.
Verificar se a alteração teve efeito
Após salvar a alteração, passe o mouse sobre o LogStore novamente e clique em Modify. Nas propriedades do LogStore, verifique se o número de dias exibido em Data Retention Period corresponde ao valor definido, confirmando que a configuração foi aplicada. Se a retenção permanente estiver ativada para o LogStore, nenhum número personalizado de dias será exibido, indicando que os logs neste LogStore são mantidos até que você altere a configuração.
Solucionar problemas de Período de Retenção de Dados que não pode ser modificado ou falha ao salvar
Se o Data Retention Period não puder ser editado (o botão de edição está esmaecido ou a duração do armazenamento não pode ser selecionada), ou se um erro for retornado ao salvar a alteração e as configurações de ciclo de vida não puderem ser concluídas, verifique os itens a seguir nesta ordem:
O LogStore é um LogStore dedicado criado automaticamente por um service da cloud ou pelo Simple Log Service. A criação automática aplica-se a LogStores dedicados do Redis, MongoDB e LogStores dedicados de gerenciamento do Simple Log Service, cujo período de retenção é gerenciado pelo service da cloud correspondente. Ao tentar salvar a alteração no console do Simple Log Service, uma mensagem solicitará que você realize a operação no console desse service da cloud. Para usar um período de retenção personalizado, ajuste-o no console do service da cloud correspondente ou crie um LogStore standard para seus logs de negócios.
O LogStore é um LogStore reservado pelo sistema com o prefixo
internal-, por exemplointernal-operation_log,internal-alert-historyouinternal-etl-log. Esse LogStore já está vinculado a uma configuração específica de importação de dados, e o console indica que ele está configurado para essa finalidade, impedindo a personalização de seus itens de configuração.A conta atual não tem permissões suficientes. Modificar a configuração de um LogStore exige permissões de gerenciamento de LogStore no Project alvo, ou seja, permissões como
log:*LogStorelistadas na seção Escopo e permissões deste tópico. Se você fizer login como usuário do Resource Access Management (RAM), solicite a política de sistemaAliyunLogFullAccessou uma política personalizada contendo essas permissões ao proprietário da conta Alibaba Cloud.A página do console não está sendo exibida corretamente. Atualize a página ou troque de navegador, passe o mouse sobre o LogStore alvo novamente, clique em Modify e tente modificar o Data Retention Period mais uma vez.
Em cenários padrão, também é possível concluir a configuração modificando o
ttlconforme descrito na aba API desta seção. Para os LogStores dedicados mencionados acima, ainda é necessário ajustar o período de retenção no console do service da cloud correspondente.
API
Ajuste o período de retenção de logs atualizando o valor ttl em Update Logstore.
Otimizar custos de armazenamento usando camadas
Console
Em Basic Information, clique em Modify e ative as camadas inteligentes.
-
Configure a Storage Policy: A soma dos dias das três camadas deve ser igual ao período total de retenção de dados.
Hot storage: mínimo de 7 dias.
IA storage class: mínimo de 30 dias.
Archive Storage: mínimo de 60 dias.
Defina Data retention period como Limited days, ative Intelligent tiering e configure as transições de camada em Storage policy: o hot storage transita automaticamente para a IA storage class após o término de seu período, a IA storage class transita para o Archive Storage, e o Archive Storage é excluído automaticamente após o fim de seu período.
Clique em Save. Para detalhes, consulte Intelligent tiering.
API
Ajuste dinamicamente a política de retenção para as camadas de armazenamento atualizando os valores ttl, hot_ttl e infrequentAccessTTL em Update Logstore.
Coletar logs de frontend
O Simple Log Service oferece o WebTracking para coletar logs de mini programas, aplicativos móveis (iOS/Android) e navegadores.
Você pode usar este recurso de duas formas:
Use STS authentication para transmissão. Este método é adequado para ambientes de produção e não requer alterações na configuração do LogStore.
Use anonymous transmission via OpenAPI. Este método destina-se apenas a testes e exige a ativação de uma configuração no LogStore, conforme descrito abaixo.
Console
Nas Propriedades Básicas, clique em Modify, ative o WebTracking e clique em Save.
API
Ative o WebTracking definindo o parâmetro enable_tracking como true em Update Logstore.
Adicionar IP público e horário de chegada do log automaticamente
Quando ativado, a ingestão subsequente de logs adiciona automaticamente:
__tag__:__client_ip__: o endereço IP público do dispositivo de origem do log.
__tag__:__receive_time__: o horário em que o log chega ao servidor do Simple Log Service, formatado como timestamp UNIX (segundos desde 1970-01-01 00:00:00 UTC).
Console
Nas Propriedades Básicas, clique em Modify, ative Record public IP e clique em Save.
API
Ative o registro de IP público definindo o parâmetro appendMeta em Update Logstore.
Ajustar desempenho de ingestão usando shards
Cada shard suporta 5 MB/s ou 500 escritas por segundo para ingestão, e 10 MB/s ou 100 leituras por segundo para consumo. Estes são limites flexíveis. O sistema tenta atender solicitações além desses limites, mas não garante a qualidade do service. Se o tráfego exceder a capacidade de um shard, divida-o para aumentar a capacidade.
Console
Nas Propriedades Básicas, clique em Modify, ative o Sharding automático, defina o limite de shards e clique em Save.
O Simple Log Service suporta splitting and merging shards individuais.
API
Parar faturamento ou excluir LogStore
Uma vez excluídos, todos os dados de log no LogStore são perdidos permanentemente e não podem ser recuperados. Proceda com cautela.
Antes de excluir um LogStore, avalie o impacto nos negócios. A exclusão geralmente não afeta as operações se o LogStore não for usado para monitoramento, alertas, análises ou auditorias, e se não for a source de dados para transformação, envio ou consultas via API. Antes de prosseguir, confirme que não restam configurações associadas importantes. Os dados de um LogStore excluído não podem ser recuperados.
Console
-
Limpeza antes da exclusão.
Exclua todas as configurações de Logtail associadas antes de excluir o LogStore. Esta é a única verificação de pré-requisito obrigatória que o console realiza ao excluir um LogStore: se ainda houver configurações de coleta Logtail associadas, o console informará que elas existem e devem ser excluídas primeiro, impedindo a continuidade da exclusão. Portanto, se um LogStore não puder ser excluído, remova primeiro todas as configurações de coleta Logtail dele e tente excluí-lo novamente.
Se o LogShipper estiver ativado para este LogStore, pare de gravar novos dados e confirme se todos os dados existentes foram enviados com sucesso antes da exclusão.
A Release Protection de um Project aplica-se ao próprio Project: após ativada, você deve desativá-la manualmente antes de poder excluir o Project. A exclusão de um único LogStore não é afetada por esse recurso, portanto, não é necessário desativá-lo.
-
Etapas de exclusão.
Na aba , passe o mouse sobre o LogStore desejado e selecione .
Na caixa de diálogo Warning, clique em Confirm Deletion.
-
Observações pós-exclusão.
Taxas de armazenamento ainda se aplicam no dia da exclusão. Nenhuma taxa é acumulada a partir do dia seguinte. Você não receberá uma fatura para este LogStore a partir do terceiro dia após a exclusão.
Após a exclusão, todas as tarefas de exportação, jobs de transformação de dados, tarefas de SQL agendado que usam este LogStore como source e tarefas de importação direcionadas a ele serão excluídas.
API
Exemplos de configuração para cenários reais
Monitoramento e análise em tempo real para cargas de trabalho de alto volume
Sua aplicação online gera grandes volumes de logs em tempo real. Quando ocorrem falhas, você precisa localizar rapidamente os logs de erro e monitorar métricas de desempenho (como QPS e latência de resposta) com alertas em tempo real.
Configuração recomendada: LogStore Standard + pay-by-ingested-data + sharding automático.
Motivo: O LogStore Standard suporta análises, monitoramento em tempo real e visualização. Com alto volume de ingestão e potencial necessidade de indexação extensiva, o modelo pay-by-ingested-data oferece melhor eficiência de custos, e o sharding automático garante desempenho consistente de ingestão e análise.
Cenários de conformidade, auditoria e regulamentação
Regulamentações do setor exigem o armazenamento de logs de operação do usuário e logs de segurança por mais de seis meses para auditoria, mas a frequência diária de consultas e análises é muito baixa.
Configuração recomendada: LogStore Query + camadas inteligentes.
Motivo: O LogStore Query suporta cargas de trabalho apenas de busca com um custo de tráfego de índice menor que o Standard. As camadas inteligentes reduzem os custos de armazenamento de longo prazo movendo automaticamente logs mais antigos para camadas de armazenamento de menor custo.
Referências relacionadas
Comparação de LogStore sob faturamento pay-by-feature
Os LogStores Query suportam apenas o faturamento pay-by-feature. Sob este modelo, os LogStores Standard e Query comparam-se da seguinte forma:
Item de Comparação | Standard | Especificação Query | |
Custo | USD 0.0875/GB | USD 0.0146/GB | |
Recursos | Data ingestion (apenas para logs de aplicação) | Suportado | Não suporta ingestão de logs de cloud products. |
Suportado | Suportado | ||
Suportado | Suportado | ||
Analytics (instrução SQL) | Suportado | Não suportado | |
Suportado | Suportado | ||
Suportado | Suportado | ||
Suportado | Não suportado | ||
Suportado | Suportado | ||
Suportado | Não suportado | ||
Suportado | Suporta apenas alertas baseados em consulta | ||
Suportado | Não suportado | ||
Suportado | Suportado | ||
Suportado | Suportado | ||
Suportado | Suportado | ||
Limites
O modelo pay-by-ingested-data suporta o conjunto completo de recursos do SLS. Recursos de valor agregado, como consulta e análise, transformação de dados, alertas inteligentes e consumo/envio, não incorrem em cobranças extras, mas estão sujeitos aos limites de cota a seguir.
|
Limite de cota |
Descrição |
|
Volume de transformação de dados |
Máximo de 100 TB por LogStore por mês. |
|
Volume de dados de SQL Agendado |
Máximo de 20 TB por LogStore por mês. |
|
Volume de dados de envio |
Máximo de 100 TB por LogStore por mês. |
|
Volume de dados de consumo |
Máximo de 100 TB por LogStore por mês. |
|
Volume de computação de job de alerta |
Máximo de 100 TB por LogStore por mês. |
Visão geral do faturamento
Os custos do LogStore dependem principalmente do modo de faturamento selecionado.
Pay-by-feature: O faturamento ocorre separadamente pelo uso real de recursos como capacidade de armazenamento, tráfego de índice, operações de leitura/escrita e quantidade de shards.
Pay-by-ingested-data: Você paga apenas pelo volume bruto de dados ingeridos, com 30 dias de armazenamento gratuito e vários recursos gratuitos incluídos.
Detalhes principais de preços:
Tráfego de índice Standard: USD 0.0875/GB.
Tráfego de índice Query: USD 0.0146/GB.
Dicas de otimização de custos:
Se o seu período de retenção de logs for próximo ou superior a 30 dias, o modelo pay-by-ingested-data geralmente é mais econômico.
Para cenários de arquivamento e apenas recuperação, use LogStores Query para reduzir custos de indexação.
Use camadas inteligentes para mover dados acessados com pouca frequência para camadas de armazenamento de menor custo.
FAQ
Não é possível criar um LogStore
Por padrão, você pode criar até 200 LogStores por Project. Exclua LogStores não utilizados ou solicite um aumento de cota conforme abaixo.
Faça login no console do Simple Log Service, e clique em no Project desejado na lista de Projects.
Na página do Project, acesse Overview > Basic Information > Resource Quota e clique em Manage. No painel Resource Quotas, ajuste o limite de cota do LogStore e clique em Save para enviar sua solicitação. Aguarde cerca de uma hora para que a alteração tenha efeito.
Estão faltando logs no Simple Log Service?
-
Project ou LogStore ausente
Se você excluir manualmente um Project ou LogStore, os logs não poderão ser recuperados. Use ActionTrail para verificar eventos de exclusão nos últimos 90 dias.
-
Se sua conta permanecer inadimplente por mais de 7 dias, o service será considerado abandonado. Os Projects serão recuperados e os dados excluídos permanentemente. Para detalhes, consulte Overdue payments.
Como posso reduzir os custos de armazenamento de logs?
Para verificar seu faturamento do SLS, consulte View SLS storage capacity and consumption records.
Download historical logs locally ou ship them to OSS for storage.
Como identifico a source de dados dos logs coletados em um LogStore?
Se um Project contiver LogStores que você não criou, ou se você não tiver certeza de qual service da cloud grava logs em um LogStore, use os métodos a seguir para confirmar a source de dados e o service de origem do log:
Verifique a configuração de importação de dados do LogStore: As configurações de coleta do Logtail e as configurações de envio ou importação de logs de services da cloud correspondem diretamente às sources de dados que gravam no LogStore. Esta é a maneira mais direta de confirmar a origem.
Visualize os Raw Logs na página Query and Analysis do LogStore: a coluna Time/IP de cada entrada de log exibe o campo identificador de origem
__source__. Logs que o Logtail coleta de arquivos também carregam campos reservados como__tag__:__path__, cujos nomes são palavras reservadas do Simple Log Service, e você pode usar esses campos para determinar a origem de execução dos logs.Verifique a descrição do Project: Um Project proveniente de criação automática por um service da cloud geralmente declara sua finalidade e origem na descrição.
LogStores com o prefixo
internal-, por exemplointernal-operation_log,internal-alert-historyeinternal-etl-log, são reservados pelo Simple Log Service para importações de dados específicas. Para esses LogStores, o console indica que o LogStore atual está configurado para uma importação de dados específica e que seus itens de configuração não podem ser personalizados.Não confie no campo
productTyperetornado porGetLogStorepara determinar a origem: este campo não é definido na OpenAPI do Simple Log Service e seus valores não são padronizados. Use-o apenas como um sinal auxiliar, nunca como única base para sua conclusão.
O armazenamento de logs brutos está ativado por padrão para um LogStore?
Sim. O armazenamento de logs brutos é ativado por padrão e não requer configuração manual. Depois que os logs são gravados em um LogStore, os logs brutos são armazenados, e o Simple Log Service não fornece uma opção separada para armazenamento de logs brutos. O tempo de retenção dos logs é determinado pelo Data Retention Period do LogStore.
Para confirmar isso, faça login no console do Simple Log Service, acesse a página Query and Analysis do LogStore alvo, selecione um intervalo de tempo e visualize os logs gravados na aba Raw Logs. A aba Raw Logs também está disponível quando a indexação está desativada para o LogStore. Se a página indicar que a indexação não está ativada, você só poderá consultar os dados gravados após a entrada em vigor da indexação.