HestiaCP ile Apache2'de sık sık çökmeler mi yaşıyorsunuz? Monit otomatik izleme ve sorun giderme kılavuzu (eksiksiz yapılandırma ile)

HestiaCP ortamlarında sık sık Apache2 çökmeleri veya Monit otomatik yeniden başlatma hataları mı yaşıyorsunuz? Bu makale, Monit ile Apache2'yi izlerken sık karşılaşılan sorunlardan kaçınmak için pratik bir kılavuz sunmakta, PID yolu uyumsuzluğu ve izin engellemesi gibi yaygın sorunları derinlemesine analiz etmekte ve üretim kalitesinde Monit otomasyon yapılandırma dosyaları sunmaktadır. Yüksek kullanılabilirlik sunucu bakım tekniklerinde uzmanlaşın ve arızalardan ikinci seviye otomatik kurtarma elde edin!

Monit kullanarak Apache2'yi izlerken karşılaştığım zorluklar

Geçen cuma, sunucu gece yarısı bana bir Monit uyarısı verdi.

Şaşkınlıkla panele göz attım ve apache2 durum sütununda kırmızı bir Zaman Aşımı uyarısı gördüm.

Biraz düşündüm. Gün içinde sunucuya Monit izleme sistemini ekledim ve yapılandırmayı çevrimiçi bir eğitimden kopyalayıp yapıştırdım. Herhangi bir sorun olmamalı, değil mi?

Ertesi sabah yine zaman aşımı yaşandı. Üçüncü kezden sonra, Monitor sistemi tamamen pes etti ve panelde "İzlenmiyor" yazısı belirdi.

BEN...

İtiraf ediyorum, ilk başta ciddiye almadım. Apache2 izleme mi? İnternette bir sürü şablon yapılandırması bulabilirsiniz, sadece kopyalayıp yapıştırın. Ama bu yapıştırma işlemi beni gerçekten çileden çıkardı.

HestiaCP'nin varsayılan mimarisi ile Monit portları arasındaki çatışmanın temel nedeni

Öncelikle size bana çok fazla sorun çıkaran yapılandırmayı göstereyim, böylece sizin gördüğünüz sürümle tamamen aynı olup olmadığını görebilirsiniz.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

Gayet iyi görünüyor, değil mi? 80 numaralı portu kontrol ediyor ve çökerse yeniden başlatılıyor. 5 yeniden başlatmadan sonra hala çöküyorsa, zaman aşımına uğruyor.

Sorun şu ki, Apache2'niz 80 numaralı portta bile çalışmıyor.

Bu, HestiaCP'nin bir dezavantajı ve birçok insanın bu tuzağa düşmesinin temel nedenidir. HestiaCP'nin varsayılan mimarisi, Nginx + Apache2'nin ters proxy'sidir; Nginx önde 80 ve 443 numaralı portları kullanırken, Apache2 arkada yerel 8081 numaralı portta çalışır.

Monit'ten 80 numaralı porttaki Apache2'nin çalışır durumda olup olmadığını kontrol etmesini isterseniz, bu McDonald's'a gidip KFC bulmaya benzer. Sunucu size boş boş bakar ve ikiniz de birbirinize bakarsınız. Sonunda Monit, sunucunun çalışmadığını belirler ve çılgıncasına yeniden başlatmaya başlar.

Yeniden başlatmanın ardından port hala 8081 olarak kalıyor. Monit daha sonra 80 numaralı portu yoklamayı deniyor, bu da başarısız oluyor, bu yüzden tekrar yeniden başlatılıyor. Bu döngü, Monit onarılamaz olduğuna karar verip zaman aşımına uğrayana kadar tekrarlanıyor.

Bunu ilk gördüğümde gerçekten şok oldum. İnternette bulduğum on eğitim videosundan dokuzu 80 numaralı portu kullanıyordu. Eğer onları takip ettiyseniz, sorun sizde değil, bilginin kaynağındaydı.

