Рейтинг:0

syslog-ng: как настроить отправку сообщений RFC5424 с подсчетом октетов

флаг al

Пожалуйста, не утруждайте себя чтением этого вопроса. syslog-ng уже настроен для отправки сообщений RFC5424 с кадрированием с подсчетом октетов по умолчанию. Меня смутило поведение другого компонента. Этот вопрос недействителен.


У меня есть конфигурация syslog-ng OSE (v3.31.2):

@версия: 3.29
@include "scl.conf"
    
источник s_network {
    udp (ip (0.0.0.0) порт (514));
};
    
пункт назначения d_network_telegraf {
    syslog («телеграф» порт (601) транспорт (tcp));
};
    
журнал {
    источник (s_network);
    пункт назначения (d_network_telegraf);
};

Намерение состоит в том, чтобы направить RFC3164 форматированные сообщения системного журнала, полученные на UDP-порту 514, и пересылать их как RFC5424 форматированные сообщения в телеграф на TCP-порт 601.

С этой конфигурацией syslog-ng выдает пересылаемые сообщения в виде RFC5424 с непрозрачным (заполненным октетами) кадрированием (сообщение начинается с символа ASCII <). К сожалению, телеграф ожидает получать сообщения с кадрированием по октетам (сообщение начинается с цифры). RFC6587 охватывает их.

Хотя можно настроить телеграф на ожидание непрозрачного кадрирования, похоже, это работает неправильно. Прежде чем я углублюсь в это, я хотел бы попробовать альтернативу, которая заключается в настройке syslog-ng для вывода сообщений RFC5424 с кадрированием с подсчетом октетов. В любом случае, это, по-видимому, рекомендуемый тип кадрирования.

Однако я ничего не могу найти в документах syslog-ng по этому поводу. Почти во всех случаях в документации обсуждается использование системный журнал водитель для вход, нет вывод, а тут почти нет упоминаний подсчета октетов вообще.

Можно ли настроить syslog-ng таким образом?


РЕДАКТИРОВАТЬ

Это точная конфигурация, которую я использую:

@версия: 3.29
@include "scl.conf"

параметры {
    создать каталоги (да);
    флеш-линии (1);
    время повторного открытия (60);
};

источник s_local {
    система();
    внутренний();
};

источник s_network {
    udp (ip (0.0.0.0) порт (514));
};

