Шаблон

Я давно собирался настроить мониторинг службы DFS Replication на нашем Zabbix, но готовых шаблонов в сети не нашел. Попалось несколько заброшенных проектов тут и тут, но первый автор так и не довел до конца, а во втором не работала ссылка для скачивания шаблона. К тому же, оба ограничивались лишь мониторингом бэклогов, хотя по факту метрик намного больше. Поэтому я решил сделать свой велосипед с круглым рулем и турбинами шаблон сдискавери и скриптами. Начал уже давно, но довести дело до конца всё руки не доходили. Как говорится, нет худа без добра: на удаленке в самоизоляции наконец доделал. Работы было проделано много, но я не жадный, поэтому делюсь. :)

Before you begin

• Далее в тексте под хостом я буду иметь в виду сервер с ролью DFSR, для которого настраивается мониторинг.

• Иногда для краткости вместо словосочетаний группа репликации и реплицируемая папка я буду пользоваться аббревиатурами RG и RF.

В общем и целом

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

Ответить на второй вопрос мне было легко. Разумеется, это будет мониторинг агентом с LLD и кастомными скриптами. Выбирая язык для скриптов, я, не долго думая, остановился на PowerShell. Много возможностей, активно продвигается Microsoft, горячо любим мной :). Была еще мысль сделать на VBScript для легковесности совместимости со старыми версиями Windows, но, подумав, отказался от этой затеи.

Всего в решении два PS-скрипта: Get-DFSRObjectDiscovery.ps1 и Get-DFSRObjectParam.ps1

Как легко понять из названия, первый - для обнаружения объектов мониторинга (item или элемент данных в терминлогии Zabbix), второй - для получения значений свойств этих объектов. Данные в основном собираются посредством WMI-запросов. Разбирать скрипты здесь не буду, т.к. комментарии есть в самом коде.

Ответить на вопрос "что мониторить?" было сложнее. Методом тыка Полагаясь на свой опыт развертывания DFSR и изучив документацию, я выделил несколько основных сущностей, относящихся к DFSR, для каждой из этих сущностей составил список параметров, значения которых мне было бы интересно мониторить.

Итак, сущности:

• группы репликации;

• реплицируемые папки;

• подключения;

• тома DFSR;

• партнеры;

• общее состояние.

Метрики для каждой из сущностей и способы их сбора будут описаны ниже.

Данные будут собираться только для тех объектов DFSR, к которым имеет отношение хост. Например, если в Active Directory есть группа репликации MyRG3, но хост в нее не входит, то метрики для нее собираться не будут. Аналогично с папками и подключениями.

Для большинства айтемов и триггеров в шаблоне есть описания и ссылки на статьи из базы знаний Microsoft.

В лабе я тестировал шаблон на разных версиях Zabbix от 2.2 до 5.0 и Windows от 2008R2 SP1 до 2019, в продакшне опробовал на Zabbix 3.4, Zabbix 5.0 и Windows 2012 R2.

В шаблоне используются преобразования значений (value mapping), поэтому потребуются права суперадмина на сервере Zabbix.

Группы репликации (DFS Replication Groups)

Параметры:

• количество исходящих подключений (outbound connections);

• количество входящих подключений (inbound connections);

• количество реплицируемых папок (number of folders);

• отключенное расписание (blank schedule).

Все эти параметры и триггеры для них описаны в правиле обнаружения DFS Replication Groups LLD.

С количеством подключений и папок, думаю, понятно, про расписание немного поясню. Для группы репликации задается расписание по умолчанию, которое будут наследовать подключения, создаваемые между партнерами этой группы. Администратор может ограничить использование полосы пропускания в зависимости от дня недели и времени суток вплоть до полной остановки репликации в определенное время. В случае, если в расписании репликация отключена полностью для каждого часа каждого дня недели, этот параметр будет равен 1, в противном случае должен возвращаться 0.

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