Bozulmuş bir Apache2 PID dosyası, Monit'in işlemi yanlışlıkla mevcut değilmiş gibi tanımlamasına neden oldu.

Port numarasını 80'den 8081'e değiştirdikten sonra, Monit'in teorik olarak bunu algılayabilmesi gerekir, değil mi?

Ancak gerçekte, zaman zaman hala "Yürütme başarısız oldu " hatası veriyor.

Uzun süre uğraştıktan sonra, sonunda sebebin basit olduğunu keşfettim: PID dosyası bozulmuştu.

Şöyle düşünün, Monit sürekli olarak Apache2'yi yeniden başlatıyor, her seferinde zorla öldürüp yeniden başlatıyor ve bu işlemi birkaç kez tekrarlıyordu. Bu süreçte, /var/run/apache2/apache2.pid dosyasının boyutu 0 bayta düşebilir.

Başka bir deyişle, dosya hala orada, ancak içi boş.

Monit bu dosyayı okuduğunda hiçbir şey bulamıyor. Apache2'niz arka planda mükemmel bir şekilde çalışıyor olsa bile, Monit Apache2'nizi tanımıyor; Monit bu işlemin var olduğunu düşünmüyor.

Bunu görünce bir an nutkum tutuldu.

Bu bir kilitlenme durumudur. Monit, Apache 2 örneğini algılayamaz, Apache2'yi yeniden başlatır, yeniden başlatma işlemi sırasında PID dosyasını bozar, bir sonraki algılamada başarısız olur ve tekrar yeniden başlatılır. Bu döngü, zaman aşımı gerçekleşene kadar devam eder.

HestiaCP Ortamında Apache2 İzleme İçin Sorun Giderme ve Onarım Adımları

Dürüst olmak gerekirse, soruşturma süreci karmaşık değil, ancak hangi yönde soruşturma yapmanız gerektiğini bilmeniz gerekiyor.

İlk adım, Apache2'nizin hangi portta dinleme yaptığını belirlemektir. Terminale bir komut yazmanız yeterlidir.

netstat -tulpn | grep apache2

Alternatif olarak, `ss` komutunu kullanabilirsiniz; etkisi aynıdır.

ss -tulpn | grep apache2

Buna benzer bir çıktı göreceksiniz.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

Doğrulanan sayı 80 değil, 8081. Sorunun kaynağı bu.

İkinci adım, bozulmuş PID dosyasını onarmaktır. Bu daha basittir.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

Öncelikle, düzeltme işlemleri sırasında müdahale etmesini önlemek için Monit izleme işlemini duraklatın. Ardından, temiz bir PID yazabilmesi için Apache2'yi yeniden başlatın. Son olarak, dosya içeriğini kontrol etmek için `cat` komutunu kullanın; dosya boş bir dize değil, sayılardan oluşan bir dize içermelidir.

Bu adım tamamlandığında, sorun temelde çözülmüş olur.

Monit Geleneksel Uyarlanabilir ve Saldırgan Koruyucu Yapılandırmalarının Karşılaştırmalı Analizi

Apache2'yi Monit ile yapılandırmaya yönelik çevrimiçi eğitimler genellikle iki kategoriye ayrılır.

Bir türü de "geleneksel uyarlama türü"dür; bu tür, çok fazla karmaşık kısıtlama eklemeden hizmetleri yönetmek ve yerel bağlantı noktalarını kontrol etmek için `service` komutunu kullanır. Bu yapılandırma, HestiaCP'de sadece bağlantı noktasını değiştirerek kullanılabilir ve nispeten kararlıdır.

Bir diğer yaklaşım ise, hizmetleri yönetmek için systemctl kullanan, alt süreç kısıtlamaları ekleyen ve daha sıkı tespit mantığı kullanan "agresif koruma" yöntemidir. Harika görünüyor, ancak ölümcül bir kusuru var: kullanılan durdurma komutu `killall -9`.

