> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting

title: "Sorun Giderme"
description: "AgentEye Sorun Giderme belgeleri."
------------------------------------------------

Bu rehber, üretimde karşılaşabileceğiniz semptomları somut bir tanı ve çözüme eşleştirerek, zaten sahip olduğunuz araçlardan sorunları çözmekte yardımcı olur. Ek gözlemlenebilirlik altyapısı kurmanız gerekmez. Sunucu, toplayıcı, pano, yapay zeka asistanı, Python SDK, sağlık ve sertifika izleme, yedeklemeler, ClickHouse tabanlı analitikler ve çok kiracılılığı kapsar.

Pano sayfaları `/<org-slug>/…` altında kuruluş kapsamlıdır ve etkinlik akışı kuruluş ana sayfasıdır (`/<org-slug>/`). Bu rehberdeki sayfa adları (örneğin `/sessions`, `/queries`) bu kuruluş kapsamlı rotaları ifade eder.

***

## Günlükleri Görüntüleme

AgentEye günlüğe kaydetme veya izleme yığını içermez. Hem sunucu hem de pano yapılandırılmış günlükleri **stdout** dosyasına yazar, böylece `kubectl` veya `docker` ile doğrudan okuyabilirsiniz; toplayıcıya gerek yoktur.

### Kubernetes

Sunucu ve pano için canlı günlükleri takip edin:

```bash theme={null}
kubectl logs -n agenteye -l app=server    -f --timestamps
kubectl logs -n agenteye -l app=dashboard -f --timestamps
```

Yararlı varyantlar:

| Amaç                                | Komut                                                             |
| ----------------------------------- | ----------------------------------------------------------------- |
| Son 200 satır (izleme yok)          | `kubectl logs -n agenteye -l app=server --tail=200 --timestamps`  |
| Önceki kilitlenmeden günlükler      | `kubectl logs -n agenteye <pod-name> --previous`                  |
| Tüm çoğaltmaları aynı anda takip et | `kubectl logs -n agenteye -l app=server --max-log-requests=10 -f` |
| Postgres (StatefulSet)              | `kubectl logs -n agenteye postgres-0 -f`                          |

### Docker Compose

```bash theme={null}
docker logs -f agenteye-server
docker logs -f agenteye-dashboard
```

### Pano ve sunucuyu arasında tek bir isteği ilişkilendirme

Her pano isteği bir `request_id` ile etiketlenir ve `x-request-id` başlığı aracılığıyla sunucuya iletilir. Sunucu, yanıt başlıklarında ve bu istek için yayınladığı her günlük satırında okunur. Bir isteği uçtan uca izlemek için:

1. Yanıt başlığından kimliği yakalayın, örneğin:
   ```bash theme={null}
   curl -i https://dashboard.example.com/api/events | grep -i x-request-id
   # x-request-id: 9a7b0d6e-5e9b-4c0a-9f8a-5f1e4b5c0f3a
   ```
2. Her iki pod'un günlüklerinde o kimliği arayın:
   ```bash theme={null}
   REQ=9a7b0d6e-5e9b-4c0a-9f8a-5f1e4b5c0f3a
   kubectl logs -n agenteye -l app=dashboard --tail=5000 | grep "$REQ"
   kubectl logs -n agenteye -l app=server    --tail=5000 | grep "$REQ"
   ```

Panonun `proxy passthrough`, `withAuth: authorized` ve `upstream response` satırlarını sunucunun `http request received` / `http request completed` çifti ile birlikte göreceksiniz; hepsi aynı `request_id` paylaşır.

### JSON günlükleri ve `jq`

Panonun `NODE_ENV=production` olduğunda varsayılan olarak açık olan `AE_LOG_JSON=1` ayarlayın. Satır başına bir JSON nesnesi yayınlar. Sonra yapısal olarak filtreleyin:

```bash theme={null}
kubectl logs -n agenteye -l app=dashboard --tail=5000 \
  | jq 'select(.level == "warn" or .level == "error")'

kubectl logs -n agenteye -l app=dashboard --tail=5000 \
  | jq 'select(.route == "POST /api/keys")'
```

Rust sunucusu izleme `key=value` çiftleri yayınlar; `jq` olmadan iyi çalışır:

```bash theme={null}
kubectl logs -n agenteye -l app=server --tail=5000 | grep 'status=5'   # 5xx
kubectl logs -n agenteye -l app=server --tail=5000 | grep 'actor_key_id='
```

### Ayrıntı düzeyini artırma

| Bileşen | Ortam değişkeni | Örnek                                                       |
| ------- | --------------- | ----------------------------------------------------------- |
| Sunucu  | `RUST_LOG`      | `RUST_LOG=debug` veya `RUST_LOG=agenteye_server=debug,info` |
| Pano    | `AE_LOG_LEVEL`  | `AE_LOG_LEVEL=debug`                                        |

Sunucuda `debug`, kimlik doğrulama başına `api key authenticated` satırı ekler. Panoda `debug`, `upstream request`, `session validated` ve `proxy passthrough` satırları ekler.

### Günlük tutma

Konteyner stdout geçicidir; kubelet günlük dosyalarını (konteyner başına varsayılan \~10 MiB) döndürür ve diskte küçük bir sayı tutar. Pod silindiğinde günlükler ortadan kalkar. Daha uzun tutma veya çapraz pod araması gerekiyorsa, kümenizi `/var/log/containers/` dosyasını takip eden bir günlük toplayıcısına (Loki, CloudWatch, Cloud Logging, Datadog, vb.) yönlendirin. AgentEye belirli bir seçimi gerektirmez veya öne sürmez.

***

## Kimlik Doğrulama Sorunları

### `docker pull` "unauthorized" hatasıyla başarısız

Docker'ı `AGENTEYE_TOKEN` ile GHCR'a karşı kimlik doğruladığınızdan emin olun:

```bash theme={null}
echo $AGENTEYE_TOKEN | docker login ghcr.io -u x --password-stdin
```

Token `agenteye-enterprise` kuruluşunda `read:packages` izinine sahip olmalıdır. Tokeniniz işe yaramazsa `support@exosphere.host` ile iletişim kurun.

### `gh release download` 404 veya 401 döndürüyor

* `AGENTEYE_TOKEN` kabuğunuzda dışa aktarıldığını doğrulayın: `echo $AGENTEYE_TOKEN`
* `GITHUB_TOKEN=$AGENTEYE_TOKEN gh release download ...` kullanmakta olduğunuzu doğrulayın (`gh` CLI, `GITHUB_TOKEN` okuyor)
* Token `agenteye-enterprise/releases` üzerinde `contents:read` gerekir

