Где почитать логи службы сервера 1с

Win10 x64
8.3.8.2322 х32

Через 2 сек после запуска останавливается служба «1C:Enterprise 8.3 Server Agent».
Переустанавливал, удалял папку «C:\Program Files (x86)\1cv8», устанавливал службу под разными пользователями, удалял процесс rmngr — ничего не помогло.
Если запустить руками ragent.exe, то пишет:
Server agent started.
Server agent finished.

В журнале windows логов по агенту нет.
Пробовал и другие релизы.
Где копать?

(0) В журнале Виндоус логи должны быть. В крайнем случае настрой технологический журнал.
(1) В журнале винды этих логов нет.

(0) копай сюда C:\Program Files\1cv8\srvinfo.
Сохраняй куда-нибудь все внутренности и убивай их, запускай сервер, запускай администрирование сервера 1с предприятие и настраивай занова

(1) В тех. журнале в файле G:\log\2017-30-08\ragent_11140\17083108.log:

35:00.923002-0,EXCP,0,process=ragent,setUnhandledExceptionFilter=setUnhandledExceptionFilter
35:02.970000-0,EXCP,0,process=ragent,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657,Descr=’src\RHostImpl.cpp(2385):
81029657-3fe6-4cd6-80c0-36de78fe6657: . . . . . . . (. /. . /. )’

(3) Я и так полностью удалял папку «C:\Program Files (x86)\1cv8» перед установкой 1с
Кстати, в логе тех. журнала в конце сообщения нечитаемые каракули. Что это?
А в «C:\Program Files\» нет папки «1cv8»?
81029657-3fe6-4cd6-80c0-36de78fe6657 Ошибка сетевого доступа к серверу
попробуй грохнуть ipv6 или поставить свежие релизы 8.3.10

(7) нет папки
(9) я отключил ipv6. Совсем грохнуть? А как?

netstst выдает:
——————————————————
Имя Локальный адрес Внешний адрес Состояние
TCP 0.0.0.0:135 Main:0 LISTENING
TCP 0.0.0.0:445 Main:0 LISTENING
TCP 0.0.0.0:1433 Main:0 LISTENING
TCP 0.0.0.0:1536 Main:0 LISTENING
TCP 0.0.0.0:1537 Main:0 LISTENING
TCP 0.0.0.0:1538 Main:0 LISTENING
TCP 0.0.0.0:1539 Main:0 LISTENING
TCP 0.0.0.0:1540 Main:0 LISTENING
TCP 0.0.0.0:1547 Main:0 LISTENING
TCP 0.0.0.0:1552 Main:0 LISTENING
TCP 0.0.0.0:2179 Main:0 LISTENING
TCP 0.0.0.0:3389 Main:0 LISTENING
TCP 0.0.0.0:7680 Main:0 LISTENING
TCP 127.0.0.1:1434 Main:0 LISTENING
TCP 127.0.0.1:5939 Main:0 LISTENING
TCP 192.168.1.239:139 Main:0 LISTENING
TCP 192.168.1.239:1544 db5sch101101122:https ESTABLISHED
TCP [::]:135 Main:0 LISTENING
TCP [::]:445 Main:0 LISTENING
TCP [::]:1433 Main:0 LISTENING
TCP [::]:1536 Main:0 LISTENING
TCP [::]:1537 Main:0 LISTENING
TCP [::]:1538 Main:0 LISTENING
TCP [::]:1539 Main:0 LISTENING
TCP [::]:1540 Main:0 LISTENING
TCP [::]:1547 Main:0 LISTENING
TCP [::]:1552 Main:0 LISTENING
TCP [::]:2179 Main:0 LISTENING
TCP [::]:3389 Main:0 LISTENING
TCP [::]:7680 Main:0 LISTENING
TCP [::1]:1434 Main:0 LISTENING
UDP 0.0.0.0:500 *:*
UDP 0.0.0.0:3389 *:*
UDP 0.0.0.0:3544 *:*
UDP 0.0.0.0:4500 *:*
UDP 0.0.0.0:5050 *:*
UDP 0.0.0.0:5353 *:*
UDP 0.0.0.0:5355 *:*
UDP 0.0.0.0:56367 *:*
UDP 127.0.0.1:1900 *:*
UDP 127.0.0.1:49599 *:*
UDP 192.168.1.239:137 *:*
UDP 192.168.1.239:138 *:*
UDP 192.168.1.239:1900 *:*
UDP 192.168.1.239:5353 *:*
UDP 192.168.1.239:49598 *:*
UDP 192.168.1.239:50818 *:*
UDP [::]:500 *:*
UDP [::]:3389 *:*
UDP [::]:4500 *:*
UDP [::]:56368 *:*
UDP [::1]:1900 *:*
UDP [::1]:5353 *:*
UDP [::1]:49597 *:*
——————————————————

