Как связать дедовский 1С и модный Kubernetes в одном дашборде

В большинстве российских компаний 1С и облачная инфраструктура работают параллельно и никак не пересекаются. DevOps-команда смотрит на метрики в Grafana, финансовый директор смотрит в 1С, а когда падает сервис оплаты — все смотрят друг на друга и ждут, кто первым начнёт разбираться.

Технически связать их реально за один спринт. Платформа 1С умеет отдавать данные через REST API по протоколу OData ещё с восьмёрки — достаточно опубликовать базу на веб-сервере. Kubernetes отдаёт метрики через Prometheus. Grafana умеет читать оба источника одновременно.

В статье, как это сделать на практике: какие данные вообще стоит тащить из 1С в общий дашборд, где обычно ломается интеграция и как не превратить это всё в очередную ФИЧУ, которая падает каждый раз после обновления конфигурации.

Что умеет 1С в плане интеграции

Забудьте о том, что 1С — это закрытая коробка, к которой можно обращаться только через COM-соединение или выгрузки текстовых файлов на FTP. Современная 1С — это нормальный HTTP-бэкенд, если правильно включить тумблеры.

REST API и OData из коробки

Вам не нужно писать ни строчки кода на 1С, чтобы вытащить из неё метрики. Платформа умеет автоматически генерировать REST-интерфейс для всех объектов конфигурации сразу после публикации базы на веб-сервере (обычно это Apache или IIS).

Под капотом работает открытый протокол OData 3.0. 1С честно принимает HTTP-запросы и отдаёт чистый JSON. Хотите посмотреть количество открытых заказов? Стучитесь GET-запросом к документу. Нужны остатки на складе? Спрашиваете виртуальную таблицу регистра накопления.

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

КОД

OData поддерживает фильтрацию прямо в URL. Если вам нужны только заказы за конкретный период или больше определённой суммы, вы передаёте это в параметре $filter, и 1С сама собирает нужную выборку на стороне базы данных.

HTTP-сервисы внутри конфигурации

OData отдаёт данные «как есть», повторяя структуру таблиц 1С. Иногда это слишком тяжеловесно. Например, если для дашборда вам нужна одна цифра «Сумма продаж за час», через OData придётся вытягивать массив заказов и суммировать их на стороне Kubernetes.

Для таких случаев в 1С есть HTTP-сервисы. Это кастомные эндпоинты, которые 1С-разработчик пишет прямо в конфигураторе. Вы договариваетесь с ним о контракте, он пишет код, который внутри 1С сам считает нужные метрики и отдаёт наружу лёгкий JSON в нужном вам формате.

Плюс: идеальная подгонка под архитектуру, меньше трафика, работает быстро. Минус: каждый такой эндпоинт придётся поддерживать и тестировать при обновлениях основной конфигурации.

Файловый обмен как запасной вариант

Случаются ситуации, когда безопасники отказываются открывать HTTP-порты сервера 1С наружу, или база крутится в закрытом контуре.

Здесь работает старый добрый асинхронный обмен. В 1С настраивается регламентное задание, которое собирает нужные метрики и складывает их в JSON-файл в общую сетевую папку или S3-хранилище. Exporter на стороне K8s просто читает этот файл по расписанию.

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

Как устроен стек на стороне Kubernetes

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

Prometheus собирает, Grafana показывает

Стандартный стек наблюдаемости (observability) в Kubernetes состоит из двух главных компонентов.

• Prometheus — это база данных временны́х рядов. Он работает по pull-модели: у него есть список эндпоинтов, он ходит по ним с заданной частотой (например, каждые 15 секунд), забирает текущие значения метрик и складывает к себе в хранилище.

• Grafana — она ничего не хранит и ничего не собирает. Она отправляет PromQL-запросы в Prometheus, получает массивы чисел и отрисовывает их в панели.

Чтобы 1С появилась в Grafana, нам нужно научить Prometheus её опрашивать. Но Prometheus ждёт метрики в своём специфическом текстовом формате (вида orders_count{status="new"} 42), а 1С отдаёт JSON через OData. Нужен переходник.

Prometheus Exporter как мост к 1С

Этот переходник называется exporter. Технически это микросервис, который принимает запрос от Prometheus, идёт в 1С, парсит JSON-ответ и выдаёт его в нужном формате.

Пишется он элементарно. Вот рабочий пример на Python с использованием официальной библиотеки prometheus_client:

КОД

Вы упаковываете этот скрипт в Docker-образ, деплоите в Kubernetes как обычный под (Deployment) и вешаете на него Service. После этого добавляете в конфиг Prometheus новую job'у для скрейпинга вашего экспортера. Готово — метрики 1С лежат в Prometheus рядом с метриками CPU ваших подов.

Loki для логов рядом с метриками

Цифры (метрики) — это половина картины. Иногда для разбора инцидента нужны тексты ошибок: почему конкретно не провелась накладная или отвалился обмен с банком.