***

## Sunucu Sorunları

### Sunucu "invalid port number" ile başarısız

`POSTGRES_PASSWORD` (veya başka bir kimlik bilgisi) URL'ye özel karakterler içeriyor (`/`, `+`, `=`) ve `DATABASE_URL` ayrıştırmasını kırarıyor. Hex kodlamasını kullanarak parolayı yeniden oluşturun:

```bash theme={null}
NEW_PASS=$(openssl rand -hex 24)
```

Sonra Kubernetes gizlisini güncelleyin ve Postgres içindeki parolayı değiştirin (veya Docker Compose için `.env` dosyasını yeniden oluşturun) ve sunucuyu yeniden başlatın. [enterprise-docs/kubernetes-deployment.md](/tr/agenteye/kubernetes-deployment) § "PostgreSQL credentials" içindeki tam adımları görebilirsiniz.

### Sunucu başlangıçta hemen çıkıyor

Konteyner günlüklerini kontrol edin:

```bash theme={null}
docker logs agenteye-server
```

Yaygın nedenler:

* `DATABASE_URL` ayarlanmadı veya hatalı biçimlendirildi: sunucu hatayı günlüğe kaydeder ve çıkar.
* Postgres ulaşılamıyor: Postgres konteynerinin veya yönetilen DB'nin çalıştığını ve ana bilgisayar/bağlantı noktasının doğru olduğunu doğrulayın.
* Göçler başarısız: SQL hataları için günlükleri kontrol edin.

### `GET /health` 200 olmayan değer döndürüyor veya zaman aşımına uğruyor

Sunucu ilk başlangıçta göçler çalıştırıyor olabilir. Birkaç saniye bekleyin ve yeniden deneyin:

```bash theme={null}
curl http://localhost:8080/health
```

Sorun devam ederse, hataların `docker logs agenteye-server` kontrol edin.

### `GET /ready` 503 döndürüyor

`/ready`, hazırlık sondası; sunucu **Postgres veya ClickHouse'a** ulaşamadığında `503` döndürür. Gövde, hangi bağımlılığın başarısız olduğunu adlandırır:

```bash theme={null}
curl -s http://localhost:8080/ready
# {"status":"not_ready","checks":{"postgres":"ok","clickhouse":"down","redis":"ok"}}
```

`down` olarak rapor ettiği bağımlılığı düzeltin: ClickHouse/Postgres pod'u `Running` durumunda mı? `CLICKHOUSE_URL` / `DATABASE_URL` doğru ve ulaşılabilir mi? Kubernetes'te pod `/ready` iyileşene kadar `NotReady` okunur; bu beklenen ve sağlık izlemesinin uyarı verdiği tam sinyaldir. Redis hiçbir zaman bir neden değildir: rapor edilir ancak hazırlığı başarısız kılmaz.

### Toplayıcı 401 Unauthorized döndürüyor

Toplayıcının API anahtarı `events:add` iznine sahip değildir veya anahtar devre dışı bırakılmıştır. Doğru izinle yeni bir anahtar oluşturun:

```bash theme={null}
curl -s -X POST http://your-server:8080/keys \
  -H "Authorization: Bearer $ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"new-collector","permissions":["events:add"]}'
```

### Doğrulanmış istekler aniden yavaş (\~200ms yerine \~5ms)

Bu, `REDIS_URL` ayarlanırken Redis'in aşağıda olduğunun belirtisidir. Her önbellek çağrısı 100ms sonra zaman aşımına uğrar ve Postgres'e döner; kimlik doğrulama ve OTP yollarında istek iki tane bu tür geri dönüş yapar.

Sunucu günlüklerinde doğrulayın:

```
auth cache: L2 get failed error=redis call timed out
```

Çözüm:

1. `redis-cli -h <your-redis> ping` ile Redis'in küme ağında ulaşılabilir olduğunu doğrulayın.
2. Redis kısa bir süre aşağıdaydı ve şimdi geri döndüyse, **sunucu pod'larını yeniden başlatın**. `redis::aio::ConnectionManager` temel bağlantı bıraktıktan sonra güvenilir bir şekilde yeniden kurulmaz; pod yeniden başlatması yeni bağlantıyı temiz bir şekilde seçer. Aynı şey pano için de geçerlidir.
3. Şu an Redis çalıştırmak istemiyorsanız, dağıtımda `REDIS_URL` ayarını kaldırın ve yeniden başlatın. Her iki hizmet de önbellek olmadan çalışır (doğruluk korunur; gecikme önceki Redis tabanına döner).

### Sunucu günlüklerde `OTP request rate-limited` raporları veriyor ancak kullanıcı sadece bir kez denedi diyor

Redis'in ulaşılamaz olup olmadığını kontrol edin. Geri dönüş yolu `SELECT COUNT(*) FROM otp_codes WHERE created_at > now() - interval '15 minutes'` kullanır, bu daha önce oluşturulmuş OTP satırlarını görür. Kullanıcı bir saatlik "Yeniden Gönder" tıklaması yaptıysa, 15 dakikalık pencere yine de ≥5 kod içerebilir. Pencere döndükten sonra bekleme veya `DELETE FROM otp_codes WHERE user_id = $1 AND created_at > now() - interval '15 minutes'` (operatör konsolu) çalıştırarak çözün.

### `ALLOWED_EMAILS` / `SESSION_TTL_SECS` / `OTP_TTL_SECS` değiştirdim ve yeniden başlattım; hiçbir şey olmadı

Bu ortam değişkenleri **yalnızca ilk önyükleme tohumları**. `settings` tablosu eşleşen anahtar için bir satıra sahip olduğunda, bu satır gerçek kaynaktır; ortam değişkeni ilk önyüklemede bir kez okunur ve sonraki her yeniden başlattırmada göz ardı edilir.

İlk önyüklemeden sonra bunları değiştirmek için panoya giriş yapın ve `/settings` altında düzenleyin. Değişiklik saniyeler içinde tüm çoğaltmalar arasında uygulanır; yeniden başlatma gerekmez.

Ortamdan yeniden tohumlamayı zorlamanız gerekiyorsa (nadiren, genellikle yalnızca geliştirmede yararlı), `DELETE FROM settings WHERE key = '<key>'` çalıştırın ve sunucuyu yeniden başlatın. Önyükleme, sonraki önyüklemede mevcut ortam değişkeni değerini seçer. `/settings` aracılığıyla düzenleme, üretimdeki desteklenen yoldur.

***

## Toplayıcı Sorunları

### Toplayıcı başlıyor ancak etkinlikler panoda görünmüyor

1. Toplayıcının çalıştığını doğrulayın: `systemctl status agenteye-collector` (Linux) veya işlemi kontrol edin.
2. `AGENTEYE_URL` `http(s)://your-server-host:8080/events` (not: `/events` yolu) işaret ettiğini doğrulayın.
3. Hemen çıktı görmek için bir kerelik flush çalıştırın:
   ```bash theme={null}
   agenteye-collector flush
   ```
4. Python SDK'nın aslında dosya yazıp yazmadığını kontrol edin: `ls ${AGENTEYE_HOME:-~/.agenteye}/events/`
5. `${AGENTEYE_HOME:-~/.agenteye}/failed/` içinde dosyalar varsa, yüklemeler başarısız oluyor. Toplayıcı günlüklerinde hatayı kontrol edin; büyük olasılıkla 4xx (kötü anahtar veya URL) veya ağ sorunu.

### Dosyalar `$AGENTEYE_HOME/events/` içinde birikmiş ve yüklenmemiş

* Toplayıcı çalışmıyor olabilir. Başlatın: `agenteye-collector start`; başlangıçta önceden varolan etkinlikleri otomatik olarak temizler.
* Toplayıcı durumunu kontrol edin: `agenteye-collector health`
* Toplayıcı çalışıyor ancak sunucuya ulaşamıyor olabilir. Toplayıcı ve sunucu ana bilgisayarları arasında güvenlik duvarı kurallarını kontrol edin.

### `$AGENTEYE_HOME/failed/` içinde dosyalar

Dosyalar tüm yeniden deneme denemelerinin tükendiğinden sonra `failed/` dizinine taşınır (varsayılan: 5 deneme, üstel geri kapatma). Bu, ya:

* Sunucu 4xx hatası döndürdü (kötü anahtar, yanlış URL veya yük sorunu)
* Sunucu, tüm yeniden deneme penceresi boyunca ulaşılamadı

Temel sorunu düzeltin, ardından el ile yeniden kuyruğa alın:

```bash theme={null}
mv ${AGENTEYE_HOME:-~/.agenteye}/failed/*.jsonl ${AGENTEYE_HOME:-~/.agenteye}/events/
agenteye-collector flush
```

### Toplayıcı her yüklemede `network error` raporları veriyor (TLS anlaşması başarısız)

`AGENTEYE_URL` aleyhine `curl -k` başarılı olursa ancak toplayıcı ikili `error sending request for url (...)` ile her yüklemeyi başarısız olursa, AgentEye sunucusu, halka açık güvenilir bir CA tarafından imzalanmayan bir TLS sertifikası sunuyor.

**Üretim yolu**, `deploy/base/certificates/domain.env` içinde yapılandırılmış ACME alımı ana bilgisayarıdır (bkz. [`kubernetes-deployment.md`](/tr/agenteye/kubernetes-deployment) Aşama 3.1 / 4.2). `INGEST_DOMAIN` halka açık Traefik LB'sine çözüldükten ve cert-manager Let's Encrypt sertifikasını verdikten sonra, toplayıcılar sunucu sertifikasını sistem güven deposuna karşı **`AGENTEYE_TLS_CA` olmadan** doğrularlar; eski kendi imzalı dağıtıma karşı ayarlandıysa onu toplayıcı yapılandırmasından temizleyin.

**Belirti: toplayıcı dün çalıştı, \~90 günlük boşluğundan sonra bugün başarısız.** Bu, dağıtımın yine de `ingest-tls` için eski `selfsigned` vericisinde olduğu anlamına gelir. 90 günlük sertifika döndürüldü ve sabitlenmiş CA dosyası eski. Şu anki sunucu sertifikasını çıkararak ve `AGENTEYE_TLS_CA` güncelleyerek kısa vadede çözün:

```bash theme={null}
kubectl get secret ingest-tls-cert -n agenteye \
  -o jsonpath='{.data.tls\.crt}' | base64 -d > /etc/agenteye/server-ca.crt
```

```bash theme={null}
export AGENTEYE_TLS_CA=/etc/agenteye/server-ca.crt
agenteye-collector flush
```

`AGENTEYE_TLS_CA` ek bir güven yerleri ekler; standart genel kökler yine de güvenilir.

### `ingest-tls` Sertifikası dağıtımdan sonra `Ready: False` takılı

```bash theme={null}
kubectl describe certificate ingest-tls -n agenteye
```

`Events` ve başvurulan `Order` / `Challenge` bakın. Yaygın nedenler:

* **DNS halka açık LB'ye çözülmüyor.** HTTP-01 doğrulayıcı `INGEST_DOMAIN` konumuna ulaşamıyor. `dig +short INGEST_DOMAIN` ile doğrulayın; `traefik-public` LoadBalancer'ın `EXTERNAL-IP` ile aynı adrese çözülmelidir. cert-manager DNS yayıldıktan sonra otomatik olarak yeniden dener; Sertifikayı silmek gerekmez.
* **Yük dengeleyici / güvenlik grubunda port 80 engellendi.** HTTP-01, Let's Encrypt'in genel doğrulayıcılarından port 80'e erişilebilirlik gerektirir. Yukarı akış WAF veya SG kısıtlıysa, açın (Traefik yapılandırması HTTPS'e yeniden yönlendirir ancak Boulder yeniden yönlendirmeyi izler ve yanıtı kabul eder).
* **`dnsNames` değiştirilmedi.** `kubectl get certificate ingest-tls -n agenteye -o jsonpath='{.spec.dnsNames}'` `INGEST_DOMAIN_PLACEHOLDER` gösteriyorsa, `domain.env` adımını atlattınız; `domain.env.example` dosyasından oluşturun ve yeniden uygulayın.
* **Let's Encrypt tarafından hız sınırlandırıldı.** Aynı ana bilgisayar için tekrarlanan başarısız siparişler, yinelenen sertifika veya başarısız doğrulama limitini tetikler. Yeniden denemeden önce en az bir saat bekleyin; tam hız sınırlaması iletisi için Sipariş durumunu kontrol edin.

### `dashboard-tls` Sertifikası `Ready: False` takılı / tarayıcı hala uyarı gösteriyor

Yukarıdaki `ingest-tls` ile aynı tanı akışı (`kubectl describe certificate dashboard-tls -n agenteye`); DNS, port-80, yer tutucu ve hız sınırlaması nedenleri tümü geçerlidir, artı iki panoya özel:

