Logsign üzerinde EPS oranlarında bir doyum sözkonusu olduğunda Analiz işlemi gerçekleştirmek için yapılması gerekenler;
İlk olarak UDP paketleri Syslog'a gelmeden önce düşenleri teşhis edelim.
Bunu Kernel seviyesinden netstat -s (statistic) ile genel bir istatistik alalım.
netstat -su komutu ile sadece UDP paket durumunu görebiliriz.
watch netstat -su ile gerçek zamanlı takip edelim.
Burada;
31816671 packet receive errors
> Tüm paket kayıpları, network tabanlı olanlarda buna dahil olarak görebiliriz.
Bizim bu bölümde bakacağımız; RcvbufErrors: 31816671
, Buradaki paket kayıpları daha syslog'a gelmeden düşen paketler. Bu paket kayıplarının nedeni donanım yetersizliğinden (CPU, RAM, I/O) kaynaklı olabilir.
Bunun için vmstat 2 (iki saniyede bir) komutu ile i/o durumunu inceleyelim.
Buradaki iki sütun önemli;
wa (wait) > bekleyen
id (idle) > boşta
Buradaki değerler beklenen aralıkta ise i/o değerini o an için normal kabul ederek (yükün olduğu saatte analiz etmek daha yararlı olacaktır.)
Ardından top ile işlemci durumuna bakalım;
root 32276 8.1 1.9 559972 78192 ? Ssl 07:00 18:08 indexer: main
root 32309 0.0 0.6 222244 27968 ? Sl 07:00 0:00 indexer: from file
root 32311 56.6 1.8 368124 77052 ? Rl 07:00 126:13 indexer: from queue
root 32314 7.3 2.1 279628 85976 ? Sl 07:00 16:20 indexer: post (index)
root 32316 11.3 2.0 277224 83660 ? Sl 07:00 25:24 indexer: post (temp)
Bizim özellikle odaklanmamız gereken işlemler yukarıdadır. Bu işlemlerin harcadıkları işlemci durumuna göre fikir yürütmek mümkün olacaktır.
Burada indexer:main işlemciyi tükettiğinden işlemcinin core sayısı arttırılarak indexer:main paralel çalıştırılabilir.
EPS oranları /opt/var/log/indexer-stat-jobs içerisinden çekilmekte ancak tamamı yansıtılmamaktatır. Bu dosyaya giderek son bir dakikalık durum özeti alnır.
tail indexer-stat.json
komutu ile ilgili dosya görüntülenir.
{sysylog ile başlayan tag satırı kopyalanarak; jsonlint.com sitesinde Validate edilir.
Veya tail indexer-stat.json -f | grep processPool ile sadece ilgili işlem havazu işratlenerek gözlemlenebilir.
Buradaki çıktı, her bir layer ve kaynak için bize yararlı bilgiler verir;
Örneğin; "packetCount": 36169, ile ilgili sayıyı 60'a böldüğümüzde (indexer dakikalık aldığından) EPS oranını görürüz. ( ~603 gibi...)
Buradaki kıymetli bilgi; "processPool": 19999, Burada maksimum 20k olan işlem havazunun dolduğunu görüyoruz. Yani İşlemciden kaynaklı havuzun dolduğunu görüyoruz. İşlemci başarımını arttırdığımızda bu sefer RAM ve I/O problemleri yaşamamızda mümkün.
Saniyede meydana gelen kayıp için (tamamını yansıtmayacaktır);
Özetle yukarıdaki temel metotlar ile UDP'de paket kayıplarının CPU, RAM ve I/O'da nerede düştüğü hakkında bilgi edinilebilir. (TCP kullanılarak el sıkışma ile durum daha da netleştirilebilir ancak bu çift yönlü trafik olacağı da unutulmamalı.)
Yorumlar