Порт 1540 указан. Кем же он используется, если агент 1с лежит?

(10) вот ты и навелся на причину незапуска.
порты кем-то заняты. дальше у тебя 2 рецепта:
1) освободить порты.
2) переехать 1ску на другие порты.

TCP 0.0.0.0:1539 Main:0 LISTENING
SessionEnv
[svchost.exe]
TCP 0.0.0.0:1540 Main:0 LISTENING
[spoolsv.exe]

У меня подозрение на это.
Как исправить?

SpoolSv — это аббревиатура от Print Spooler Service
есть ощущение что он сам динамически выбирает свободные порты.
удали сетевой принтер на своем сервере и посмотри порты еще раз.

Я не очень понял — раз удалил папку 1cv8, значит нужно заново подключить базы через Администрирование серверов 1С. Скорее всего 1С не запускалась как раз из-за того, что обнулился 1CV8Reg.lst файл, в котором были прописаны базы.

Работа с логами (журналами) сервера

Как правило, в Linux логи хранятся в специальном каталоге /var/log , внутри которого создаются отдельные файлы и папки для того или иного сервиса. Однако стоит учитывать, что для служб и ПО не запрещено задавать специальные каталоги для хранения логов. Например, для виртуальных хостов (сайтов) панель ISPmanager задает специальный каталог ( /var/www/htttpd-logs ) для удобного анализа логов по каждому сайту отдельно. А, например, стороннее ПО, устанавливаемое в директорию /opt , чаще всего будет вести логи также внутри этого каталога.

Стоит отметить, что несмотря на общую структуру, наименования отдельных файлов и каталогов могут отличаться в зависимости от определенной версии ОС, чаще всего разделяют на Debian-based (Debian/Ubuntu) и RedHat-based (Centos, Rocky Linux, AlmaLinux и т.д.), в статье мы будем разделять именно так.

Далее рассмотрим подробнее особенности вышеназванных наиболее популярных категорий журналов.

Системные логи

Начнем с системных логов как наиболее важных (система — основа работы сервера:)).

Системный журнал, как правило, записывается в файлы:
Debian-based:
/var/log/syslog RedHat-based:
/var/log/messages
Там находится много различной информации о событиях, процессах и ошибках практически от всех системных служб сервера и, в частности, сообщения от ядра Linux. Также к системному логу можно отнести:
/var/log/dmesg (для удобного просмотра этого журнала можно просто выполнить команду dmesg -T )
/var/log/kern.log
в этих файлах ведется журнал с сообщениями ядра и драйверов всех устройств сервера. Обратите внимание, что эти логи ведутся с момента старта системы, поэтому часто после ее аварийной перезагрузки довольно сложно узнать, что было, так как этого события уже нет в логе.
Логи авторизации.
Сюда вносится информация о входах в систему, в том числе и о неудачных попытках (полезно для отслеживания попыток подбора пароля к системе и выяснения, кто был на сервере)
Debian-based:
/var/log/auth.log RedHat-based:
/var/log/secure

Лог загрузки ОС:
/var/log/boot.log

Лог планировщика (CRON) системы:
/var/log/cron

Логи веб-сервера

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

У Apache и Nginx есть свои логи, как правило, двух категорий: первая — хранит журнал посещений, вторая — хранит информацию об ошибках, уведомлениях, примечаниях, предупреждениях и т. д.

Также в связке с Nginx довольно часто устанавливается интерпретатор PHP (php-fpm), соответственно, он тоже имеет свой лог с ошибками и уведомлениями.

Логи веб-сервера Apache

Apache создает два лог-файла:

лог посещений (доступа) ( access.log/access_log );
лог ошибок ( error.log/error_log ).

Конфигурация Apache позволяет задать хранение этих файлов отдельно для каждого сайта, размещенного на сервере. Хороший пример — реализация журналов веб-сервера в панели ISPmanager — логи хранятся в директории /var/www/httpd-logs и называются domain.name.access.log и domain.name.error.log , где вместо domain.name — имя определенного домена. Могут быть и другие реализации хранения логов, это всегда отражено в конфигурационных файлах веб-сервера.

