LLM Loglama En İyi Uygulamaları: Üretimde Uyguladığımız 9 Kural [2026]

LLM Loglama En İyi Uygulamaları: Üretimde Uyguladığımız 9 Kural [2026]

Bu dokuz LLM loglama en iyi uygulaması, üretim ortamındaki yığınımızın gerçekten çalıştırdığı kurallar: dört servis genelinde ayda 1,2 milyon LLM isteğini logluyoruz ve her biri Grafana Loki'ye model, token, gecikme, cost_usd ve trace_id içeren tek bir JSON satırı olarak düşüyor. Kaydı structlog 25.4.0 yazıyor, Presidio önce PII'yi temizliyor ve tüm hat, gözlemlenebilirlik yığınımızın loglama yarısını oluşturuyor.

Öne Çıkanlar

• Her LLM isteğini 14+ adlandırılmış alan içeren yapılandırılmış JSON olarak loglayın, asla serbest metin değil.
• PII'yi log yazımından önce Presidio veya eşdeğeriyle maskeleyin, sonrasında değil.
• Her trace'e OpenTelemetry GenAI semantik sözleşme özniteliklerini ekleyin.
• Günde 1 milyon istekte aynı 60GB, Datadog'da ayda 108$, Loki'de 30$, ClickHouse'da 1,20$ tutuyor.

LLM Loglama Aslında Ne Anlama Geliyor (ve "Her Şeyi Logla" Neden İşe Yaramıyor)

LLM loglama, her model isteğinin ve yanıtının yapılandırılmış kaydını yakalamak demektir: prompt, tamamlama, token sayıları, gecikme, maliyet ve hepsini bir kullanıcı oturumuna bağlayan trace. Bu, altyapı loglaması değildir. CPU, bellek ve pod yeniden başlatmaları metrik yığınınıza aittir; bu yazı yalnızca model davranışını hata ayıklamanıza, maliyetlendirmenize ve denetlemenize olanak tanıyan istek düzeyindeki kaydı ele alıyor.

"Her şeyi logla" içgüdüsü kolay kolay ölmez ve pahalıya patlar. Günde 1 milyon istekte tam promptlar ve tamamlamalar ayda kabaca 60GB metin üretir ve bu metnin bir kısmı, artık süresiz olarak sakladığınız müşteri PII'sidir. GDPR'ın Madde 5 veri minimizasyonu ilkesi kişisel verilerin "yeterli, ilgili ve gerekenle sınırlı" olmasını şart koşar ve ham prompt dökümü bu testi ilk günden kaybeder. Her şeyi loglamak bir strateji değildir; aylık faturası olan bir yükümlülüktür.

9 LLM Loglama Kuralı Nelerdir?

Dokuz kural, uygulayacağımız sırayla: tam promptları ve yanıtları hashlenmiş tanımlayıcılarla loglayın, yapılandırılmış JSON yayın, istek başına token ve maliyeti yakalayın, OpenTelemetry trace bağlamını ekleyin, PII'yi yazımdan önce maskeleyin, yüksek hacimde örnekleme yapın, saklama katmanları belirleyin, güvenlik olaylarını ayırın ve sonucu sorgulanabilir kılın. Aşağıdakilerin her biri, onu uygulayan kod veya tabloyla birlikte geliyor.

Kural 1: Tam Prompt ve Yanıtı Loglayın (Ham PII Değil, Hash ile)

Her istek için tam promptu ve tam tamamlamayı loglayın, çünkü kısmi loglar, modelin gerçekte ne gördüğüne dair hiçbir kayıt olmadan bir olaya bakakalmanızın nedenidir. Tek istisna kimliktir: ham kullanıcı kimliklerini, e-postaları veya adları asla kayda yazmayın. Bunun yerine kullanıcı kimliğinin SHA-256 hash'ini saklayın. Hash, çevrimdışı bir arama ile bir kullanıcının tam oturum geçmişini yeniden oluşturmanıza yine de olanak tanır; log satırının kendisi ise onu okumaması gereken herkes için işe yaramaz kalır. Sistem promptları için de aynı mantık: onları hashleyin, hash'i loglayın ve düz metni, zaten sürüm kontrollü olan prompt kayıt defterinizde tutun.

Kural 2: Yapılandırılmış JSON Kullanın: Her Alan Adlandırılmış, Hiçbir Şey Serbest Metin Değil

