Agent iş akışları için
--json kullanın. Kimlik bilgilerini korumalı yerel
yapılandırmada tutun. Kişiler, araçlar ve agentlar arasında yalnızca
değişken adlarını paylaşın.Başlamadan önce
Şunları hazırlayın:- Node.js 18 veya üstü.
- LogBrew CLI v0.1.30 veya üstü.
jq.- Bash veya Zsh.
- Sunucu tarafında çalışan bir Node.js uygulaması için paket dizini.
quickstart-node projesini, development ortamını ve quickstart@1
sürümünü kullanır. Bu testi production’dan ayrı tutun. Başka bir çalışma
zamanı için SDK entegrasyonu rehberini kullanın.
İlk logunuzu gönderin ve okuyun
1
Hesap durumunu okuyun
CLI’ı CLI rehberindeki komutla kurun. Ardından hesap
durumunu okuyun.Kontrol noktası: durum, kimliği doğrulanmış hesap erişimini bildirir.
Bildirmiyorsa bir kişi
logbrew login komutunu bir kez çalıştırır.
Ardından logbrew status --json komutunu yeniden çalıştırın. Mevcut kimlik
doğrulama çalışıyorsa agent yeni bir giriş başlatmamalıdır.2
CLI'dan bir proje oluşturun
Yalnızca sahibinin erişebildiği bir dizinde yeni bir dosya seçin. CLI,
başarılı olduğunu bildirmeden önce projenin alım anahtarını bu dosyaya
yazar. Anahtarı ve dosya yolunu asla ekrana yazdırmaz.Proje oluşturmak hesap durumunu değiştirir. Hedef dosya önceden var
olmamalıdır. Sonuç net değilse aynı komutu yeniden çalıştırın. CLI bekleyen
isteğinin kimliğini yeniden kullanır.
--abandon-retry seçeneğini yalnızca
farklı bir deneme başlatmak için kullanın.Kontrol noktası: çıktı status: "created" değerini, created kurulum
durumunu ve bir alım anahtarı türünü bildirir. Proje vardır ve anahtar
saklanmıştır. Bu, telemetrinin ulaştığını göstermez. Bkz.
Projeler.3
Node.js SDK'sını kurun
4
Güvenli bir SDK logu gönderin
Yalnızca yer tutucu içeren bir Olaya kimlik bilgisi, başlık, istek gövdesi, müşteri verisi veya yerel yol
yazmayın.Kontrol noktası: betik,
info loguyla birlikte sürüm ve ortam
işaretlerini gönderin. Anahtar yalnızca bu Node.js işlemi için ayarlanır.
Uygulama kimliği context içine yazılır.Her çalıştırma yeni olay kimlikleri oluşturur. SDK aynı çalıştırmada
gönderimi yeniden denerse aynı gövdeyi aynı kimliklerle gönderir. Kabul
edilmiş bir olay yeniden denemeyle tekrar gelirse LogBrew onu ikinci kez
saklamaz.2xx bir status_code ile "ok":true
yazdırır. Yeniden denemeden sonra attempts, 1 değerinden büyük olur.
Başarılı bir gönderim son kontrol değildir.Gönderim başarısız olursa betik 1 koduyla çıkar ve
{"ok":false,"error":"unauthenticated"} gibi kısa bir JSON hatası yazdırır.
İstek gövdesini veya anahtarı yazdırmaz. Reddedilen bir proje anahtarı
unauthenticated hatasına neden olur. Yeni bir CLI girişi bunu düzeltmez.5
Proje doctor raporunu okuyun
CLI bu okuma için kayıtlı hesap erişimini kullanır. Projenin alım
anahtarını kullanmayın.Kontrol noktası: raporda
status: "ready" bulunur. checks içindeki
her öğeyi de okuyun. 0 çıkış kodu tüm kontrollerin geçtiğini göstermez.
Başka bir durum için next alanını ve
doctor raporu referansını
izleyin. ready durumundaki bir proje, bu test logunun ulaştığını
göstermez.6
Test logunu okuyun
SDK’nın toplu gönderimindeki projeyi, sürümü ve ortamı kullanın.Kontrol noktası:
LogBrew quickstart check o proje, sürüm ve ortam
için görünür. Bu yalnızca test logunun ulaştığını gösterir.Test sonucunu okuyun
Örnek üç olay gönderir. Bunlardan yalnızca biri logdur. Sürüm ve ortam işaretleri loga bağlam verir.
Testi
info düzeyinde tutun. Daha kolay bulmak için error düzeyine
çevirmeyin. Bunun yerine proje ve zaman filtrelerini kullanın. Bkz.
Önem düzeyi değerleri.
console.log satırı gönderim sonucunu terminalinize yazdırır. client.log
çağrısı logu LogBrew’e gönderir. Başarılı ilk gönderim şunu yazdırır:
--project filtresi olayları
taşımaz.
Örnek bir istek span’i oluşturmadığı için bu logda iz bağlamı yoktur. Bu, logun
başarısız olduğunu göstermez. CLI okuması anlık bir görüntüdür. Sonraki
olayları okumak için komutu yeniden çalıştırın veya canlı akış için
logbrew watch logs --json kullanın.
Sık karşılaşılan kurtarma kararları
Telemetri hâlâ eksikse
ilk telemetri kontrollerini
kullanın. Bu kontroller yardımcı olmazsa sorun bildirin.
Kimlik bilgisi, ham telemetri, müşteri verisi, yerel yol veya kaynak kodu
eklemeyin.
Uygulamanıza geçin
- İstemciyi uygulamanızın kurulum kodunda bir kez oluşturun.
- Paket dosyalarınızda SDK sürümlerini sabitleyin. Yükseltmeleri production dışında test edin.
- Alım anahtarını mevcut gizli bilgi yapılandırmanızdan okuyun. Anahtar açığa çıkmış olabilirse yenileyin. Bkz. Alım anahtarını yenileyin.
- Dağıtım yapılandırmanızdaki kararlı hizmet, ortam ve sürüm adlarını kullanın. Bkz. Sürümler.
- İşlemi ve sonucunu adlandıran log mesajları yazın, örneğin
Report generation completed. Özel değerleri mesajın dışında tutun. Bir isteğin veya kullanıcı kaydının tamamını loga kopyalamayın. - Yinelenen kayıtları önlemek için her uygulama logunu tek bir gönderici göndersin. LogBrew’ü eklemeden önce her kaydı hâlihazırda gönderen entegrasyonu bulun.
- Production’a geçmeden önce gerçek kod yolundan güvenli bir olay gönderin ve geri okuyun. Mesajını, hizmetini, sürümünü ve ortamını kontrol edin. Bağımsız bir örnek, uygulamanızın kod yolunu test etmez.
Projeler
Kurulum durumunu okuyun ve projenin alım anahtarlarını yönetin.
SDK entegrasyonu
Çalışma zamanınız için SDK paketini seçin.
Bir sorunu inceleyin
Bir sorunun iz ve ilişkili log kanıtını izleyin.
Sorun bildirin
Güvenli ve gizli bir destek raporu gönderin.
