Tüm Ürünler
Search
Belge Merkezi

Simple Log Service:LogStore Yönetimi

Son Güncelleme:Sep 30, 2026

LogStore, Simple Log Service (SLS) içinde günlük verilerini toplamak, depolamak ve sorgulamak için kullanılan bir depolama birimidir.

Temel kavramlar

LogStore nedir?

LogStore, Simple Log Service içindeki bir veri kapsayıcısıdır. Farklı uygulamalardan veya kaynaklardan gelen günlükleri izole etmek ve yönetmek için bir Project altında birden fazla LogStore oluşturabilirsiniz.

LogStore planlama en iyi uygulamaları

  • Her günlük kaynağı veya günlük türü için ayrı bir LogStore oluşturun. Örneğin, NGINX erişim günlüklerini ve hata günlüklerini ayrı LogStore'larda saklayın. Bu yaklaşım, günlüklerin karışmasını önler ve sonraki sorgulama, analiz, izin izolasyonu ile uyumluluk denetimi süreçlerini basitleştirir.

  • seviye sınıflandırılmış koruma uyumluluğu ve benzeri gereksinimleri karşılamak için tek bir Project'i birleşik erişim kontrolü sınırı olarak kullanın. Sunucu günlükleri, veritabanı günlükleri ve konsol işlem günlükleri gibi her günlük türü için bu Project içinde ayrı LogStore'lar oluşturun. Bu düzenleme, kategorize edilmiş depolamayı ve denetim izlenebilirliğini destekler.

  • Bir LogStore, günlükleri yıl, ay, gün veya saat bazında otomatik olarak kategorilere ayırmaz ve otomatik olarak klasörler oluşturmaz. Günlük sorgulama tamamen günlük içeriğindeki gerçek zaman alanlarına dayanır.

Ek olarak, belirli Alibaba Cloud hizmetleri veya SLS özellikleri, özel amaçlar için otomatik olarak özel LogStore'lar oluşturur. Bu LogStore'lar başka türde verileri kabul edemez. Örnekler şunlardır:

LogStore teknik özellikleri karşılaştırması

Simple Log Service, özellikleri ve maliyeti açısından farklılık gösteren Standard ve Query olmak üzere iki LogStore türü sunar.

Tür

Maliyet (Dizin Trafiği Ücreti Karşılaştırması)

Senaryolar

Standard

USD 0.0875/GB

Etkileşimli analiz, gerçek zamanlı izleme, görselleştirme veya gözlemlenebilirlik sistemleri oluşturma işlemleri için bu türü kullanın.

Query türü (Query)

USD 0.0146/GB

Bu tür analizi desteklemez. Yalnızca analiz gerektirmeyen hızlı anahtar kelime aramasına ihtiyaç duyduğunuz günlük arşivleme, denetim günlüğü depolama veya sorun giderme senaryoları için kullanın. Tipik kullanım durumları, nadir erişimle birlikte uzun vadeli saklamayı (aylar veya yıllar) içerir.

Kapsam ve izinler

İzin notları (genişletilebilir)

  • Bir Alibaba Cloud hesabı kullanarak oturum açarsanız varsayılan olarak tam izinlere sahip olursunuz ve LogStore'ları doğrudan yönetebilirsiniz.

  • Bir Resource Access Management (RAM) kullanıcısı olarak oturum açmak için ihtiyaç halinde Alibaba Cloud hesap sahibinden aşağıdaki iki Simple Log Service sistem ilkesini talep edebilirsiniz.

    • AliyunLogFullAccess: Simple Log Service için tam yönetim izinleri verir.

    • AliyunLogReadOnlyAccess: Simple Log Service'e salt okunur erişim sağlar.

    Sistem ilkeleri ihtiyaçlarınızı karşılamıyorsa ayrıntılı izin yönetimi için bir özel ilke oluşturun.

    İşlem

    Gerekli izinler

    LogStore Yönetimi

    • log:ListProject

    • log:GetAcceleration

    • log:ListDomains

    • log:GetLogging

    • log:ListTagResources

    • log:GetProject

    • log:ListLogStores

    • log:*LogStore

    • log:*Index

    • log:ListShards

    • log:GetLogStoreHistogram

    • log:GetLogStoreContextLogs

    LogStore Sorgulama

    • log:ListProject

    • log:GetAcceleration

    • log:ListDomains

    • log:GetLogging

    • log:ListTagResources

    • log:GetProject

    • log:ListLogStores

    • log:GetLogStore

    • log:GetLogStoreHistogram

    • log:GetIndex

    • log:CreateIndex

    • log:UpdateIndex

    • log:ListShards

    • log:GetLogStoreContextLogs