* **`DASHBOARD_DOMAIN` yanlış LoadBalancer'a çözülüyor.** Halka açık alma LB'si değil, *pano* Traefik LB'sine işaret etmelidir. Ana bilgisayar adını `dig +short` yapın ve pano LB adresine karşı karşılaştırın.
* **Pano Traefik örneği sorunu sunulayamıyor.** Paket Traefik LB adresine erişebilir olabilir. Bundled pano değerleri dosyası ile kurulmalıdır; cert-manager'ın HTTP-01 çözücüsü için kapsamlı Ingress sağlayıcısını etkinleştirir. Olmadan çözücü yönlendirilmez ve Sipariş sonsuza kadar `pending` kalır. Sağlanan değerleri kullanarak örneği yükseltin; bekleyen meydan sonra otomatik olarak tamamlanır.
* **LoadBalancer IP'yi kısıtladı.** Kaynak aralıkları port 80'e de uygulanır; bu, Let's Encrypt'in doğrulayıcılarını engeller — hem ilk verme hem de her \~75 günlük yenileme. LB'yi yeniden açın veya kilitlemeden önce destek ile DNS-01 çözücüyü koordine edin.

Verme başarısız olurken, pano önceki sertifikasını (veya yeni bir kurulumda ingress varsayılanı) sunmaya devam eder — erişim tarayıcı uyarısı tarafından düşürülür, hiçbir zaman düşmez.

### CLI, pano güvenilir bir sertifika aldıktan sonra TLS doğrulamasını atlıyor

`--insecure` `cli.json` adresinde oturum açma sırasında kalıcıdır. Pano halka açık güvenilir bir sertifika sunduğunda, `agenteye --base-url https://<your-dashboard-domain> --secure login` ile oturum açın; doğrulama geri açılır ve başlangıç uyarısı kaybolur.

***

## Pano Sorunları

### `ADMIN_EMAIL` kullanıcısını devre dışı bırakamaz veya düzenleyemez

Tasarım gereğidir. `ADMIN_EMAIL` ile eşleşen kullanıcı, her sunucu başlangıcında korumalı olarak işaretlenir: pano bu satırın Devre Dışı Bırak düğmesini gizler ve API bu satıra karşı `DELETE /users/:id` ve `PUT /users/:id` `403 Forbidden` ile reddeder. Bir veritabanı tetikleyicisi ayrıca korumalı satırı devre dışı bırakacak doğrudan `UPDATE` deyimlerini reddeder.

Önyükleme yöneticisini döndürmek için, ortamınızda `ADMIN_EMAIL` değiştirin ve sunucuyu yeniden başlatın. Yeni e-posta korumalı olarak üretilir. Önceki yönetici, veritabanında açıkça kaldırıncaya kadar korumalı bayrağı saklar (genellikle uygun, önceki e-posta açıkça kaldırıncaya kadar geçerli bir yönetici olduğundan).

### Pano hiçbir etkinlik göstermediği

1. Pano ortam değişkenlerindeki sunucu URL'sinin ve API anahtarının doğru olduğunu doğrulayın (`AGENTEYE_SERVER_URL`, `AGENTEYE_API_KEY`).
2. Pano API anahtarının `events:read` izinine ihtiyacı vardır.
3. Etkinliklerin gerçekten alındığını doğrulayın: `curl http://your-server:8080/events -H "Authorization: Bearer $ADMIN_KEY"`

### `/errors` boş ancak `/events` kırmızı satırlar gösteriyor

Daha yeni SDK sürümleri hataları `agent_end` / `tool_result` / `hook_completed` olayları olarak ve `event_type: "error"` satırı olarak, taşıda `outcome: "error"` ile yayınlarlar. `/errors` sayfası şimdi her ikisini de eşleştirir: `/events` akışının kırmızı olarak gösterdiği herhangi bir satır (açık `event_type='error'`, yük `outcome`/`status` başarısız kümede, `is_error: true` veya gerçek `error` alanı) `/errors` altında görünür. Daha önce `/events` kırmızı satırlar görüyorken "bu pencerede hata yok" görüştüyseniz, pano + sunucuyu birlikte yükseltin (genişletilmiş filtre `GET /events` üzerinde `errored=true` olur) ve iki görünüm anlaşacaktır.

### `/models`, `/tools` veya `/hooks` geniş zaman aralıklarında yavaş veya yükleme başarısız

**Belirti:** büyük bir etkinlikler tablosu (milyonlarca satır) üzerinde, `/models`, `/tools` veya `/hooks` açma — veya zaman aralığını `7d`, `30d` veya `all` olarak genişletme — grafikler döner ve sonra bir yükleme hatası gösterir. Sunucu `latency_aggregate` isteği için ClickHouse `MEMORY_LIMIT_EXCEEDED` (Kod 241) veya sorgu zaman aşımını günlüğe kaydeder.

**Neden:** daha eski derlemeler bu sayfaların gecikme ve dağıtım toplamalarını tam ham olay `payload` okuyan ve istek/yanıt olaylarını bellek içi sırala ve birleştirme ile eşleştiren bir sorgu ile hesapladı. Tepe sorgusu belleği bu nedenle pencere boyutuyla büyüdü, böylece meşgul bir kiracıda geniş bir aralık ClickHouse'un sorgu başına bellek tavanını aşabilir.

**Düzeltme:** bu düzeltmeyi içeren bir derlemeyü yükseltin. Toplamay artık yalnızca kompakt tanıtılan sütunları okur ve olayları akış birleştirmesiyle eşleştirir, böylece tepe belleği artık ham yükle ölçeklenmez — geniş pencereler bellek tavanında yer alır ve kesirleri tamamlar. İyileştirme tamamen sorgu tarafıdır: tüm mevcut verilere sonraki sayfa yüklemesinde uygulanır; yeniden alım veya geri doldurma yok.

### Pano yükleme başarısız / boş sayfa

Pano konteyner günlüklerini kontrol edin:

```bash theme={null}
docker logs agenteye-dashboard
```

En yaygın neden `AGENTEYE_SERVER_URL` veya `AGENTEYE_API_KEY` eksik veya ulaşılamayan bir sunucuyu işaret etmektir.

### Pano analitikleri / telemetrisi

Pano, varsayılan olarak anonim ürün kullanımı analitiklerini PostHog'a gönderir; pano kendi `/ingest` yolu (için `https://us.i.posthog.com` ters proxy) aracılığıyla yönlendirilir. İlk taraf olarak göndermek, tarayıcı adblocker'larının bunları bırakmaması anlamına gelir. Bu, panonun temel işlevselliğinden bağımsızdır:

