Я пытаюсь отправить записи файлов как сообщения через TCP, где syslog-ng находится в контейнере и отправляет в другой контейнер. У меня было две разные попытки, обе с проблемным поведением. Первая конфигурация:
@version: 3.31
source s_file {
file("/var/log/my_file.json" follow_freq(1) flags(no-parse));
};
template log_template {
template("MSGSTART${MESSAGE}MSGEND");
};
class SngResolver(object):
def init(self, options):
"""
Initializes the parser
"""
self.counter = 0
return True
def parse(self, log_message):
log_message["SYSUPTIME"] = subprocess.check_output(['cat', '/proc/uptime']).decode('utf-8')
log_message["SEQUENCEID"] = str(self.counter)
self.counter += 1
# return True, other way message is dropped
return True
};
parser p_resolver {
python(
class("SngResolver")
);
};
# Define the destination for Suricata logs
destination d_container {
syslog("my_other_container" transport("tcp") port(1234) template(log_template));
};
# Define the log path for Suricata logs
log {
source(s_file);
parser(p_resolver);
destination(d_container);
};
При использовании этого метода иногда полученное сообщение начиналось с количества байтов в пришедшем сообщении, например 400
, . В других случаях они этого не делали и переходили сразу к сообщению.
Позже я изменил назначение, чтобы использовать network
вместо syslog
. Теперь нет кадрирования.
Я не против, если мне придется использовать TCP, UDP, что угодно. У меня есть golang, полученный через сокет TCP, и я хочу, чтобы он читал одно сообщение за раз и анализировал его. Как это достижимо? Спасибо
решение1
Назначение syslog() будет использовать формат кадрирования с подсчетом октетов на транспорте (tcp) и транспорте (tls), как описано в RFC5425. Он НЕ будет использовать кадрирование на транспорте (udp), поскольку в этом случае датаграмма делит сообщения, используя границы пакетов. Транспорт UDP описан в RFC5426.