Temel bir LogStore oluşturma

Console

  1. Simple Log Service konsoluna oturum açın. Project listesinde hedef Project'i tıklayın.

  2. Log Storage > Logstores sekmesinde + simgesini tıklayın.

  3. Create Logstore sayfasında ayarları yapılandırın ve OK öğesini tıklayın.

    1. LogStore türü: Varsayılan olarak Standard.

    2. Faturalama modu:

      • Pay-by-feature: Kullanılan her kaynak (depolama, dizin oluşturma ve okuma/yazma işlemleri gibi) için ayrı faturalandırılırsınız ve küçük ölçekli senaryolarda maliyetleri kontrol etmenize yardımcı olan aylık ücretsiz bir kota alırsınız.

      • Pay-by-ingested-data: Yalnızca ham alınan veri hacmi için ödeme yaparsınız. Depolama ve temel özellikler 30 gün boyunca ücretsizdir ve daha basit, daha uygun maliyetli bir fiyatlandırma modeli sunar.

      Hızlı ipucu: Saklama süreniz 30 güne ne kadar yakınsa ve dizine eklediğiniz alan sayısı ne kadar fazlaysa (özellikle tam metin dizini), pay-by-ingested-data o kadar uygun hale gelir.
    3. LogStore adı: Project içinde benzersiz olmalı ve oluşturulduktan sonra değiştirilememelidir.

    4. Veri saklama süresi: Varsayılan olarak 30 gün.

    5. Diğer tüm ayarları varsayılan değerlerinde bırakın.

    Tam LogStore parametre listesi (genişletilebilir)

    Parametre

    Açıklama

    LogStore türü

    SLS LogStore'ları Standard ve Query türlerini destekler. Maliyetleri optimize etmek için senaryonuza göre seçim yapın.

    • Standard, SLS'nin tam analiz özellikleri paketini içerir; gerçek zamanlı izleme, etkileşimli analiz ve gözlemlenebilirlik sistemleri oluşturma için idealdir.

    • Query'nin dizin trafiği fiyatı Standard'ın %29'u kadardır. Aynı bütçeyle Query, daha düşük maliyetle daha fazla alanı dizine eklemenize olanak tanır. Ancak Query yalnızca anahtar kelime aramasını destekler ve istatistiksel analizi desteklemez.

    Faturalama modu

    • Pay-by-feature: Orijinal SLS faturalama modeli. Kaynakların (depolama ve dizin oluşturma gibi) ve özelliklerin (veri dönüştürme ve veri aktarma gibi) gerçek kullanımına göre kullandıkça öde esasına göre ücretlendirilirsiniz.

    • Pay-by-ingested-data: Yalnızca ham alınan veri hacmi için ücret alan basitleştirilmiş bir SLS faturalama modelidir. Alımdan sonra 30 günlük ücretsiz depolama ve veri dönüştürme ile veri aktarma gibi özelliklere ücretsiz erişim sağlarsınız. Bu model, SLS'yi yoğun kullananlar için basit, öngörülebilir ve uygun maliyetlidir.

    LogStore adı

    LogStore adı, Project içinde genel olarak benzersiz olmalı ve oluşturulduktan sonra değiştirilememelidir.

    WebTracking

    WebTracking, tarayıcı, iOS/Android uygulaması ve ön uç erişim günlüklerinin hızlı bir şekilde toplanmasını sağlar. Varsayılan olarak devre dışıdır.

    Veri saklama süresi

    Gün cinsinden saklama süresi. Geçerli değerler: 1–3650. Bunu 3650 olarak ayarlamak kalıcı saklama anlamına gelir. Günlükler yapılandırılan saklama süresine ulaştığında silinir.

    Akıllı katmanlandırma

    Verileri yaşam döngüsü yönetimi kullanarak otomatik olarak katmanlandırır.

    • Sıcak depolama:

      • Sıcak depolama, sık erişilen veriler için ölçeklenebilir, yüksek kullanılabilirliğe sahip bir çözümdür.

      • Gerçek zamanlı erişimi destekler ve yüksek performanslı günlük sorgulama ve analizi sunar; bu da sık sorgulama ve analiz senaryoları için idealdir.

    • IA depolama sınıfı

      • IA depolama sınıfı (eski adıyla soğuk depolama), sorgulama, analiz, görselleştirme, uyarı, aktarma ve dönüştürme için tam yetenekleri korurken uzun vadeli depolama maliyetlerini düşürür.

      • Sorun geri izleme gibi düşük sıklıkta sorgulama ve analiz senaryoları için uygundur.

    • Arşiv Depolama

      • Arşiv Depolama, sıcak ve IA depolamanın ötesinde daha düşük maliyetli, sorgulanabilir ve analiz edilebilir uzun vadeli bir depolama seçeneği sunar.

      • Uzun vadeli denetim günlüğü saklama için idealdir.

    Parça sayısı

    Her parça saniyede 5 MB yazma aktarım hızı ve saniyede 10 MB okuma aktarım hızını destekler. Veri trafiği bir parçanın kapasitesini aşarsa parçayı bölebilirsiniz. Veri trafiği bir parçanın maksimum okuma ve yazma kapasitesinin altına düşerse maliyetleri düşürmek için parçaları birleştirebilirsiniz.

    Otomatik parçalama

    Yazma trafiği mevcut parçaların okuma/yazma kapasitesini 5 dakikadan fazla süreyle aşarsa otomatik parçalamayı etkinleştirmek veri hacmine göre parça sayısını artırır.

    Maksimum parça sayısı

    Otomatik parçalama etkinleştirildiğinde otomatik olarak en fazla 256 parça oluşturulabilir.

    Genel IP'yi kaydet

    Sistem, günlükleri aldıktan sonra istemcinin genel IP adresini ve günlük varış zamanını otomatik olarak ekler.

