Skip to main content
Açık kaynak LogBrew CLI terminalden telemetri okur ve hesap verilerini yönetir. Kurulum, giriş ve sık yapılan işler için CLI rehberiyle başlayın.

CLI nasıl çalışır?

Terminalde okunabilir metin kullanın. Betiklerde ve kodlama asistanlarında --json kullanın. Hesap okumaları için hesap girişi gerekir. Girişi başlatmadan önce logbrew status --json komutunu çalıştırın. Tarayıcıdaki yetkilendirmeyi bir kişinin tamamlaması gerekir. Proje alım anahtarları (ingest key) telemetri gönderir. Hesap girişinin yerini tutamaz. Proje oluşturma, anahtar oluşturma, sorun durumu, öncelik ve sorumlu değişiklikleri, dağıtımlar ve destek güncellemeleri hesap verilerini değiştirir. Bunlardan birini çalıştırmadan önce aksiyonun ve hedefin doğru olduğundan emin olun. Tüm komutları görmek için logbrew --help çalıştırın. Bir komutun seçeneklerini görmek için ona --help ekleyin, örneğin logbrew read logs --help. JSON kuralları için logbrew help json çalıştırın.

Proje doctor raporunu okuyun

logbrew projects --json çıktısındaki bir proje kimliğini kullanın:
Komut proje durumunu ve son bir logu okur. Proje oluşturmaz, anahtarı değiştirmez ve kurulum kaydetmez. Rapor status, checks ve next alanlarını içerir. Her kontrol check, status ve next alanlarını içerir. Kontroller api, auth, project, ingest_key, setup, telemetry ve logs olur. 0 çıkış kodu, CLI’ın bir rapor yazdığı anlamına gelir. Projenin hazır olduğu anlamına gelmez. Raporun status değerini ve her kontrolü okuyun. not_checked durumundaki bir kontrol geçmemiştir. Proje okuması başarılı olduğunda logs kontrolü visible, empty, unavailable, error veya invalid_response olur. Bu kontrol raporun status değerini değiştirmez. Boş bir log sonucu diğer sinyaller hakkında bilgi vermez. Başarısız bir okuma boş bir sonuç değildir. next değerini kurtarma yönlendirmesi olarak kullanın. Bu değer hesap veya proje durumunu değiştirme izni vermez.

Örnek: hesap erişimi eksik

Hesap kimlik bilgileri olmadan komut API isteği yapmaz. Bu raporu standart çıktıya yazar ve 0 koduyla çıkar:
Bu rapor proje API teşhisinden farklıdır. state, setup_status veya next_action API alanlarını içermez.

Filtreler

--since, 24h veya 7d gibi bir süre ya da bir RFC 3339 zaman damgası kabul eder. --until bir RFC 3339 zaman damgası kabul eder. Bu, aralığa dâhil olmayan bir bitiş zamanıdır ve --since değerinden sonra olmalıdır. Kimlikle okunan tek bir sorun --until kabul etmez. Log önem düzeyi info, warning, error veya critical olur. Sorun durumu, sorunun önem düzeyi değil, iş akışındaki durumudur. --status ignored, --status archived için eski bir addır. --status open, unresolved; --status closed ise resolved anlamına gelir. --assignee none, sorumlusu olmayan sorunları; --assignee my_teams ise ekiplerinizin sorunlarını seçer. Başka bir --assignee değeri invalid_assignee ile başarısız olur. CLI şu takma adları da kabul eder: --project-id, --env, --service-name, --trace-id, --distinct-id ve --severity için --level. Yeni betiklerde tablodaki adları kullanın. Bu komut 1 günlük hataları okur:
Proje kimliği projeyi seçer. Hizmet adı o projedeki bir bileşeni seçer. Boşluk içeren değerleri tırnak içine alın:
Kısa çizgiyle başlayan arama metni için metnin önüne -- koyun:

Bir sorun oluşumu seçin

Bir sorun eşleşen oluşumları gruplar. Sorunun durumu, oluşum sayısı, ilk görülme ve son görülme zamanları için sorunu okuyun:
Tek bir oluşumdan kanıt almak için explain issue veya investigate issue kullanın. --occurrence olmadan LogBrew önerilen oluşumu seçer. Bu her zaman en son olay değildir. En son olayı okumak için:
--occurrence; recommended, first veya LogBrew’ün döndürdüğü bir oluşum kimliğini de kabul eder. Bu komutlar proje, sürüm, ortam ve zaman filtrelerini reddeder. Kanıtları karşılaştırmadan önce seçilen oluşumun zaman damgasını okuyun. Kanıt alanları için Bir sorunu inceleyin rehberine bakın.

Sorun durumunu ve önceliğini değiştirin

1 sorunu değiştirmek için 1 sorun kimliği kullanın:
archive durumu archived, resolve durumu resolved, reopen ise durumu unresolved yapar. Öncelik high, medium veya low olur. Ayarladığınız öncelik sabit kalır. Aksi hâlde öncelik sorunun önem düzeyini izler. 1’den fazla sorunu değiştirmek için --project ekleyin. Tüm sorunlar o projede olmalıdır. Tek bir komut en fazla 100 sorunu değiştirir:
Sonuç her sorun için 1 girdi içerir. Her girdi updated, unchanged veya not_found olur. unchanged bir sorun istenen değere zaten sahipti. Bir ağ hatasından sonra aynı komutu yeniden çalıştırabilirsiniz. Bu komutlar onay istemez. Önce sorun kimliklerini kontrol edin. Sorun okumaları ve değişiklikleri ignored yerine archived gösterir. Ayrıca her sorunun priority, priority_source ve assignee değerlerini gösterir. Sorun yanıtı bölümüne bakın.

