Troubleshooting - FailproofAI

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:

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

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:

Yanıt başlığından kimliği yakalayın, örneğin:

curl -i https://dashboard.example.com/api/events | grep -i x-request-id
# x-request-id: 9a7b0d6e-5e9b-4c0a-9f8a-5f1e4b5c0f3a

Her iki pod’un günlüklerinde o kimliği arayın:

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:

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:

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:

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:

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 § “PostgreSQL credentials” içindeki tam adımları görebilirsiniz.

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

Konteyner günlüklerini kontrol edin:

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:

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:

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:

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:

redis-cli -h <your-redis> ping ile Redis’in küme ağında ulaşılabilir olduğunu doğrulayın.
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.
Ş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

Toplayıcının çalıştığını doğrulayın: systemctl status agenteye-collector (Linux) veya işlemi kontrol edin.
AGENTEYE_URL http(s)://your-server-host:8080/events (not: /events yolu) işaret ettiğini doğrulayın.
Hemen çıktı görmek için bir kerelik flush çalıştırın:
agenteye-collector flush
Python SDK’nın aslında dosya yazıp yazmadığını kontrol edin: ls ${AGENTEYE_HOME:-~/.agenteye}/events/
${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:

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 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:

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

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ı

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

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).
Pano API anahtarının events:read izinine ihtiyacı vardır.
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:

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 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 bakın.

Yapay Zeka Asistanı Sorunları

Tam kurulum için bkz. enterprise-docs/assistant.md.

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ı:

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.

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:

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:

kubectl -n agenteye delete pod -l app=clickhouse   # yeniden oluşturulur

Kurulum ve yapılandırma için bkz. enterprise-docs/health-monitoring.md.

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:

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:

kubectl get secret cert-renewal-notify-config -n agenteye

Eksikse, oluşturun:

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:

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:

kubectl get cronjob cert-renewal-check -n agenteye

Manuel bir denetim tetikleyin:

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:

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:

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:

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ı:

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 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:

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:

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:

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.
CH sunucudan ulaşılabilir olduğunu doğrulayın: kubectl exec -n agenteye deploy/server -- curl -fsS http://clickhouse:8123/ping.
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):

Pod bellek dışı katllarını kontrol edin:
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.
ClickHouse’u reddettiklerini sorun:
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.

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:

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:

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.
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.
Düğümün kendisi tavan ise, ClickHouse görebileceği ana bilgisayar belleğini kontrol edin:
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):
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

AI Asistanı

​title: “Sorun Giderme” description: “AgentEye Sorun Giderme belgeleri.”

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

​Kubernetes

​Docker Compose

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

​JSON günlükleri ve jq

​Ayrıntı düzeyini artırma

​Günlük tutma

​Kimlik Doğrulama Sorunları

​docker pull “unauthorized” hatasıyla başarısız

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

​Sunucu Sorunları

​Sunucu “invalid port number” ile başarısız

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

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

​GET /ready 503 döndürüyor

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

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

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

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

​Toplayıcı Sorunları

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

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

​$AGENTEYE_HOME/failed/ içinde dosyalar

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

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

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

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

​Pano Sorunları

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

​Pano hiçbir etkinlik göstermediği

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

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

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

​Pano analitikleri / telemetrisi

​CLI analitikleri / telemetrisi

​Yapay Zeka Asistanı Sorunları

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

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

​Gönderirken “assistant not configured” (HTTP 503)

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

​CLI Sorunları

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

​Python SDK Sorunları

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

​ValueError: Reserved field names cannot be used as custom fields

​Sağlık İzleme Sorunları

​Slack’a (Robusta) uyarı gelmiyorum

​Sunucu NotReady çevresinde dolaşıyor

​Sertifika İzleme Sorunları

​CronJob Slack bildirimleri göndermiyorum

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

​Yedekleme Sorunları

​agenteye-backup “No space left on device” ile başarısız

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

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

​ClickHouse tabanlı değerlendirmeler / oturumlar / sorgular

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

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

​Sorgular yük altında “Memory limit exceeded” ile başarısız veya ClickHouse OOMKilled

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

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

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