Что касается стандартной реализации, то логи на Debian-based системах хранятся в каталоге /var/log/apache2 , а у RedHat-based систем в каталоге /var/log/httpd .

Логи веб-сервера Nginx

Nginx создает тоже два файла, хранящих журнал посещений и журнал ошибок. Файлы находятся в каталоге /var/log/nginx . В случае конфигурации веб-сервера как связки Nginx с Apache, журналы Nginx иногда пишутся в одном файле с логами Apache, с одной стороны, это может быть удобно, но в некоторых случаях для обнаружения ошибок это может создать трудности.

Также как и в Apache, Nginx может быть настроен для ведения логов каждого сайта отдельно.

Пример отображения стандартных логов Nginx в консоли:

Файлы .gz — это архивы логов, созданные в результате ротации логов, о ней расскажем позже.

Логи PHP-интерпретатора

Стандартно PHP-интерпретатор входит в конфигурацию Apache как модуль PHP. В таком случае все ошибки PHP хранятся там же, где основной лог Apache.
Если интерпретатор PHP работает в виде службы PHP-FPM (например, для связки веб-сервера Nginx+PHP-fpm), то логи хранятся отдельно, в каталоге /var/log/php-fpm .

В PHP (через конфигурационный файл php.ini) возможно настроить запись ошибок в определенный лог-файл, либо задать запись ошибок на определенной странице в отдельный файл (это уже осуществляется через файл .htaccess в соответствующем каталоге сайта). Чаще всего для таких случаев задают имя файла php_error.log или просто error.log , располагаться они могут как в каталоге сайта, так и любом другом каталоге пользователя, проверить лучше непосредственно в конфигурации PHP и веб-сервера.

Логи почтовой службы

На серверах довольно часто, помимо веб-сервера, присутствует и почтовая служба для отправки и приема писем все с тех же сайтов или отдельно через электронные почтовые ящики. Наиболее популярной конфигурацией почты сейчас является связка Exim (отправка и прием писем по протоколу SMTP) и Dovecot с сортировщиком sieve (для доступа пользователей к почтовым ящикам по протоколу IMAP/POP3).

В этом случае логи Exim находятся в каталоге /var/log/exim , чаще всего интересует файл mainlog (в нем хранятся все события почтовой службы), еще есть panic.log (там находятся сообщения об ошибках).

У Dovecot же логи, как правило, пишутся в файл /var/log/maillog или /var/log/mail.log , в него заносится информация о доставке, приеме и сортировке писем.

Логи FTP

В качестве FTP-службы в Linux есть несколько вариантов ПО, но в целом методика ведения логов у каждого ПО примерно схожая. В папке /var/log создаются журналы FTP-сервера, в случае использования vsFTPd это будет файл vsftpd.log , а в случае proFTPd — proftpd.log . В случае PURE-FTPd поищите файл /var/log/pureftpd.log . Если лога FTP вы не обнаружите, скорее всего, он все равно ведется, но уже в системных логах, упомянутых выше, это:

Также некоторые FTP-службы имеют файл лога xferlog , в котором пишется информация обо всех передачах по протоколу FTP.

Логи сервера базы данных

Рассмотрим сначала наиболее распространенный сервер баз данных MySQL. В стандартной настройке он ведет лог в файле mysqld.log или mysql.log . Файл располагается в папке /var/log/mysql или /var/log/mariadb , в зависимости от используемой версии MySQL.

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

Также сервер MySQL может создавать в этой папке файл отладки медленных запросов к базе данных. Обычно он называется mysql_slow.log .
Иногда, в случае если настроена репликация баз данных, включают и ведение бинарных логов, они заносятся в файл mysql-bin.log . Этот лог, помимо большого своего объема на диске, также может снизить производительность сервера баз данных, поэтому также без особой необходимости включать его ведение не стоит.

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

/var/log/postgresql/postgresql-x.x.main.log
где x.x — номер версии PostgreSQL

Ротация логов

Для сайтов, имеющих активную посещаемость или большое количество уведомлений и ошибок PHP на многих страницах сайта, размеры журналов могут очень быстро разрастись и в конечном итоге заполнить диск сервера. Для предотвращения этих ситуаций в Linux есть стандартный инструмент ротации логов — logrotate.

На примере логов веб-сервера работает он так. Раз в сутки (время можно задавать) файл лога, например, access.log переименовывается logrotate’ом в access.log.1 и проходит через gzip-сжатие, после чего получает имя access.log.1.gz. А вместо переименованного access.log тут же создается новый пустой файл с этим именем, куда и продолжает писаться информация о посещениях. На следующие сутки, уже при наличии файла access.log.1.gz, аналогично создается файл уже с именем access.log.2.gz, таким же образом далее все дни. Количество хранимых архивов и период можно настроить.

По такому же принципу ротируются логи и других служб — FTP, почтовой службы, системные логи.

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

Чтение лог-файлов

Логи бывают разные, как и способы их чтения.

Стандартным советом для просмотра содержимого текстового файла был бы совет использовать команду:

Однако, в случае когда логи объемны и, например, активно ведутся целый день, команда cat вывалит на вас гору информации, неудобную для просмотра.

Она может быть полезна, только если вы ищите сразу в логе что-то определенное, например, ошибку:

cat имя.лога | grep err

Но даже в этом случае ошибку можно поискать сразу командой grep :

grep ‘err’ имя.лога

Без поиска же более логичен в данном случае просмотр лога через инструмент tail :

tail имя.лога — выведет последние 10 строк журнала,
tail -n 100 имя.лога — выведет последние 100 строк журнала, числовое значение можно менять в зависимости от необходимого числа строк,
tail -f имя.лога — просмотр лога в «прямом эфире», т. е. все поступаемые в лог записи тут же обновляются на экране, удобно для отслеживания ошибок, появляющихся после определенных действий.

Ну, а если все же требуется прочитать весь объемный лог или как минимум пробежаться глазами для отслеживания событий, для этого есть более удобный, чем cat, инструмент less :

less имя.лога — покажет первую страницу лога (те строки, которые поместятся на экран консоли), пролистывать можно клавишами «вверх»/«вниз» (построчно) и PageUp/PageDown (постранично).

Важно, для выхода из просмотра в less , просто нажмите клавишу q .

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

После ввода необходимой части текста, нажмите Enter , все участки текста, которые подходят условиям поиска, будут подсвечены.

Для быстрого перехода в конец файла, нажмите клавишу G , для перехода в начало файла — g .

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

Технологический журнал в 1С

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

Общая информация

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

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

Технологический журнал может продуцировать два вида информации:

Логи — файлы с расширением *.log, в которых в текстовом виде храниться информация о произошедших событиях;
Дампы — файлы с расширением *.mdmp, в которых хранится содержимое оперативной памяти рабочего процесса на момент его «падения». Самостоятельный анализ дампа невозможен, так как исходный код платформы закрыт. Единственный способ проанализировать дамп — отправить его в тех. поддержку или на партнерский форум.

Включение технологического журнала

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

%LOCALAPPDATA%\1C\1cv8\dumps (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\dumps )

%LOCALAPPDATA%\1C\1cv8\logs (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\logs )

USR1CV8 — имя пользователя под которым работает сервер 1С. Логи хранятся 24 часа, при этом делятся на файлы — каждый час новый файл.

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

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

Выбор директории зависит от задачи: если нужно настроить тех. журнал для всех версий 1С, то файл настроек нужно разместить здесь:

Если настроить нужно конкретную версию, то здесь (зависит от версии):

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

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

Создание файла настроек

Теперь перейдем к содержимому файла настроек logcfg.xml.

Вначале приведем пример файла настроек:

Администрирование 1С для самых маленьких. Часть первая — разделяй и властвуй

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

Предисловие

Сначала я просто хотел написать небольшую статью о том, как мы разносили базы по службам, но в ходе углубления в этот процесс мы добавляли всякие разные штуки (мониторинг служб, потом мониторинг пользователей внутри 1С, потом прикрутили заббикс, и, наконец, пришли к CI/CD на базе 1С). В итоге я понимаю что пихать это в одну статью будет слишком — решил разделить на несколько. Ну а название навеяно циклом статей «сети для самых маленьких», которые принесли мне много приятных минут и к которым я отсылаю всех, кто «хочет изучить сети». Итак, мы приступаем!

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

В этой статье я хочу поделиться своим опытом администрирования большого числа 1С в корпоративном секторе. Базы все разные, есть разработка, есть тестовые, все как у всех. Но их просто достаточно много. И все было хорошо, но в определенный момент проводить какие-то админские работы стало крайне тяжело и рискованно.