Python'da veya başka herhangi bir dilde LLM loglama en iyi uygulamaları için yapılandırılmış loglama JSON ile pazarlık edilemez olan kuraldır: her alan adlandırılmış, tiplendirilmiş ve sorgulanabilir olacak, hiçbir şey biçimlendirilmiş dize olarak dökülmeyecek. INFO called gpt-4o, took 812ms gibi serbest metin bir satır yalnızca greplenebilir. Bir JSON kaydı ise modele göre toplanabilir, maliyete göre toplanabilir ve bir trace'e birleştirilebilir. OpenAI'nin kendi üretim en iyi uygulamaları da aynı fikri öne sürüyor: yapılandırılmış meta verileri print ifadeleriyle değil, SDK katmanında yakalayın.

İşte her Techsy servisinin yayınladığı şema, on dört alan:

{
  "request_id": "req_01J9XK4M7Q",
  "timestamp": "2026-07-18T09:24:31.482Z",
  "environment": "production",
  "model": "claude-sonnet-4-20250514",
  "prompt_tokens": 1284,
  "completion_tokens": 396,
  "latency_ms": 812,
  "cost_usd": 0.0098,
  "system_prompt_hash": "sha256:9f2c1a4e...",
  "user_id_hash": "sha256:b7e4d831...",
  "rag_sources": ["kb/pricing-2026.md", "kb/refund-policy.md"],
  "guardrail_result": "pass",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

Üç alan bir notu hak ediyor. cost_usd, istek anında token sayılarından ve modelin yayınlanmış tarifesinden hesaplanır, asla gece çalışan bir iş tarafından sonradan doldurulmaz. İki hash alanı, Kural 1 uzlaşmasıdır: çevrimdışı ilişkilendirilebilir, logda opaktır. trace_id ve span_id ise W3C trace-context değerleridir ve Kural 4 tam olarak bununla ilgilidir.

Dört servisin sağlayıcılara doğrudan çağrı yapması, enstrümante edilecek dört yer gibi geliyorsa, bir LiteLLM proxy bunu merkezileştirir: her sağlayıcının önünde tek bir loglama kancası.

Kural 3: Token Sayılarını ve İstek Başına Maliyeti Yakalayın

Token kullanım takibi, yarın çalışan bir ambar işinde değil, log satırının kendisinde yer almalıdır. Her sağlayıcı yanıtta girdi ve çıktı token sayılarını döndürür; o andaki modelin token başına tarifesiyle çarpın ve cost_usd değerini kayda yazın. Tarifeler değişir ve önbelleğe alınmış ile yeni girdi tokenları için farklılık gösterir, bu yüzden maliyeti daha sonra statik bir fiyat tablosuyla hesaplamak geçmişi sessizce yeniden yazar. Her satırda maliyetle, "hangi özellik pahalı?" sorusu bir finans projesi yerine tek satırlık bir sorgu haline gelir ve doğrudan LLM API harcamanızı azaltma çalışmasını besler.

Kural 4: Trace Bağlamını Ekleyin (OpenTelemetry GenAI Semconv)

Trace kimliği olmayan bir log satırı yetimdir: onu okuyabilirsiniz, ancak hangi yeniden denemenin, hangi RAG adımının veya hangi kullanıcı turunun onu ürettiğini söyleyemezsiniz. Çözüm, model çağrılarını enstrümante etmek için standart öznitelik adları olan OpenTelemetry GenAI semantik sözleşmeleridir. Logu aktif bir span içinde yayın; trace_id ve span_id kendiliğinden eklenir, böylece Grafana'da tek bir tıklama sizi trace şelalesinden doğrudan ham kayda götürür.

Her gen_ai span'inde ayarlamaya değer öznitelikler:

from opentelemetry import trace

tracer = trace.get_tracer("ai-sdr")

with tracer.start_as_current_span("chat.completion") as span:
    span.set_attribute("gen_ai.system", "anthropic")
    span.set_attribute("gen_ai.request.model", "claude-sonnet-4-20250514")
    response = client.messages.create(**payload)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
    span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
    log.info("llm.request", cost_usd=cost)  # Rule 2 record, trace IDs auto-attached

Kural 5: PII'yi Log Yazımından Önce Maskeleyin

PII maskeleme, kayıt yazıldıktan sonra temizlenmek üzere değil, yazılmadan önce gerçekleşmelidir. Bir e-posta adresi Loki'ye girdiğinde, nesne depolama yedeklerinizde de demektir ve "sonradan sildik" bir GDPR yanıtı değildir. Kurulumuzda Microsoft Presidio bir structlog işlemcisi olarak çalışır ve e-posta ile telefon numaralarının %94'ünü Loki'ye ulaşmadan yakalar; kaçırılanlar neredeyse tamamen tuhaf biçimlendirmelerdir ve bunları buldukça özel tanıyıcılara ekliyoruz.

Tüm kanca on beş satır:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

PII_ENTITIES = ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER", "CREDIT_CARD", "IBAN_CODE"]

def redact_pii(text: str) -> str:
    results = analyzer.analyze(text=text, language="en", entities=PII_ENTITIES)
    return anonymizer.anonymize(text=text, analyzer_results=results).text

# In the structlog processor chain, before JSONRenderer:
# event_dict["prompt"] = redact_pii(event_dict["prompt"])

Maskeleme, girdi ve çıktı filtrelerinizle aynı hat katmanında yer alır ve aynı şekilde test edilmelidir. Guardrail hattımız bir logdaki sızan e-postayı bir operasyon notu olarak değil, başarısız bir eval olarak ele alır.

Kural 6: Yüksek Hacimde Akıllıca Örnekleme Yapın

Günde kabaca 100 bin isteğin altında her şeyi loglayın. Bunun üzerinde, tam hacimli loglama, asla okumayacağınız veriler üzerinden bir depolama vergisidir ve örnekleme, önemli kayıtları tutma biçiminizdir. Tuzak şu: rastgele örnekleme, LLM trafiği için en kötü seçenektir, çünkü hatalar, reddetmeler ve beş dolarlık istekler tanım gereği nadirdir, bu yüzden tekdüze bir %10 oranı tam olarak hata ayıkladığınız olayları eler. Sonuca göre örnekleyin, yazı turaya göre değil.

Yaygın bir kurulum, kenarlarda kural tabanlı (üretim ve kurumsal tenantlar: her zaman logla) artı ortada kuyruk tabanlıdır. Bu çerçeveye loga özgü açı: guardrail_result ve cost_usd alanlarınız örnekleme sinyalleridir ve Kural 2 ile 8'i izlediyseniz zaten mevcuttur.

Kural 7: İhtiyaç Duymadan Önce Bir Saklama Politikası Belirleyin

Log saklama politikası, sakin olduğunuzda verdiğiniz bir karardır, çünkü alternatifi onu iki kat hacimde bir maliyet incelemesi sırasında vermektir. GDPR'ın Madde 5 depolama sınırlama ilkesi kişisel verilerin "gerekenden uzun süre tutulmaması" gerektiğini söyler, bu da pratikte katmanlı saklama demektir:

Sıcak, "on dakika önce ne oldu?" sorusuna hızlı ve pahalı yanıt verir; soğuk, "Mart ayında bu müşteriye ne söyledik?" sorusuna yavaş ve ucuz. Programa göre, otomatik olarak silin, yoksa katmanlar sadece bir şemadır.

Kural 8: Guardrail ve Güvenlik Olaylarını Ayrı Loglayın

Güvenlik olayları (guardrail engellemeleri, reddetmeler, politika ihlalleri) telemetri değildir; bunlar denetim kayıtlarıdır ve kendi akışlarında yer almalıdır. Üç neden. Uyarı: engellenen prompt enjeksiyonlarındaki bir artış birini uyarmalıdır ve bu uyarıyı 1 milyon rutin satıra karşı ayarlayamazsınız. Saklama: uyumluluk, güvenlik kayıtlarının hata ayıklama loglarından yıllarca daha uzun yaşamasını talep edebilir. Erişim: denetçiler tüm hortumunuzu değil, güvenlik akışını alır. Kararı ana kayıtta etiketleyin (guardrail_result: "block") ve tam kaydı ayrı akışa yönlendirin. Güvenlik olayı sayılan şeyler guardrail olayları rehberimizde ele alınıyor.

Kural 9: Logları Sorgulanabilir Kılın, Sadece Depolanmış Değil

Bir dakika içinde sorgulayamadığınız bir log, bir gözlemlenebilirlik sinyali değil, bir yedektir. Sorgulanabilir demek, dizinlenmiş alanlar, nöbetçinizin gerçekten bildiği bir sorgu dili ve olaydan önce kurulmuş panolar demektir. Biz Loki çalıştırıyoruz ve maliyet anomalileri, gecikme gerilemeleri ve "dün X tenantı için her reddetmeyi göster" için haftada 30+ kez sorguluyoruz. Grafana Loki dokümanları sözdizimi için referanstır; değerini kanıtlayan desen, doğrudan ayrıştırılmış JSON alanları üzerinde filtrelemektir:

{service="ai-sdr"} |= "llm.request" | json
  | model = "claude-sonnet-4-20250514"
  | cost_usd > 0.05
  | line_format "{{.timestamp}} {{.request_id}} ${{.cost_usd}} {{.latency_ms}}ms"

Beş satır, notebook'a aktarım yok. Mevcut deponuz bunu yapamıyorsa, önce düzeltilecek sorun odur.

Üretimde Gerçekte Ne Logluyoruz

Yeterince teori. İşte AI SDR hattımızdan, girişteki ayda 1,2 milyon istek rakamının arkasındaki servisten alınan maskelenmiş yapılandırma. structlog 25.4.0'ı JSON işleyerek çalıştırıyor, Promtail aracılığıyla Grafana Cloud Loki'ye gönderiyor. Bu hattaki model claude-sonnet-4-20250514 ve her çağrı tam olarak Kural 2 ve 5'teki işlemci zincirinden geçiyor:

import structlog

structlog.configure(
    processors=[
        structlog.contextvars.merge_contextvars,
        structlog.processors.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        redact_pii,          # Rule 5: Presidio, before serialization
        add_otel_trace_ids,  # Rule 4: trace_id + span_id from the active span
        structlog.processors.JSONRenderer(),
    ],
)
log = structlog.get_logger()

Bu kurulumla ilk çeyrekten iki rakam. Aylık alım dört servis genelinde 47GB'a oturdu ve p95 log yazma gecikmesi 3ms, yani hat istek süresine ölçülebilir hiçbir şey eklemiyor.

Kendini amorti eden yapılandırma değişikliği: Mart 2026'da her log girdisine cost_usd ekledik. Bir hafta içinde, yeniden deneme döngülerinde ayda 340$ yakan bir prompt şablonu bulduk. Geçici bir API hatası üç yeniden denemeyi tetikliyordu ve her biri tam 4.000 tokenlık bağlamı yeniden gönderiyordu. Loglar bunu tek satırlık bir sorgu haline getirdi; istek başına maliyet olmadan, bir sonraki çeyrek bütçe incelemesinde açıklanamayan bir kalem olarak ortaya çıkacaktı.

Ölçekte LLM Log Depolama Ne Kadara Mal Olur?

Günde 1 milyon istekte, LLM log depolama aynı veri için mağazaya bağlı olarak kabaca ayda 1,20$ ile 108$ arasında tutar. Hesap: tam bir yapılandırılmış kayıt ortalama yaklaşık 2KB'tır, yani günde 1 milyon istek günde 2GB veya ayda 60GB'tır. Aşağıdaki satıcı tarafından yayınlanan fiyatlandırma (Temmuz 2026), bu 60GB'ın üç yaygın arka uçtaki maliyetidir.

Kaynaklar: Datadog fiyatlandırma, Grafana Loki ve ClickHouse gözlemlenebilirlik dokümanları.

İki uyarı, çünkü bu bizim satıcı tarifelerinden hesaplamamız, çalıştırdığımız bir kıyaslama değil. Birincisi, Datadog'un rakamı her şeyi dizinlediğinizi varsayar; çoğu ekip bir alt kümeyi dizinler ve çok daha az öder, Loki ve ClickHouse ise esas olarak sakladığınız için ücret alır. İkincisi, kendi kendine barındırılan ClickHouse'un 1,20$'ı gerçek bir faturayı gizler: kümeyi çalıştırma işlemi ve onu işletme mühendis saatleri. Ayda 60GB'ta, yönetilen bir hizmet neredeyse her zaman daha ucuz toplam yanıttır. Kendi kendine barındırma, GB başına farkın operasyon yükünü ezdiği, kabaca ayda 1TB'ın üzerinde mantıklı olmaya başlar.

Fark, çıkarılacak derstir. Günde 1 milyon istekte, Datadog dizinli ile kendi kendine barındırılan ClickHouse arasındaki fark kabaca 90 kat: aynı 60GB için 108$'a karşı 1,20$. Mağazayı mimari zamanında seçin, fatura geldikten sonra değil.

Hangi Loglama Aracını Seçmelisiniz?

Çoğu ekip için seçim dört seçeneğe iner: LLM yerel bir platform (Langfuse veya LangSmith), bir proxy katmanı aracı (Helicone) veya zaten çalıştırdığınız altyapıya giden düz bir OpenTelemetry hattı. Tablo, gerçekte farklılaşan karar noktalarını kapsar; panolar, oynatma ve prompt sürümleme dört seçenekte de standart donanımdır.

Görüşümüz, açıkça: OTel yerel artı Loki çalıştırıyoruz, çünkü başka her şey için zaten Grafana yığınına sahiptik ve bir veri kaynağı daha eklemek, dördüncü bir satıcı benimsemekten daha iyiydi. Hiç gözlemlenebilirlik yığını olmadan sıfırdan başlıyorsanız, Langfuse'un izleme modeli ve ücretsiz katmanı faydalıya giden en hızlı yoldur ve kendi kendine barındırma seçeneği çıkış kapısını açık tutar. İki LLM yerel lider arasında seçim yapıyorsanız, Langfuse ve LangSmith karşılaştırmamız tam karşılaştırmayı yapar. Ve loglama daha büyük bir izleme kararının bir parçasıysa, tam platform karşılaştırması daha geniş alanı kapsar.

En Yaygın LLM Loglama Hataları Nelerdir?

Baktığımız kırık LLM loglama kurulumlarının çoğunu altı hata oluşturur. Her birinden, log hacmi sizden önce yakalarsanız, kaçınmak ucuzdur:

• Maskelemeden ham PII loglama. En yaygın ve en pahalı olan. Bir destek dışa aktarımı veya ihlal edilmiş bir kova, prompt loglarını bir veri koruma olayına dönüştürür. Yazımdan önce maskeleyin (Kural 5), okumada değil.
• Saklama politikası yok. Süresiz depolama her yerde varsayılandır ve faturanızı her yıl sessizce ikiye katlar. Asla silmiyorsanız, bir loglama sisteminiz yoktur; büyüklük sanrıları olan bir arşiviniz vardır.
• Yapılandırılmamış metin logları. Yalnızca greplenebilen print çıktısı demo ölçeğinde çalışır ve günde 100 bin istekte çöker; "X modeli için her başarısız isteği bul" bir sorgu yerine bir kabuk betiği öğleden sonrası haline geldiğinde.
• Yalnızca hataları loglama. Başarılı istekler, sapmayı tespit ettiğiniz temeldir ve değerlendirme hattınızın ham maddesidir. Kazanımları da loglayın, hacim zorlarsa örnekleyerek.
• Maliyet alanlarını görmezden gelme. İstek başına cost_usd olmaması, maliyet uyarısı olmaması, özellik başına atıf olmaması demektir ve yukarıdaki üretim bölümündeki ayda 340$'lık yeniden deneme döngüsü, çeyrek faturasına kadar görünmez kalır.
• Trace korelasyonu yok. Spanlerden kopuk loglar, çok adımlı ajan hata ayıklamasını tahmine dönüştürür. Log satırınızda trace_id yoksa, çözüm Kural 4'tür.

Sıkça Sorulan Sorular

Her LLM isteği için ne loglamalısınız?

En azından: PII maskelenmiş tam prompt ve tamamlama, model adı, girdi ve çıktı token sayıları, gecikme, ABD doları cinsinden maliyet, hashlenmiş bir kullanıcı tanımlayıcısı ve OpenTelemetry trace ile span kimlikleri. Hattınızda bu aşamalar varsa RAG kaynak kimliklerini ve guardrail kararını ekleyin. On dört adlandırılmış alan, istek başına bir JSON satırı.

LLM logları için en iyi biçim nedir?

Yapılandırılmış JSON, istek başına bir nesne, her alan açıkça adlandırılmış. Serbest metin logları yalnızca greplenebilir; JSON kayıtları modele göre toplanabilir, maliyete göre toplanabilir ve tracelere birleştirilebilir. Kaydı Python'da structlog veya Node'da pino gibi yapılandırılmış bir logger ile yayın ve bir JSON serileştirici ile işleyin, asla dize biçimlendirmeyle değil.

LLM loglarında PII'yi nasıl ele alırsınız?

Log yazımından önce maskeleyin, sonra değil. Promptu ve tamamlamayı loglama hattınızın içinde Microsoft Presidio gibi bir dedektörden geçirin, adları, e-postaları ve telefon numaralarını <EMAIL_ADDRESS> gibi tokenlarla değiştirin. Ham PII log deponuza ulaştığında yedeklerinizde de demektir ve sonradan silme, GDPR'ın minimizasyon testini nadiren karşılar.

Ölçekte LLM log depolama ne kadara mal olur?

Günde 1 milyon istek, kayıt başına 2KB ile ayda yaklaşık 60GB için, Datadog'un dizinli LLM Observability fiyatlandırmasında kabaca ayda 108$, Grafana Cloud Loki'de ayda 30$ veya kendi kendine barındırılan ClickHouse için sıkıştırılmış S3 depolamada işlem artı ayda yaklaşık 1,20$ bekleyin. Bunlar Temmuz 2026 itibarıyla satıcı tarafından yayınlanan tarifelerdir; kendi kendine barındırma buna mühendislik zamanı ekler.

OpenTelemetry GenAI semantik sözleşmeleri nelerdir?

Bunlar, LLM çağrılarını enstrümante etmek için OpenTelemetry'nin standart öznitelik adlarıdır: sağlayıcı için gen_ai.system, model için gen_ai.request.model, token sayıları için gen_ai.usage.input_tokens ve output_tokens ve üretimin neden durduğu için gen_ai.response.finish_reasons. Bunları kullanmak, Jaeger'dan Tempo'ya ve Langfuse'a kadar herhangi bir OTel uyumlu arka ucun, özel ayrıştırıcılar olmadan tracelerinizi okuması demektir.

Yüksek trafikte LLM loglarını nasıl örneklersiniz?

Her hatayı, her guardrail engellemesini ve bir maliyet eşiğinin üzerindeki her isteği tutun, gerisini örnekleyin. Bu kuyruk tabanlı yaklaşım, gerçekte hata ayıkladığınız nadir olayları korur, oysa tekdüze rastgele örnekleme onları sıkıcı trafikle aynı oranda eler. Günde 100 bin isteğin altında, örneklemeyi tamamen atlayın ve her şeyi loglayın.

LLM loglarını ne kadar süre saklamalısınız?

Katmanlandırın: canlı hata ayıklama için 7 gün sıcak, olay incelemesi ve maliyet analizi için 30 gün ılık ve uyumluluk ile denetimler için sıkıştırılmış nesne depolamada 1 yıla kadar soğuk. GDPR'ın depolama sınırlama ilkesi, kişisel verilerin gerekenden uzun tutulmasını yasaklar, bu yüzden her katmanı manuel temizlik yerine otomatik silmeyle eşleştirin.

LLM loglama ile LLM izleme arasındaki fark nedir?

Log, tek bir olayın düz kaydıdır: bu istek şu alanlarla gerçekleşti. Trace, tüm bir istek yolu boyunca spanlerin nedensel ağacıdır, örneğin önce getirme, sonra model çağrısı, sonra iki araç çağrısı. Loglar size ne olduğunu söyler; traceler nerede ve neden olduğunu söyler. Üretim kurulumları, trace_id ile birleştirilmiş ikisini de yayınlar.

Sonuç

Özet: her isteği adlandırılmış alanlı JSON olarak loglayın, maliyeti istek anında hesaplayın, OTel trace bağlamını ekleyin, PII'yi yazımdan önce maskeleyin, günde 100 bin isteği geçtiğinizde sonuca göre örnekleyin ve gerçekte sorgulayabileceğiniz bir depo seçin. Dokuz kural, sprint başına birini benimseyebileceğiniz şekilde sıralanmıştır ve Kural 2, 4 ve 5, en hızlı geri dönüş sağlayan üçüdür. Logların etrafındaki daha geniş izleme yığınını seçiyorsanız, en iyi AI gözlemlenebilirlik platformları derlememizle başlayın. Ve LLM yığınınız için yapılandırılmış loglamayı kurmada yardıma ihtiyacınız varsa, ücretsiz danışmanlık alın.