В экосистеме K8s за логи отвечает Loki — он умеет принимать структурированные логи и отдавать их обратно.

Если настроить выгрузку журнала регистрации 1С в сторону Loki (например, через тот же exporter или агент сборки логов), вы получаете ультимативный дашборд. На одном экране в Grafana у вас будет график падения сетевого трафика в кластере, график падения чеков из 1С, а прямо под ними — таблица с текстами ошибок из базы за ту же самую минуту.

Где обычно ломается

Интеграция 1С и K8s кажется простой только в теории, по факту — это две разные системы. Если запустить мониторинг по принципу «написали скрипт и забыли», он упадёт в первый же месяц. И вот почему.

Обновления конфигурации 1С

Главный враг любой OData-интеграции — релизный цикл самой 1С. OData жёстко завязана на имена объектов в базе данных.

Программист 1С переименовал реквизит СтатусОплаты в СтатусДокумента? Ваш Python-экспортер упадёт с ошибкой KeyError, метрики перестанут собираться, а дашборд в Grafana замрёт на старых значениях. HTTP-сервисы ведут себя аналогично — если в очередном релизе поменяли логику сбора данных, старый эндпоинт сломается.

Как чинить: Во-первых, договориться об API-контракте. Во-вторых, добавить в CI/CD пайплайн на стороне 1С банальный автотест: после сборки релиза дёргаем тестовые OData-запросы. Если тест упал — значит, обновление ломает мониторинг, и релиз останавливается.

Авторизация и сетевая доступность

Исторически 1С — это глубокий бэкофис, закрытый файрволами. Kubernetes живёт либо в облаке, либо в выделенном контуре. Подружить их по сети — это всегда квест через службу безопасности.

OData умеет в Basic-авторизацию, но слать логины-пароли в открытом виде между кластером и 1С — плохая идея.

Минимально рабочий вариант: поставить перед 1С API Gateway (тот же Nginx или Kong), закрыть его на mTLS (взаимную аутентификацию по сертификатам) и пускать внутрь только IP-адреса подов вашего экспортера. Пароль от учётки 1С должен лежать в Kubernetes Secrets, а не хардкодиться в Python-скрипте.

Разные ритмы данных

У DevOps-инженеров и аналитиков 1С разное восприятие времени. Prometheus собирает метрики CPU каждые 15 секунд. 1С может рассчитывать себестоимость раз в час или перепроводить документы задним числом.

Если натравить ваш Python-экспортер на тяжёлый OData-запрос (например, «собери-ка мне все чеки за сегодня и посчитай среднее») каждые 15 секунд, 1С просто ляжет от количества соединений. А если опрашивать 1С раз в 10 минут, то график на фоне метрик Kubernetes будет выглядеть рваным.

Как чинить: В Grafana есть настройка Min step для каждой панели. Разделите экраны: метрики K8s пусть обновляются раз в 15 секунд, а бизнес-данные из 1С — раз в минуту или пять минут. А чтобы не класть базу тяжёлыми запросами, делайте агрегацию на стороне 1С (через HTTP-сервис), а не вытягивайте тысячи строк OData в память экспортера ради одного числа.

Пошаговый план интеграции

Разработчики Centicore Group, которые занимаются заказной разработкой и интеграцией сложных контуров, часто повторяют одно правило: не пытайтесь на первом этапе затащить в мониторинг вообще всё. Вот минимальный путь, который можно пройти за неделю без отрыва от основной работы:

1. Определите одну бизнес-метрику, которая важна SRE. Это может быть «количество чеков в минуту» или «число ошибок проведения». Не тащите всю финансовую отчётность в Grafana.
2. Опубликуйте 1С на веб-сервере. Включите поддержку стандартного интерфейса OData и проверьте, что нужный документ или регистр отдаёт JSON по HTTP.
3. Напишите Python-экспортер. Он должен делать ровно две вещи: ходить в 1С по расписанию через OData и отдавать данные в формате, понятном Prometheus. Оберните скрипт в Docker.
4. Настройте сетевой доступ. Спрячьте 1С за API Gateway. Задеплойте под с экспортером в Kubernetes и дайте ему доступ к шлюзу.
5. Настройте Prometheus. Добавьте scrape-конфиг, чтобы Prometheus начал опрашивать ваш экспортер. Убедитесь, что метрика появилась в хранилище.
6. Соберите дашборд. Выведите на один экран в Grafana технические метрики кластера (CPU, память, рестарты) и бизнес-метрику из 1С. Обязательно разведите интервалы обновления: для K8s — 15 секунд, для 1С — 1–5 минут.
7. Настройте первый алерт. Например: «Если количество ошибок из 1С > 10 за 5 минут, а в кластере есть рестарты подов — отправь уведомление в Трекер».

1С и Kubernetes — это просто два HTTP-клиента, как только вы соберёте их на одном дашборде, половина конфликтов между бизнесом и разработкой отпадёт сама собой.