Неделю мы искали, почему задание отрабатывает вхолостую, и всё это время оно вообще не запускалось. В истории механизма 580 записей, и все до одной поставлены руками: автоматических нет ни за один день с апреля 2025-го. Ошибок при этом ноль, потому что ошибке негде было возникнуть. Первую версию - задание пропускает запуск, увидев недавний успех - убил замер: четыре дня молчания после того, как мы расчистили состояние. Показываю весь перебор причин, ложную улику с расписанием, из-за которой расследование ушло в сторону на несколько дней, и то поле карточки, которое всё это время решало. Перебор собран списком по порядку проверки, так что по нему можно пройти свою базу.
Кто потребляет больше всех и что изменилось - два разных вопроса, и деградацию объясняет только ответ на второй. На сервере 1С, который начал грузить процессор, первым под подозрение попал обмен, и ряд запусков за двенадцать суток показал, что запускается он так же, как раньше. Дальше шесть мест, где расследование могло свернуть не туда, от службы печати с почти целым ядром до пустых файлов технологического журнала, и приём, которым нужный сервис кластера нашли без перезапуска агента. Корневая причина в разборе не названа, текст говорит об этом сразу.
Код не меняли год, а операция, которая раньше шла секунду, стала идти минуту. Виноват в таком обычно не код, а то, что данные перешли порог: у квадратичного алгоритма удвоение объёма стоит четырёхкратного роста работы, поэтому поломка не подкрадывается постепенно, а наступает сразу. В разборе - случай коллеги, где сервис деградировал месяц. Три объяснения закрыли замером, а развязку дал профиль на 16 642 снимках: 80,0 % процессорного времени в одной функции, которую при этом нельзя было чинить. Разогнали её 20 копий одного документа по 443 581 байту, наплодил их собственный экспортёр сервиса. Дальше - как отличить квадратичный рост от линейного двумя замерами, где такие места прячутся в коде 1С и что делать, если урезать боевую базу вдвое нельзя.
Платформа 1С давно вышла за рамки учетных систем. Сегодня это полноценная среда для создания сложных, высоконагруженных и распределенных приложений. А значит, и стек технологий современного разработчика кардинально изменился. Систематизируем весь инструментарий, который превращает 1С-программиста в инженера: от EDT и Git до автотестов на YAxUnit, контейнеризации приложений в Docker, мониторинга в Prometheus и организации шины данных на Kafka. Разберемся, зачем каждый инструмент нужен, как он вписывается в жизненный цикл разработки и с чего начать его внедрение.
Почему счётчики кластера не отвечают на вопрос и как спросить по-человечески. Подход вопрос вместо метрики, семь вопросов о нагрузке, и техника, без которой это не работает: зерно снимка агрегат, сетевой каталог для многоузлового кластера, определение своей базы по сеансу, версия RAS под сервер.
Три пакетных файла проверили на то, что они на самом деле возвращают.
Один сообщал об ошибке при успешном завершении, два возвращали ноль после провала. Мониторинг по кодам возврата на этой цепочке горел бы красным там, где всё хорошо, и молчал бы там, где работа не делалась тридцать пять дней.
Началось всё со скучной сверки расписания с журналом, а кончилось матрицей, в которой два шага из пяти стоят с нулём при шести прогонах из шести у соседей. Шаг, отработавший шесть раз, всё это время строил результат по срезу от десятого июня: сорок один день одних и тех же данных. Разбираю три механизма, каждый из которых превращал провал в зелёную строку отчёта, и почему единственная метрика, которая поймала бы всё сразу, - возраст данных внутри результата. Плюс честные границы: что после починки не замерили и какой вывод статьи на площадке так и не внедрили.
Мониторинг блокировок сам оказался старейшей открытой транзакцией в базе: сеанс спит, блокировок по нему ноль, транзакция висит четверо с половиной суток. Порог в его собственном запросе - пять секунд, свою транзакцию он продержал порядка восьмидесяти тысяч таких порогов и себя ни разу не заметил. Ни в один отчёт "кто кого блокирует" такой сеанс не попадает: никто никого не ждёт.
Это четвёртый из четырёх механизмов, разобранных в статье. Остальные три: один текст ошибки на две совершенно разные причины, из-за которого уходят в разбор графов вместо одной правки обработчика; кольцевой буфер диагностики, обнуляемый переключением основного узла; события, записанные под чужим именем базы, из-за чего запрос отдаёт ноль строк там, где данные лежат.
По каждому разобрано, как он выглядит, чем отличается от настоящей пустоты и что с ним делать.
Если в журнале регулярно всплывает deadlock, а пользователь жалуется на документ, которого в отчёте о взаимоблокировке вообще нет, эта статья про то, как искать настоящего виновника.
Главный вывод: разбирать один deadlock бесполезно. Один случай не отличить от совпадения, а картину даёт только частота: какие объекты повторяются во всех отчётах сразу.
Внутри готовый SQL-запрос, который разворачивает список ресурсов в таблицу частот, и три грабли на нём. Плюс четыре ложных следа, на которые мы потратили часы, и объяснение, почему объект из жалобы виноват не был.
Чем закончилось: помогла одна галочка на реквизите, а замер до и после показал разницу на два порядка по логическим чтениям. Есть и раздел про цену этого решения, которую мы не измерили.
Если у вас интеграционная шина и обмены иногда встают непонятно почему, эта статья про то, где искать.
Главный вывод за год эксплуатации: очереди самой шины виноваты редко. Отставание копится на стороне 1С, и обычный мониторинг длины очереди его не ловит совсем: очередь короткая, всё зелёное, а канал стоит сутки.
Внутри пять поломок, которые не воспроизводятся на тестовом стенде и вылезают только на длинном непрерывном аптайме, и три случая, когда шина отчиталась «доставлено», а данные в базу не приехали. По каждой: симптом, куда мы полезли сначала и почему мимо, настоящая причина и что помогло.
Отдельно история про то, как врал наш мониторинг, и как проверить свой за полчаса.
В конце чеклист на двадцать пунктов: что задать в контейнере до первого запуска, что мониторить кроме длины очереди и чем рестарт шины отзовётся в базах-приёмниках.
Готовый модуль трейсинга операций для 1С: создание спанов со стеком, наследование TraceID, поддержка распределённых трейсов (фоновые задания, HTTP, интеграции), гарантированное завершение спанов при любом исходе и граничный режим «отката» стека. Все данные пишутся в журнал регистрации в JSON-виде и визуализируются в отдельной обработке — с деревом спанов, длительностями, статусами, атрибутами и ошибками.
Небольшой графический монитор происходящего в 1С. Показывает в реальном времени, что происходит в базе - входы пользователей, изменения объектов, ошибки, фоновые и регламентные задания, нагрузку на сам журнал регистрации. Умеет ловить события по правилам и показывать уведомления.
Разбираем, как подготовить Шину 1С к промышленной эксплуатации и обеспечить непрерывность интеграционных процессов при сбоях, обновлениях и недоступности отдельных узлов. Показываем варианты отказоустойчивой архитектуры – от подтверждения обработки сообщений до активно-пассивной и активно-активной схем с двумя экземплярами шины. Рассказываем, как контролировать инфраструктуру и потоки сообщений с помощью штатных и пользовательских метрик, а также как защитить продуктовую шину от случайного подключения копий баз с теми же учетными данными.
Когда пользователи формулируют проблему как «1С тормозит», они описывают не техническую причину, а наблюдаемый эффект. В средних и крупных организациях за одной и той же жалобой могут находиться принципиально разные механизмы: насыщение вычислительных ресурсов, ожидания в СУБД, блокировки, неэффективные запросы, ошибки сервера 1С, конкуренция с регламентными заданиями или особенности прикладной логики.
Практический гайд по применению DevOps-практик в 1С-инфраструктуре: контейнеризация СУБД, инфраструктура как код, мониторинг с алертами, автоматические бэкапы.
Разбираю подводные камни и делюсь готовыми конфигами.
Для 1С-разработчиков, которые хотят автоматизировать рутину и приблизиться к продакшен-среде.
Интеграция SIEM с 1С помогает выстроить централизованный контроль безопасности и выявлять инциденты на уровне бизнес-системы – от несанкционированных действий до аномалий в работе пользователей. Разбираемся, как работают сбор, нормализация и корреляция событий, и какие сценарии стоит отслеживать в 1С в первую очередь. Объясняем, какие подходы к интеграции доступны и какие результаты можно получить на практике, а также как использование SIEM снижает риски утечек и повышает общий уровень защиты информационных ресурсов компании.
Рассмотрим разнообразные подходы к мониторингу 1С.
Организация мониторинга публикаций на IIS при помощи ELK.
Мониторинг состояния базы при помощи zabbix и rac.
Прямые запросы при помощи самописных скриптов из zabbix.
Объясняем, как связка Prometheus и Grafana помогает выстроить прозрачный и масштабируемый мониторинг: от первых шагов до продвинутых сценариев работы. Учимся собирать метрики, подключать экспортеры, настраивать Push-gateway, визуализировать данные и строить собственные дашборды. Разбираемся, как контролировать сотни и тысячи показателей, включая бизнес-метрики, и как настроить интеграцию Prometheus с 1С. Материал расширяет технический кругозор и демонстрирует, как поднять рабочий мониторинг за 15 минут.
В логах содержится огромное количество полезной информации о том, как «живет» система: какие процессы в ней выполняются, и какие ошибки возникают. Расскажем о том, как выстроить централизованное хранение и обработку разрозненных логов, превратив их в полезный инструмент анализа и диагностики.
Делимся опытом поддержки баз 1С с более чем 6 000 одновременно работающих пользователей и рассказываем о ключевых подходах к контролю высоконагруженных систем. Рассмотрим реальные кейсы и дадим ответ на вопрос о том,: что точно надо контролировать. Сравним ElasticSearch и ClickHouse, дадим ссылки на статьи и репозитарии для быстрого старта, а также посмотрим на примеры рабочих столов для анализа логов технологического журнала в ElasticSearch.
Рассказываем, почему высоконагруженным бэкендам на 1С нужен регулярный мониторинг и что происходит, когда его нет: производительность и стабильность деградируют, а обращения пользователей копятся. Показываем, как построили легкую систему наблюдаемости для бэкендов корпоративных порталов. Она включает сбор метрик из технологического журнала, Apdex, журнала регистрации и динамики размеров таблиц с последующим анализом в связке ClickHouse и служебной информационной базы на 1С. Объясняем, какие отчеты и метрики быстрее всего помогают находить критичные проблемы производительности, и демонстрируем интерфейс расследования. Разбираем несколько кейсов оптимизации, найденных по итогам мониторинга, включая доработки функционала БСП «управление доступом» и «присоединенные файлы».
Когда речь заходит об инфраструктуре 1С, кажется, что все работает как часы: пользователи выполняют свои задачи, отчеты формируются без сбоев, зарплата начисляется вовремя. Как только начинается замедление базы, фоновые задания начинают зависать, а в службу поддержки поступают жалобы от раздраженных пользователей — ситуация требует вмешательства.
Необходимо внедрить базовый мониторинг 1С, чтобы избежать неприятных моментов и минимизировать простой системы. Правильно организованный мониторинг не только помогает своевременно выявлять и предотвращать большинство проблем, но и существенно облегчает диагностику в случае сбоев. При этом не требуется больших затрат или сложных ИТ-решений — базовый и при этом эффективный мониторинг можно реализовать быстро, просто и без лишних сложностей.
В статье я расскажу, как организовать такой мониторинг, не изобретая велосипед и используя проверенные практики. Но для начала разберемся, зачем вообще мониторить 1С.
Мониторинг в ландшафте 1С помогает не только вовремя выявлять проблемы и повышать SLA, но и укреплять информационную безопасность. Разбираем источники данных, ограничения штатных инструментов и современные практики мониторинга на базе Prometheus, ClickHouse и Grafana. А также рассказываем о коробочном решении «Оркестратор 1С-систем» и планах его развития.
Рассказываем, куда смотреть после миграции на PostgreSQL: как диагностировать нехватку или избыток буферного кэша, отслеживать работу автовакуума, репликации и чекпойнтера. На основе реальных аудитов покажем ключевые инструменты мониторинга и научим правильно интерпретировать их данные.
Администраторы следят за серверами и оборудованием, но кто следит за 1С? Показываем, как на базе только стандартного стека 1С упаковать RAS и построить простую систему мониторинга и оповещений без КИП, ТЖ и сложных инструментов. В статье – рабочие приемы, паттерны и лайфхаки, которые позволяют вовремя реагировать на проблемы и получать аналитику без лишних затрат.
Возникновение нештатных ситуаций при эксплуатации высоконагруженных и распределенных систем неизбежно. Для снижения рисков, связанных с простоем системы, используется мониторинг. В статье речь пойдет о том, какие в Почте России ставятся задачи мониторинга, каким образом они решаются, и какие инструменты для этого используются.
Если развернуть слепок рабочей среды в окружении для тестирования, тесты могут начать взаимодействовать с рабочим окружением. Расскажем о том, как автоматически перенастраивать базы 1С под окружение разработки или тестирования с помощью концепции Service Discovery.
С проблемами распухания tempdb при работе с базой данных 1С регулярно сталкиваются и админы, и разработчики. О том, как мониторить, диагностировать и решать такие проблемы, на конференции Infostart Event 2021 Moscow Premiere рассказал Александр Криулин.
Как быстро познакомиться с системой на новой работе или если вас пригласили провести аудит контура на 1С? О том, какие инструменты использовать для быстрой проверки настроек сервера 1С, сервера MS SQL и общей оценки инфраструктуры на производительность, на конференции Infostart Event 2021 Post-Apocalypse рассказал архитектор 1С Юрий Былинкин.
Если с системой что-то может случиться, это рано или поздно случится. О том, как научиться узнавать о проблемах не только от пользователей, а, возможно, и прогнозировать их заранее, на конференции Infostart Event 2021 Moscow Premiere рассказал системный архитектор ООО «Серебряная пуля» Артем Кузнецов.
Приложение на мобильной платформе 1С Предприятие, позволяющее разбирать все, что может быть разобрано в командной строке linux, и выводить полученный результат типовыми методами системы компоновки данных. По мотивам направления Эксперт по технологическим вопросам
Организация потокового обмена системы 1С с большим количеством разнородных устройств – нетривиальная задача. О том, как организовать архитектуру такого решения с учетом возможного масштабирования хранимых данных и поддерживаемых интерфейсов, на конференции Infostart Event 2021 Post-Apocalypse рассказал TeamLead и специалист по внедрению компании ИнфоСофт Григорий Шатров.
Программа для тестирования вашей инфраструктуры 1С. Анализ ключевых параметров оборудования и ПО серверов 1С и MS SQL, поиск ошибок в базах 1С на стороне MS SQL, тестирование производительности серверов MS SQL и 1С, обмен результатами замеров с сообществом, построение отчета.
Специалист по информационным системам в компании «Камин-Софт» Алексей Федотов выступил на митапе Инфостарта, посвященном работе 1С и Linux. Алексей поделился с коллегами, как контролировать работу 1С на Linux с помощью Zabbix.