`killall -9` ne anlama geliyor? Cihazın ne yaptığına bakılmaksızın zorla sonlandırılması anlamına geliyor. Bu kaba kuvvet işlemi, az önce bahsettiğim sorun olan bozuk PID dosyalarını kolayca geride bırakabilir.

Kişisel deneyimime göre, agresif bir yapılandırmada alt işlem sayısını sınırlamak gerçekten faydalı. Apache2 sunucunuz bir CC saldırısıyla aşırı yüklendiğinde, alt işlem sayısını sınırlamak sunucunun bellek yetersizliğinden dolayı çalışmasını engelleyebilir. Ancak, `killall -9` yaklaşımı gerçekten kullanılamaz durumda.

Sonuç olarak uzlaştım ve her iki yapılandırmanın avantajlarını birleştirdim.

HestiaCP Apache2 İzleme En İyi Uygulama Yapılandırması

/etc/monit/conf.d/apache2 dosyasını aşağıdaki içerikle değiştirin.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

Bu birkaç satırlık yapılandırmanın ardındaki mantığı kısaca açıklayayım.

HestiaCP'nin ters proxy mimarisine tam olarak uyacak şekilde 8081 numaralı bağlantı noktasını yazın; 80 numaralı bağlantı noktasını yazmayı bırakın.

PID dosyasının bozulmasını önlemek için `killall -9` komutu yerine `systemctl stop` komutunu kullanın.

Çocuk işlem sınırı eklendi: Çocuk işlem sayısı 120'yi aşarsa, CC saldırılarını önlemek için işlem iki ardışık döngüden sonra yeniden başlatılacak, ancak bu çok agresif bir önlem değil.

Arızaları tespit etme mantığı, "2 döngü için" yaklaşımını kullanacak şekilde değiştirildi; bu, yeniden başlatmanın yalnızca iki ardışık arızadan sonra tetiklendiği ve yanlış pozitifleri azalttığı anlamına gelir. Sadece bir tespit sonrasında yeniden başlatılan önceki yapılandırma, açıkçası biraz fazla hassastı.

Son zaman aşımı eşiği, 10 döngü içinde 5 yeniden başlatmaya kadar gevşetilerek yeterli hata toleransı sağlanmıştır.

HestiaCP İzleme izlemeYapılandırma Sorun Giderme Özeti ve Deneyim Paylaşımı

Yapılandırma değişikliklerini yaptıktan sonra apache2'yi izledim ve panelde sonunda yeşil bir "OK" göstergesi belirdi.

O anki duygularımı nasıl tarif edebilirim? İki gün boyunca bir hatayla uğraştıktan sonra, sorunun tek bir satırlık yanlış bir yapılandırmadan kaynaklandığını öğrenmek gibiydi. Hem sinir bozucu hem de gülünçtü.

Monit kendi başına iyi bir şey ve sunucunun arka plan işlemlerini izlemesi gerekiyor. Ancak sorun şu ki, birçok çevrimiçi eğitim "Apache2 yalnızca 80 numaralı portu kullanıyor" varsayımına dayanıyor, oysa HestiaCP ters proxy kullanıyor; bu da bu varsayımın doğru olmadığı anlamına geliyor.

Talimatları izlerseniz, sorun sizde değil; sorun, eğitimin sizin durumunuzdan farklı bir senaryoya uygulanabilir olmasıdır.

Eğer siz de HestiaCP kullanıyorsanız ve Apache2'yi izlemek için Monit ile uğraşıyorsanız, iki şeyi unutmayın: Portu 8081'e değiştirin ve durdurmak için `killall -9` yerine `systemctl` komutunu kullanın. Bu iki şeyi yaparsanız, daha fazla sorun yaşamamanız gerekir.

Buraya kadar okuduğunuza göre, eğer faydalı bulduysanız lütfen beğenin ve paylaşın. Güncellemeleri ilk öğrenmek istiyorsanız beni takip edebilirsiniz!

Makalemi okuduğunuz için teşekkür ederim. Bir sonraki yazıda görüşmek üzere.