К
чтобы не потерять ничего при упавшем коллекторе?
обычно для этого делается кэширование на стороне отправителя, если логи считаются критичными. так же, как это делает ваш агент в случае отвала коры или сиема
Size: a a a
2019 February 25
SK
Можно просто посмотреть в правилах нормализации по далласу, в PTKB, там видно что конкретно оно ждёт на вход)
К
ну вот я копаю в эту сторону со стороны поддержки Dallas Lock, потому что какая-то настройка syslog, судя по документации, там имеется, только вот ничего не шлет. мне больше интересно была ли эта возможность рассмотрена при написании профилей для Dallas Lock на стороне PT
а у них появился суппорт? я, правда, давно внедрял эту весч... но тогда суппорт не мог сказать, что как восстановить рабоспосоность, если диск на центральном сервере отъехал и есть резервная копия.
IY
Можно просто посмотреть в правилах нормализации по далласу, в PTKB, там видно что конкретно оно ждёт на вход)
перечитайте сообщения, пожалуйста.
вопрос не в том, что ждет на вход PT, а почему он ждет только ODBC, хотя там ещё как минимум 2 способа забрать есть и БД это не способ хранения логов Dallas Lock по умолчанию
вопрос не в том, что ждет на вход PT, а почему он ждет только ODBC, хотя там ещё как минимум 2 способа забрать есть и БД это не способ хранения логов Dallas Lock по умолчанию
IY
а у них появился суппорт? я, правда, давно внедрял эту весч... но тогда суппорт не мог сказать, что как восстановить рабоспосоность, если диск на центральном сервере отъехал и есть резервная копия.
заказчик говорит что есть, он и общается
К
перечитайте сообщения, пожалуйста.
вопрос не в том, что ждет на вход PT, а почему он ждет только ODBC, хотя там ещё как минимум 2 способа забрать есть и БД это не способ хранения логов Dallas Lock по умолчанию
вопрос не в том, что ждет на вход PT, а почему он ждет только ODBC, хотя там ещё как минимум 2 способа забрать есть и БД это не способ хранения логов Dallas Lock по умолчанию
думаю, это лучше закинуть тикетом в саппорт. не исключено, что ждет только одбц, потому что в рамках внедрений позитив сталкивался только с таким способом ведения логов
IY
думаю, это лучше закинуть тикетом в саппорт. не исключено, что ждет только одбц, потому что в рамках внедрений позитив сталкивался только с таким способом ведения логов
да сделал уже, ждет ODBC, другие способы сбора не планируются
К
тогда только самим разрабатывать формулы нормализации и закидывать позитив тряпками...
К
то есть, извините, подготовленными формулами и инструкциями по настройке источника
IY
я хочу знать не теряю ли я время на выяснение этих нюансов, может быть дейстивительно больше никак не собрать. тогда я твердо заказчику скажу или ставьте БД или не будет логов, а так он только меня тряпками закидывает
AP
Не, ну почему. Если Даллас может сислог, то теоретически можно впихнуть. Только руками много работать придется.
К
да и из файлов можно, только директорию с файлами расшарить придется
IY
Andrei Potseluev
Не, ну почему. Если Даллас может сислог, то теоретически можно впихнуть. Только руками много работать придется.
было бы круто если бы мог, я поэтому сюда и написал, может кто-то делал
IY
но, видимо, нет
NA
Вы не пробовали в Конфидент обращаться?
IY
Вы не пробовали в Конфидент обращаться?
пробовал, жду ответа
NK
при инсталляции mp core вот такая ошибка, с чем это может быть связано?
NK
NA
пробовал, жду ответа
Спросил потому, что DL внедрял уже года 4 назад, не помню уже как локальные логи хранятся. У кого-то из вендоров локальные логи были пошифрованы. Могу путать с Secret Net.
IY
ID:793544149
неподдерживаемая клиентская ОС, соответственно отсутствие какого-то компонента Windows?