API

Logstore oluşturma

LogStore yapılandırmasını değiştirme

Aşağıdaki parametreleri oluşturma sırasında yapılandırabilirsiniz. Bu bölümde örnek olarak LogStore değişikliği kullanılmıştır.

  1. image Log Storage öğesini tıklayın. LogStores sayfasında hedef LogStore'un üzerine gelin ve Modify seçeneklerini belirleyin.

  2. LogStore özelliklerinde senaryonuza göre ilgili ayarları değiştirin.

Belirli günlükleri silme veya günlük saklama süresini ayarlama

Console

Basic Information bölümünde Modify öğesini tıklayın, veri saklama süresini ayarlayın ve Save öğesini tıklayın.

Simple Log Service, Log Soft Delete özelliğini kullanarak belirli günlük girişlerini silmeyi destekler. LogStore'un Query and Analysis sayfasında sorgu koşullarını girin, bir zaman aralığı seçin ve silme görevini göndermek için Log Soft Delete öğesini tıklayın. Silinen günlük girişleri sonraki sorgularda görünmez ve saklama süresi sona erdiğinde kalıcı olarak silinir. Ayrıca veri saklama süresini değiştirerek süresi dolmuş günlükleri toplu halde silebilir veya tüm günlükleri kaldırmak için faturalandırmayı durdurabilir veya LogStore'u silebilirsiniz.
  • Specified Days: Geçerli değerler: 1–3650. Bunu 3650 olarak ayarlamak kalıcı saklama anlamına gelir. Günlükler saklama süresi sona erdiğinde silinir.

  • Permanent Storage: Günlükleri LogStore'da süresiz olarak saklar.

