OffVPSOFFSHORE VPSDestek

İlk yanıt

Uygulamanız durdu. İlk yararlı ipucunu bulun.

Neyin ve ne zaman durduğunu kaydederek başlayın. Yeniden başlatmadan önce süreci, bağlantı noktasını ve ilk ilgili hatayı inceleyin: tekrarlanan yeniden başlatmalar yararlı bir hatayı farklı bir belirtiyle değiştirebilir.

OffVPS saha kılavuzu · İncelendi · 5 dk okuma

Gözlemlenebilir bir hata tanımlayın

“Durdu” bir HTTP hatası, zaman aşımı, tamamlanmayan bir iş veya çıkan bir süreç anlamına gelebilir. Bir URL veya eylemi, en son bilinen çalışma zamanını, ilk hata zamanını ve saat diliminizi yazın. Herkesin mi yoksa yalnızca bir istemcinin mi etkilendiğini ekleyin. Araştırma sırasında mevcut SSH oturumunu açık tutun; erişim kurallarını değiştirmek bir uygulama hatasına gerekli ilk yanıt değildir.

Bu kılavuz, systemd kullanan bir Linux ana bilgisayarı, adında bir uygulama hizmeti first-api.service, ve yerel bir sağlık uç noktası 127.0.0.1:3000/healthzvarsayar. Bu varsayılanlar ilk API dağıtım kılavuzuyla eşleşir. Gerçek adlarınızı kullanın. İnceleme, diğer kullanıcıların süreçlerini veya günlüklerini görmek için yönetici izni gerektirebilir. Aşağıdaki komutlar ve çıktılar örnektir; bu kılavuz için hiçbir sağlayıcı örneği test edilmemiştir.

Notları başarısız uygulamanın kendi dizini dışında tutun. Yorumlardan önce gözlemleri kaydedin: “09:18 UTC'de bağlantı reddedildi” bir olgudur; “VPS'in daha fazla CPU'ya ihtiyacı var” hâlâ bir hipotezdir. Sunucunun kendisine ulaşılamıyorsa, uygulama yeniden başlatmanın mümkün olduğunu varsaymak yerine kurulu kurtarma erişiminizi kullanın ve bağlantı ayrıntılarını toplayın.

Süreç durumunu ve yakın geçmişini okuyun

systemctl status first-api.service --no-pager --full
systemctl show first-api.service -p ActiveState -p SubState -p Result -p ExecMainStatus -p NRestarts

Durum görünümü, geçerli veya en son çağrıyı açıklar ve son günlük iletilerini içerir. Seçilen özellikler, daha sonra karşılaştırmanız için size kompakt bir kayıt sunar. Başarısız bir durum veya artan yeniden başlatma sayısı incelenmeyi hak eder; etkin bir süreç hâlâ bir istek testine ihtiyaç duyar. Bunlar, aşağıda açıklandığı gibi farklı kontrollerdir: upstream systemctl başvurusu.

Birim eksikse, önce adını ve dağıtım yöntemini doğrulayın. Etkileşimli bir terminalde başlatılan bir uygulama, bir konteyner ve bir systemd hizmeti farklı sahiplere ve günlüklere sahiptir. Hemen yeni bir hizmet oluşturmak, aynı bağlantı noktası için rekabet eden iki kopya bırakabilir. Değiştirmeden önce mevcut düzeni belirleyin.

Dinleyiciyi kontrol edin ve yerel bir istek yapın

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

Beklenen adresi ve bağlantı noktasını arayın, ardından sahibi olan süreci belirleyin. Başka bir bağlantı noktasını dinleyen bir süreç sağlıklı olabilir ancak yapılandırılmış proxy tarafından erişilemez olabilir. Farklı bir süreç beklenen bağlantı noktasını ele geçirmiş olabilir. ss kılavuzu dinleyici ve süreç seçeneklerini tanımlar.

Yerel istek çalışıyor ve genel HTTPS isteği başarısız oluyorsa, şu kontrollerle devam edin: DNS, TLS ve proxy kontrolleri. Dinleyici yoksa, başlatma hatasını inceleyin. Bağlantı başarılı oluyor ancak uygulama bir hata döndürüyorsa, o rotayı ve bağımlılıklarını araştırın. Curl, --fail bir HTTP hata yanıtı için başarıyla tamamlanabilir, bu nedenle yalnızca çıkış koduna güvenmek yerine yanıtı okuyun. Bakınız curl'ün yanıt ve hata seçenekleri.

