сплит журнал применения многопоточного

Question

У меня есть многопоточное приложение, которое генерирует журналы, как упоминалось:

D Fri Feb 01 00:21:23 2013 <no machine> pin_deferred_act:10233 pin_mta_conf.c:636 1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:1:0:1359658283:1 
      pin_mta_convert_cmdline_options_to_flist parameters flist 

    D Fri Feb 01 00:21:23 2013 App-BRM-Prod-Pri.acttv.in pin_deferred_act:10233 pcpst.c(78):406 1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:2:0:1359658283:0 
      connect to host=172.16.87.14, port=11962 OK 
    D Fri Feb 01 00:21:24 2013 App-BRM-Prod-Pri.acttv.in pin_deferred_act:10233 pin_mta.c:2479 1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:1:0:1359658283:0 
      Config object search input flist 
    0 PIN_FLD_POID   POID [0] 0.0.0.1 /search/pin -1 0 
    0 PIN_FLD_FLAGS   INT [0] 0 
    0 PIN_FLD_TEMPLATE  STR [0] "select X from /config/mta where F1 = V1 " 
    0 PIN_FLD_ARGS   ARRAY [1] allocated 20, used 1 
    1  PIN_FLD_CONFIG_MTA ARRAY [0] allocated 20, used 1 
    2   PIN_FLD_NAME   STR [0] "pin_deferred_act" 
    0 PIN_FLD_RESULTS  ARRAY [0] allocated 20, used 1 
    1  PIN_FLD_POID   POID [0] NULL poid pointer 
    D Fri Feb 01 00:21:24 2013 App-BRM-Prod-Pri.acttv.in pin_deferred_act:10233 pin_mta.c:2484 1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:3:7:1359658284:2 
      Config object search output flist 
    0 PIN_FLD_POID   POID [0] 0.0.0.1 /search/pin -1 0 
    D Fri Feb 01 00:21:24 2013 App-BRM-Prod-Pri.acttv.in pin_deferred_act:10233 pin_mta.c:3138 1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:1:7:1359658284:2 

Так нити обновления журналов, как pin_deferred_act: 10233: 1: 7 - > где 1 задает журнал из первого потока в файле журнала.

Я хочу, чтобы создать файл журнал для каждого потока, где начальная точка должна быть:

1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:1: 

и конечная точка должна быть:

D Fri Feb 01 00:21:24 2013 App-BRM-Prod-Pri.acttv.in 

(где дата/метка время будет продолжать модифицирование). Все экземпляры должны быть в одном файле.

Для .: например

D Fri Feb 01 00:21:23 2013 <no machine> pin_deferred_act:10233 pin_mta_conf.c:636 1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:1:0:1359658283:1 
      pin_mta_convert_cmdline_options_to_flist parameters flist 
    D Fri Feb 01 00:21:23 2013 App-BRM-Prod-Pri.acttv.in pin_deferred_act:10233 pcpst.c(78):406 1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:2:0:1359658283:0 
      connect to host=172.16.87.14, port=11962 OK 
    D Fri Feb 01 00:21:24 2013 App-BRM-Prod-Pri.acttv.in pin_deferred_act:10233 pin_mta.c:2479 1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:1:0:1359658283:0 
      Config object search input flist 
    0 PIN_FLD_POID   POID [0] 0.0.0.1 /search/pin -1 0 
    0 PIN_FLD_FLAGS   INT [0] 0 
    0 PIN_FLD_TEMPLATE  STR [0] "select X from /config/mta where F1 = V1 " 
    0 PIN_FLD_ARGS   ARRAY [1] allocated 20, used 1 
    1  PIN_FLD_CONFIG_MTA ARRAY [0] allocated 20, used 1 
    2   PIN_FLD_NAME   STR [0] "pin_deferred_act" 
    0 PIN_FLD_RESULTS  ARRAY [0] allocated 20, used 1 
    1  PIN_FLD_POID   POID [0] NULL poid pointer 
    D Fri Feb 01 00:21:24 2013 App-BRM-Prod-Pri.acttv.in pin_deferred_act:10233 pin_mta.c:3138 1:App-BRM-Prod-Pri.acttv.in:pin_deferred_act:10233:1:7:1359658284:2 

должен перейти в один файл - Thread1.log, а так же для других потоков, файл должен быть создан как Threadn.log с соответственно.

Answer 1

Файлы представляют собой беспорядочный, немасштабируемый способ обработки журналов для начала. Лучше всего обрабатывать журналы как потоки сообщений входа в журнал, связанных с источниками (источниками) -> приемником (-ами). Рассмотрим syslog, logplex или аналогичный, если Oracle предоставляет альтернативные средства сбора данных. Пользовательская перепродажа может быть осуществимой в зависимости от того, какие узкие места IOPS регистрируются или другие факторы.

Рекомендуется использовать монотонные часы с высоким разрешением и/или глобально-ориентированные временные метки GUID. При использовании настенного времени обязательно используйте UTC с обратной компенсацией, синхронизированный с источниками времени с низким уровнем страты.

Выше рекомендации могут варьироваться в зависимости от потребностей применения, конечно, поэтому экспериментируйте и применяйте разумно.

Answer 2

Я думаю, что совет Барри полезно, но в том случае, если вы не можете изменить выход журнала приложения, здесь быстрое решение Perl:

#!usr/bin/perl 
use strict; 
use warnings; 

my %logs; 
my $last_log; 
while (<$main_log_file>) #open that application's log in this variable. 
{ 
    if (/pin_deferred_act:\d+:(\d+):\d/) 
    { 
     unless (defined $logs{$1}) 
     { 
      open $fh,'>',"Thread$1.log") or die "Can't open Thread $1 log: $!"; 
      $logs{$1} = $fh; 
     } 

     $last_log = $logs{$1}; 
    } 

    if (defined $last_log) 
    { 
     print {$last_log} $_; 
    } 
    else 
    { 
     #Didn't find starting line. Error handling?  
    } 
} 

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