Not

Değişiklikler hemen etkili olur ancak süresi dolmuş verilerin silinmesi biraz zaman alabilir.

Değişikliğin etkili olduğunu doğrulayın

Değişiklik kaydedildikten sonra LogStore'un üzerine tekrar gelin ve Modify öğesini tıklayın. LogStore özelliklerinde Data Retention Period için görüntülenen gün sayısının ayarladığınız değer olup olmadığını kontrol edin; bu, ayarın uygulandığını onaylar. LogStore için permanent retention etkinleştirilmişse özel bir gün sayısı görüntülenmez; bu, bu LogStore'daki günlüklerin ayarı değiştirene kadar saklandığı anlamına gelir.

Değiştirilemeyen veya kaydedilemeyen Veri Saklama Süresini giderme

Data Retention Period düzenlenemiyorsa (saklama süresi düzenleme düğmesi soluksa veya depolama süresi seçilemiyorsa) ya da değişikliği kaydettiğinizde bir hata döndürülüyor ve yaşam döngüsü ayarları tamamlanamıyorsa aşağıdaki öğeleri sırayla kontrol edin:

  • LogStore, bir cloud hizmeti veya Simple Log Service tarafından otomatik olarak oluşturulan özel bir LogStore'dur. Otomatik oluşturma, Redis özel LogStore'ları, MongoDB özel LogStore'ları ve Simple Log Service yönetimi özel LogStore'ları için geçerlidir; bunların veri saklama süresi ilgili cloud hizmeti tarafından yönetilir. Değişikliği Simple Log Service konsolunda kaydettiğinizde işlemi ilgili cloud hizmetinin konsolunda gerçekleştirmeniz gerektiğini belirten bir mesaj görüntülenir. Özel bir saklama süresi kullanmak için bunu ilgili cloud hizmetinin konsolunda ayarlayın veya iş günlükleriniz için standart bir LogStore oluşturun.

  • LogStore, internal- önekiyle sistem tarafından ayrılmış bir LogStore'dur; örneğin internal-operation_log, internal-alert-history veya internal-etl-log. Böyle bir LogStore zaten belirli bir veri içe aktarma yapılandırmasına bağlıdır ve konsol, mevcut LogStore'un belirli bir veri içe aktarma için yapılandırıldığını belirtir; bu nedenle yapılandırma öğeleri özelleştirilemez.

  • Mevcut hesabın yeterli izni yoktur. Bir LogStore yapılandırmasını değiştirmek için hedef Project üzerinde LogStore yönetim izinleri, yani bu konunun Scope and permissions bölümünde listelenen log:*LogStore gibi izinler gerekir. Bir Resource Access Management (RAM) kullanıcısı olarak oturum açıyorsanız Alibaba Cloud hesap sahibinden AliyunLogFullAccess sistem ilkesini veya bu izinleri içeren özel bir ilkeyi talep edin.

  • Konsol sayfası doğru görüntülenmiyor. Sayfayı yenileyin veya başka bir tarayıcıya geçin, hedef LogStore'un üzerine tekrar gelin, Modify öğesini tıklayın ve ardından Data Retention Period değerini tekrar değiştirin.

  • Standart senaryolarda, bu bölümün API sekmesinde açıklandığı gibi ttl değerini değiştirerek de ayarı tamamlayabilirsiniz. Yukarıda açıklanan özel LogStore'lar için saklama süresini yine de ilgili cloud hizmetinin konsolunda ayarlamanız gerekir.

API

Update Logstore işleminde ttl değerini güncelleyerek günlük saklama süresini ayarlayın.

Katmanlandırma kullanarak depolama maliyetlerini optimize etme

