> ## Documentation Index > Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt > Use this file to discover all available pages before exploring further. # LogBrew'de sorunları önceliklendirme ve çözme > LogBrew'de sorunları yönetin. Oluşum kanıtını okuyun, sorunun sahibini bulun, ardından sorunları çözün, arşivleyin, yeniden açın, önceliklendirin ya da bir kişiye veya ekibe atayın. 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'ı](/tr/guides/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: | Alan | Anlamı | | - | - | | `title` | Yakalanan hatanın başlığı. | | `severity` | Yakalanan önem düzeyi. | | `triage.effective_severity` | LogBrew'ün sorun kurallarından sonra kullandığı önem düzeyi. `severity` yakalanan değeri korur. Bir kural uygulandığında `triage.rule_applied` değeri `true` olur. | | `occurrence_count` | Gruptaki saklanan oluşum sayısı. | | `first_seen_at` | Saklanan en eski oluşumun zamanı. | | `last_seen_at` | Saklanan en yeni oluşumun zamanı. | | `project_id` | Sorunu içeren proje. | | `service_name` | En son oluşumun hizmeti. | | `release` | En son oluşumun sürümü. | | `environment` | En son oluşumun ortamı. | | `status` | Sorunun iş akışı durumu. Bkz. [Durum değerleri](#status-values). | | `priority` | Sorunun önceliklendirme sırası. Bkz. [Öncelik](#priority). | | `priority_source` | Önceliği bir kişi ayarladıysa `manual`. Öncelik önem düzeyini izliyorsa `derived`. | | `assignee` | Sonraki adımın sorumlusu olan hesap veya ekip ya da `null`. Bkz. [Sorunları atayın](#assign-issues). | 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 | Durum | Anlamı | | - | - | | `unresolved` | Sorun bir karar bekliyor. | | `resolved` | Ekip sorunu düzeltildi olarak işaretledi. Durum düzeltmeyi kanıtlamaz. | | `archived` | Ekip sorunu etkin önceliklendirmeden çıkardı. | `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: | Öncelik | Anlamı | | - | - | | `high` | Sorunu önce inceleyin. | | `medium` | Sorunu `high` sorunlardan sonra inceleyin. | | `low` | Sorun bekleyebilir. | 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: ```bash theme={null} logbrew read issues --project "" --status unresolved \ --priority high --since 24h --json ``` ## 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. ```bash theme={null} logbrew issues assignees --project "" --json ``` `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. ```bash theme={null} logbrew issues assign "" "" --json logbrew issues assign "team:" "" --json ``` Sorunu kendinize atamak için kullanıcı kimliği yerine `me` kullanın. Sorumluyu kaldırmak için `logbrew issues unassign "" --json` komutunu kullanın. Bir projenin en fazla 100 sorununu değiştirmek için `--project` ekleyin. ```bash theme={null} logbrew read issues --project "" --assignee me \ --status unresolved --json ``` Ekiplerinizin sorunları için `--assignee my_teams`, tek bir ekip için `--assignee "team:"`, 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 ```bash theme={null} logbrew issues owners "" --json ``` 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: | `source` | Anlamı | | - | - | | `ownership_rule` | Projenin bir kuralı sorunla eşleşiyor. `rule`, `line` ve `matched` kuralı ve neyle eşleştiğini gösterir. | | `codeowners` | Projenin CODEOWNERS dosyasındaki bir satır, bir yığın çerçevesinin yoluyla eşleşiyor. | | `recent_activity` | Hesap sorunu değiştirdi veya soruna atandı. | `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: ```text theme={null} # type:pattern owner... path:src/payments/** ada@example.com #payments url:/checkout/* #web service:billing-api ada@example.com tags.region:eu-* #europe module:app.billing.* ada@example.com ``` `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: ```bash theme={null} logbrew issues ownership set --project "" \ --rules ownership.txt --codeowners .github/CODEOWNERS --json logbrew issues ownership --project "" --json ``` 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 ```bash theme={null} logbrew issues activity "" --json ``` 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 ```bash theme={null} logbrew inbox --json logbrew inbox read --json ``` 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ışı ```bash theme={null} logbrew read issues --project "" --environment production \ --release api@1.2.3 --status unresolved --since 24h --json ``` 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. ```bash theme={null} logbrew read issue "" --json ``` 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. ```bash theme={null} logbrew investigate issue "" --occurrence recommended --json ``` 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](/tr/guides/investigate-an-issue) rehberini 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. ```bash theme={null} logbrew read trace "" --project "" --json logbrew read logs --trace "" --project "" \ --since 24h --json ``` İz okumasının zaman filtresi yoktur. Durum `not_linked` ise sorun kanıtıyla devam edin. İ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. ```bash theme={null} logbrew investigate issue "" verify \ --baseline-occurrence "" \ --candidate-deployment "" \ --json ``` 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. Tek bir komut çalıştırın. Bu komutlar onay istemez. Bu yüzden önce sorun kimliğini kontrol edin. ```bash theme={null} logbrew issues resolve "" --json logbrew issues archive "" --json logbrew issues reopen "" --json logbrew issues priority low "" --json logbrew issues assign me "" --json ``` `--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 "" 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: ```bash theme={null} logbrew issues archive "" "" "" \ --project "" --json ``` 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: | Sonuç | Anlamı | | - | - | | `updated` | LogBrew değişikliği uyguladı. | | `unchanged` | Sorun zaten istenen değere sahipti. | | `not_found` | Projede bu kimlikte bir sorun yok. LogBrew bu kimlik için hiçbir şeyi değiştirmedi. | 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](/tr/reference/telemetry-api#update-issues-in-bulk) 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 "" "" --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. | Sonuç | Kurtarma | | - | - | | `not_logged_in` | Bir kişiden `logbrew login` komutunu çalıştırmasını isteyin, ardından okumayı yeniden deneyin. | | `invalid_issue_command` | Komutu düzeltin. 1'den fazla sorun için `--project` kullanın; en fazla 100 kimlik verin ve her kimliği bir kez yazın. | | Geçersiz sorun kimliği | Tam kimliği bir sorun listesinden veya ayrıntı yanıtından kopyalayın. | | Sorun bulunamadı | Giriş yapılmış hesabı ve projeyi doğrulayın. | | Bir değişiklik `status` `403` ile başarısız oluyor | Hesap bu projede sorunları yönetemiyor. Erişimi olan bir kişiden isteyin. | | `invalid_assignee` | `--assignee` filtresi `me`, `none`, `my_teams`, bir kullanıcı kimliği veya `team:` alır. | | Bir atama `status` `422` ve `api_code` `validation_failed` ile başarısız oluyor | Hesap projeyi okuyamıyor veya ekip projenin organizasyonunda değil. `logbrew issues assignees` listesinden birini seçin. | | `invalid_ownership_command`, `invalid_ownership_file` | Komutu düzeltin. Sahiplik dosyası en fazla 128 KiB boyutunda UTF-8 metin olmalıdır. | | `invalid_inbox_command` | `logbrew inbox` veya `logbrew inbox read` kullanın. | | `investigation_response_invalid` | Yanıt CLI doğrulamasından geçemedi. Bir kez yeniden deneyin. Tekrarlarsa CLI'ı güncelleyin veya sorunu bildirin. Doğrulamayı atlatmayın. | | İz durumu `not_linked` | Sorun kanıtıyla devam edin. İz okumayın. | | İz durumu `unavailable` | İnceleme okumasını daha sonra yeniden deneyin. | | Doğrulama `insufficient_traffic` | Sorunu `unresolved` olarak tutun. Aday sürümün trafik almasını bekleyin, ardından yeniden doğrulayın. | 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](/tr/reference/telemetry-api) sayfasına bakın. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.