Реплицируемые папки (DFS Replicated Folders)

Параметры:

• количество файлов в бэклогах (backlog size);

• состояние (state)

• включена или выключена (enabled)

• режим "только чтение" ('read-only' mode)

• настройка "Переместить удаленные файлы в папку конфликтов и удалений" ('remove deleted' enabled)

• отказоустойчивость (redundancy)

• размер, заданный для промежуточной папки (stage quota)

• занятое место в промежуточной папке (stage used)

• процент свободного места в промежуточной папке (stage free (percentage))

• размер, заданный для папки конфликтов и удалений (conflict quota)

• занятое место в папке конфликтов и удалений (conflict used)

• процент свободного места в папке конфликтов и удалений (conflict free (percentage))

• данные счетчиков производительности;

Для бэклогов создано правило обнаружения DFS Replicated Folders Backlog LLD. Я решил мониторить только исходящие бэклоги. Во-первых, DFSR - распределенная система, поэтому предполагается, что мониторинг будет настроен комплексный, на все DFSR-серверы. И, учитывая, что исходящий бэклог сервера = входящий бэклог его партнера, я решил не дублировать по сути одну и ту же метрику, привязывая ее к разным хостам. Во-вторых, очередь входящих файлов характеризует больше не локальный сервер, а его партнера, расходуя место в его промежуточной папке и, как правило, вызывая предупреждения в журнале событий этого партнера.

Для кастомизации мониторинга бэклогов есть 3 макроса:

{$BACKLOGMAXWARNING} - порог для warning-триггера (по умолчанию равен 10);

{$BACKLOGMAXAVERAGE} - порог для average-триггера (по умолчанию равен 100);

{$BACKLOGPERIOD} - как долго размер бэклога должен быть выше порогового значения (по умолчанию 15 минут).

Таким образом, если количество файлов в бэклоге превышает 10 в течение 15 минут, срабатывает warning-триггер. Если же количество файлов переваливает за 100, то срабатывает уже average-триггер.

Кстати, пока прорабатывал тему мониторинга DFSR, с удивлением обнаружил, что в Managment Pack для SCOM ("православная" система мониторинга для продуктов Microsoft) сбор данных о бэклогах по умолчанию отключен для экономии ресурсов сервера. Мне же это видится одной из главных метрик, дающих представление о состоянии сервиса. Поэтому я добавил для него еще и график:

За сбор остальных параметров (кроме счетчиков производительности) отвечает правило DFS Replicated Folders LLD. Здесь всё должно быть понятно, поясню только параметры state и redundancy.

State - это состояние папки, которое может принимать одно из следующих значений:

• Uninitialized (0)

• Initialized (1)

• Initial Sync (2)

• Auto Recovery (3)

• Normal (4)

• In Error (5)

Redundancy - это количество партнеров, на которых есть копия папки в состоянии Normal. Если окажется, что у папки нет рабочих копий ни на одном из партнеров, сработает соответствующий триггер.

Предвосхищая резонный вопрос про stage free (percentage) и conflict free (percentage), сразу отвечу. Да, можно было бы сделать их в виде вычисляемых айтемов, но я решил выполнять эти вычисления на стороне хостов, чтобы снизить нагрузку на zabbix-сервер.

Если в промежуточной папке или папке конфликтов остается менее 5% свободного места, срабатывают соответствующие триггеры. Стандартное значение 5% можно переназначить с помощью макросов {$STAGEDIRPFREEMIN} и {$CONFLICTDIRPFREEMIN}.

Для счетчиков производительности есть правило обнаружения DFS Replicated Folders PerfCounters LLD. Большинство прототипов в нем отключено по умолчанию, т.к., на мой взгляд, это лишняя информация, которая будет расходовать место в базе данных и отнимать процессорное время. Но ничто не мешает вам включить нужные счетчики как на уровне шаблона, так и для конкретного хоста или даже айтема на этом хосте. Кстати, при работе со счетчиками есть свои нюансы, о которых я расскажу позже в отдельной статье.