Console

  1. Basic Information bölümünde Modify öğesini tıklayın ve akıllı katmanlandırmayı etkinleştirin.

  2. Storage Policy değerini yapılandırın: Üç katmandaki günlerin toplamı toplam veri saklama süresine eşit olmalıdır.

    • Sıcak depolama: minimum 7 gün.

    • IA depolama sınıfı: minimum 30 gün.

    • Arşiv Depolama: minimum 60 gün.

    Data retention period değerini Limited days olarak ayarlayın, Intelligent tiering özelliğini etkinleştirin ve Storage policy içinde katman geçişlerini yapılandırın: sıcak depolama süresi dolduktan sonra otomatik olarak IA depolamaya geçer, IA depolama Arşiv Depolamaya geçer ve Arşiv Depolama süresi dolduktan sonra otomatik olarak silinir.

  3. Save öğesini tıklayın. Ayrıntılar için bkz. Intelligent tiering.

API

Update Logstore işleminde ttl, hot_ttl ve infrequentAccessTTL değerlerini güncelleyerek depolama katmanları için saklama politikasını dinamik olarak ayarlayın.

Ön uç günlüklerini toplama

Simple Log Service, mini programlardan, mobil uygulamalardan (iOS/Android) ve tarayıcılardan günlük toplamak için WebTracking sağlar.

Bu özelliği iki şekilde kullanabilirsiniz:

  • İletim için STS kimlik doğrulamasını kullanın. Bu yöntem üretim ortamları için uygundur ve LogStore yapılandırma değişiklikleri gerektirmez.

  • OpenAPI aracılığıyla anonim iletimi kullanın. Bu yöntem yalnızca test amaçlıdır ve aşağıda açıklandığı gibi LogStore'da bir ayarın etkinleştirilmesini gerektirir.

Console

Basic Properties bölümünde Modify öğesini tıklayın, WebTracking'i etkinleştirin ve Save öğesini tıklayın.

API

Update Logstore işleminde enable_tracking parametresini true olarak ayarlayarak WebTracking'i etkinleştirin.

Genel IP'yi ve günlük varış zamanını otomatik olarak ekleme

