Panduan Praktikal Penyelesaian Masalah Pengeluaran Linux SRE

Senario

Pelayan aplikasi e-dagang kritikal mula mengalami kependaman respons yang meningkat. Pengguna melaporkan halaman tamat masa. Pelayan menjalankan CentOS 7 dengan 64 teras CPU dan 256 GB RAM, mengehos Nginx dan aplikasi Java.

Gejala

• Log masuk SSH lambat; arahan mengambil 2-3 saat untuk output.
• uptime memaparkan purata beban: 55.23, 48.19, 32.54 (melebihi 80% daripada 64 teras CPU).
• top mendedahkan beberapa proses Java menggunakan CPU sehingga 3000% (berbilang utas).
• iostat -x 1 menunjukkan %util cakera secara konsisten 99%, await > 100ms.

Langkah Diagnostik

Langkah 1: Semakan Sumber Keseluruhan

# Semak beban, memori, dan I/O
top -b -n1 | head -20
free -h
vmstat 1 5
iostat -x 1 3

Penemuan: CPU pengguna tinggi, CPU sistem rendah; memori mencukupi; I/O cakera tidak normal.

Langkah 2: Kenal Pasti Punca I/O

# Kenal pasti proses dengan I/O cakera berat
iotop -oP
# Semak status sistem fail
df -h
dstat --top-io --top-bio 1 5

Proses Java menulis log yang sangat besar, dan partisyen /var/log berada pada penggunaan 95%.

Langkah 3: Analisis Penulisan Log

# Semak saiz fail log
ls -lh /var/log/app/*.log
# Gunakan strace untuk mengesan syscall tulis (AWAS: bukan pada pengeluaran kecuali perlu)
strace -p <PID> -e trace=write -c -S time 2>&1 | head -20

Pengesahan: Rangka kerja log dikonfigurasi untuk penulisan segerak, menghasilkan log besar pada setiap GC.

Kawalan Risiko

• Jangan kill -9 proses kritikal.
• Maklumkan pasukan sebelum menukar tahap log (log audit mungkin hilang).
• Gunakan ionice untuk mengurangkan keutamaan I/O: ionice -c 2 -n 7 -p <PID>.
• Putar log dengan selamat (hentikan tulis dahulu atau gunakan copytruncate): logrotate -f /etc/logrotate.d/app.

Penyelesaian dan Undur

Jangka Pendek: Mampat dan putar log

# Putaran manual
mv /var/log/app/current.log /var/log/app/current.log.$(date +%Y%m%d%H%M%S)
kill -HUP <PID>  # Maklumkan proses untuk buka semula fail
# Konfigur logrotate untuk mampatan harian, simpan 7 hari

Jangka Panjang: Tukar log ke tak segerak

Ubah suai Appender dalam log4j2.xml:

<RollingFile name="RollingFile" fileName="/var/log/app/app.log" filePattern="/var/log/app/app-%d{yyyy-MM-dd}-%i.log.gz">
  <PatternLayout pattern="%d{ISO8601} [%t] %-5p %c - %m%n"/>
  <Policies>
    <TimeBasedTriggeringPolicy/>
    <SizeBasedTriggeringPolicy size="100 MB"/>
  </Policies>
  <DefaultRolloverStrategy max="7"/>
  <AsyncLogger>
    <AppenderRef ref="RollingFile"/>
  </AsyncLogger>
</RollingFile>

Uji di pementasan sebelum gunakan pada pengeluaran.

Undur

Jika perubahan gagal, pulihkan konfigurasi log asal dan mulakan semula:

cp /etc/app/log4j2.xml.bak /etc/app/log4j2.xml
systemctl restart app

Pengesahan

• Jalankan iostat -x 1 semula; %util harus <30%, await <10ms.
• Uji tekanan Nginx dengan ab atau wrk; masa respons harus normal.
• Pantau purata beban di bawah 70% teras CPU selama 5 minit berturut-turut.

Bila Mengemukakan Tiket OpsGlobal

• Punca tidak jelas selepas mengikuti langkah di atas.
• Parameter kernel (cth. vm.dirty_ratio) perlu ditala tetapi anda tiada akses pengeluaran.
• Disyaki kegagalan perkakasan (cth. sektor rosak) memerlukan penggantian.
• Penyelesaian masalah melebihi 2 jam tanpa kemajuan.

Kemukakan melalui konsol OpsGlobal dengan: - Tetingkap masa dan skop impak. - Arahan diagnostik yang dilaksanakan dan output (dinyahpeka). - Versi OS, parameter kernel, dan sandaran konfigurasi berkaitan.