Какие у нас были сложности:

Подвисшая база тянула за собой перезапуск службы, а значит страдали невинные (пользователи других баз)
Было тяжело понять кто сегодня «герой дня» — какая база заняла все ресурсы
Обновление релизов — обновление одной тянуло за собой автоматическое обновление всех баз на этой службе
Ручное подключение баз пользователям, ручное изменение в случае переездов
Мониторинг
И только сейчас я понимаю что это была только вершина айсберга.

Акт первый, действие нулевое

Небольшое отвлечение на основные постулаты, осознание которых далось большой кровью и болью.

Старые версии 1С (до 8.3.11+) имеют просадку по производительности при работе в виртуализированной среде. (Источник — Гилев и собственные тесты)
Кластер есть, но с ним все крайне не просто. Возможно его доработают потом, но пока он в основном для галочки. (источник — собственный опыт)
При выборе процессора смотрите только на частоту. Процессор в 6 ядер по 3,4Ггц порвет в куски процессор на 20 ядер по 2Ггц. Проблема в том, что 1С вообще ничего не знает про параллельные вычисления. По сути это работает так — у нас есть определенное число воркеров для каждой службы, их раскидывают по процессорам, и если в каком то воркере пользователь запустил какой-то тяжелый отчет то в системе будет загружено только одно ядро процессора. Именно то, на котором работает воркер с запущенным заданием… Для БД ситуация кстати ровно обратная. (источник — Гилев, собственный опыт, опыт коллег)
Не используйте логи в «новом» формате (запись в SQLLite) — вы очень быстро столкнетесь с тем, что производительность этого решения еще хуже чем файлового варианта. (Источник — собственный опыт, опыт коллег).
По подсказкам из комментариев есть вариант вынести логи на отдельный инстанс.
В 8.3.12 обещали логи в нормальный скуль.
1С оооочень не любит IPv6. На всех серверах с 1С лучше сразу понижать приоритет IPv6 до минимума. (Источник — Гилев, собственный опыт)
Используйте для виртуальных серверов виртуальные сетевые карточки E1000. С остальными проблема по производительности (Источник — Гилев, но на собственном опыте не подтвердилось, хотя особо и не тестили)
Обслуживание баз дает хороший прирост производительности, особенно периодический пересчет итогов, а так же обслуживание индексов SQL (Источник — собственный опыт, Гилев)
Поиск причин падения 1С сродни поеданию неочищенного кактуса. Выяснить что-то толком можно только через боль, унижения и страдания. (Источник — собственный опыт)
Нет ни одного официального образа ни под один гипервизор. Про докер я вообще молчу. (Источник — сайт 1С)
Программная лицензия для сервера привязывается к — сюрприз, сюрприз — серийному номеру процессора (и еще огромному количеству параметров сервера). В эпоху повсеместной виртуализации ход потрясающий. Поясняю — активировали сервер, переехали на другую ноду, перезагрузили машину — 1С не запуститься. Расчехляйте новый активационный код. (Источник — собственный опыт, болтливая техническая поддержка 1С =))
1С — это учетная система, а не отчетная. Хотите много нормальных жирных отчетов и быстро — выводите это за рамки 1С. (Источник — собственный опыт)
У 1С есть два неоспоримых достоинства, за счет которых она будет процветать еще долго:
- стоимость самого продукта/разработчиков
- скорость разработки
  и к сожалению для российского бизнеса они являются первоочередными. А зачастую и единственными, на что вообще смотрят. (Источник — печальная реальность)
Никогда не используйте файловую шару как место под хранилище конфигураций 1С. Только службу. Иначе маты со стороны разработки о упавшем черт знает когда хранилище станут вашим неизменным спутником по жизни. (Источник — собственный опыт, опыт коллег)

Акт первый, действие первое

Первая короткая сценка из корпоративной жизни

На сцене — Админ (А), программист 1С (П1С) и представитель бизнеса (ПБ)
ПБ — У нас медленно работает программа!
А — у меня в системе все хорошо!
П1С — я все написал правильно, у меня на компьютере все работает быстро!
ПБ (робко и растерянно) — но она же долго…
А и П1С хором — у нас все хорошо, проблема на вашей стороне!

Проблемы всегда случаются не вовремя (с) (5-летний философ)

