Лог — это информационный след, оставленный после выполнения какого-либо действия. С его помощью не только находят ошибки, но и анализируют скорость обработки, нагрузку, объем информации и многое другое. Хотя само действие может быть невидимым, следы от него появляются в логах.
В серверных и настольных редакциях платформы Loginom, логи — это хронологическая последовательность записей, фиксирующих время и наиболее значимые события.
Просматривая логи, можно анализировать следы, которые оставили те или иные действия. Каждое событие оставляет свой отпечаток. И если действовать как опытный охотник, можно узнать много интересного: кто где ночует, кто какими тропами ходит, кто где часто бывает. О некоторых событиях можно узнать только по следам.
Чтобы начать эффективно работать с логами, нужно знать: какие задачи они решают и когда без них нельзя, формат записи логов и где находится файл с ними, правила перезаписи и как выбрать уровень логирования. Также надо понимать, как организовать работу с ними на локальном компьютере и при коллективной работе.
Разработчики, используя лог-файлы, устраняют ошибки в программном обеспечении, администраторы выясняют причины отказов в работе, служба безопасности определяет виды угроз. Для непривилегированных пользователей эта информация, как правило, избыточна и для основной работы не нужна.
В основном логи в Loginom нужны для выполнения четырех типов задач: отладка, профилирование, мониторинг и обеспечение безопасности.
Когда что-то не сработало, нужно понимать, что именно произошло и как исправить. Сценарий подобен сложному механизму. Логи — это индикаторы на каждом его узле. Если что-то не работает, логи указывают, где именно произошел сбой. Это позволяет быстро выявить причину (проблема с базой данных, нехватка памяти, ошибка в коде и т.д.) и устранить ее.
Профилирование — это процесс анализа скорости выполнения различных задач. Запускается программа, и требуется выяснить, какие сценарии выполняются быстро, а какие медленно. Часто сценарии зависят друг от друга.
Это особенно актуально при работе с большими объемами данных. Неправильная настройка может привести к тому, что вычисления будут занимать несколько суток. Для оценки производительности важно фиксировать и анализировать время начала и завершения выполнения задач.
Мониторинг представляет собой процесс наблюдения за работой системы. Чаще всего включает сбор данных и их анализ, чтобы выявить проблемы и улучшить ситуацию.
Представим, что существует система поддержки принятия решений (СППР), которая функционирует непрерывно. Может возникнуть ситуация, когда она перестает работать с приемлемым временем отклика. Логи помогают разобраться в чем проблема: на стороне системы поддержки или к ней перестали обращаться. Например, СППР может работать штатно, а у смежной системы что-то сломалось. Или, наоборот, резко увеличилось количество обращений и платформа перестала справляться. Логи помогают понять — это спам, атака, неполадки в работе оборудования или что-то другое.
Обработка данных похожа на конвейерное производство, где используются датчики для мониторинга и выявления сбоев на различных этапах. В аналитической платформе реализован аналогичный подход: тот же конвейер, только он берет данные и прогоняет их через узлы. А логи, как датчики, позволяют наблюдать за самим процессом.
Кто-то может получить доступ к списку клиентов и продать его, отправить конфиденциальную информацию конкуренту или выложить в общий доступ. Такие действия надо предотвращать вне зависимости от того, были ли осознанными или выполнены по незнанию.
Логи позволяют отслеживать аутентификацию в системе, изменение учетных данных, операции по передаче данных, такие как загрузка и выгрузка файлов и тому подобное. Таким образом логи используют для контроля безопасности.
В Loginom каждая строка лог-файла представляет собой сообщение в формате:
yyyy-mm-ddThh:mm:ss.mss level GUID (process:thread>user:session:[requestID]) — message[textJSON]Пример записи логов в Loginom:
2024-10-23T15:56:19.242 info 64b508f609b0804e883887780de60675 (loginom.exe:12560>User1:1) - Сохранен пакет "C:/Users/User1/Documents/Package2.lgp"{"PACKAGE_FILE": "C:/Users/User1/Documents/Package2.lgp"}Данный формат записи в лог понятен, прост и дает возможность преобразовывать полученную информацию с помощью скриптов (выполнять парсинг).
После парсинга данные из логов можно заносить в базы данных, обрабатывать, показывать, считывать нужные показатели, метрики и т.д. Например, можно посчитать количество ошибок, сколько пользователей запустило определенный сценарий, какое время уходило на его выполнение и т.д.
По умолчанию для серверной редакции (Windows) логи записываются в файл app.log папки:
C:\ProgramData\Loginom\Server\LogsДля Desktop редакции (Windows) по умолчанию в файл app.log папки:
C:\Users\User\AppData\Roaming\Loginom\Personal\LogsДля любой операционной системы, как Windows, так и Linux, есть возможность записать логи в файл (Тип логирования: Файл).
Помимо работы с файлами, для операционной системы Linux существует еще один вариант работы с логами — это стандартный компонент Systemd с названием Journald, обеспечивающий централизованный способ управления и доступа к записям логов.
Journald популярен благодаря своей важной роли в управлении системными журналами для Linux и активно применяется. Для более полного понимания всех возможностей, функций и тонкостей этой системы ведения логов, стоит уделить данному вопросу отдельное внимание и изучить его более подробно.
При неудачном запуске сценария или отдельного узла в Loginom выводится сообщение об ошибке. Это способ отладки при интерактивной работе с платформой. Он помогает не во всех случаях. Как правило, нельзя обойтись без логов в процессах без визуального интерфейса и при коллективной работе.
Логи часто используются, когда что-то работает не визуально. Многие расчеты выполняются в фоновом режиме, где нет интерфейса, и даже технически увидеть происходящее невозможно. В этом случае логи становятся единственным источником информации о том, что произошло.
Во многих крупных компаниях ночные графики работы полностью расписаны. В нерабочее время выполняются ETL-процессы, резервное копирование, подготовка данных, автоматическое формирование отчетов. Каждую ночь информация загружается из различных баз, обрабатывается и выгружается в другие базы.
С помощью логов можно понять, что произошло за ночь. Не видно само действие, но зафиксирован его информационный след.
Логи также критично важны, как только речь идет о коллективной работе. Выполнение задач одного пользователя может помешать работе других или наоборот. Каждый пользователь видит только часть системы, свое окно, в то время как параллельно работают коллеги, а это огромное количество других процессов.
Одновременно могут запускаться фоновые процессы, ETL-процессы, обращения к веб-сервису и многое другое. И чаще всего пользователь не может на эти процессы влиять, у него, из соображений безопасности, нет даже доступа к этой информации.
Ему недоступна вся картина. Поэтому фактически единственный способ проанализировать все эти процессы — это посмотреть на их следы, то есть на логи.
Логи записываются в файл, но на самом деле они, чаще всего, перезаписываются. Накопление их не всегда предсказуемо (был один запуск программы или пришлось запускать ее сто раз) и через какое-то время их размер становится значительным, занимая большой объем дискового пространства. Чтобы разрастание не стало стихийным, при достижении какого-то лимита, старые лог-файлы удаляются и на их место записываются новые.
Правила перезаписи логов в Loginom регулируются двумя параметрами: максимальным размером и количеством резервных лог-файлов.
Максимальный размер лог-файла задается в байтах.
При превышении данного размера, файл сохраняется с расширением .1 и создается новый. Например, старый файл app.log при превышении указанного размера сохранится как app.log.1, а взамен ему будет создан новый app.log, где и продолжится ведение журнала.
Количество резервных копий, создаваемых при превышении максимального размера лог-файла, задается положительным целым числом.
При превышении размера файла и создании нового файла логирования, старый файл получает расширение .1, со сдвигом старых сохраненных файлов на +1: .2, .3, ..., .<максимальный индекс>, старый резервный файл app.log.1 станет app.log.2, а если на момент добавления резервного файла уже был достигнут лимит, то самый старый файл лога удаляется.
При значении количества резервных копий < 1 старые файлы логов не сохраняются.
У логов в Loginom есть различная детализация. Уровень логирования — параметр, который позволяет настраивать какие события будут записываться в лог-файл. Самый компактный вариант — Авария, когда записываются только ошибки, приводящие к выходу сервера из строя. Самый детализированный — Трассировка. При этом в лог записывается максимальное количество информации.
Однако за все приходится платить. С увеличением уровня логирования растет не только детализация, но и занимаемая память. К тому же работа с журналом событий отнимает определенное время, которое уходит на запись в файл. Поэтому надо подбирать уровень логирования, который будет адекватен решаемой задаче.
По умолчанию установлен уровень Информация.
Этого уровня достаточно для простого пользования платформой. Когда нужно провести профилирование, понять, на каком узле теряется скорость, или для отладки процесса, задается максимальный уровень — Трассировка.
| Уровень логирования | Входящие уровни |
|---|---|
| Трассировка | Авария, Ошибка, Предупреждение, Событие, Информация, Отладка, Трассировка |
| Отладка | Авария, Ошибка, Предупреждение, Событие, Информация, Отладка |
| Информация | Авария, Ошибка, Предупреждение, Событие, Информация |
| Событие | Авария, Ошибка, Предупреждение, Событие |
| Предупреждение | Авария, Ошибка, Предупреждение |
| Ошибка | Авария, Ошибка |
| Авария | Авария |
Описание уровней логирования:
| Уровень логирования | Выводимые команды |
|---|---|
| Авария | Выводит ошибки, приводящие к выходу сервера из строя |
| Ошибка | Все ошибки попадают в лог, за исключением частых ошибок (например, ошибки преобразования типа в Калькуляторе) |
| Предупреждение | Предупреждения о проблемах в конфигурации (возникают при загрузке или копировании/вставке узлов), о несуществующих или лишних колонках при синхронизации колонок, об ошибках в Калькуляторе. Ошибки, которые предоставляют информацию о возникновении непредвиденного события. Сообщение о неудавшейся попытке подключения пользователем. |
| Событие | Открытие, закрытие и сохранение пакета. Установка версии Пакета. Конвертация Пакета старой версии. |
| Информация | Открытие (закрытие) сессий пользователя. Действия с сессиями и Пакетами (закрытие Пакетов и сессий) из менеджера сессий. Действия с сессиями и Пакетами (закрытие Пакетов и сессий) из менеджера сессий. Изменение пользователя (добавление, удаление, перемещение в группы) через администратора. Добавление (удаление) общих папок. Сообщения от менеджера памяти. Ошибки при обновлении колонок в визуализаторах «Таблица» и «Статистика». |
| Отладка | Активация (деактивация) узлов. Ошибки преобразования типов для переменных типов в Калькуляторе |
| Трассировка | Логируются все операции, например, подбор модели при обучении узла ARIMAX |
Если работа проходит на локальной машине, чаще всего есть доступ ко всем папкам и можно посмотреть логи. Таким образом эта информация доступна, даже если и не нужна для основной работы пользователя.
При коллективной работе логи всех пользователей сохраняются в одни и те же файлы. Они находятся вне зоны доступа обычного пользователя по умолчанию, т.е. не в том месте, где хранятся сценарии.
Это связано с тем, что в общих логах содержится информация по всем пользователям: какие сценарии запускались, данные скачивались, кто входил на платформу и прочее. Поэтому, чтобы исключить риски для безопасности, доступ к логам должен быть ограничен пределами области основной работы. Для непривилегированного пользователя информация об общих логах скрыта по трем причинам: во-первых, она является ему не нужной, во-вторых, избыточной (в потоке логов трудно искать нужные), в-третьих, это подрывает защищенность и нарушает сохранность данных.
В серверной редакции логи пишутся в один общий файл не потому, что их нельзя поделить. Это можно реализовать, но для анализа ситуации обязательно оценивать всю картину целиком. На одном сервере запускается много сценариев и может произойти сбой не потому, что пользователь что-то сделал неправильно, а из-за параллельных процессов, например кем-то будет запущена выгрузка огромного объема данных.
И эти процессы бесполезно анализировать на уровне отдельного пользователя. Когда работает много людей, требуется видеть всю картину, нужно как бы подняться над ними.
Фиксируя ключевые события, логи позволяют решать задачи отладки, профилирования, мониторинга и обеспечения безопасности. Когда у процесса нет визуального интерфейса и при коллективной работе они критически важны для анализа работы системы.
В платформе Loginom логи по умолчанию записываются в файл app.log и для дальнейшей обработки их можно парсить. В операционной системе Linux есть возможность использовать Journald, но в этом случае потребуется работа администратора, так как этот компонент Systemd нужно настраивать.
Уровни логирования в Loginom предоставляют возможность выбирать детализацию в зависимости от конкретной задачи. Это важно для того, чтобы не перегружать систему и избежать записи излишних данных.
В условиях коллективной работы все логи складываются в «одну кучу». При этом доступ к ним должен быть ограничен, чтобы обеспечить безопасность чувствительной информации и защиту данных.
Логирование в Loginom — это не просто хронологические записи событий, а важный процесс, который помогает понять, что происходит в системе и как оптимизировать ее работу. Каждый лог является следом, оставленным действиями на сервере. Умение анализировать эти данные обеспечивает возможность оперативно реагировать на возникающие проблемы.
Другие материалы по теме:
