Аудит лицензий FlexLM: логи, пики и реальная потребность

Зачем делать аудит лицензий и что он должен ответить

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

Аудит лицензий FlexLM помогает перейти от ощущений и жалоб «нам постоянно не хватает» к проверяемым ответам по логам. Самый полезный результат здесь не красивый график, а ясное понимание: где дефицит настоящий, а где он создан настройками или привычками.

Обычно бизнес ждет от аудита ответов на практичные вопросы:

• Нужно ли докупать или можно перераспределить и настроить правила выдачи.
• Какие команды и какие модули создают очередь и блокируют других.
• Сколько лицензий нужно в пиковые часы, а сколько - в обычные дни.
• Есть ли сезонность (например, всплески перед сдачей проектов, аудитами, закрытием квартала).

Под «реальной потребностью» важно понимать не среднее потребление, а спрос в моменты, когда простой стоит денег: в 10:00 в понедельник, в конце месяца, в период тендеров или выпуска документации. Среднее может выглядеть комфортно, но именно пики определяют, будут ли очереди на запуск и срывы сроков.

По итогам аудита обычно принимают приземленные решения: докупают только те функции, которые стабильно упираются в пик; переводят часть пользователей на другой тип лицензии (если это допускает вендор); настраивают тайм-ауты и правила возврата; договариваются об «окнах» для тяжелых задач; убирают лишние автозапуски модулей. В крупных организациях (например, в госсекторе или промышленности) такие выводы часто становятся основой политики использования инженерного ПО и понятного бюджета без догадок.

Подготовка: что уточнить до сбора логов

Перед тем как начинать аудит лицензий FlexLM, важно договориться о правилах игры. Иначе логи соберутся, а спор о том, что именно считать, начнется уже на этапе отчета.

Сначала определите владельца процесса. Обычно участвуют ИТ (доступ к серверам и настройкам), инженеры (как реально запускают ПО), закупки (контракты и лимиты), а также безопасность (разрешения на выгрузку и хранение логов). Один человек должен принять финальные решения: какие источники считаем «истиной» и как трактуем исключения.

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

Отдельно зафиксируйте модель лицензирования. Одни продукты работают по concurrent, другие по named user, третьи - через токены или наборы функций. Даже внутри одного вендора встречаются смешанные схемы, где «лицензия» на бумаге равна нескольким функциям в FlexNet Publisher.

Чтобы не упустить детали, заранее согласуйте:

• Какие приложения и модули входят в аудит, и какие версии считаем актуальными.
• Где находятся license server(а) и есть ли резервные или дублирующие.
• Как трактуем удаленную работу: VPN, VDI, терминальные фермы.
• Кто и как подтверждает список функций (по контрактам и файлам лицензий).
• Что считаем «пользователем»: учетную запись, рабочую станцию или команду.

Задайте границы периода анализа. Минимально имеет смысл брать 4-12 недель, чтобы увидеть типичные пики. Если возможна сезонность (учебные проекты, бюджетные циклы, квартальные релизы), лучше 6-12 месяцев. Например, в проектных отделах нагрузка часто растет перед сдачей этапов, и короткий период дает ложную «норму».

FlexLM (FlexNet Publisher): какие логи собирать и где они живут

В FlexLM почти всегда есть два источника событий: процесс менеджера лицензий lmgrd и демон конкретного вендора (vendor daemon). Для аудита важны оба. lmgrd пишет общие события (старт, остановка, ошибки), а vendor daemon фиксирует выдачу и возврат лицензий по функциям и пользователям. Если собрать только один файл, картина будет неполной.

Обычно встречаются три типа логов. Debug log (часто его называют debug.log) - это подробный поток сообщений, где есть строки про выдачу и возврат. Report log - более структурированный журнал для отчетов (если он включен), из него проще считать статистику по периодам. Event log встречается реже и зависит от платформы и настроек сервиса, его удобно использовать как подтверждение перезапусков, сбоев и смены конфигурации.

Для расчета потребности убедитесь, что в логах действительно есть рабочие события. Чаще всего нужны строки:

• OUT или CHECKOUT: кто и когда взял лицензию (функция, пользователь, хост)
• IN или CHECKIN: когда вернул
• DENIED: отказ из-за нехватки лицензий или политики
• QUEUED: постановка в очередь (если у продукта есть очереди)
• сообщения о перезапуске демона: чтобы не принять обрыв сессий за массовый возврат

Перед сбором проверьте время. Если сервер живет в одном часовом поясе, а отчеты строятся в другом, пики легко сдвинутся на час, и вывод о «пиковых» командах окажется неверным. Желательно включить синхронизацию времени (NTP) и явно зафиксировать часовой пояс в отчете.

Путь к файлам задается в настройках службы или демона (в параметрах запуска или конфиге), а не всегда лежит рядом с license.dat. Заранее проверьте ротацию (сколько дней хранится, сжатие, переименование) и соберите «хвосты» старых файлов. Для анализа сезонности нужны месяцы данных, поэтому хранение стоит настроить так, чтобы не терять историю.

Какие данные извлекать из логов: минимум для расчета

Для аудита лицензий FlexLM важно не собрать «все подряд», а получить ровно те поля, по которым можно честно посчитать потребность и увидеть пики. Первое, что стоит проверить: включен ли usage logging, и есть ли в логах события выдачи и возврата лицензий (CHECKOUT и CHECKIN). Если в логе видны только ошибки или общий старт демона, детализации не хватит.

Минимальный набор полей

Если вы выгружаете данные в таблицу или в систему аналитики, на каждую операцию (выдача, возврат, отказ) обычно достаточно пяти-семи колонок:

• время события (в одном часовом поясе, с датой и временем)
• feature (имя функции или пакета лицензии)
• user (логин) и при возможности домен
• host (имя рабочей станции или узла)
• количество (сколько лицензий занято этим событием)

Эти поля дают основу для расчета одновременного потребления: по времени вы строите «сколько занято прямо сейчас», по feature разделяете продукты, по user и host видите потребителей и повторное использование.

Что добавить, чтобы цифры не обманули

Отдельно фиксируйте события ошибок и отказов. Для оценки дефицита важны DENIED (лицензий не хватило), timeout (сеанс «повис» и не вернул лицензию вовремя), invalid hostid (проблемы привязки), а также сообщения о неверном ключе или неподдерживаемой версии.

Пользователей нужно нормализовать. Один и тот же человек может попадать как user, как DOMAIN\user, а иногда как служебная учетка (например, запуск задач на рендере). Заранее решите, кого считать «человеком», а кого - сервисом, иначе аудит покажет завышенный спрос.

Наконец, сохраните данные о самом сервере лицензий: версии lmgrd и vendor daemon, параметры таймаута и borrow, настройки резервирования (RESERVE), список файлов лицензий и их обновлений. Простой пример: если на feature настроен RESERVE 5 для группы, общая «емкость» есть, но для остальных пользователей пик наступит раньше, и это важно учитывать.

Аналоги FlexLM: как переносить подход на другие менеджеры

Если у вас уже выстроен аудит лицензий FlexLM, сам подход легко перенести на другие менеджеры. Почти везде одна и та же логика: лицензия выдана, возвращена, не выдана (нет свободных) либо пользователь попал в ожидание. Меняются названия событий и формат логов.

Sentinel RMS и RLM обычно дают достаточно данных, чтобы посчитать фактическую потребность так же, как и для FlexNet Publisher: кто взял, когда взял, когда вернул и почему не получил. Но иногда часть информации прячется в отдельном отчете админ-консоли или вендорской утилите.

Сопоставьте терминологию один раз

Главная сложность часто не в расчетах, а в переводе слов. То, что в одном месте называется feature, в другом может быть product, module, token, entitlement. Чтобы не спорить каждый раз, заранее сделайте короткий «словарь» и используйте его во всех отчетах.

Обычно достаточно унифицировать:

• объект потребления: feature или продукт, включая редакцию и версию
• события: выдача (checkout), возврат (checkin), отказ (deny), ожидание (queue/wait)
• идентификаторы: пользователь, хост, приложение, проект или команда (если можно восстановить)
• единицу измерения: лицензия, токен, «пулы» по типам, лимиты по группам

На практике это выглядит так: в RLM вы ловите строку выдачи по имени модуля и user@host, а «пик» считаете по параллельным активным сессиям. В Sentinel RMS дополнительно проверяете, не включен ли заем (borrow), иначе сессии в логах будут «длинными» и исказят сезонность.

Когда без отчета вендора не обойтись

Если лицензирование сложное (токены, пакеты, зависимые модули, ограничения по группе AD) или логи не содержат причину отказа, лучше запросить вендорный usage-отчет. Он особенно нужен, когда важно точно объяснить очереди, перерасход по пакетам и реальные лимиты по каждому праву (entitlement).