И вот в одно прекрасное солнечное утро (на самом деле это была глубокая зимняя ночь) мы поняли что завтра надо запустить новую базу. Завтра наступал тот прекрасный день, который уже много раз описывался тысячами авторов и имя ему — легион! Тьфу, простите, занесло. Имя этому дню был дедлайн. Час ночи, завтра на 200 компах должна запуститься новая база.» Да не проблема, у нас же все компы в домене! Сейчас быстренько сделаем логин-скрипт и дело в шляпе!» подумаете вы. И будуте правы — так же подумали и мы. И сделали. Только, как обычно это бывает, погорели на мелочи — я в логон-скрипте я прописал %filename%.bat а коллега выложил %filename%.cmd.

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

Но мысль автоматизации этого процесса у меня в голове засела очень крепко и стал даже вырисовываться план внедрения.

В итоге мы пришли к следующей идеологии:

Все раздается через AD — создаются группы вида 1cbases-%версия платформы%-%имя базы% и туда силами хелпдеста добавляются пользователи, которым нужна база.
- одна группа — одна база
- 1cbases — это префикс по которому удобно искать группы
- версия платформы 81, 82 и 83 (релиз не принципиален)
- название базы соответствует имени файла с настройками
Как мы это делали:
1. Через групповые политики добавляется новое задание в планировщик (задача планировщика прописать пользователю путь к файлу подключения базы):
  - запускать от имени пользователя
  - событие — разблокировка компьютера
  - действие — запуск нашего скрипта
2. Создаем нужные группы в АД и заполняем их пользователями
3. Создаем нужные файлы для запуска самих 1С. Тут остановлюсь чуть поподробнее. Изначально мы долго мучили интернет своими запросами и нашли полное описание структуры файлов *.v8i. Но потом нашелся способ проще и гениальнее.
  - запускаем 1С
  - настраиваем подключение к базе
  - проверяем что все работает
  - кликаем правой клавишей по названию базы и выбираем пункт — «Сохранить ссылку в файл»
Код скрипта:
```
#Первым шагом создаем место для логов if (Test-Path "$env:HOMEDRIVE\!script_report\add_1c_bases_report.txt") < Remove-Item "$env:HOMEDRIVE\!script_report\add_1c_bases_report.txt" -Force -ErrorAction SilentlyContinue; >New-Item "$env:HOMEDRIVE\!script_report\add_1c_bases_report.txt" -ItemType file -Force -ErrorAction SilentlyContinue; Add-Content -Value ("Дата последнего запуска: " + (Get-Date -Format F)) -Path "$env:HOMEDRIVE\!script_report\add_1c_bases_report.txt"; if ( (gwmi Win32_OperatingSystem | select Caption, CSDVersion) -notlike "*server*") # запрет запуска на серверных ОС < Add-Content -Value "Операционная система распознана как клиентская" -Path "C:\!script_report\add_1c_bases_report.txt"; if (!(Test-Path "$env:APPDATA\1C\1CEstart\ibases.v8i")) #если нет этого файла 1С подтягивает данные из списка баз 8.1 и игнорирует список баз 8.2 < New-Item "$env:APPDATA\1C\1CEstart\ibases.v8i" -ItemType file -Force; # Создаем этот файл если его нет Add-Content -Value "Файл $env:APPDATA\1C\1CEstart\ibases.v8i не найден, создали его" -Path "C:\!script_report\add_1c_bases_report.txt"; >if (Test-Path "$env:APPDATA\1C\1CEstart\1CEStart.cfg") < Remove-Item "$env:APPDATA\1C\1CEstart\1CEStart.cfg" -Force #-ErrorAction SilentlyContinue #удаление старого конфигурационного файла для 8.1 >New-Item "$env:APPDATA\1C\1CEstart\1CEStart.cfg" -ItemType file -Force #создание нового конфигурационного файла для 8.2 $GroupList = ([ADSISEARCHER]"samaccountname=$($env:USERNAME)").Findone().Properties.memberof -replace '^CN=([^,]+).+$','$1' # Создание списка групп пользователя foreach ($Group in $GroupList) # генерация списка общих баз на основе имени группы < if ($Group.Length -gt 6) # Проверка длины имени группы < If ($Group.Substring(0,7) -eq "1cbases") # вычисление группы указывающей на базу 1С < Switch ($Group.Substring(8,2)) # выбор платформы 8.1 или 8.2 < "81" # Создание строчки из файла со списком общих баз для 8.1 "82" # Создание строчки из файла со списком общих баз для 8.2 "83" # Создание строчки из файла со списком общих баз для 8.3 > Add-Content -Value ("Пользователь принадлежит групп $Group") -Path "C:\!script_report\add_1c_bases_report.txt"; Add-Content -Value ("Добавлено значение: CommonInfoBases=\\gold585.int\TechFiles\CommonBases\" + $Group.Substring(11) +".v8i") -Path "C:\!script_report\add_1c_bases_report.txt"; > > > > else
```
1. Добавление баз теперь не было морокой — просто делали группу, добавляли файл с настройками — дальше все происходило автоматом
2. Могли спокойно переносить базы куда угодно, просто меняя конфигурацию в файле с настройками подключения к базе (как показала практика — очень удобно)
3. Сберегли обувь хелпдеску
Акт первый, действие второе