А вот одним из полезных, на мой взгляд, счетчиков счетчик Conflict Files Generated, который возвращает суммарное число файлов, проигравших в конфликтах для определенной RF. Поэтому для него есть соответствующий прототип айтемов и триггеры. Для кастомизации этих триггеров есть макросы:

{$CONFLICTSGENERATEDCHANGEWARNING} - пороговое значение, при превышении которого сработает warning-триггер (по умолчанию 10);

{$CONFLICTSGENERATEDCHANGEAVERAGE} - аналогично для average-триггера (по умолчанию 100);

{$CONFLICTSGENERATEDPERIOD} - период времени, в течение которого должно произойти нужное количество конфликтов, чтобы сработал триггер (по умолчанию 5 минут).

Таким образом, если за 5 минут обнаружится более 10-ти конфликтов, то сработает warning-триггер, если больше 100 - то average-триггер.

Зачем вообще отслеживать конфликты? Представим такую ситуацию. У нас есть общая папка, опубликованная в DFSN в виде виртуального пути \\abc.com\Share. Для папки есть два конечных объекта (реальные шары на файловых серверах): \\server1\Share и \\server2\Share. Эти шары входят в группу репликации и доступны конечным пользователям в режиме чтение+запись на обоих серверах. Файловые серверы расположены в разных AD-сайтах (пусть будет Office1 и Office2). Пользователь Иванов из Office1, обратившись по пути \\abc.com\Share, попадает на server1, а его коллега Петров из Office2 - на server2 (разумеется, для пользователей это происходит прозрачно и они не подозревают, что каждый из них работает со своей копией файлов, которые фактически расположены на разных серверах). Иванов и Петров открывают файл \\abc.com\Share\Важный_отчет.xlsx (каждый - со своего сервера) и заносят туда данные. А потом перед совещанием внезапно оказывается, что сохранились только те данные, которые внес Петров, а то, что сделано Ивановым, чудесным образом исчезло, хотя он честно жал Ctrl+S каждые 5 минут, как его учили технари. Благо, данные таки можно восстановить, но зуб на ИТ у Иванова останется, ибо виноват во всем админ Сидоров, который не предусмотрел такой сценарий.

Разумеется, есть случаи, когда конфликты - это нормальная ситуация, которая не приводит к потере бизнес-значимых данных, но обычно обилие конфликтов говорит о неверно продуманной архитектуре DFS-решения. И лучше об этом заранее узнать от системы мониторинга, чем потом от пользователей.

Разумеется, есть случаи, когда конфликты - это нормальная ситуация, которая не приводит к потере бизнес-значимых данных, но обычно обилие конфликтов говорит о неверно продуманной архитектуре DFS-решения. И лучше об этом заранее узнать от системы мониторинга, чем потом от пользователей.

Для RF есть 4 прототипа графиков:

• использование места в папке конфликтов и удалений (conflict space usage)

• использование места в промежуточной папке (stage space usage)

• размер данных, полученных от партнеров с учетом сжатия и без него (received bytes)

• количество принятых файлов и количество конфликтов (received files and conflicts)

Подключения (DFS Replication Connections)

Параметры:

• состояние (state);

• включено или выключено (enabled);

• отключенное расписание (blank schedule);

• данные счетчиков производительности.

Два правила обнаружения: DFS Replication Connections LLD - для первых трех параметров, DFS Replication Connections PerfCounters LLD - для счетчиков.

State - это состояние подключения, может быть таким:

• Connecting (0)

• Online (1)

• Offline (2)

• In Error (3)

Enabled - тут понятно.

Blank schedule - аналогично параметру для RG. Подключение может иметь индивидуальное расписание, отличное от дефолтного, заданного на уровне RG.

Как и для RF, прототипы айтемов здесь почти все отключены, оставлен только счетчик bytes received per second, для которого также есть график:

Тома DFSR (DFS Replication Service Volumes)

Параметры:

• состояние (state);

• данные счетчиков производительности.

Два правила обнаружения: DFS Replication Service Volumes LLD и DFS Replication Service Volumes PerfCounters LLD. Первое - для параметра state, который может принимать следующие значения:

• Initialized (0)

• Shutting Down (1)

• In Error (2)

• Auto Recovery (3)

Второе правило обнаружения используется для счетчиков производительности и по умолчанию отключено.

Партнеры (DFS Replication Partners)

Параметры:

• доступность по PING (ping check);

• доступность по WMI (WMI check).

За оба параметра отвечает правило обнаружения DFS Replication Partners LLD. Как следует из названия, это два типа проверки: проверяется, может ли хост "достучаться" до каждого из партнеров по ICMP и WMI. Подключение по WMI будет выполняться под учетной записью, из-под которой работает служба zabbix-агента. При этом единственное назначение WMI-проверки - убедиться, что установленный на хосте агент может связаться с DFSR-партнером для сбора параметров backlog size и redundancy (они были описаны выше при разборе метрик для реплицируемых папок). А для этого необходимо, чтобы учетная запись zabbix-агента обладала правами локального администратора на каждом из партнеров. Иными словами, WMI-проверка подскажет, если у учетной записи агента не хватает прав на каком-либо из партнеров. Выглядеть это будет вот так:

Общее состояние (General)

Параметры:

• установлена ли роль DFSR (DFS Replication role installed);

• количество групп репликации, в которые входит сервер (Number of replication groups);

• количество ошибок и предупреждений в журнале событий DFSR (DFSR Event Log);

• состояние службы (DFS Replication service state);

• аптайм службы (DFS Replication service uptime);

• версия службы (DFSR Service Version);

• версия поставщика DFSR (DFSR Provider Version);

• версия поставщика мониторинга DFSR (DFSR Monitoring Provider Version);

Последние два параметра по умолчанию отключены.

Здесь правила обнаружения не нужны, поэтому все параметры находятся в разделе Items шаблона.

Немного замечаний о мониторинге журнала событий. За это отвечают 3 айтема, каждый из которых мониторит события определенного уровня критичности:

• DFSR Event Log: number of warnings

• DFSR Event Log: number of errors

• DFSR Event Log: number of critical errors

Парсинг журнала был отдан на откуп агенту, а точнее - PS-скрипту. На входе скрипт получает тип событий (предупреждение, ошибка, критическое) и период, за который нужно проанализировать журнал. На выходе отдает количество событий, соответствующих заданным критериям. Если за последний час в логе найдется хотя бы одно предупреждение или ошибка, то сработает триггер. Эти настройки можно поменять с помощью макросов:

{$DFSRLOGCRITICALMAX} - количество событий со статусом "Критическое" в логе DFSR, при превышении которого должен срабатывать high-триггер (по умолчанию 0);

{$DFSRLOGERRORSMAX} - количество событий со статусом "Ошибка" в логе DFSR, при превышении которого должен срабатывать average-триггер (по умолчанию 0);

{$DFSRLOGWARNINGSMAX} - количество событий со статусом "Предупреждение" в логе DFSR, при превышении которого должен срабатывать warning-триггер (по умолчанию 0);

{$DFSRLOGPERIOD} - за какое время надо анализировать лог (по умолчанию 1 час)

Состояние службы может принимать такие значения:

• Service Starting (0)

• Service Running (1)

• Service Degraded (2)

• Service Shutting Down (3)

• Stopped (100)

• Not Found (101)

Остальные параметры разбирать не буду, там всё ясно из названия.

Напоследок

Чтобы иметь наглядную картину, я создал для каждой RG соответствующую группу хостов на Zabbix-сервере и сделал для каждой RG скрин, на котором видно общее состояние хостов группы и графики для различных метрик.