Очистка и нормализация: чтобы расчеты были честными

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

Сначала договоритесь о единой временной шкале. Сервер лицензий и рабочие станции могут жить в разных часовых поясах или с разным NTP. Практичный вариант - перевести все в UTC и округлять до минут (или до 5 минут, если важна скорость обработки). Такое округление уменьшает шум от коротких переподключений и не портит картину по пикам.

Дальше - имена. В логах встречаются feature name, vendor daemon, а в закупках и переписке - маркетинговые названия. Для аудита нужна таблица соответствий «как в логе» -> «как в договоре». Иначе одна и та же опция разъедется на две строки, а разные версии одной функции сольются.

Зафиксируйте правила нормализации:

• приводите время к одной зоне и округляйте до 1 или 5 минут
• ведите словарь названий: feature/INCREMENT -> коммерческое имя
• определите «сессию»: активна, пока есть CHECKOUT и не было CHECKIN (или сработал тайм-аут, например 30 минут без событий)
• сводите пользователя к одному идентификатору (логин или e-mail), хост оставляйте отдельным полем
• заранее решите, как считать пересечения: один пользователь на двух хостах одновременно - это 2 лицензии или подозрительное поведение

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

Удобное правило: помечайте такие записи флагами (test/edu/service) и считайте метрики в двух вариантах - «как есть» и «без исключений». Например, ночные checkout от сервисного аккаунта могут создавать «пиковые» команды на графике, хотя реальная загрузка днем совсем другая.

Какие метрики считать, чтобы увидеть реальную потребность

Чтобы аудит лицензий FlexLM дал полезный ответ, важно смотреть не на одну цифру, а на набор метрик. Одна и та же «занятость» может означать как нормальную работу, так и постоянные очереди и отказы.

Начните с базового разреза: по feature (конкретная лицензируемая функция) и по продукту (если несколько features относятся к одному пакету). Средняя занятость быстро показывает «фон», но почти всегда обманывает. Поэтому рядом держите медиану: она лучше описывает типичный день без редких всплесков.

Дальше нужен peak concurrent - максимум одновременного использования. Считайте его отдельно по дням, неделям и месяцам: дневной пик важен для поддержки работы «здесь и сейчас», а недельный и месячный показывают, насколько пик устойчивый.

Абсолютный пик иногда бывает разовым (например, после релиза проекта все одновременно запустили CAD на 20 минут). В таких случаях полезнее 95-й перцентиль по одновременной занятости: он отражает «почти худший» сценарий, но без одиночных выбросов.

Чтобы увидеть спрос против предложения, добавьте метрики давления на лимит:

• доля DENIED по feature и по часу (как часто людям реально не хватало)
• QUEUED и среднее время ожидания (если очередь включена)
• топ групп и пользователей по DENIED/QUEUED (кто упирается чаще)
• часы дня с максимальной долей отказов
• разница между пиком использования и пиком отказов (они не всегда совпадают)

Пример: в отделе из 40 инженеров медиана по feature всего 6, а дневной пик 18. Если DENIED почти нет, покупать 18 лицензий может быть лишним. Но если в 10:00-12:00 каждый день растут DENIED у одной команды, проблема не в «средней занятости», а в конкретном окне и группе.

Пошаговый разбор: как посчитать потребность по логам

Расчет реальной потребности начинается не с графиков, а с «чистого» набора событий. В аудит стоит брать период, который включает обычные недели и хотя бы один напряженный этап (сдача проекта, закрытие месяца, сессия в вузе).

Сначала проверьте полноту: есть ли логи за все дни, не менялась ли версия сервера, не было ли резервного license server, совпадают ли часовые пояса. Один пропущенный день может «съесть» пик.

Дальше работает простая схема:

1. Соберите файлы за выбранный период и отметьте разрывы (переезд, перезапуск, ротация логов).
2. Преобразуйте строки в таблицу событий: время, пользователь (или host), feature, действие (выдача/возврат), количество.
3. Постройте занятость во времени для каждой feature: на каждой отметке «текущая занятость = предыдущая + выдачи - возвраты».
4. Сравните занятость с лимитом пула и выделите окна дефицита: когда занятость упирается в лимит и появляются отказы или очередь.
5. Сформулируйте рекомендации: размер пула по каждой feature и понятные правила доступа (кому приоритет, что можно переносить на ночные расчеты, где нужен второй сервер).

Чтобы ряд был удобным, выбирайте шаг 1-5 минут. Например, если у feature «CAD_Pro» лимит 20, а по минутам часто виден уровень 19-20 с отказами в 10:00-12:00, это не «в среднем не хватает», а конкретное окно, где команда теряет время.

В конце разделите выводы на два типа: «не хватает лицензий» (есть отказы и устойчивый упор в лимит) и «нужно навести порядок» (лицензии зависают на хостах, нет возвратов, пользователи держат сессии сутками). Так проще закупать точечно и защищать бюджет аргументами, а не впечатлениями.

Как находить пики, «пиковые» команды и сезонность

Пик - это не «самое большое число за год», а короткий отрезок времени, когда лицензии реально заканчиваются и люди ждут. Для аудита полезно смотреть загрузку с мелким шагом: 1 минута или 5 минут. Часто видно, что «максимум» держится 10-20 минут, а дальше откат, и это меняет решение о докупке.

Пики по минутам и «длина» пика

Соберите временной ряд «сколько лицензий занято» по каждой feature и версии. Отметьте не только максимум, но и длительность: сколько минут в день вы были выше, например, 90% пула. Это помогает отличить разовый всплеск от стабильной нехватки.

Удобный минимум для отчета:

• максимум и 95-й перцентиль по занятости
• число минут в месяц выше 80% и 95% пула
• среднее время ожидания (если есть логи отказов или очереди)

Тепловая карта и сезонность

Тепловая карта «день недели x час» по каждой feature быстро показывает, где живет нагрузка: утренние входы, обеденные провалы, вечерние пакетные прогоны. Если строить такую карту отдельно по подразделениям, можно увидеть, что один отдел «поджигает» пик, а остальные работают ровнее.

Сезонность по месяцам ищут так же, как пики, но на длинной оси: сравните месячные профили и отметьте повторяющиеся волны. Типичные причины: закрытие проектов, учебные сессии, отчетные периоды, переход на новую версию, запуск новых групп.

Чтобы найти «пиковые» команды, возьмите топ 1-5% интервалов по занятости и посчитайте, какие пользователи, хосты и подразделения чаще всего активны именно в эти окна. Дальше проверьте гипотезы: обучение (много коротких сессий), пакетные задачи (длинные ночные захваты), боты или скрипты, ошибки, когда лицензия не возвращается из-за зависшего процесса.

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

Компания планировала докупить лицензии CAD: в пуле было 40 concurrent, пользователи работали на 3 площадках, плюс разные смены. Жалобы звучали одинаково: «в середине дня не пускает», поэтому запрос на закупку выглядел логично.

Когда сделали аудит лицензий FlexLM и подняли журналы за 6-8 недель, картина оказалась другой. По общей загрузке максимум был коротким и доходил до 38 из 40, то есть в целом «емкости» хватало. При этом в логах регулярно встречались DENIED именно по двум feature, и они совпадали по времени с пиком в одной из команд.

Причины нашли не в количестве лицензий, а в настройках и гигиене:

• на одну группу стояло резервирование, из-за чего часть пула была недоступна другим командам даже при простое
• были «зависшие» сессии: CAD закрыт, а checkout висит часами и держит место
• площадки жили в разных часовых поясах, и пересечение «утро-обед» давало неожиданный общий пик

Решение получилось точечным: перераспределили пулы между площадками, настроили тайм-аут (idle timeout/linger), убрали лишние резервирования. Докупили не «еще 10 concurrent», а одну конкретную feature, по которой DENIED были системными.

Для закупки и руководителя результат оформили в цифрах и графиках: общий график занятости по часу, отдельные графики по проблемным feature, таблица DENIED (сколько, когда, у каких площадок) и короткий вывод «что меняем» и «что покупаем». Такой отчет проще защищать, потому что он объясняет причину, а не просто фиксирует недовольство пользователей.

Частые ошибки и ловушки в аудите лицензий

Самая частая ошибка - смотреть только «среднее» потребление. Среднее сглаживает картину и прячет короткие, но дорогие пики. Если пик длится 20-40 минут каждый день в одно и то же время, именно он определяет, сколько лицензий реально нужно. Иначе люди будут ждать или искать обходные пути.

Вторая ловушка - смешивать логи с разных серверов, не выровняв время. Разные часовые пояса, переход на летнее время, неверные часы на VM дают «пики», которых не было. Перед расчетами проверьте, что временные метки сопоставимы, иначе аудит превращается в угадайку.