Вторая короткая сценка из корпоративной жизни

На сцене — Админ (А), программист 1С (П1С), разговор после ухода представителя бизнеса
А — Ваш этот 1С — $#%но. Сколько можно решать железом проблемы архитектуры и уровня разработчиков!
П1С — да это ваши сервера #$@но! У меня на локальной файловой базе все летает! Настройте уже ваше хозяйство по нормальному!
Спорщики удаляются со сцены сыпля взаимными обвинениями, опускается занавес, свет гаснет.

И с этой стороны ни чуть не лучше… (с) печальный ослик Иа-Иа в свой собственный день рождения

Вот представьте себе — сидите вы в удобном кресле, в одной руке чашка вкусного чая, в другой пышущая жаром и свежестью булочка из кулинарии ближайшего магазина, за окном приятно пахнет весной… И это, конечно же, самое подходящие время для звонка с проблемой! Коллега — Байконур, у нас %@па!

Я — я так понимаю что стадию Хьюстона с проблемами мы уже успешно пролетели?
Коллега — да. База %имя базы% подвисла, вообще не отвечает, ТОПы уже рвут и мечут. 3 раза мне уже звонили. Надо перезагружать службу.
Я — так там же еще пачка баз на этой службе.
Коллега — да, поэтому вторая половина ТОПов тоже рвет и мечет что их отключат.