Получилось примерно так:

В процессе продакшн-эксплуатации шаблона выявилась проблема с опросом значений счетчиков производительности для RF: по непонятным мне причинам агент Zabbix перестает получать их показания и генерирует в своем логе ошибки вида "perf_counter[\XXX\YYY]" is not supported: Cannot obtain performance information from collector. Средствами же самой Windows (perfmon, typeperf, Get-Counter) эти счетчики опрашиваются нормально. Лечится перезапуском службы Zabbix Agent. Проблема касается только RF-счетчиков, счетчики для других сущностей (например, для подключений) агент опрашивает без проблем.

Шаблон и инструкции по установке есть на GitHub и Zabbix Share. Забирайте!

Буду рад конструктивной критике и предложениям по улучшению шаблона.

Источники вдохновения

Monitoring DFSR

DFSR WMI Classes

DFSR Performance Objects, Their Counters, Corresponding WMI Classes, and Using WMIC or Vbscript to View Them

Get-DFSRBacklog (Technet gallery)

DFS Replication Backlog Discovery

DFS Replication Management Pack for Windows Server 2008 R2

Optional configuration for the DFS Replication Management Pack

PowerShell Zabbix Json и ConvertTo-Json2

Displaying Unicode in Powershell

powershell : changing the culture of current session

Searching the Active Directory with PowerShell

PowerShell scripting performance considerations

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

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

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

А еще сразу скажу, что далее будет все на питоне... Вот... Сказал. Не буду больше ходить вокруг да около, у нас всего 5 минут (помните, да?). Приступим!

Пошаговая инструкция

1) Создаем репозиторий на гитхабе из моего шаблона

2) Регистрируемся на Heroku

3) Создаем новое приложение

4) Привязываем наш репозиторий к проекту на Heroku

5) Настраиваем автоматический deployment

6) Смотрим на адрес, где будет висеть наш бот

7) Настраиваем переменные среды

8) Собираем наше приложение и ждем пока оно запустится

9) Заходим по адресу из пункта 6 и добавляем к ссылке пароль. Получиться что-то такое: fancy-panda.herokuapp.com/?password=<ADMIN_PASSWORD>

10) Устанавливаем webhook, переходя по ссылке на подобие fancy-panda.herokuapp.com/set_webhook?password=<ADMIN_PASSWORD>

Тестируем

Теперь, когда мы закончили все настраивать, пора посмотреть, что же мы "натворили".

Посмотреть в живую можно тут.

Добавляем функционал

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

@bot.message_handler(commands=["id"])def get_id(message):    logger.info(f'</code>@{message.from_user.username}<code> used /id')    bot.send_message(message.chat.id, f"user_id = {message.chat.id}")

Думаю, дальше ограничивает вас только воображение... (ну почти)

Применение в проектах

Все любят, когда есть примеры работы. На основе этого шаблона я сделал бота wifi_qr_bot, который генерирует QR-коды для подключения к WiFi. Это упрощает жизнь, ведь пароль у вас длинный (безопасность, все дела), а вводить его на каждом новом устройстве вам лень.

Выводы

Вот мы и сделали нашего бота, который хоститься в облаке. Он уже многое умеет в плане логирования. Для логирования я написал отдельную библиотеку, tg-logger. Если интересно, как она работает, то потыкайте в демо бота. Если все еще интересно, прочитайте мою статью. Такие пироги с котятками...

Ссылки

• Репозиторий шаблона: https://github.com/otter18/telegram-bot-template

• Рабочий бот (запущенный шаблон): https://t.me/sjfsdjflsdkjlkgjdfg_bot

• WiFi QR-code generator bot: https://t.me/wifi_qr_bot

• Исходный код WiFi QR-code generator bot: https://github.com/otter18/wifi_qr_bot

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