Отдельно проваливаются расчеты, когда не учитывают RESERVE и ограничения по группам. Формально лицензии есть, но часть зарезервирована под конкретную команду или проект. В итоге один отдел видит «свободно», а другой получает отказ.

Не делайте вывод «раз DENIED нет, значит проблем нет». Пользователи часто обходят ограничения: запускают работу ночью, делят задачи, держат сессии открытыми, используют очереди в приложении. Это снижает DENIED, но не снижает неудобство.

И еще одна причина ошибок - слишком короткий период. 1-2 недели легко попадают на отпуск, закрытие квартала или учебную сессию. Надежнее брать хотя бы 6-8 недель, а лучше 3 месяца, чтобы увидеть повторяющиеся пики.

Короткая проверка перед выводами:

• сопоставили время на всех источниках логов
• учли RESERVE и правила доступа по группам
• проверили не только среднее, но и длительность пиков
• убедились, что период не «случайный» (праздники, дедлайны)
• посмотрели признаки очередей и ручных обходов

Короткий чеклист перед отчетом и следующими шагами

Перед тем как фиксировать выводы, проверьте базовые вещи. Большинство ошибок в расчете потребности появляются не из-за формул, а из-за «кривых» исходных данных и разного понимания, что именно считается лицензией.

Проверка данных и расчетов

Пройдитесь по пунктам ниже и отмечайте, где нужны уточнения у админов, инженеров или закупки:

• Период логов закрывает нужные месяцы без «дыр», а время приведено к одному часовому поясу.
• Названия feature и опций сопоставлены с реальными продуктами и командами, включая алиасы и разные vendor daemon.
• Построены ключевые метрики: максимум (peak), 95-й перцентиль, а также DENIED и QUEUED по времени.
• Понятно, какие команды делают пики и почему: дедлайны, ночные прогоны, пакетные задачи, общий пул на несколько отделов.
• Подготовлены 2-3 понятных сценария, что делать дальше: перераспределить права, настроить лимиты или очередь, или докупить ровно недостающее.

После этого оформите выводы так, чтобы их можно было проверить. Например: «в апреле по feature X 95-й перцентиль = 38, peak = 47; при этом 80% отказов между 10:00 и 12:00, основной вклад дает команда проектирования». Так меньше споров в стиле «нам всегда не хватает».

Следующие шаги

Назначьте владельца изменений (ИТ, инженерный руководитель, закупка) и срок контрольной проверки. Хорошая практика: внедрили изменения, подождали 2-4 недели, снова сняли метрики и сравнили DENIED/QUEUED и 95-й перцентиль до и после.

Что делать дальше: закрепляем эффект и готовим инфраструктуру

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

План на 1-3 месяца

Начните с шагов, которые часто дают эффект без закупок:

• Согласуйте правила: какие функции критичны, кому они нужны, и что считается просто «удобно иметь».
• Наведите порядок в пулах: разделите лицензии по продуктам и командам, если сейчас все в одном котле.
• Настройте лимиты и приоритеты там, где это поддерживается (например, отдельные группы для ночных расчетов).
• Уберите «шум»: обучите пользователей закрывать сессии, проверьте автозапуск, зависшие процессы и неверно настроенные клиенты.
• Зафиксируйте решение по закупке: докупить, перераспределить или изменить тип лицензирования, и на каких данных это основано.

Дальше стоит укрепить инфраструктуру лицензирования. Для FlexNet Publisher обычно упираются в доступность и наблюдаемость: резервирование (триадный сервер, если уместно), отказоустойчивость на уровне ОС и виртуализации, централизованный сбор логов, базовый мониторинг доступности и заполнения пулов. Отдельно проверьте время: единый NTP на серверах и клиентах, иначе пики и сезонность будут «плясать».

Как часто повторять и что мерить

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

• 95-й перцентиль одновременного использования по ключевым функциям
• количество отказов (DENIED) и в какие часы
• средняя длительность сессий и доля «аномально длинных»
• доля пользователей, создающих пики (топ-10)
• сезонность по неделям: рост или просадка относительно базового периода

Если логов много, используется несколько менеджеров лицензий или нужен надежный контур сбора и отчетности (а не ручные выгрузки), имеет смысл подключать системного интегратора. Например, GSE.kz (gse.kz) как производитель серверов и системный интегратор может помочь выстроить инфраструктуру под серверы лицензий и централизованный мониторинг, а затем сопровождать контур 24/7, чтобы лицензирование оставалось доступным для производственных команд.