пункт назначения d_local {
    файл("/data/syslog-ng/var/log/messages");
    file("/data/syslog-ng/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3 ));
};

место назначения d_network_files {
    файл("/data/syslog-ng/var/log/messages-network");
    file("/data/syslog-ng/var/log/messages-network-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits (3));
};

пункт назначения d_network_telegraf {
    syslog («телеграф» порт (601) транспорт (tcp));
};

журнал {
    источник (s_network);
    пункт назначения (d_network_telegraf);
    пункт назначения (d_network_files);
};

Вот сообщение, отправленное logger -i -d --server localhost это тест в syslog-ng через UDP-порт 514:

0000 02 42 ac 15 00 09 02 42 69 3a f6 78 08 00 45 00 .B.....Bi:.x..E.
0010 00 a6 79 e7 40 00 40 11 68 2b ac 15 00 01 ac 15 ..y.@[email protected]+......
0020 00 09 b4 bd 02 02 00 92 58 d8 3c 31 33 3e 31 20 ........X.<13>1 
0030 32 30 32 31 2д 31 31 2д 31 38 54 31 32 3а 34 31 2021-11-18T12:41
0040 3а 35 39 2е 39 34 33 39 36 35 2б 31 33 3а 30 30 :59,943965+13:00
0050 20 6b 6f 72 69 6d 61 6b 6f 20 64 61 76 69 64 20 коримако дэвид 
0060 36 38 38 31 34 30 20 2d 20 5b 74 69 6d 65 51 75 688140 - [timeQu
0070 61 6c 69 74 79 20 74 7a 4b 6e 6f 77 6e 3d 22 31 ality tzKnown="1
0080 22 20 69 73 53 79 6e 63 65 64 3d 22 31 22 20 73 "isSynced="1" с
0090 79 6e 63 41 63 63 75 72 61 63 79 3d 22 37 39 37 yncAccuracy="797
00a0 30 30 30 22 5d 20 74 68 69 73 20 69 73 20 61 20 000"] это 
00b0 74 65 73 74 тест

А вот перехваченное сообщение между syslog-ng и telegraf (TCP-порт 601):

0000 02 42 ac 15 00 07 02 42 ac 15 00 09 08 00 45 00 .B.....B......E.
0010 00 эк ба 61 40 00 40 06 27 70 ак 15 00 09 ак 15 ...а@.@.'р......
0020 00 07 a7 ab 02 59 be 1c 32 98 d1 f9 90 93 80 18 .....Y..2.......
0030 01 f6 59 19 00 00 01 01 08 0a 0c 3e 2a 2d 7a e2 ..Y........>*-z.
0040 58 de 3c 31 33 3e 31 20 32 30 32 31 2d 31 31 2d X.<13>1 2021-11-
0050 31 37 54 32 33 3а 34 31 3а 35 39 2б 30 30 3а 30 17T23:41:59+00:0
0060 30 20 31 37 32 2e 32 31 2e 30 2e 31 20 31 20 2d 0 172.21.0.1 1 -
0070 20 2д 20 2д 20 32 30 32 31 2д 31 31 2д 31 38 54 - - 2021-11-18T
0080 31 32 3а 34 31 3а 35 39 2е 39 34 33 39 36 35 2б 12:41:59.943965+
0090 31 33 3а 30 30 20 6б 6ж 72 69 6д 61 6б 6ф 20 64 13:00 коримако д
00a0 61 76 69 64 20 36 38 38 31 34 30 20 2d 20 5b 74 жадный 688140 - [т
00b0 69 6d 65 51 75 61 6c 69 74 79 20 74 7a 4b 6e 6f imeQuality tzKno
00c0 77 6e 3d 22 31 22 20 69 73 53 79 6e 63 65 64 3d wn="1" isSynced=
00d0 22 31 22 20 73 79 6e 63 41 63 63 75 72 61 63 79 "1" syncAccuracy
00e0 3d 22 37 39 37 30 30 30 22 5d 20 74 68 69 73 20 ="797000"] это 
00f0 69 73 20 61 20 74 65 73 74 0a — тест.

Вы можете видеть, что сообщение, которое начинается с байта 66 (0x42), начинается с < символ (<13>1 2021...). Согласно RFC6587, это интерпретируется не как кадрирование с подсчетом октетов, а как альтернатива: непрозрачное кадрирование.

Полный журнал syslog-ng для этого события:

[2021-11-17T23:41:59.944928] Входящая запись журнала; line='<13>1 2021-11-18T12:41:59.943965+13:00 korimako david 688140 - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="797000"] это тест.
[2021-11-17T23:41:59.987236] Исходящее сообщение; message='2021-11-17T23:41:59.944+00:00 172.21.0.1 HOST=172.21.0.1 HOST_FROM=172.21.0.1 LEGACY_MSGHDR="1 " MESSAGE="2021-11-18T12:41:59.943965+13:00 korimako david 688140 - [timeQuality tzKnown=\"1\" isSynced=\"1\" syncAccuracy=\"797000\"] это тест" PROGRAM=1 SOURCE=s_network\x0a'
[2021-11-17T23:41:59.987403] Исходящее сообщение; message='17 ноября 23:41:59 172.21.0.1 1 2021-11-18T12:41:59.943965+13:00 korimako david 688140 - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="797000"] это это тест\x0a'
[2021-11-17T23:42:31.994550] Соединение с системным журналом установлено; fd='12', server='AF_INET(172.21.0.7:601)', local='AF_INET(0.0.0.0:0)'
[2021-11-17T23:42:31.994946] Исходящее сообщение; message='<13>1 2021-11-17T23:41:59+00:00 172.21.0.1 1 - - - 2021-11-18T12:41:59.943965+13:00 korimako david 688140 - [timeQuality tzKnown="1 " isSynced="1" syncAccuracy="797000"] это тест\x0a'
[2021-11-17T23:42:36.996059] EOF произошел во время простоя; фд='12'
[2021-11-17T23:42:36.996187] Соединение системного журнала закрыто; fd='12', server='AF_INET(172.21.0.7:601)', time_reopen='60'
[2021-11-17T23:43:36.996635] Соединение с системным журналом установлено; fd='12', server='AF_INET(172.21.0.7:601)', local='AF_INET(0.0.0.0:0)'

ОБНОВЛЕНИЕ 1: я обнаружил отсутствующее значение подсчета октетов в начале сообщения — оно находится в предыдущем кадре TCP. Я думаю, это означает, что выходные данные syslog-ng все-таки используют кадрирование с подсчетом октетов. Сейчас я активно отлаживаю источник телеграфа, потому что я думаю, что он получает сообщение, но впоследствии ошибочно закрывает соединение. Я обновлю это, когда узнаю больше.


ОБНОВЛЕНИЕ 2: я определил, что в плагине системного журнала телеграфа есть ошибка или ошибка в документации, и он отключает все входящие TCP-соединения, которые простаивают более 5 секунд. Это не проблема синтаксического анализа, а просто тайм-аут.

Поэтому с syslog-ng проблем нет, и весь этот вопрос недействителен.

Рейтинг:0
флаг vn

syslog-ng можно настроить для поддержки всех комбинаций: форматов RFC3164 или RFC5424, с технологией кадрирования, определенной в RFC6587, или без нее.

системный журнал() использует кадрирование RFC6587 (подсчет октетов) и предпочитает RFC5424 в качестве формата сообщения, но возвращается к RFC3164 на стороне источника, когда синтаксический анализ RFC5424 завершается неудачно.

сеть() работает без кадров (без подсчета октетов — в RFC это называется «непрозрачное кадрирование»), и по умолчанию используется RFC3164, но это можно изменить (на RFC5424) с помощью флаги (syslog-протокол) флаг.

флаг al
При использовании `syslog()` или `network(... flags(syslog-protocol))` как вы переключаетесь между режимами подсчета октетов и непрозрачным (вставка октетов)? В настоящее время я использую `syslog()`, и он кажется только непрозрачным. Оба эти режима охватываются RFC6587. Возможно, есть специальная опция для переключения на подсчет октетов? Я не могу найти что-либо в документах об этом, хотя.
MrAnno avatar
флаг vn
syslog() должен использовать подсчет октетов, а network() использует старый метод "непрозрачного кадрирования" (разделяет сообщения с помощью \n).
MrAnno avatar
флаг vn
Если это не так, возможно, вы нашли ошибку. Вы используете ту же конфигурацию, которой поделились?
флаг al
Я обновил текст своего вопроса, включив в него полную конфигурацию, которую я использую, а также некоторые записи wireshark и соответствующие журналы консоли syslog-ng. Дайте мне знать, если что-то еще может быть полезно увидеть.
флаг al
Еще одно обновление - я обнаружил «отсутствующий» префикс «[цифры]» для подсчета октетов в предыдущем кадре TCP, поэтому он присутствует в потоке. Я пропустил это. Таким образом, это означает, что syslog-ng *выводит* кадры с подсчетом октетов, как и ожидалось. Я думаю, что определенно есть проблема с тем, как телеграф обрабатывает эти сообщения, поскольку он активно закрывает соединение после каждого сообщения из-за тайм-аута. Я отлаживаю это сейчас. В любом случае, @MrAnno, спасибо за то, что ответили на это время, и приношу извинения за то, что потратил его впустую.
MrAnno avatar
флаг vn
Не за что. Хм, интересно. Есть кое-что, что может быть вам интересно: в случае, если telegraf отправляет что-либо обратно в syslog-ng, по умолчанию соединение закрывается, потому что драйверы network(), syslog() не ожидают ответов от сервера. Если это так, вы можете попробовать следующий недокументированный вариант: `close-on-input(no)`.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.