BigData LogManager для 1С

#126

Дык всегда можно переключиться в старый формат. В чем проблема?

1 Симпатия
#127

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

#128

В каком плане тупит? Старый вариант же как раз лучше работает по скорости записи.

#129

При чтении из него и поиске

#130

Новый тупит не меньше, при достаточном объеме.

#131

Вот поэтому и отрезаем выгруженные куски к чертям - они всё равно уже в ES.

#132

Добрый день!
Дошли руки до сбора логов, поставили graylog.
Решил сначала собрать записи ЖР из текстовых файлов через filebeat в graylog.
Пока смотрятся только файлы данных *.lgp с такими настройками в yml

 multiline.pattern: '^{\d{14}.+$'
 multiline.negate: true

События прилетают, но ни пользователя, ни метаданных, ни других полезных вещей не видно.

Как лучше сделать загрузку с определением значений массивов в 1Cv8.lgf? Pipeline видимо надо какой-то использовать, как его описать?
Может кто-нибудь поделиться наработками?
Спасибо

#133
#134

А там поддерживаются человекочитаемые имена метаданных и пользователи?

#135

Да, поддерживает вроде, вот его статья на ИС https://infostart.ru/public/182820/
Формат логов в старом формате описан, например, тут: https://infostart.ru/public/182061/
по сути эта его программа разбирает логи и кладет в mssql.
а мне хотелось бы реализовать разбор ми отправку на filebeat без дополнительных шлюзов.

мне очень понравилась идея “Старый журнал + filebeat -> es”

#136

Тут надо свой beat написать. Для разработки битов есть шаблон.
Я даже в какой-то момент начал эту задачу, но оно пока настолько концепт, что не публикую )

#137

Она не обязательно кладет в MSSQL, она умеет сразу в эластик отправлять

#138

Я не помню указывали или нет - пусть будет тут

#139

Только это ТЖ, но пусть будет тут

#140

У меня такая схема вышла: 1С ЖР => файлы, разбитые по дням => logstash => elasticsearch

Logstash’ем собираю ЖР из файлов с логами(lgp), фильтрую и загружаю в Elasticsearch, поиск и графики через Kibana. Из файла lgf составляю маппинг и отдаю его логсташу, чтобы была возможность видеть не только непонятные IDшники, но ещё и “human-readable” данные.
Сырых данных ЖР > 1ТБ. В эластике занимают места процентов на 20% меньше, благодаря сжатию.
Могу поделиться наработками, если кому интересно.

#141

Мне было бы очень интересно, особенно про маппинг

#142

А собственно файлы lgf каким образом парсятся?

#143

ktb
alex

Конфиги логстеша: https://github.com/ggerogery/logstash-1c-security-logs

А собственно файлы lgf каким образом парсятся?

“В лоб”, скриптом на баше, который в репе лежит - lgp-to-yml.sh. Он по крону парсит lgf в формат словарей для logstash’а(“KEY”: “VALUE”). Потом, главное, правильно расставить интервалы, чтобы за секунду до получения событий логстешем словари были обновлены. Рабочий конфиг логстеша - logstash/conf.d/raw_files_1.conf. Там есть фильтры translate:

translate {
field => “[UserId]”
destination => “[User]”
dictionary_path => “/etc/logstash/conf.d/custom_mapping_1C/DB_NAME_UserId.yml”
refresh_interval => 104
fallback => “Nothing to match!”
}

в этом примере он будет смотреть в поле UserId, увидит там, например, запись 1984, в словаре DB_NAME_UserId.yml посмотрит, что 1984 - это Петров_А_А, которого и поместит в User

raw_files_1.conf - там описан пайплайн, который смотрит в диру с сырыми логами конкретной БД 1С, каждое отдельное событие склеивает в одну строку(codec multiline) и прогоняет через все фильтры(mutate’ты -> grok -> translate), готовый результат складывает в эластик. Логи 1С неоднородные слишком, у меня вышло 6 разных GROK паттернов, которые покрывают все логи.

6 Симпатий
#144

Попробовал. Тестовая база разобралась хорошо, а рабочая нет. Все таки паттерны grok не подойдут под то что 1С сделала - у меня вылезло что в данных {P, {6 к примеру дополнительно 197 объектных полей. Предварительно получается неплохо, если я перед logstash файл прогоняю через рег-выражения, для приведения pattern.

#145

Добрый день!

Пытаюсь получить наименование файла логов ТЖ 1с, но ничего не выходит. За пример взял часть кода из вашего сообщения:

{
"grok": {
  "field": "source",
  "patterns": [
    "%{NUMBER:tempyymmddhh}.log"
  ]
}
}

в логах выдает ошибку:
(status=400): {“type”:“illegal_argument_exception”,“reason”:“field [source] not present as part of path [source]”}

Без данного куска, все работает и разбирается

полный pipeline

{
 "description" : "onec tj pipeline",
 "processors": [
    {
      "grok": {
        "field": "message",
        "patterns": ["%{NUMBER:num_min}:%{BASE10NUM:num_sec}-%{NUMBER:duration},%{WORD:event1c},%{NUMBER:level}"]
      }
    },  
    {
        "grok": {
          "field": "message",
          "patterns": [
            "process=%{WORD:process1c}"
          ],
          "on_failure": [
            {
              "set": {
                "field": "process1c",
                "value": ""
              }
            }
          ]
        }
    },  
    {
	    "grok": {
	      "field": "message",
	      "patterns": [
	        "Usr=%{WORD:usr}"
	      ],
	      "on_failure": [
	        {
	          "set": {
	            "field": "usr",
	            "value": ""
	          }
	        }
	      ]
	    }
    },  
    {
        "grok": {
          "field": "message",
          "patterns": [
            "Context=%{WORD:context}"
          ],
          "on_failure": [
            {
              "set": {
                "field": "context",
                "value": ""
              }
            }
          ]
        }
    },
	{
	"grok": {
	  "field": "source",
	  "patterns": [
	    "%{NUMBER:tempyymmddhh}.log"
	  ]
	}
	}
  ]
}

Подскажите пожалуйста в чем может быть проблема?

Заранее благодарен!