Skip to main content
Sorun, aynı parmak izini paylaşan hata oluşumlarını gruplar. Durumu, önceliği veya sorumluyu değiştirmeden önce grup özetini ve bir oluşumu okuyun. Durum, öncelik veya sorumlu değişikliği bir ekip kararını kaydeder. Yazılımı onarmaz ve yakalanan olayları yeniden yazmaz. Başlamadan önce LogBrew CLI’ı kurun ve logbrew login komutunu çalıştırın.

​
Sorunlar ve oluşumlar

Sorun listesi tam bir olay değil, bir grup özeti döndürür. Ayrıntıyı açmadan önce şu alanları okuyun: Oluşum sayısı, etkilenen kullanıcı sayısı değildir. Sayılar ve zamanlar hata geçmişinin tamamına değil, dönen kapsama aittir. --since veya --until filtresi LogBrew’ün saydığı oluşumları sınırlar. Bir sayıyı bildirirken onu üreten filtreleri de bildirin.

​
Durum değerleri

archived değerinin eski adı ignored idi. İki ad aynı sorunları seçer ve ikisi de giriş olarak kabul edilir. logbrew read, logbrew issues ve API sürüm 2 ile 3 archived gösterir. API sürüm 1 (varsayılan), canlı izleme akışı ve sorun inceleme yanıtı ignored gösterir. Panel bu durumları Çözülmemiş, Çözülmüş ve Arşivlendi olarak gösterir. Durum tek bir oluşuma değil, sorunun tamamına uygulanır. Önem düzeyi aciliyeti gösterir, durum ise kararı kaydeder. İkisini ayrı tutun. critical bir sorun, doğrulanmış bir düzeltmeden sonra resolved olabilir. archived bir sorun yakalanan önem düzeyini korur. LogBrew çözülmüş bir sorunu otomatik olarak yeniden açmaz. Çözümden sonra yeni bir oluşum gelirse inceleme lifecycle.effective_status değerini regressed olarak bildirir. Bir kişi sorunu yeniden açana kadar status değeri resolved kalır.

​
Öncelik

Öncelik, ekibin sorunları hangi sırayla önceliklendireceğini belirler: Her sorunun bir önceliği vardır. Kimse ayarlamazsa öncelik sorunun önem düzeyini izler: error ve critical, high; warning, medium; info ise low olur. Bir sorun kuralı önem düzeyini değiştirdiğinde öncelik triage.effective_severity değerini izler. Bu durumda priority_source değeri derived olur. Bir kişi önceliği ayarladığında öncelik sabit kalır ve priority_source değeri manual olur. Önce incelenecek sorunları listelemek için:

​
Sorunları atayın

Sonraki adımın sorumlusunu göstermek için sorunu atayın. Bir sorunun 0 veya 1 sorumlusu olur: bir hesap ya da bir ekip.
1

Kimlerin atanabileceğini bulun

assignees, projeyi okuyabilen her hesabı user_id, name ve email ile listeler. teams, projenin organizasyonundaki her ekibi team_id, slug ve name ile listeler. Projeyi okuyamayan bir hesaba veya başka bir organizasyonun ekibine sorun atayamazsınız.
2

Sorunu atayın

Sorunu kendinize atamak için kullanıcı kimliği yerine me kullanın. Sorumluyu kaldırmak için logbrew issues unassign "<issue_id>" --json komutunu kullanın. Bir projenin en fazla 100 sorununu değiştirmek için --project ekleyin.
3

Sorunlarınızı okuyun

Ekiplerinizin sorunları için --assignee my_teams, tek bir ekip için --assignee "team:<team_id>", kimsenin sorumlu olmadığı sorunlar için --assignee none kullanın.
Sorun atamak için projede sorunları yönetme izniniz olmalıdır. Aynı izinle durumu, önceliği, sahiplik kurallarını, sorun ve log kurallarını da değiştirebilirsiniz. Ekipleri organizasyon sahipleri ve yöneticileri oluşturur ve üyelerini onlar seçer. Bir ekip, üyelerine proje erişimi vermez. Bir üye projeye erişimini kaybettiğinde o üyeye atanmış sorunlarda sorumlu görünmez. Bir ekip silindiğinde de ona atanmış sorunlarda sorumlu görünmez. Bu sorunlar --assignee none okumalarında çıkar. Üye erişimi yeniden alırsa sorunlar o üyeyi yeniden gösterir. Bu arada biri sorumluyu değiştirdiyse veya kaldırdıysa bu olmaz.

