Rsyslog elasticsearch
Когато администрирате сървърен парк от около 10 или повече, има нужда от централизирано съхранение на регистрационни файлове.
Тук има няколко цели.
- Първо, сигурност - всичко е фиксирано и се дублира не само локално, но и на отдалечен сървър. Ако сървърът е хакнат и регистрационните файлове са изтрити, тогава в конкретен случай ще бъде възможно да се възстанови какво е направено и кога; кой и къде.
- Втората точка е удобна обработка на трупи. Регистрационните файлове могат бързо да бъдат избутани в elastic и чрез интерфейса на kibana е лесно да се види какво се случва, да се изградят зависимости и т.н.
- Третият важен момент е общата среда за разбор на логове с програмистите. Можете да сравните времето на едно или друго събитие според определени критерии със събития на други сървъри, обикновено този критерий е основният за внедряване на централизирано съхранение на журнали.
- Има още един много важен момент в големите кампании - протоколът syslog е много удобен за използване за доставяне на съобщения не само от сървъри, но и от приложения, crons и други неща до магазина. Освен това има значително увеличение на производителността - приложението не трябва да отваря файл на диска, още по-малко да се свързва по мрежата с elasticsearch - всичко, което е необходимо, е да записва данни в syslog сокета. Освен това, с правилната конфигурация, доставката ще се извърши чрез самия syslog и процесът ще продължи работата си без значителни забавяния.
Да започваме. На повечето сървъри rsyslogd вече е инсталиран в кутията, която, наред с други неща, може да изпраща регистрационни файлове на elasticsearch. Това е много готино, защото не изисква допълнителна връзка под формата на logstash!
За надеждност в ластик ще дублираме трупите в ластик и на диск.
За изпращанение използваме tcp, защото мрежата е голяма, с няколко vpn тунела, режийните разходи от този подход са 100ms за установяване на връзка и загубата на регистрационни файлове не е Jadai. Конфигурацията за предаващата страна изглежда така: