Aplikasi Anda berhenti. Temukan petunjuk berguna pertama.

Tentukan satu kegagalan yang dapat diamati

“Berhenti” bisa berarti kesalahan HTTP, timeout, tugas yang tidak selesai, atau proses yang keluar. Tuliskan satu URL atau tindakan, waktu terakhir diketahui berfungsi, waktu kegagalan pertama, dan zona waktu Anda. Sertakan apakah semua orang terpengaruh atau hanya satu klien. Biarkan sesi SSH saat ini tetap terbuka selama investigasi; mengubah aturan akses bukan respons pertama yang diperlukan untuk kesalahan aplikasi.

Panduan ini mengasumsikan host Linux menggunakan systemd, layanan aplikasi bernama first-api.service, dan endpoint kesehatan lokal di 127.0.0.1:3000/healthz. Default ini cocok dengan panduan deployment API pertama. Ganti dengan nama aktual Anda. Inspeksi mungkin memerlukan izin administrator untuk melihat proses atau log pengguna lain. Perintah dan output di bawah ini bersifat ilustratif; tidak ada instance penyedia yang diuji untuk panduan ini.

Simpan catatan di luar direktori aplikasi yang gagal. Catat observasi sebelum interpretasi: “connection refused pada 09:18 UTC” adalah fakta; “VPS perlu lebih banyak CPU” masih hipotesis. Jika server itu sendiri tidak dapat dijangkau, gunakan akses pemulihan yang telah Anda buat dan kumpulkan detail koneksi daripada mengasumsikan restart aplikasi dapat dilakukan.

Baca status proses dan riwayat terbarunya

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

Tampilan status menjelaskan pemanggilan saat ini atau yang terbaru dan menyertakan pesan jurnal terkini. Properti yang dipilih memberi Anda catatan ringkas untuk dibandingkan nanti. Status gagal atau jumlah restart yang terus bertambah perlu diselidiki; proses yang aktif tetap memerlukan uji permintaan. Ini adalah pemeriksaan yang berbeda, sebagaimana dijelaskan dalam referensi systemctl upstream.

Jika unit tidak ada, verifikasi dulu namanya dan metode deployment. Aplikasi yang dijalankan di terminal interaktif, kontainer, dan layanan systemd memiliki pemilik dan log yang berbeda. Membuat layanan baru segera dapat meninggalkan dua salinan yang bersaing memperebutkan port yang sama. Identifikasi pengaturan yang ada sebelum mengubahnya.

Periksa listener dan buat permintaan lokal

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

Cari alamat dan port yang diharapkan, lalu identifikasi proses pemiliknya. Proses yang mendengarkan di port lain mungkin sehat tetapi tidak dapat dijangkau oleh proxy yang dikonfigurasi. Proses lain mungkin telah mengambil port yang diharapkan. manual ss menentukan opsi listener dan proses.

Jika permintaan lokal berhasil dan permintaan publik HTTPS gagal, lanjutkan melalui pemeriksaan DNS, TLS, dan proxy. Jika listener tidak ada, periksa kegagalan startup. Jika koneksi berhasil tetapi aplikasi mengembalikan error, selidiki rute tersebut dan dependensinya. Curl tanpa --fail dapat berhasil diselesaikan untuk respons error HTTP, jadi baca responsnya alih-alih hanya mengandalkan kode keluarnya. Lihat opsi respons dan kegagalan curl.

Baca di sekitar kegagalan pertama, bukan hanya baris terakhir

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

Kueri pertama memilih layanan; kueri kedua memilih pesan kernel. Sesuaikan intervalnya agar mencakup permintaan terakhir yang berhasil dan perubahan yang mendahului gangguan. Akses dan retensi menentukan apa yang masih tersedia. referensi journalctl upstream menjelaskan filter unit, waktu, dan kernel. Redaksi token, data pelanggan, dan string koneksi sebelum membagikan kutipan.

Kutipan ilustratif dari aplikasi terpisah dengan fitur unggah:

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

Ini mengarah pada akses pengguna layanan ke path tertentu. Periksa kepemilikan file dan direktori induk terhadap instruksi rilis. Jangan memberikan akses tulis yang luas ke seluruh filesystem. Pesan proxy "upstream unavailable" nanti akan menjadi konsekuensi dalam skenario ini, jadi memperbaiki proxy terlebih dahulu akan melewatkan penyebabnya.

Bandingkan sumber daya dengan rilis terbaru

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

Snapshot ini membantu Anda menanyakan apakah tekanan memori, ruang filesystem, atau kehabisan inode bertepatan dengan kegagalan tersebut. Interpretasinya ada di panduan memori dan disk; satu bacaan sibuk tidak menetapkan penyebabnya. Layanan juga dapat mencapai batas sumber dayanya sendiri sementara host lainnya masih memiliki kapasitas.

Bandingkan pengenal rilis yang di-deploy, perintah start, nama variabel lingkungan yang diperlukan, dan path data dengan rilis terakhir yang berfungsi. Jangan membuang nilai lingkungan rahasia ke dalam laporan. Cari direktori yang diganti nama, dependensi runtime yang hilang, perubahan port, atau migrasi database yang tidak kompatibel. Nyatakan apa yang berubah dan apa yang diprediksi error akan Anda temukan.

Lakukan satu koreksi yang wajar dan verifikasi pemulihan

Pilih koreksi terkecil yang didukung bukti. Untuk kegagalan izin ilustratif, itu berarti memulihkan akses yang dimaksudkan untuk akun layanan, lalu melakukan satu upaya start terkendali. Jika Anda menggunakan rilis kode yang diketahui berfungsi sebagai gantinya, pertama-tama pastikan apakah skema database-nya tetap kompatibel. Rollback kode tidak dapat secara otomatis membalikkan migrasi data.

Setelah koreksi, ulangi pemeriksaan layanan, endpoint lokal, dan permintaan publik yang sama. Pastikan tindakan aplikasi yang representatif berfungsi, error baru telah berhenti, dan proses tetap stabil melalui beban kerja normal berikutnya. Kebijakan restart dapat membantu memulihkan proses, tetapi tidak membuat program yang terus-menerus rusak menjadi sehat; konsultasikan referensi layanan systemd untuk kebijakan sebenarnya.

Akhiri catatan insiden Anda dengan gejala, petunjuk berguna pertama, perubahan yang dilakukan, dan hasil verifikasi. Jika penyebabnya masih belum pasti, laporkan ketidakpastian itu dengan bukti yang telah diredaksi alih-alih menyebut restart sementara sebagai perbaikan permanen. Tingkatkan daftar periksa rilis dengan pemeriksaan yang seharusnya menangkap kegagalan ini lebih awal.