Etkinleştirildiğinde sonraki günlük alımı otomatik olarak şunları ekler:

  • __tag__:__client_ip__: günlük kaynağı cihazının genel IP adresi.

  • __tag__:__receive_time__: Günlüğün Simple Log Service sunucusuna varış zamanı; UNIX zaman damgası olarak biçimlendirilir (1970-01-01 00:00:00 UTC'den bu yana geçen saniye).

Console

Basic Properties bölümünde Modify öğesini tıklayın, Record public IP özelliğini etkinleştirin ve Save öğesini tıklayın.

API

Update Logstore işleminde appendMeta parametresini ayarlayarak genel IP kaydını etkinleştirin.

Parçaları kullanarak alım performansını ayarlama

Her parça alım için saniyede 5 MB veya 500 yazma ve tüketim için saniyede 10 MB veya 100 okuma desteği sağlar. Bunlar yumuşak sınırlardır. Sistem bu sınırların ötesindeki istekleri yerine getirmeye çalışır ancak hizmet kalitesini garanti etmez. Trafik bir parçanın kapasitesini aşarsa kapasiteyi artırmak için parçayı bölün.

Console

Basic Properties bölümünde Modify öğesini tıklayın, Automatic sharding özelliğini etkinleştirin, parça sınırını ayarlayın ve Save öğesini tıklayın.

Simple Log Service, bireysel parçaların bölünmesini ve birleştirilmesini destekler.

API

Split shard.

Merge shard.

Faturalandırmayı durdurma veya LogStore silme

Uyarı

Silindiğinde Logstore'daki tüm günlük verileri kalıcı olarak kaybolur ve kurtarılamaz. Dikkatli ilerleyin.

Bir LogStore'u silmeden önce iş etkisini değerlendirin. Bir LogStore izleme, uyarı, analiz veya denetim için kullanılmıyorsa ve veri dönüştürme, veri aktarma veya API sorguları için veri kaynağı değilse silinmesi genellikle iş operasyonlarını etkilemez. İlerlemeden önce önemli ilişkili yapılandırmaların kalmadığını onaylayın. Silinen bir LogStore'daki veriler kurtarılamaz.

Console

  1. Silme öncesi temizlik.

    1. LogStore'u silmeden önce ilişkili tüm Logtail yapılandırmalarını silin. Konsolun bir LogStore'u silerken gerçekleştirdiği tek zorunlu ön koşul denetimi budur: LogStore hala Logtail toplama yapılandırmalarıyla ilişkilendirilmişse konsol Logtail yapılandırmalarının bulunduğunu ve önce silinmesi gerektiğini bildirir; silme işlemi devam edemez. Bu nedenle bir LogStore silinemiyorsa önce o LogStore'un tüm Logtail toplama yapılandırmalarını silin ve ardından LogStore'u tekrar silin.

    2. Bu LogStore için LogShipper etkinleştirilmişse yeni veri yazmayı durdurun ve silmeden önce mevcut tüm verilerin başarıyla aktarıldığını onaylayın.

    3. Bir Project'in Release Protection özelliği Project'in kendisine uygulanır: etkinleştirildikten sonra Project'i silebilmeniz için manuel olarak devre dışı bırakmanız gerekir. Tek bir LogStore'u silme işlemi bu özellikten etkilenmez; bu nedenle devre dışı bırakmanız gerekmez.

  2. Silme adımları.

    1. Log Storage > Logstores sekmesinde hedef LogStore'un üzerine gelin ve Delete seçeneklerini belirleyin.

    2. Warning iletişim kutusunda Confirm Deletion öğesini tıklayın.

  3. Silme sonrası notlar.

    1. Silme gününde depolama ücretleri hala uygulanır. Sonraki günden itibaren ücret tahakkuk etmez. Silme işleminden sonraki üçüncü günden itibaren bu LogStore için fatura almazsınız.

    2. Silme işleminden sonra bu LogStore'u kaynak olarak kullanan tüm dışa aktarma görevleri, veri dönüştürme işleri, zamanlanmış SQL görevleri ve bu LogStore'u hedefleyen içe aktarma görevleri silinir.

API

Delete Logstore

Gerçek dünya senaryoları için yapılandırma örnekleri

Yüksek hacimli iş yükleri için gerçek zamanlı izleme ve analiz

Çevrimiçi uygulamanız gerçek zamanlı olarak büyük hacimli günlükler oluşturur. Arızalar meydana geldiğinde hata günlüklerini hızla bulmanız ve performans ölçümlerini (QPS ve yanıt gecikme süresi gibi) gerçek zamanlı uyarılarla izlemeniz gerekir.

Önerilen yapılandırma: Standard LogStore + pay-by-ingested-data + automatic sharding.

Neden: Standard LogStore analizi, gerçek zamanlı izlemeyi ve görselleştirmeyi destekler. Yüksek alım hacmi ve kapsamlı dizin oluşturma ihtimali göz önüne alındığında pay-by-ingested-data daha iyi maliyet verimliliği sunar ve automatic sharding tutarlı alım ve analiz performansı sağlar.

Uyumluluk, denetim ve düzenleyici senaryolar

Endüstri düzenlemeleri, denetim amacıyla kullanıcı işlem günlüklerinin ve güvenlik günlüklerinin altı aydan fazla süreyle saklanmasını gerektirir; ancak günlük sorgulama ve analiz sıklığı çok düşüktür.

Önerilen yapılandırma: Query LogStore + intelligent tiering.

Neden: Query LogStore, Standard'a kıyasla daha düşük dizin trafiği maliyetiyle yalnızca arama iş yüklerini destekler. Intelligent tiering, eski günlükleri otomatik olarak daha düşük maliyetli depolama katmanlarına taşıyarak uzun vadeli depolama maliyetlerini azaltır.

İlgili referanslar

Pay-by-feature faturalaması altında LogStore karşılaştırması

Query LogStore'ları yalnızca pay-by-feature faturalamasını destekler. Bu modelde Standard ve Query LogStore'ları şu şekilde karşılaştırılır:

Karşılaştırma Öğesi

Standard

Query Teknik Özellikleri

Maliyet

Dizin trafiği

USD 0.0875/GB

USD 0.0146/GB

Özellikler

Veri alımı (yalnızca uygulama günlükleri için)

Desteklenir

Cloud ürün günlüğü alımını desteklemez.

Akıllı katmanlandırmayı etkinleştir

Desteklenir

Desteklenir

Arama

Desteklenir

Desteklenir

Analiz (SQL deyimi)

Desteklenir

Desteklenmez

Bağlamsal sorgu

Desteklenir

Desteklenir

LiveTail

Desteklenir

Desteklenir

LogReduce

Desteklenir

Desteklenmez

Yeniden dizin oluşturma

Desteklenir

Desteklenir

Pano

Desteklenir

Desteklenmez

Uyarı

Desteklenir

Yalnızca sorgu tabanlı uyarıları destekler

Scheduled SQL

Desteklenir

Desteklenmez

Veri dönüştürme

Desteklenir

Desteklenir

Veri aktarma

Desteklenir

Desteklenir

Standart tüketim

Desteklenir

Desteklenir

Sınırlar

Pay-by-ingested-data, tam SLS özellik setini destekler. Sorgu ve analiz, veri dönüştürme, akıllı uyarı ve tüketim/aktarma gibi katma değerli özellikler ek ücret gerektirmez ancak aşağıdaki gibi kota sınırlarına tabidir.


Kota sınırı


Açıklama


Veri dönüştürme hacmi


LogStore başına ayda maksimum 100 TB.


Scheduled SQL veri hacmi


LogStore başına ayda maksimum 20 TB.


Aktarma veri hacmi


LogStore başına ayda maksimum 100 TB.


Tüketim veri hacmi


LogStore başına ayda maksimum 100 TB.


Uyarı işi hesaplama hacmi


LogStore başına ayda maksimum 100 TB.

Faturalandırmaya genel bakış

LogStore maliyetleri öncelikli olarak seçilen faturalama moduna bağlıdır.

  • Pay-by-feature: Depolama kapasitesi, dizin trafiği, okuma/yazma işlemleri ve parça sayısı gibi kaynakların gerçek kullanımı için ayrı ayrı faturalandırılırsınız.

  • Pay-by-ingested-data: Yalnızca ham alınan veri hacmi için ödeme yaparsınız; 30 günlük ücretsiz depolama ve birden fazla ücretsiz özellik dahildir.

Temel fiyatlandırma ayrıntıları:

  • Standard dizin trafiği: USD 0.0875/GB.

  • Query dizin trafiği: USD 0.0146/GB.

Maliyet optimizasyonu ipuçları:

  • Günlük saklama süreniz 30 güne yakınsa veya 30 günü aşıyorsa pay-by-ingested-data genellikle daha uygun maliyetlidir.

  • Arşivleme ve yalnızca geri alma senaryoları için dizin oluşturma maliyetlerini azaltmak amacıyla Query LogStore'ları kullanın.

  • Nadir erişilen verileri daha düşük maliyetli depolama katmanlarına taşımak için intelligent tiering kullanın.

SSS

LogStore oluşturulamıyor

Varsayılan olarak Project başına en fazla 200 LogStore oluşturabilirsiniz. Kullanılmayan LogStore'ları silin veya aşağıdaki gibi bir kota artışı talep edin.

  1. Simple Log Service konsoluna oturum açın ve Project listesinde hedef Project'i tıklayın.

  2. Project sayfasında Overview > Basic Information > Resource Quota bölümüne gidin ve Manage öğesini tıklayın. Resource Quotas panelinde LogStore kota sınırını ayarlayın ve isteğinizi göndermek için Save öğesini tıklayın. Değişikliğin etkili olması yaklaşık bir saat sürer.

Simple Log Service'de günlükler eksik mi?

  • Project veya LogStore eksik

    Bir Project veya LogStore'u manuel olarak silerseniz günlükler kurtarılamaz. Son 90 gün içindeki silme olaylarını kontrol etmek için ActionTrail kullanın.

  • Hesabınız 7 günden fazla süreyle ödenmemiş kalırsa hizmet terk edilmiş sayılır. Project'ler geri alınır ve veriler kalıcı olarak silinir. Ayrıntılar için bkz. Ödemesi geciken ödemeler.

Günlük depolama maliyetlerini nasıl azaltabilirim?

Bir LogStore'a toplanan günlüklerin veri kaynağını nasıl belirlerim?

Bir Project'te oluşturmadığınız LogStore'lar varsa veya hangi cloud hizmetinin bir LogStore'a günlük yazdığından emin değilseniz veri kaynağını ve günlük kaynak hizmetini onaylamak için aşağıdaki yöntemleri kullanın:

  • LogStore'un veri içe aktarma yapılandırmasını kontrol edin: Logtail toplama yapılandırmaları ve cloud hizmeti günlüklerinin aktarma veya içe aktarma yapılandırmaları, LogStore'a yazan veri kaynaklarıyla doğrudan eşleşir. Kaynağı onaylamanın en doğrudan yolu budur.

  • LogStore'un Query and Analysis sayfasında Raw Logs görüntüsünü inceleyin: her günlük girişinin Time/IP sütunu kaynak tanımlayıcı alanı __source__ değerini gösterir. Logtail'in dosyalardan topladığı günlükler ayrıca __tag__:__path__ gibi ayrılmış alanlar taşır; bunların adları Simple Log Service ayrılmış sözcükleridir ve bu alanları kullanarak günlüklerin çalışma zamanı kaynağını belirleyebilirsiniz.

  • Project'in açıklamasını kontrol edin: Bir cloud hizmeti tarafından otomatik oluşturmada gelen bir Project genellikle açıklamasında amacını ve kaynağını belirtir.

  • internal- önekiyle LogStore'lar; örneğin internal-operation_log, internal-alert-history ve internal-etl-log, belirli veri içe aktarmaları için Simple Log Service tarafından ayrılır. Bu LogStore'lar için konsol, mevcut LogStore'un belirli bir veri içe aktarma için yapılandırıldığını ve yapılandırma öğelerinin özelleştirilemeyeceğini belirtir.

  • Kaynağı belirlemek için GetLogStore tarafından döndürülen productType alanına güvenmeyin: bu alan Simple Log Service OpenAPI'de tanımlanmamıştır ve değerleri standart değildir. Yalnızca yardımcı bir sinyal olarak kullanın, asla sonucunuz için tek dayanak olarak kullanmayın.

Bir LogStore için ham günlük depolama varsayılan olarak etkin midir?

Evet. Ham günlük depolama varsayılan olarak etkindir ve manuel yapılandırma gerektirmez. Günlükler bir LogStore'a yazıldıktan sonra ham günlükler depolanır ve Simple Log Service ham günlük depolama için ayrı bir anahtar sağlamaz. Günlüklerin ne kadar süreyle saklandığı LogStore'un Data Retention Period değeri tarafından belirlenir.

Bunu onaylamak için Simple Log Service konsoluna oturum açın, hedef LogStore'un Query and Analysis sayfasına gidin, bir zaman aralığı seçin ve Raw Logs sekmesinde yazılan günlükleri görüntüleyin. LogStore için dizin oluşturma devre dışı bırakıldığında da Raw Logs sekmesi kullanılabilir. Sayfa dizin oluşturmanın etkin olmadığını belirtiyorsa yalnızca dizin oluşturma etkin hale geldikten sonra yazılan verileri sorgulayabilirsiniz.