Сервер BNComplex хранит логи работы в текстовых файлах. Более того, так как серверная часть выполнена в виде служб, то это практически единственный способ  Обычно, для записи логов используется специальная служба "BN Logger Service". Служа создает тектовые файлы в соотвествии с ее настройками, производимыми в ini файле (см. идущую в составе документацию).  Текстовые файлы достаточно информативны, содержат много информации, посему просмотр оных может дать много пищи для размышления.

Периодически приходится просмотривать эти логи (журналы работы) оставленные программой BNComplex - при чем, данные файлы могут насчитывать многие и многие Мб, и просматривать их вручную (Блокнотом) крайне не удобно, особенно когда знаешь что именно тебе нужно найти.

В таких ситуациях незаменимыми становятся утилиты текстового поиска в файлах, которые позволяют по заданной маске найди строку

Первое что нам потребуется это findstr, входящая в комплект поставки Windows server (да и не только)

Достоинства: оно уже есть в составе windows, проста в использовании, не требует лицензии (входит в комплект Windows)

Недостатки:

Бедность поиска	Из-за использования ограниченного набора шаблонов для регулярных выражений поиск сложных конструкций крайне сложно выполним.
Медлительность	Относительно медленная работа, по сравнению с другими утилитами
ограниченность вывода	выводит только искомую строку, а часто нужны строки выше или ниже искомой.

Именно бедность поиска и ограниченность вывода толкнули на поиск замены для данного средства. В качестве алтернативы была выбрана один из клонов grep

Достоинства: использование сложных регулярных выражений для поиска, бесплатность лицензии, быстрый поиск, широкие возможности коммандной строки, расширенный вывод найденного.

Недостатки:

Отсуствие руссификации

Инструкция только на английском, однако в интернете достаточно описаний по использованию ПО

И так, выбор упал на Grep как "Must have", если мы хотим быстро просматривать логи на предмет поиска в них заранее определенных строк.

Это важно! Большинство приводимых примеров поиска будет ориентированно именно на использование вышеуказанной утилиты.

Выводы:

Для работы используем:

- Блокнот = когда не знаем что ищем, или для просмотра определенного времени в логе

- grep = когда значем что ищем - маску для поиска.

Для примера покажу, как можно сделать выборку для поиска информации об IMSI модема, установленного на навигационном АТ М2М CyberGX (иногда бывает, что номер АТ "сбивается" и на сервер приходит что-то мало вразумительное, однако прибор в прочих выполняет свои функции - определяет свою позицию, передает данные, и узнать что это за прибор - его номер - можно только по номеру INSI. После можно отправить команду изменения номера для АТ, что вернет все на место).

Для этого воспользуемся логами службы TCPGate (а других вариантов и нет...), которая "общается" с АТ, предоставляя "декодированные" данные уже для других служб BNComplex-а

Скрипт выборки таков:

где

• -B3 - ключик означает что кроме искомой нужно еще три строки выше вывести.
• ".*Login request from [[]{1}00160000.*" - шаблон поиска строки логина на сервер АТ с указанным серийным номером. Шаблон указывается в кавычках. Сочетание симолов ".*" обозначает любой символ либое количество раз (см. инструкцию к grep) для отображения квадратных скобок используется указание множества "[[]{1}". Что в "переводе" означает - символ 1 подрад идущий символ "[", после указываются цифры номера АТ. 
• C:\BNComplex\Logs\TCPGate\TCP100911.log - после шаблона указывается имя анализируемого файла, в нашем случае это файл лога службы TCPGate. В качестве имен файлов можно так же использовать общепринятые подстановочные символы: например C:\BNComplex\Logs\TCPGate\TCP1009*.log - все файлы из каталога "C:\BNComplex\Logs\TCPGate\", с именем начинающимся на TCP1009 и далее любые симовлы, с расширением log

• TCPlog_find.txt - весь резльтат вывода записывается в файл 
• start TCPlog_find.txt и после открывается блокнотом

пример возврата

17/01/2011 00:06:29.218 (I) Main: Accepted with thread ID=035C5A30
17/01/2011 00:06:29.218 (I) 035C5A30: Received [AFFF220500001701110006330000000000160000050002509966612927582501DDFA]:2
17/01/2011 00:06:29.218 (I) 035C5A30: IMSI: [0250996661292758]
17/01/2011 00:06:29.218 (I) 035C5A30: Login request from [00160000] ver.293
--
17/01/2011 01:04:35.265 (I) Main: Accepted with thread ID=035D5068
17/01/2011 01:04:35.265 (I) 035D5068: Received [AFFF2205000017011101043900000000001600000500025099666129275825013EFA]:2
17/01/2011 01:04:35.265 (I) 035D5068: IMSI: [0250996661292758]
17/01/2011 01:04:35.265 (I) 035D5068: Login request from [00160000] ver.293

Как видим, IMSI прибора в логах не указан с привязкой к номеру АТ (строка с IMSI не содержит номер АТ), однако, после строки "IMSI" идет строка "Login request from" - ее то мы и ищем, выводя заодно 3 предшествующих строки (3- для запаса, обычно хватает одной для данного случая, однако при большом потоке данных строки лога могут перебиваться данными от разных приборов). Так же из примеры видно, что данный поиск крайне затруднительно выполнить при помощи findstr, так как нам фактически требуется строки выше от искомой, что findstr не позволяет выполнить.

Читайте далее Часть 2 = работа с базой данных комплекса

Читайте так же: BNComplex - настройка пути логирования, форматы строк , BNComplex: Контекстное меню для файлов *.log - быстрый вызов типовых действий