Sorun atayın

Bir sorunun 0 veya 1 sorumlusu olur: bir hesap ya da bir ekip. Bir projede atayabileceğiniz hesapları ve ekipleri listeleyin:
1 sorunu bir hesaba, me ile kendinize veya bir ekibe atayın:
Sorumluyu kaldırın:
Durum ve öncelikte olduğu gibi, o projenin en fazla 100 sorununu değiştirmek için --project ekleyin. Hesap projeyi okuyabilmeli, ekip de projenin organizasyonunda olmalıdır. Size veya ekiplerinize atanan sorunları bulmak için:
Metin çıktısı sorumlunun adını, ekipler için de team #<slug> gösterir. Hesabın adı yoksa e-posta adresini, o da yoksa kullanıcı kimliğini gösterir. Sorumlusu olmayan bir sorun unassigned gösterir.

Sahipler, geçmiş ve gelen kutusu

issues owners, önerilen sahipleri ve kontrol ettiği kanıtı listeler. issues ownership set, her biri en fazla 128 KiB olan yerel dosyaları gönderir. Boş bir dosya, o dosyanın metnini temizler. issues activity ve inbox, 1 ile 200 arasında --limit ve next_cursor içinden gelen --cursor-time ile --cursor-id değerlerini alır. Sorunun sahibini bulun bölümüne bakın.

Önem düzeyi kurallarını ayarlayın

Önem düzeyi info, warning, error, critical veya source olur. source, yakalanan önem düzeyini yeniden gösterir. --ignore, eşleşen logları varsayılan log listesinde gizler. --ignore olmadan kural onları gösterir.

Sonraki sayfayı okuyun

Loglar, sorunlar, aksiyonlar, metrikler ve izler cursor ile sayfalamayı kabul eder. Sürümler kabul etmez. İlk sayfa için --pagination cursor kullanın:
Yanıt logs ve next_cursor alanlarını içerir. Null olmayan bir next_cursor, time ve id içerir. Bunları --cursor-time ve --cursor-id ile gönderin:
Her sayfada aynı filtreleri ve sınırı koruyun. next_cursor değeri null olduğunda durun. Başka sayfa olup olmadığına satır sayısıyla değil, cursor ile karar verin. Son sayfa boş olabilir:
Sorunlar, aksiyonlar ve metrikler aynı yapıyı kullanır. Yalnızca logs yerine issues, actions veya metrics bulunur.

Canlı izleme

logbrew watch --json; canlı logları, sorunları ve aksiyonları akış olarak alır. Tek bir türü almak için logs, issues veya actions ekleyin. tail, follow ve stream, watch için takma adlardır. Watch izleri veya span’leri desteklemez. Watch için --json gerekir. Bu seçenek olmadan komut watch streams JSON for agents yazar ve 1 koduyla çıkar. Watch sorun olayları arşivlenmiş bir sorunu öncelik olmadan ignored olarak gösterir. Güncel durumunu ve önceliğini almak için sorunu okuyun. Watch yalnızca --severity error,critical gibi --severity kabul eder. logbrew watch actions, --severity kabul etmez. CLI bu filtreyi olayları aldıktan sonra uygular. Sunucunun gönderdiği veriyi azaltmaz. Watch’ta proje, sürüm, ortam veya zaman filtresi yoktur. Bu filtreler için bir read komutu kullanın. Geçici bir bağlantı kopmasından sonra CLI bekler ve yeniden bağlanır.

Sonuçları ve hataları okuyun

--json seçeneğini komuttan önce veya sonra yazın. Çıktıyı kullanmadan önce çıkış kodunu okuyun. İnsanlar için yazılmış çıktıyı ayrıştırmayın. Bu çıktı sürümler arasında değişebilir. Başarılı çıktı API yanıtının yapısını korur. Bir dizi veya bir nesne olabilir. Cursor ile sayfalama olmadan bir log okuması dizi döndürür. Boş bir dizi hiçbir logun eşleşmediği anlamına gelir. Bu bir hata değildir. Hatalar standart hataya gider. İstisna debug-artifacts --json komutudur. Bu komut hataları standart çıktıya yazar. JSON hatası ok, error, message ve next alanlarını içerir. Sabit hata kodu olarak error değerini kullanın. Önerdiği komutu çalıştırmadan önce next değerini inceleyin. Örneğin logbrew watch traces --json 2 koduyla çıkar ve şunu yazar:
logbrew read logs --limit 0 --json 2 koduyla çıkar ve şunu yazar:
Değeri düzeltin ve komutu yeniden çalıştırın. Reddedilen bir komut boş bir sonuç değildir. HTTP hataları için API hataları, doğrudan API istekleri için Telemetri API’si sayfasına bakın.