Каталог решений - Анализ полного технологического журнала, 100ГБ+

Анализ полного технологического журнала, 100ГБ+

Анализ полного технологического журнала, 100ГБ+

В наличии

В этой статье рассматривается анализ полного технологического журнала, размер которого за 1 час достигает 50Гб+.
Когда у какого-то пользователя что-то происходит, но не постоянно, и выделить определенного пользователя не получается, и проще собрать полный технологический журнал.
Но на дальнейшем анализе доступные визуальные средства не выдерживают таких объемов, и просмотр журнала объемом 50Гб попросту вылетает.
Но поведение 1С все же хотелось бы изучить и проанализировать, что происходит.

Категория:

Описание

Я не буду рассматривать в этой статье, как запускать скрипт на BASH. На это есть куча других статей в интернете.

Анализом технологического журнала занимаюсь давно. И проанализировать DBMSSQL события, которые длятся свыше 1 секунды, не составляет труда. Логи занимают 1.5Гб места за сутки, загрузили в Инструменты разработчика и проанализировали узкие места.

Сделали рассылку топ-10 событий на почту, аномалии оптимизировали.

Все хорошо? Вроде, да!

Но иногда возникали проблемы, понимаешь, что все "долго" оптимизировано по максимуму, а у пользователей проблемы. Значит, есть события, которые выполняются меньше 1 секунды, или еще куча вариантов.

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

Хочется включить полный технологический журнал и по нему посмотреть, что происходит. Смотрим, что он занимает 130ГБ.

Загрузка 5ГБ логов может занимать несколько часов, а уж о 130ГБ нет и речи. Такой объем визуальные инструменты не загрузят в принципе.

И я перед собой поставил задачу:

  • отбирать события в технологическом журнале по определенным критериям отбора;
  • за определенное время (не только час, но и до секунды);
  • оставить их ровно в той же иерархии, как 1С пишет;
  • оставить только те файлы, в которых остались события по отбору;
  • чтобы можно было загрузить файлы теми же визуальными средствами.

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

В итоге получился вот такой скрипт на BASH (на момент написания статьи максимально оптимизированный):

  #!/bin/bash
  #$1 mindatetime
  #$2 maxdatetime
  #$3 log catalog, result filter
  #$4 any filter condition
  maincat="/d/UPP/logz_filtr$3"
  rm -r ${maincat}
  mkdir -p $maincat
  
  mindatetime=$(echo $1"000000000000" | cut -c1-12)
  maxdatetime=$(echo $2"999999999999" | cut -c1-12)
  mindatehour=$(echo $mindatetime | cut -c1-8)
  maxdatehour=$(echo $maxdatetime | cut -c1-8)
  
  
  for file in $(find //server-name/logz_all/all/rphost_*/*.log -type f); do
    file_datehour_ext=${file##*/}
    file_datehour=${file_datehour_ext%.*}
    dir_m1=${file%/*}
    rphostname=${dir_m1##*/}
    dirname="${maincat}/${rphostname}"
    fullfilename="${dirname}/${file_datehour}.log"
    echo "current ${file}"
    if [[ ($file_datehour -le  $maxdatehour) && ($file_datehour -ge $mindatehour) ]] ; then
  	  mkdir -p $dirname
  	  cat $file |
  	  perl -pe 's/\xef\xbb\xbf//g'|
  	  awk -vORS= '{if(substr($0, 3, 1)==":" && substr($0, 6, 1)==".") print "\n" $0; else print "<line>" $0;}'|
  	  #без времени выполнения
  	  awk -v mindatetime=$mindatetime -v maxdatetime=$maxdatetime -v file_datehour=$file_datehour '{fulldatetime=file_datehour substr($0, 1, 2) substr($0, 4, 2); if (fulldatetime >= mindatetime && fulldatetime <= maxdatetime) print $0;}' 2>/dev/null|
  	  grep -P "$4"|
  	  perl -pe 's/<line>/\n/g' > "${fullfilename}"
  	  numbstr=$(wc -l $fullfilename | awk '{ print $1 }')
  	  echo "fullfilename=${fullfilename}, numbstr=${numbstr}"
  	  if [[ $numbstr -lt 1 ]] ; then
  	   rm -rf $fullfilename
  	  fi
  	  find $dirname -type d -empty -delete
    fi
  done
  

Если запускать скрипт через файл, можно указывать входные параметры, и поменьше дергать сам текст скрипта

Параметры:

  1. минимальная дата + время, за которое отбирать события
  2. максимальная дата + время, за которое отбирать события
  3. каталог, в который будем выкладывать результат
  4. отбор событий, которые мы хотим отфильтровать и получить результат

Пример запуска данного скрипта по пользователю:

  time bash main.sh 210317190500 210317191500 _Пользователь Usr=Пользователь

Пример запуска данного скрипта по номеру соединения:

  time bash main.sh 210317190500 210317191500 _123 ,SessionID=123,

Что необходимо поправить в скрипте:

  • основной результирующий каталог, в который можно складывать результат и вместе с 3им параметров выкладывать в разные папки:
  maincat="/d/UPP/logz_filtr$3"
  • сетевой каталог, из которого считываем логи (можно указывать и локальный путь, если логи скопировали, или запустить на самом сервере 1с, но не рекомендую, идет нагрузка на процессор):
  for file in $(find //server-name/logz_all/all/rphost_*/*.log -type f); do
  

Таким образом анализ технологического журнала с одного сервера анализируется без корректировок файла.

has been added to your cart:
Оформление заказа