* **Pano konteynerı** (tarayıcı değil) PostHog'a ulaşıyor. Giden erişimi `https://us.i.posthog.com` engelliyse, telemetrisi sessiz olarak no-op; pano normal çalışır ve kullanıcılara hata yüzeylenmez.
* Agent, oturum veya etkinlik verisi hiçbir zaman dahil değildir, yalnızca pano kullanıcı arayüzü kullanımı.
* Telemetriyi tamamen devre dışı bırakmak için pano konteynerında `AE_ANALYTICS_DISABLED=1` ayarlayın ve yeniden başlatın. Dağıtım rehberindeki [Telemetri & gizlilik](/tr/agenteye/deployment#telemetry--privacy) bakın.

### CLI analitikleri / telemetrisi

`agenteye` CLI, varsayılan olarak anonim kullanımı analitiklerini PostHog'a gönderir: hangi komutlar çalışır, başarı/çıkış durumu ve süresi. Bu CLI'nin işlevselliğinden bağımsızdır:

* **CLI çalıştıran makine** `https://us.i.posthog.com` doğrudan ulaşıyor. Giden erişimi engelliyse, telemetrisi sessiz olarak no-op (gönderme zaman sınırlı, bu nedenle bir komutu hiçbir zaman geciktirmez) ve CLI normal çalışır.
* Agent, oturum veya etkinlik verisi hiçbir zaman dahil değildir: komut **argümanları ve bayrak değerleri** (pano URL, token, e-posta, oturum kimlikleri, sorgu filtreleri) hiçbir zaman gönderilmez.
* Devre dışı bırakmak için CLI ortamında `AGENTEYE_ANALYTICS_DISABLED=1` (veya çapraz araçlar `DO_NOT_TRACK=1`) ayarlayın. CLI rehberindeki [Telemetri & gizlilik](/tr/agenteye/cli#telemetry--privacy) bakın.

***

## Yapay Zeka Asistanı Sorunları

Tam kurulum için bkz. [enterprise-docs/assistant.md](/tr/agenteye/assistant).

### Asistan kabarcığı görünmüyor

Kabarcık **tümü** tutarsa gizlenmiş olur:

* Oturum açan kullanıcı `agent:use` izinlerine sahiptir.
* `AGENTEYE_AGENT_URL` panonun üzerinde ayarlanmış ve `agent` hizmeti ulaşılabilir.
* `agent` hizmette LLM uç noktası yapılandırılmıştır (`ANTHROPIC_API_KEY`, ağ geçidi ile `ANTHROPIC_BASE_URL` veya Bedrock/Vertex). Hiçbiri ayarlanmazsa, aracı "yapılandırılmamış" bildirir ve kabarcık gizli kalır.

Pano ana bilgisayarından aracının durumunu kontrol edin: `curl http://agent:9100/health` `{"status":"ok","llm_configured":true,...}` döndürmelidir.

### Asistan bir şeyi okuması gerektiğini söylüyor

Araçlar kullanıcı başına kapı kapalı. Kullanıcı `evaluations:read` (veya `events:read`, `dashboards:read`) yoksa, eşleşen araçlar sunulmaz ve asistan okunması gerektiğini söyler. İlgili okuma iznini verin.

### Gönderirken "assistant not configured" (HTTP 503)

`agent` konteynerinin LLM uç noktası yapılandırılmamış veya panonun `AGENTEYE_AGENT_TOKEN` aracı ile eşleşmiyor. Her ikisini de ayarlayın ve yeniden başlatın.

### `agent` konteynerı yük altında yeniden başlatılıyor / bellek yetersiz

Her sohbet, kısa ömürlü bir alt işlem çıkartır. Konteynerü bir init işlemiyle çalıştırdığınızdan (görüntü `tini` kullanıyor; Compose'da `init: true` ayarlayın) ve yeterli bellek sınırları verdiğinizden emin olun. Gerekirse `AGENTEYE_AGENT_MAX_STEPS` azaltın.

***

## CLI Sorunları

### `agenteye` `ModuleNotFoundError: No module named 'click'` ile başlama başarısız

Version **0.1.6** में `agenteye` CLI'nin taze kurulumu, başlangıçta çöküm yaşayabilir:

```
ModuleNotFoundError: No module named 'click'
```

0.1.6, `click` `typer` tarafından dolaylı olarak yüklenmesine güvendi; mevcut `typer` versiyonları artık çekmez, bu nedenle temiz bir ortam paketi eksik bir şekilde çıkıyor. **0.1.7 veya daha yenisine yükseltin**, `click` doğrudan bağımlı:

```bash theme={null}
pipx upgrade agenteye      # pipx ile yüklendiyse (veya: pipx install --force agenteye)
uv tool upgrade agenteye   # uv ile yüklendiyse
pip install --upgrade agenteye
```

Kurulum rehberi için bkz. [enterprise-docs/cli.md](/tr/agenteye/cli).

***

## Python SDK Sorunları

### `$AGENTEYE_HOME/events/` içinde görünen dosya yok

SDK olayları arabelleğe alır ve varsayılan olarak her 500 ms temizler. İşleminiz temizlemeden önce çıkarsa, olaylar kaybolabilir. Kısa ömürlü komut dosyalarında daha hızlı temizleme için `agenteye.configure(flush_interval=0.1)` çağırın veya işleminiz bir temizleme döngüsü için yeterli uzun çalıştığından emin olun.

`AGENTEYE_HOME` ayarlandıysa, SDK'nın `$AGENTEYE_HOME/events/` yazıp `~/.agenteye/events/` (SDK ≥ 0.0.1b5 gerekir) yazıp yazmadığını doğrulayın.

### `ValueError: Reserved field names cannot be used as custom fields`

`timestamp`, `type` ve `environment` adları ayrılmış olup özel alanlar olarak kullanılamaz. İçlerinden birini iletmek oluşturur:

```
ValueError: Reserved field names cannot be used as custom fields: [...]
```

Sorunlu özel alanı yeniden adlandırın. `session_id` ve `agent_id` olay çağrısının açık parametreleri, özel alanlar değildir; bir başka özel alan olarak tekrar iletmek `TypeError` oluşturur.

***

## Sağlık İzleme Sorunları

### Slack'a (Robusta) uyarı gelmiyorum

Robusta sağlık uyarısı **opt-in**; kurulu ve bir Slack kanalına yönlendirilene kadar hiçbir şey göndermez. Sürüm ve havuzunu doğrulayın:

```bash theme={null}
kubectl get pods -n robusta          # robusta-runner + robusta-forwarder Running olmalı
kubectl logs -n robusta -l app=robusta-runner --tail=50
```

Yaygın nedenler: Slack `api_key` / `slack_channel` ayarlanmadı (veya token iptal edildi); `api_key` Robusta bulut geçişi tokenidir (`robusta integrations slack`) ancak paketlenmiş `disableCloudRouting: true` kendi barındırmalı Slack **bot token** gerekir (`xoxb-…`) veya `disableCloudRouting: false` ayarlayın; havuz `scope` pod'ların çalıştığı ad alanı hariç tutar (paketlenmiş değerler `agenteye` kapsamı); veya henüz hiçbir hata meydana gelmemiştir. Test uyarısını bir pod'u kaldırarak zorlayın:

```bash theme={null}
kubectl -n agenteye delete pod -l app=clickhouse   # yeniden oluşturulur
```

Kurulum ve yapılandırma için bkz. [enterprise-docs/health-monitoring.md](/tr/agenteye/health-monitoring#2-pod-failure-alerting-with-robusta-opt-in).

### Sunucu `NotReady` çevresinde dolaşıyor

Hazırlık sondası `/ready` vurur, bu Postgres veya ClickHouse ulaşılamadığında başarısız olur. Sunucu `NotReady` girişi ve çıkışı döngüsü içindeyse, bir bağımlılık aralıklı olarak kullanılamaz; ClickHouse ve Postgres pod'larını kontrol edin ve sunucunun `CLICKHOUSE_URL` / `DATABASE_URL`. `/ready` raporlarını doğrulayın:

```bash theme={null}
kubectl -n agenteye exec deploy/server -- sh -c 'curl -s localhost:8080/ready'
```

Bu sonda kasıtlı olarak toleranttır (cömert başarısızlık eşiği), bu nedenle sürdürülen çevreleme gerçek bağımlılık sorununu gösterir; aşırı agresif sonda değil. Canlılık `/health` üzerinde kalır, bu nedenle hazırlığı çevreleme pod'u yeniden **başlatmaz**.

## Sertifika İzleme Sorunları

### CronJob Slack bildirimleri göndermiyorum

`cert-renewal-check` CronJob, Sır'da depolanan bir Slack webhook URL'si gerektirir. Mevcut olduğunu doğrulayın:

```bash theme={null}
kubectl get secret cert-renewal-notify-config -n agenteye
```

Eksikse, oluşturun:

```bash theme={null}
kubectl create secret generic cert-renewal-notify-config \
  --namespace agenteye \
  --from-literal=SLACK_WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
```

Sır olmadan, CronJob yine de çalışır ve sonuçları stdout dosyasında günlüğe kaydeder. Günlükleri şu şekilde kontrol edin:

```bash theme={null}
kubectl logs -n agenteye -l job-name --tail=50
```

### İstemci sertifikası, bir bildirim alınmadan önce süresi doldu

CronJob her 12 saatte bir çalışır. Çalışmıyor olmuşsa, durumunu kontrol edin:

```bash theme={null}
kubectl get cronjob cert-renewal-check -n agenteye
```

Manuel bir denetim tetikleyin:

```bash theme={null}
kubectl create job --from=cronjob/cert-renewal-check manual-cert-check -n agenteye
kubectl logs -n agenteye -l job-name=manual-cert-check
```

Süresi dolmuş sertifikayı hemen yeniden yayınlamak için:

```bash theme={null}
cd base/certificates/client-certs
./issue-client-cert.sh <cluster-name>
```

Ardından yeniden oluşturulan `collector-mtls-secret.yaml` toplayıcıları çalıştıran kümeye uygulayın ve yeniden başlatın:

```bash theme={null}
kubectl apply -f collector-mtls-secret.yaml -n <collector-namespace>
```

***

## Yedekleme Sorunları

### `agenteye-backup` "No space left on device" ile başarısız

`agenteye-backup` CronJob, Postgres + ClickHouse'u bir `backup-tmp` `emptyDir` karalama hacmine (varsayılan `30Gi`) boşaltır, ardından `tar` arşivini doğrudan S3'e **akışla** — sıkıştırılmış arşiv hiçbir zaman karalama dosyasına yazılmaz, bu nedenle karalama sadece *ham dökümleri* tutmalıdır, dökümleri + ikinci bir diskte arşiv kopyası değil. Bir pod çıkarılan / `No space left on device` bu nedenle **ham dökümlerin** karalama boyutunu aştığı anlamına gelir (ClickHouse `events` dökümü baskın ve zaman içinde büyür). Başarısız iş günlüklerini kontrol edin:

```bash theme={null}
kubectl logs -n agenteye -l job-name=<failed agenteye-backup job>
```

Düzelt: kaplamada, CronJob'ın `backup-tmp` `emptyDir` `sizeLimit` ham dökümü toplamının üzerine çıkarın ve düğümün efemerler depolama alanı gerçekten tutabildiklerini emin olun (`sizeLimit` tavan, rezervasyon değil). Dökümleri tek bir düğümün diskini aşarsa, dökümleri kaynakta sıkıştırın veya `backup-tmp` için `emptyDir` bir PVC (EBS/PD) ile değiştirin.

> Daha eski sürümler `.tar.gz` aynı karalama olarak *yazıp* dökümleri *ve* arşiv aşırı akış olarak yazıp pod çıkarıldı **yükleme çalışmadan** — S3 başarısızlığı gibi görünüyor ama gerçekten disk. Akış yüklemesi bölüşümü kaldırır.

### `agenteye-backup` başarısız olmuş `curl` yüklemesi

İş `postgres:16` görüntüsünde çalışır ve ClickHouse HTTP dökümü için başlangıçta `curl` yüklenir. Debian paket aynalarına çıkış olmayan bir kümedeki, `apt-get` adımı başarısız olur. Bu çıkıştan yedek pod'a izin verin veya `curl` aynalanan/özel yedekleme görüntüsüne pişirin ve kaplayıcıya başvurun.

### `agenteye-backup` çalışır ancak hiçbir şey nesne depolama alanına inmiyor

Taban gerçek `BACKUP_BUCKET` (`ts-prod-agenteye/backups`) ve `agenteye-backup` ServiceAccount gönderir. İş arşivi S3'e **akışla** (`tar cz … | aws s3 cp - s3://…`). Yedekleme pod'unun tutucuya yazma erişimi yoksa yükleme hatası — ve komut `set -euo pipefail` altında çalıştığı için, o borudan herhangi bir yerde hata **tüm işi** yükleme adımında başarısız olur sessiz no-op'a göre (pod'ın EXIT tuzağı `backup FAILED during step: upload` günlüğe kaydeder). Bu, bir karalama boşluğu tahliyesi düzelttikten sonra ulaştığınız adımdır, bu nedenle yedeklemeler daha önce arşiv adımında çıkarıldıysa, yüklemenin şimdi iniş olduğunu doğrulayın. Başarısız iş günlüklerindeki S3 erişim hatası için grep'in yapılması:

```bash theme={null}
kubectl logs -n agenteye -l job-name=<failed agenteye-backup job> | grep -iE 's3|upload|denied'
```

Düzelt: kaplayıcıda `BACKUP_BUCKET` sahip olduğunuz tutucuya ayarlayın ve varolan `agenteye-backup` ServiceAccount'u yazma erişimi ile açıklayın (IRSA / İş Kimliği / Pod Kimliği). [enterprise-docs/kubernetes-deployment.md](/tr/agenteye/kubernetes-deployment) **Yedeklemeler** bölümüne bakın.

***

## ClickHouse tabanlı değerlendirmeler / oturumlar / sorgular

### Yükseltmeden sonra `/queries` sayfası kenar çubuğu boş

Üç tablo (`events`, `evaluations`, `agent_sessions`) beklenir. SchemaBrowser kenar çubuğu yükseltmeden sonra boş olmuşsa, sunucu başlangıçta ClickHouse DDL uygulamada başarısız oldu. `failed to apply CH DDL statement` sunucu günlüklerini kontrol edin:

```bash theme={null}
kubectl logs -n agenteye deploy/server | grep -E 'clickhouse|CH DDL'
```

En yaygın neden göçler çalışırken ClickHouse'a ulaşılamayacağıdır. Sunucu CH'a ulaşamıyorsa başlama reddettiğinden, takılı bir pod genellikle sessiz kopya sorgular sayfası yerine `CrashLoopBackOff` vardır, ancak kısmi DDL uygulaması (bir deyim tamam, sonraki 5xx) şemayı yarı pişmiş bırakır. CH'a ulaşılabilir doğrulandıktan sonra sunucu pod'unu yeniden başlatın:

```bash theme={null}
kubectl rollout restart deploy/server -n agenteye
```

### Yeni değerlendirmeler `/sessions` veya `/queries` içinde görünmüyor

Yükseltmeden sonra, yeni değerlendirmeler Postgres değil ClickHouse'a yazılır ve `/sessions` (gated on `evaluations:read`) ve `/queries` altında yüzey. Görünmezlerse:

1. Değerlendirici boru hattının etkin olduğunu (`EVALUATOR_ENDPOINT` sunucuda ayarlanmış) ve terminal sonuçları prodüksüyonun doğrulayın; `evaluation_finalized` günlük satırlarını kontrol edin.
2. CH sunucudan ulaşılabilir olduğunu doğrulayın: `kubectl exec -n agenteye deploy/server -- curl -fsS http://clickhouse:8123/ping`.
3. CH tablosunu spot kontrol edin: `kubectl exec -n agenteye clickhouse-0 -- clickhouse-client -q 'SELECT count() FROM agenteye.evaluations'`.

### Sorgular yük altında "Memory limit exceeded" ile başarısız veya ClickHouse `OOMKilled`

**Belirti:** ağır pano/sorgu yükü altında, analitik sayfalar (etkinlik akışı, `/sessions`, modeller/gecikme görünüşü, SQL düzenleyicisi) başarısız veya zaman aşımı; sunucu kısaca flaps `NotReady`; ve ClickHouse pod artan yeniden başlatma sayısı gösterir. Bu hemen hemen her zaman **bellek**, CPU veya disk değil.

**Belleğin olduğunu doğrulayın** (throughput sorunu değil, çoğaltma düzelttir):

1. Pod bellek dışı katllarını kontrol edin:
   ```bash theme={null}
   kubectl -n agenteye describe pod clickhouse-0 | grep -iE 'Restart Count|Last State|Reason|OOMKilled'
   ```
   `Reason: OOMKilled` / `Exit Code: 137` tırlama yeniden başlatma sayısı hikaye.

2. ClickHouse'u reddettiklerini sorun:
   ```bash theme={null}
   kubectl -n agenteye exec clickhouse-0 -- clickhouse-client -q \
     "SELECT name, value FROM system.errors WHERE value>0 ORDER BY value DESC"
   ```
   Büyük `MEMORY_LIMIT_EXCEEDED` sayısı imza. İleti *"maximum: N GiB"* okuyor — o **N `0.9 × pod'ın bellek sınırıdır`** (`deploy/base/clickhouse/configmap.yaml` `max_server_memory_usage_to_ram_ratio`). Ağır okumalarınız N'den fazlasına ihtiyacsa reddedilir.

3. *Sorun olmayan* şeyler kural — CPU, kısım sayısı ve disk tümü düşükse, çoğaltma/parçalama eklemek atılmış maliyet olur:
   ```bash theme={null}
   kubectl -n agenteye top pod clickhouse-0
   kubectl -n agenteye exec clickhouse-0 -- clickhouse-client -q \
     "SELECT table, count() parts FROM system.parts WHERE active AND database='agenteye' GROUP BY table"
   ```

**Neden:** ClickHouse pod'ının bellek sınırı analitik çalışan kümesi için çok küçük. En ağır okumalar ham JSON `payload` sütununu çeker, `JSONExtract*` üzerinde çalışır ve `FINAL` kullanır — her biri çeşitli GiB gerekebilir. Yapılandırılmış önbellekler (`mark_cache_size` + `uncompressed_cache_size`) pod'dan daha büyükse, bunları dışar: önbellekler aynı bütçeye karşı ücretlendirilir ve sorgu belleğini kalabalık hale getirir.

**Düzelt — ClickHouse'ın belleğini ölçekleyin:**

1. Kaplayıcıda ClickHouse bellek sınırını `clickhouse` StatefulSet konteyner `resources` (diğer bileşenlerin `resources` için kullanılan aynı kaplamı mekanizması) düzeltmeyi yaparak çıkarın. Kullanılabilir sunucu bütçe `0.9 × limit`, böylece `6Gi` sınırı \~5.4 GiB verir, `16Gi` \~14 GiB verir. `requests.memory` gerçek bir taban olarak da ayarlayın, bu nedenle zamanlayıcı rezervasyon yapar. Bu uygulaması **CH pod'unu yeniden oluşturur** (tek kopya → \~30–60 saniye analitikleri kapalı kalma süresi); düşük trafik penceresi yapın.
2. `deploy/base/clickhouse/configmap.yaml` içinde önbellekleri sınırla orantılı tutun — küçük önbellekler (birkaç yüz MiB) küçük pod'da güvenli; eşleşen bellek sınırı artışı ile birlikte yükselt. Sorgu başına `max_memory_usage` `users.xml` profilinde açıkça ayarlanmıştır (sabitlenmiş düğüm bölümüne bakın) ve sunucu seviyesi başlığın altında tutulur (`0.9 × limit`) hiçbir sorgu izin verilemez kont sahip daha fazla RAM.
3. Düğümün kendisi tavan ise, ClickHouse görebileceği ana bilgisayar belleğini kontrol edin:
   ```bash theme={null}
   kubectl -n agenteye exec clickhouse-0 -- clickhouse-client -q \
     "SELECT formatReadableSize(value) FROM system.asynchronous_metrics WHERE metric='OSMemoryTotal'"
   ```
   Pod sınırının sadece biraz üzeride olduğunu düşünürse, ClickHouse'u daha büyük (bellek optimize) düğüme taşıyın — kaplayıcıda düğüm seçicisi/yakınlığı — limit daha da artırmadan önce.

**Bellek ekleyemediğinizde: sorgular RAM'de çalıştırın ve hızlı başarısız — yavaş diskte dökmeyin.** Düğüm sabitlediyse ve pod büyüyemezse, herhangi bir sorgu kullanımı üst sınırı (böylece bir sorgu tüm düğümü alamaz) ve **yavaş (SSD olmayan) veri diski** üzerinde \*\*denebilir ama büyük toplamalar/tür diskte dökme yapmayın. Yavaş diske dökme sunucunun istemci okuma zaman aşımından daha yavaş, bu nedenle bir dökme sorgusu uçuş ortasında pano `500` döndürürken ClickHouse öğütmeye devam ediyor — sorguları RAM'de tutup nadir bütçe aşımı hızlı **başarısız** (`MEMORY_LIMIT_EXCEEDED`, alt saniye) yüklemeyi geri yükler. ClickHouse gotcha, bunları uygulamak:

* **Bunlar *profil* ayarları ve ClickHouse `<profiles>` yalnızca `users_config` (`users.xml` / `users.d/*.xml`) dosyasından okur — hiçbir zaman `config.d` olmaz.** `config.d/agenteye.xml` yerleştirilen bir `<profiles>` blok **sessizce göz ardı edilir** (`max_execution_time`, `max_memory_usage`, vb. basitçe uygulanmaz). Paketlenmiş yapılandırma, bu nedenle `clickhouse-config` ConfigMap `users.xml` anahtarı olarak gönderir, `/etc/clickhouse-server/users.d/agenteye.xml` takılan.
* Gönderilen varsayılanlar: `max_memory_usage` (sorgu başına tavan — bir sorgu tüm sunucu bütçesini tüketemez), `max_bytes_before_external_group_by` / `max_bytes_before_external_sort` = **`0` (döküm devre dışı)** yani sorgular yavaş diskten RAMda kalır yerine sürüyor ve `max_execution_time` (kaçak koruma, sunucunun istemci okuma zaman aşımı ile uyumludur).
* **Canlı olduklarını doğrulayın** (bu da config.d gotcha tespit etmekte):
  ```bash theme={null}
  kubectl -n agenteye exec clickhouse-0 -- clickhouse-client -q \
    "SELECT name, value FROM system.settings
     WHERE name IN ('max_memory_usage','max_bytes_before_external_group_by','max_execution_time')"
  ```
  Sıfırdan farklı `max_memory_usage` ve `max_bytes_before_external_group_by = 0` bekledi. `max_memory_usage` `0`/varsayılan okursa, profil uygulanmıyor — ayarların `users.d` takısında canlı, `config.d` değil olduğunu kontrol edin.

Ödünleşme: dökme devre dışı bırakılarak, çalışan seti `max_memory_usage` aşan bir sorgu **reddedilir** (`MEMORY_LIMIT_EXCEEDED`) yavaş tamamlamak yerine — yavaş diskte hızlı reddetme tercih edilir, çünkü dökme sorgusu öyle yine de başarısız olur. Veri diskiniz **hızlı (SSD)** olduğundan, `max_bytes_before_external_*` eşikleri yükseltebilir ve büyük sorguları diskte yığında tamamlaması gerek.

***

## Çok kiracılılık (kuruluşlar)

### Kuruluşları etkinleştiren yükseltme sırasında hatalar (karışık eski/yeni sunucu pod'ları)

**Belirti:** eski örneği yeni sunucu pod'larını yayınlayan bir yayın dağıtımı sırasında, bazı istekler başarısız: sunucu günlükleri `there is no unique or exclusion constraint matching the ON CONFLICT specification` `api_keys` yolunda gösterir ve/veya uyarı/Slack/webhook kanalları rulo uçuşu sırasında ateş kesiyor.

**Neden:** yükseltme eski örnek genişliği benzersiz dizini `api_keys(name)` kısmi per-org dizinler ile değiştirir ve uyarı kanı ayarlarını (ve `default_user_permissions`) genel `settings` tablosundan per-org `org_settings` tablosuna taşır. **Eski** bir sunucu pod'u yine `ON CONFLICT (name)` sorunları (şimdi eşleşen kısıtlama yok) ve yine eski `settings` satırlarından kanal yapılandırmasını okur (şimdi boş). Eski ve yeni pod'lar bu iki yol için güvenli bir şekilde varolan olamaz.

**Düzelt:** bu belirli yükseltmeyi karışık versiyonlar arasında yavaş haddeleme yapmayın. Temiz bir şekilde kes: eski sunucuyu sıfıra ölçekle (veya kısa bakım penceresi kullanın) ve yeni sürümü göçleriyle birlikte getirir, eski ve yeni çoğaltmaları yan yana çalıştırmak yerine. Normal trafik ve alım derhal sonra devam eder; bu yalnızca sürüm geçişi penceresini etkiler.

### Kuruluş `CREATE USER` / `CREATE ROW POLICY` üzerinde hazırlama başarısız veya bir kuruluş başka kuruluş verilerini okuyor

**Belirti:** kuruluş oluşturmak `CREATE USER`, `CREATE ROW POLICY` veya "erişim yönetimi devre dışı" bildiren bir hata döndürür; veya daha kötü, bir kuruluşun üyeleri SQL düzenleyicisi veya asistan içinde başka bir kuruluşun etkinlikleri/değerlendirmelerini görüyor.

**Neden:** per-org yalıtma, kuruluş başına ayrılmış ClickHouse kullanıcısı + satır ilkesi tarafından uygulanır. Bu SQL **erişim yönetimi** etkin ve `users_without_row_policies_can_read_rows=false` ClickHouse üzerinde gerektirir. Erişim yönetimi kapalıysa hazırlama kullanıcı/ilke oluşturamaz; satır ilkesi varsayılanı izin vericisi değerinde bırakıldıysa