​
Sorunun sahibini bulun

Sonuç, önerilen sahipleri en uygun olandan başlayarak listeler ve bir suggested_assignee değeri döndürür. Her sahibin bir source değeri vardır: inputs, LogBrew’ün kontrol ettiği yığın çerçevesi yollarını, modülleri, rota şablonunu, etiketleri ve kuralları sayar. Liste boşsa ve inputs hiç yol göstermiyorsa sorunun sahibi yok demek değildir. Yalnızca eşleştirilecek kanıt yoktur. Sahiplik kurallarını bir metin dosyasına, her satıra bir kural gelecek şekilde yazın:
path kalıbı, yığın çerçevesi yolunun sonuyla eşleşir. Bu yüzden src/payments/**, hangi dağıtım dizininde olursa olsun bu klasörün altındaki çerçevelerle eşleşir. * herhangi bir metinle eşleşir. Sahipler hesap e-postaları veya #team-slug olur. Eşleşen son kural önce gelir. Ardından kuralları, bir GitHub CODEOWNERS dosyasını ya da ikisini birden gönderin:
CODEOWNERS dosyasında bir e-posta bir hesabı, @org/team-slug ise o slug’a sahip ekibi belirtir. Proje erişimi olmayan bir hesabı veya bilinmeyen bir ekibi belirten kurallar 422 ile başarısız olur. Kimseyle eşleşmeyen CODEOWNERS sahipleri unresolved_owners içinde görünür. Boş bir dosya, o dosyanın metnini temizler.

​
Sorun geçmişini okuyun

Geçmiş; durum, öncelik, sorumlu ve önem düzeyi kuralı değişikliklerinin tamamını en yeniden başlayarak, değişikliği yapan hesapla birlikte listeler. Liste first_seen ile biter. Proje erişimini kaybeden bir hesabın yalnızca kimliği görünür. Daha fazlasını okumak için --limit ve next_cursor değerlerini kullanın.

​
Gelen kutunuzu okuyun

Gelen kutusu, başkalarının size veya ekiplerinize atadığı sorunları en yeniden başlayarak listeler. unread, okundu işaretinizden sonraki atamaları sayar. logbrew inbox read, okundu işaretini şu ana taşır. LogBrew bu atamalar için e-posta göndermez. Gelen kutusu yalnızca şu anda okuyabildiğiniz projeleri gösterir.

​
Önerilen iş akışı

1

Tek bir kapsamdaki çözülmemiş sorunları listeleyin

Sonraki liste okumalarında aynı filtreleri kullanın. Boş bir sonuç, bu kapsamla eşleşen sorun olmadığı anlamına gelir. Projede hata olmadığını kanıtlamaz. Başlığı değil, tam sorun kimliğini kopyalayın.
2

Sorun ayrıntısını okuyun

Devam etmeden önce dönen projenin doğru olduğunu doğrulayın. Okumalar anlık bir görüntü döndürür. Durumu değiştirmeden önce sorunu yeniden okuyun.
3

Bir oluşumu inceleyin

Ayrıntı ve inceleme okumaları liste filtrelerini kullanmaz. subject.project_id, event.occurred_at, sürüm ve ortam değerlerini kendi kapsamınızla karşılaştırın. Önerilen oluşum en sonuncusundan daha eski olabilir. Kanıtın tamamını incelemek için Bir sorunu inceleyin rehberini izleyin.
4

İz kanıtını yalnızca mevcutsa izleyin

İzi yalnızca correlations.trace.status değeri available olduğunda okuyun. Yanıttaki iz kimliğini kullanın. Hiçbir zaman kendiniz bir kimlik uydurmayın.
İz okumasının zaman filtresi yoktur. Durum not_linked ise sorun kanıtıyla devam edin.
5

Aday dağıtımı doğrulayın

İncelediğiniz oluşumu temel oluşum olarak kullanın. Dağıtım kimliğini dağıtım kanıtından veya sürüm sürecinizden alın.
Gözlem aralığında tekrarlama olmaması kalıcı bir düzeltmeyi kanıtlamaz. status değeri insufficient_traffic veya unavailable ise sorunu unresolved olarak tutun. Dönen sonraki adımı izleyin.
6

Durumu, önceliği veya sorumluyu değiştirin

Tek bir komut çalıştırın. Bu komutlar onay istemez. Bu yüzden önce sorun kimliğini kontrol edin.
--project olmadan her komut 1 sorun kimliği alır. Çıkış kodunu ve dönen status, priority ve assignee değerlerini kontrol edin. Sonuç eksikse sonraki değişiklikten önce sorunu yeniden okuyun.Eski betikler logbrew set issue "<issue_id>" resolved komutunu ve resolve, ignore ve reopen kısayollarını kullanabilir. ignore, archived değerini ayarlar.

​
Birçok sorunu aynı anda değiştirin

Tek bir komutla bir projenin en fazla 100 sorununu değiştirmek için --project ekleyin:
Komut her soruna aynı değişikliği uygular. Her sorun kimliği yalnızca bir kez yer alabilir. CLI, 100’den fazla kimliği veya tekrarlanan bir kimliği istek göndermeden önce reddeder. Sonuçta her sorun için komuttaki sırayla 1 girdi bulunur: Her girdide issue_id, outcome ve issue bulunur. issue, sorunun güncel hâlidir; not_found için null olur. Bir ağ hatasından sonra aynı komutu yeniden çalıştırabilirsiniz. Zaten değişmiş sorunlar unchanged gösterir. 100 sorundan fazlası için birden fazla komut çalıştırın. not_found sonucunda kimliği o projenin sorun listesinden yeniden kopyalayın. API isteği için Sorunları toplu güncelleyin bölümüne bakın.

​
Sonraki durumu seçin

  • Hata hâlâ etkinse veya düzeltme doğrulanmadıysa unresolved olarak tutun. Eksik bir iz, sorunu arşivlemek için bir neden değildir.
  • Ekip düzeltme kanıtını kabul ettikten sonra resolved olarak ayarlayın. Önerilen bir düzeltme kanıt değildir.
  • Kabul edilmiş bir durum veya yalnızca testten gelen bir sinyal için archived olarak ayarlayın. Karar sorunun her oluşumuna uygulanır. Komutun gerekçe alanı yoktur. Bu yüzden gerekçeyi ekibinizin iş kaydına yazın.
  • Çözümden sonra yeni bir oluşum gelirse unresolved ile yeniden açın. lifecycle.regression.first_reappeared_occurrence bu oluşumu tanımlar. Onu çözüm için kullanılan oluşumla karşılaştırın. Ayrı bir sorun oluşturmayın.

​
İncelemeyi devredin

Sonraki kişiye ham olay dökümü değil, referanslar verin:
  • Sorun kimliği, durum, öncelik, sorumlu ve önem düzeyi.
  • Proje, hizmet, ortam ve sürüm.
  • İlk görülme zamanı, son görülme zamanı ve oluşum sayısı.
  • Seçilen oluşum kimliği ve occurrence_selection.reason.
  • fix.status, cause.status ve bunların provenance değeri.
  • Varsa iz durumu ve iz kimliği.
  • Yeniden üretme durumu ve eksik kanıt.
  • Aday dağıtım doğrulamasının sonucu.
  • Yanıtın döndürdüğü sonraki adım.
Önerilen nedenleri ve düzeltmeleri öneri olarak etiketleyin.

​
CLI hatalarından kurtulun

Çıktıyı ayrıştırmadan önce sürecin çıkış kodunu kontrol edin. Başarılı olduğunda JSON standart çıktıya yazılır. Ayrıştırma hatası 2 koduyla çıkar. Çalışma zamanı hatası 1 koduyla çıkar. JSON hataları standart hataya yazılır ve ok: false, error, message ve next içerir. next değerini yönlendirme olarak gösterin. Otomatik olarak çalıştırmayın. Örneğin logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json komutunda --project yoktur. Komut istek göndermeden 2 koduyla ve invalid_issue_command hatasıyla çıkar. API bir isteği reddettiğinde error değeri api_error olur. HTTP durumu için status, API hata kodu için api_code değerini okuyun. Başarısız bir yanıt, durum, öncelik veya sorumlu değişikliğinin etkisiz kaldığını kanıtlamaz. Yeniden denemeden önce sorunu okuyun.

​
Yararlı bir sorunun özellikleri

  • Net bir başlık ve okunabilir bir mesaj.
  • Kararlı bir parmak izi.
  • Mevcutsa yığın çerçeveleri.
  • Sürüm, ortam ve hizmet bağlamı.
  • Oluşumla birlikte yakalandıysa iz bağlamı.
  • Tam yük dökümleri değil, küçük ve ilgili öznitelikler.
Liste filtreleri ve yanıt sözleşmeleri için Telemetri API’si sayfasına bakın.