Yalnızca son satırı değil, ilk hatanın etrafını okuyun

sudo journalctl -u first-api.service --since "30 minutes ago" --no-pager -n 100
sudo journalctl -k --since "30 minutes ago" --no-pager -n 100

İlk sorgu hizmeti seçer; ikincisi çekirdek iletilerini seçer. Aralığı, son çalışan isteği ve kesintiden önceki değişikliği içerecek şekilde ayarlayın. Erişim ve saklama, nelerin kullanılabilir kaldığını belirler. upstream journalctl başvurusu birim, zaman ve çekirdek filtrelerini açıklar. Alıntıları paylaşmadan önce belirteçleri, müşteri verilerini ve bağlantı dizelerini gizleyin.

Yükleme özelliği olan ayrı bir uygulamadan örnek alıntı:

09:18:03 field-api: opening upload directory
09:18:03 field-api: EACCES: permission denied, open '/var/lib/field-api/uploads/index.json'
09:18:03 field-api: startup aborted

Bu, hizmet kullanıcısının belirli bir yola erişimine işaret eder. Dosya ve üst dizin sahipliğini sürüm talimatlarına göre kontrol edin. Tüm dosya sistemine geniş yazma erişimi vermeyin. Daha sonraki bir proxy "upstream kullanılamıyor" iletisi bu senaryoda bir sonuç olurdu, bu nedenle önce proxy'yi onarmak nedeni gözden kaçırırdı.

Kaynakları en son sürümle karşılaştırın

free -h
df -h / /opt/first-api
df -i / /opt/first-api

Bu anlık görüntüler, bellek baskısının, dosya sistemi alanının veya inode tükenmesinin hatayla çakışıp çakışmadığını sormanıza yardımcı olur. Yorumlanmaları bellek ve disk kılavuzuiçinde yer alır; tek bir yoğun okuma nedeni kanıtlamaz. Bir hizmet, ana bilgisayarın geri kalanı kapasiteye sahipken kendi kaynak sınırına da takılabilir.

Dağıtılan sürüm tanımlayıcısını, başlatma komutunu, gerekli ortam değişkeni adlarını ve veri yollarını son çalışan sürümle karşılaştırın. Gizli ortam değerlerini bir rapora dökmeyin. Yeniden adlandırılmış bir dizin, eksik çalışma zamanı bağımlılığı, bağlantı noktası değişikliği veya uyumsuz bir veritabanı geçişi arayın. Neyin değiştiğini ve hatanın bulmanızı öngördüğü şeyi belirtin.

Gerekçeli bir düzeltme yapın ve kurtarmayı doğrulayın

Kanıtların desteklediği en küçük düzeltmeyi seçin. Örnek izin hatası için bu, hizmet hesabı için amaçlanan erişimi geri yüklemek, ardından kontrollü bir başlatma denemesi yapmak anlamına gelir. Bunun yerine bilinen çalışan bir kod sürümü kullanırsanız, önce veritabanı şemasının uyumlu kalıp kalmadığını belirleyin. Bir kod geri alma, bir veri geçişini otomatik olarak tersine çeviremez.

Düzeltmeden sonra aynı hizmet, yerel uç nokta ve genel istek kontrollerini tekrarlayın. Temsili bir uygulama eyleminin çalıştığını, yeni hataların durduğunu ve sürecin bir sonraki normal iş yükü boyunca kararlı kaldığını doğrulayın. Yeniden başlatma politikaları bir süreci kurtarmaya yardımcı olabilir ancak sürekli bozuk bir programı sağlıklı yapmaz; gerçek politika için systemd hizmet başvurusu na bakın.

Olay notunuzu semptom, ilk yararlı ipucu, yapılan değişiklik ve doğrulama sonucuyla bitirin. Neden belirsiz kalırsa, geçici bir yeniden başlatmayı kalıcı bir düzeltme olarak etiketlemek yerine bu belirsizliği gizlenmiş kanıtlarla bildirin. sürüm kontrol listesini bu hatayı daha önce yakalayacak kontrolle iyileştirin.

Kullanılan belgeler

Bu sayfa için birincil referanslar. Kendi ortamınızda kurulu sürüme ilişkin belgeleri kontrol edin.