В итоге конечно все согласовали, перезапустили, но осадочек остался.
1. В продуктовой среде мы должны следовать правилу — одна база — одна служба с разнесением по портам
2. Запускаться службы должны исключительно из-под доменных учеток. Одна служба — одна учетка. Это удобно для раздачи прав на шары, доступ в скуль и прочее. Так же, если у вас внедрена RBAC то вы можете очень оперативно посмотреть куда имеет доступ конкретный экземпляр 1С
3. Логи нужно вынести на отдельный диск и включить на эти папки сжатие (при разбитии по дням это очень сильно экономит место и ускоряет (незначительно) поиск по логам)
4. Каждой службе выдается alias в DNS для того, чтобы отвязать разработку от ip и/или dns сервера (в этом случае разработка вообще не волнуется на предмет того, где фактически находится сервер — физика, виртуальная машина в приватном облаке или вообще в публичном облаке)
5. На каждую службу мы выделяем 500 портов для пользовательских соединений (наше внутреннее решение)
Как мы это делали (для нового сервера. для уже существующего часть шагов не актуальны):
1. Создаются учетки под каждую службу
2. На машине, где они будут работать им выдаются права на «запуск как службе»
3. Ставиться MS офис, обязательно с активацией по MAK-ключу
4. Ставится sqlncli — утилита из набора MS SQL Native Client. На данный момент выше 2012 не появлялось
5. Создается папка C:\Windows\SysWOW64\config\systemprofile\Desktop — в противном случае есть проблемы с выгрузками в Word/Excel
6. Для Windows 2016 и 1С 8.1 нужно скопировать старую версию dll (В папке C:\Program Files\Common Files\System\Ole DB надо заменить два файла sqloledb.dll и sqloledb.rll взятых со старых серверов)
7. Ставятся дополнительное ODBC драйверы, если нужно подключатся к MySQL/PostgreSQL
Настройка папки для службы и логов:
1. Создается папка на отдельном диске называется в формате 1CServer%basename% (в стандартном случае это делает сама служба, ибо у нее есть в настройках запуска путь к логам)
2. Если внутрь каталога только что созданной службы переносятся данные из другого каталога (другой службы, другого сервера), то необходимо заменить владельцев (иначе служба не получит к ним доступа) с заменой владельца подконтейнеров
3. Владельцем папки делается учетная запись службы
Описание настройки службы
```
@echo off chcp 1251 установка кодировки set base=%base_name% название базы без пробелов на английском – для каталога с логами set dsce=%base name% название базы с пробелами на английском – для имени службы set dscr=%Имя базы% название базы на русском – для представления службы set sver=8.3 краткая версия – для имени и представления службы set fver=1cv8\8.3.9.2170 часть пути к нужной нам версии платформы 1С set port=8040 управляющий порт set regp=8041 основной порт set rnge=8060:8491 диапазон портов для службы set name="1C:Enterprise %sver% Server Agent (x86-64) %dsce%" имя службы (для реестра) по аналогии с типовыми, только добавляется название базы для уникальности названий set bpth=\"C:\Program Files\%fver%\bin\ragent.exe\" -srvc -agent путь к исполняемому файлу для запуска службы set logs=D:\1C_Server_%base% каталог для логов set user="%login%@%domain_name%" такой формат позволяет использовать логины длиннее 20 символов пароль нигде не указывал при создании, потому что потом всё равно надо его заново указать, только тогда у пользователя будут права на запуск служб; set view="Агент сервера 1С:Предприятия %sver% (x86-64) %dscr%" представление службы в оснастке sc create %name% binPath= "%bpth% -regport %regp% -port %port% -range %rnge% -d \"%logs%\"" type= "own" start= "auto" error= "severe" depend= "Tcpip/Dnscache/lanmanworkstation/lanmanserver" obj= %user%DisplayName= %view% тут: type= "own" – тип службы, какие бывают еще сам посмотри start= "auto" – автоматический запуск error= "severe" – не помню что значит, но устанавливает правильное значение ключа в реестре ErrorControl = 2 depend= "Tcpip/Dnscache/lanmanworkstation/lanmanserver" – зависимости (на четвертой вкладке указаны, вручную не настраиваются) sc description %name% %view% задает представление в оснастке, сразу при создании не указывается sc failure %name% reset= 0 actions= "restart/0" настройка на вкладке восстановление – перезапуск во всех случаях, через 0 минут; сброс счетчика через 0 дней То же самое без комментариев: @echo off chcp 1251 set base=%base_name% set dsce=%base name% set dscr=%Имя базы% set sver=8.3 set fver=1cv8\8.3.9.2170 set port=8040 set regp=8041 set rnge=8060:8491 set name="1C:Enterprise %sver% Server Agent (x86-64) %dsce%" set bpth=\"C:\Program Files\%fver%\bin\ragent.exe\" -srvc -agent set logs=D:\1C_Server_%base% set user="%login%@domain.company" set view="Агент сервера 1С:Предприятия %sver% (x86-64) %dscr%" sc create %name% binPath= "%bpth% -regport %regp% -port %port% -range %rnge% -d \"%logs%\"" type= "own" start= "auto" error= "severe" depend= "Tcpip/Dnscache/lanmanworkstation/lanmanserver" obj= %user% DisplayName= %view% sc description %name% %view% sc failure %name% reset= 0 actions= "restart/0"
```
1. Для того, чтобы в службах не было кроказябр
  - в cmd ввести команду chcp 1251
  - файл надо сохранить в ANSI кодировке
2. Обязательно надо проверить на отсутствие дублирующих ключей в строке запуска — служба с ними не стартует.
3. Для того, чтобы удалить службу, можно воспользоваться командой — sc delete «Имя заданное в переменной name»
4. Добавить порты используемые 1С в разрешения в firewall
5. Нужен всего один физический ключ на сервер — все службы будут активироваться им
После проведения всех мероприятий в итоге мы пришли к:
1. Базы можно спокойно перезагружать, не трогая другие базы
2. Всегда можно найти «героя» — базу, которая съедает все ресурсы
3. Любые работы с базой касаются только одной конкретной базы
В следующих статьях я планирую рассказать (если эта статья народу зайдет):
- как мы перевели авторизацию в MSSQL на kerberos и вообще оптимизировали доступы
- как мы сделали мониторинг служб — кто сколько занял ресурсов
- как мы сделали мониторинг внутри службы 1С выявления блокировок пользователями быстрее, чем они позвонят
- как мы пытались внедрить CI для 1С и что из этого вышло
UPD. Дополнил кое-что по комментариям
Похожие публикации:

Где почитать логи службы сервера 1с