Началось всё в 2009 году, когда вместо того, чтобы, для документов в электронном виде, отсканировать печать (как это обычно делается), я, по разным причинам (включая уже заметную на тот момент деформацию полимера действующей печати), запланировал отрисовать её заново. Но перед этим решил проверить: не была ли она сделана при помощи одного из популярных генераторов. Моё предположение оказалось верным и, через несколько минут, печать, со 100% точностью, я получил просто, выбрав подходящий шрифт и введя нужные данные в поля программы. Результат выглядел примерно так:

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

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

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

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

На следующем этапе нужно было определить минимально допустимую толщину линий и размер элементов микротеста для печати, но не найдя ничего конкретного, пришлось ориентироваться на ГОСТ Р 51511-2001, относящийся к печатям с воспроизведением государственного герба Российской Федерации, а именно на п. 6.2.3: Наличие линий толщиной 0,08^+0,01 мм., и п. 6.2.1, 6.2.2: Размер элементов микротекста от 0,5 до 0,8 мм.

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

Но, не смотря на все попытки сделать это при помощи эффекта арки (arc) в Photoshop, желаемого эффекта добиться не удалось, пришлось спешно знакомиться с Illustrator и, попутно, регистрироваться на профильных форумах в поисках решения. И найдено оно было далеко не сразу, кажущаяся простой задача сопротивлялась не один день.

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

В целом результатом я был доволен, заказ оформлен, оплачен и, спустя какое-то время, получен. Пробные оттиски впечатляли (тот шаблон, к слову, используется до сих пор). Однако я не учёл особенности зрительного восприятия человеком объектов, когда они могу казаться больше или меньше, чем есть на самом деле.

То же самое изображение:

Так это выглядит на самом деле (одинаковый размер печатей):

Таким образом, при одинаковых оснастках (обычно 40 мм.), оттиск по моему шаблону визуально кажется меньше, чем оттиск обычной круглой печати. Избежать этого эффекта, в моем случае, можно было заказав печать на оснастке 42-45 мм.

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

Наигравшись, я забыл о нём еще на несколько лет, до тех пор, пока, всё-таки, не захотел нормально освоить Illustrator, знакомство с которым, на тот момент, ограничивалось опытом работы над одним единственным элементом. Тогда, ожидаемо, очередные размышления на тему того, как бы сейчас выглядел шаблон, привели меня к следующей работе. В этот раз всё было по-другому: я продумывал каждый микрон, каждый элемент многократно переделывался. Иногда проходило несколько дней, прежде, чем он начинал меня полностью устраивать. Если я в чём-то сомневался, то откладывал работу, чтобы потом посмотреть на неё свежим взглядом. Примерно через год, был закончен первый вариант и меня он устраивал всем, кроме казавшейся не достаточной устойчивостью к секторному копированию (как я это назвал), когда для того, чтобы воссоздать тело печати достаточно отрисовать только небольшую её часть. Дальнейшую работу я продолжил в надежде исправить этот недостаток и, спустя какое-то время, сделать это мне удалось в полном объеме от задуманного.

Как работает защита от секторного копирования в моей реализации можно понять, по следующим кадрам:

Текущий проект оформлен таким образом, чтобы большая часть нового шаблона генерировалась автоматически при помощи скриптов. Таким образом можно получить бесконечное множество визуально одинаковых, но разных по сути шаблонов (для чего это может быть нужно, станет понятно позднее). Адаптацию одного из скриптов под свою версию Illustrator пришлось заказывать на стороне. Общий объем чистого проекта (в котором уже нет ничего лишнего) можно представить по следующим кадрам:

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

На мой взгляд максимально защищенная схема выглядит следующим образом: одна печать для документов, вторая печать (сгенерированная отдельно) для договоров и прочих важных документов и третья печать (снова сгенерированная отдельно) для ультрафиолетовой краски, в этом случае шаблон либо обрезается и добавляется ко второй печати, либо делается отдельно (что даёт большую гибкость в использовании).