Как мы используем систему мониторинга Zabbix для ритейла

    Системами мониторинга типа Zabbix искушённых пользователей не удивишь. Однако в ритейле они не частые гостьи, а если используются, то всё больше для контроля серверов. Мы же пошли дальше и применяем их для мониторинга кассового ПО и оборудования.



    Почему системы мониторинга редко встречаются в ритейле


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

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

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

    • от серверов получаем данные об утилизации процессоров, работоспособности вентиляторов, жёстких дисков, памяти, температуры процессоров и материнских плат;

    • от бесперебойников — статусы, уровень заряда, информацию о том, сколько времени они проработают в случае отключения электричества;

    • от сетевого оборудования — трафик на портах, утилизацию ресурсов.

    По части полученной информации составляются автоматические заявки в Service Desk. Ряд других данных помогает нам при расследовании инцидентов. Классический пример: пользователь жалуется, что его компьютер медленно работает. Без системы мониторинга это отследить тяжело — либо, когда подключится инженер всё уже будет в порядке, либо у сотрудника сложилось субъективное впечатление (его рабочий слабенький ПК объективно работает медленнее навороченного игрового компьютера, который стоит дома). Поэтому мы изучаем ретроспективу — графики за то время, когда человек наблюдал проблему.

    Но всё вышесказанное — банальность, ничего нового. Так уж получилось, что мы пошли дальше и с помощью Zabbix стали контролировать работоспособность кассового программного обеспечения и кассового же оборудования. Делаем это для крупных международных ритейлеров, широко представленных на российском рынке как в food, так и в non-food сегментах. Также нашу систему мониторинга приобрели некоторые региональные сетевики, которые теперь самостоятельно могут контролировать работоспособность своих бизнес-процессов.

    Почему мы стали этим заниматься


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

    С её помощью мы получаем три варианта решения проблем:

    • превентивно — устраняем проблему до того, как она случилась. Например, при мониторинге жёсткого диска видим, что место на нём сократилось до критического уровня. И принимаем в связи с этим меры;

    • постфактум — решаем проблему после того, как она случилась. Например, вышел из строя вентилятор на процессоре. Процессор пока греется, но работает. Рано или поздно он, конечно, выйдет из строя, но пока у нас есть возможность заменить вентилятор. То есть пользователь инцидент пока не заметил, но он уже есть. С его точки мы решаем проблему проактивно, но с точки зрения оборудования — постфактум;

    • аналитически — получаем большое количество данных в ретроспективе для разбора инцидентов.




    Конечно, наша система мониторинга затрагивает далеко не всё кассовое оборудование потому, что не всегда в этом есть смысл. Возьмём сканер штрихкодов. Они либо работает, либо нет. И во втором случае сотрудники магазина гораздо быстрее сообщат нам о проблеме, чем система мониторинга. Поэтому мы сконцентрировались на контроле POS-терминалов и контрольно-кассовой техники (ККТ).

    Мониторинг работоспособности ККТ


    ККТ отдаёт через драйвер достаточно информации, которая позволяет судить об её работоспособности. Например:

    • Различные инвентаризационные данные — версии железа, прошивок, драйверов, серийные номера. В общем случае состав оборудования на сервисе фиксируется в приложениях к договорам и хранится в CMDB, однако заказчик волен перемещать и заменять оборудование, как ему вздумается. Конечно, он не всегда вспоминает, что было бы неплохо уведомить об этом сервисную компанию. Тут и приходит на помощь система мониторинга, которая отслеживает изменение конфигурации оборудования. Мы написали интеграционный модуль, который корректирует CMDB согласно данным inventory из Zabbix. Кроме отслеживания реальной конфигурации оборудования на объектах обслуживания он, вкупе с функционалом автообнаружения системы мониторинга, капитально сокращает время на стартовую инвентаризацию нового клиента, если такая работа предусмотрена договором.


    Кейс из жизни: многие, наверное, помнят случай с багом в прошивке одного из производителей ККТ в декабре 2017 года? Как только появились первые сведения о проблеме, мы настроили триггер в Zabbix, сигнализирующий о содержащей баг версии прошивке, и получили список ККТ, которой необходимо срочно заняться.

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

    Контроль за кассовым ПО


    В рамках контроля кассовой программы мы мониторим различные признаки:

    • работоспособность служб — включено ПО или нет, открывает ли какие-то сетевые порты или ждёт подключения;

    • записи в логах — обычно ПО пишет в журналы о возникших проблемах, формирует свод ошибок. Как косвенный признак, если логи меняются, то ПО работает, если новых записей в них нет — значит нужно создавать заявку;

    • собственно, сами записи в логах — если встречается сообщение об ошибке, срабатывает триггер. После обработки записи передаются в ELK: Logstash у нас выгребает логи через API Zabbix;

    • результаты работы интеграционного ПО, которое закачивает, преобразовывает и отправляет данные (например, передаёт информацию в ЕГАИС, ОФД, получает номенклатуру товаров). Так, недавно неправильно сформированный пакет данных с номенклатурой вывел из строя программное обеспечение терминалов самооплаты, парализовав их работу в одном из магазинов нашего клиента. Благодаря системе мониторинга нам удалось вовремя локализовать проблему;

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

    • базы данных — отслеживаем работоспособность сервисов, доступность сетевых портов, количество баз данных, их версии и количество выключенных баз данных;

    • внешние сервисы (например, ЕГАИС, с которым мы взаимодействуем через IP сети в автоматическом режиме).




    Проблемы, которые чаще всего поступают в систему мониторинга


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

    Довольно часто приходят сообщения о некорректности локального времени. Кассовые ПК обычно не вводят в AD и службу ntp там приходится настраивать отдельно, что иногда забывается. А неправильное время на кассе чревато крупными проблемами для магазина: например, продажей алкоголя тогда, когда это запрещено, что может привести к штрафу или потере лицензии.

    Борьба с фродом и простоем оборудования


    Ещё одна сфера деятельности, где Zabbix, довольно, кстати, неожиданно, оказался полезен — борьба с фродом. Случается, что подрядчики в регионах либо отдельные полевые инженеры, которым платят сдельно, вступают в преступный сговор с пользователями заказчика и решают проблемы, которых в действительности не было. Мы их можем вывести на чистую воду, анализируя показания системы мониторинга. Пока это делается вручную, когда регистрируется подозрительный всплеск активности в какой-то определённой локации, но мы работаем над тем, чтобы в автоматизированном режиме сверять заявки с показаниями Zabbix во всех случаях, где это возможно.

    Сейчас от нашей системы мониторинга поступает от 15 до 25% заявок. Это достаточно небольшое количество, но к концу этого года хотим довести его до 50% для клиентов, которые подписали с нами договоры о сервисном обслуживании.
    Пилот
    73,00
    Компания
    Поделиться публикацией

    Комментарии 12

      0
      Как мы используем систему мониторинга Zabbix для ритейла

      И прямо на КДПВ висит пачка алертов важности «Disaster» :)
        +1
        Вы заметили!) Мы тестовую зону специально открыли)
        +1

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


        Как раз приходил ЕГАИС и прочие онлай-проверки/отчёты, видимо доросли бы и до остальных проверок что у вас реализовано.
        Интересно видеть хорошее решение коллег по бывшему цеху :)
        Молодцы инженеры что внедрили снизу и руководители что заметили какая от этого польза будет!

          0
          Спасибо, что нашли время прочитать статью!
            0
            Ребят, а не хотите вынести часть кода в github-репозиторий и рассказать как в целом это готовиться?
            Проактивный мониторинг это конечно сильное конкретное преимущество и выкладывать его в open source — себе вредить, но небольшие сети или сервис-компании однозначно скажут вам спасибо.

            Этакий обратный вклад в open source, которым все мы немного пользуемся ;)
              0
              Мы уже к такой работе готовимся, однако не на гитхабе, а на share.zabbix.com. Это как раз платформа от самих разработчиков, где пользователи могут обмениваться наработками.
                +1
                Точно, есть же такой marketplace. Но оттуда ссылки в основном ведут на гитхаб.
                Ждем! :)
          –1

          Использовал мониторинг PRTG в сети магазинов в Минске и филиалах по стране ещё в 2005-м году. Это позволило значительно снизить простои. В результате поддержкой нескольких сотен единиц техники занимался один специалист половину своего времени.
          PRTG стоит денег, но учитывая его технологическое превосходство, значительно более высокую производительность обслуживания получаем, что полная стоимость владения платным продуктом ниже бесплатного. И чем больше сенсоров, больше инфраструктура, тем больше экономия и выгода.
          А самое интересное наступает на огромных инфраструктурах, когда как не умощняй Zabbix, он уже не может решить задачу. И приходится сотню тысяч сенсоров переносить на коммерческий продукт и этот перенос стоит таких денег, что съедается вся экономия за долгие годы.

            0
            Спасибо, что зашли рассказать свою саксесс-стори, полную аргументированных заявлений. А мужики-то не знают, что заббикс не в состоянии обслуживать большие инфраструктуры, ай-яй-яй…
              –1

              Я изучал работу одного из самых крупных Zabbix проектов в мире. Поэтому это факт. Однако информация по данному проекту давалась на условиях не распространения.
              Мой комментарий был направлен на рассмотрение задачи мониторинга как более широкого, особенно в части TCO.

              0
              По-моему утверждение о том, что ретейлеры не мониторят кассовые места, слегка голословно.
              Когда ЕГАИС по алкашке начался и возник бесконечный гемморой с ключами и работой сервисов, то только самые упоротые не стали внедрять мониторинг вплоть до касс.

              Другое дело что кассы могут быть под не слишком комфортным для мониторинга ПО, и без поддержки со стороны разработчика там не обойтись.
                0
                Спасибо за пост. Парочка вопросов:
                1. Какое решение использовали в качестве CMDB?
                2. Не совсем понял техническое решение
                Logstash у нас выгребает логи через API Zabbix

                Вы анализируете лог при помощи Zabbix и в случае аварии берёт проблемную строку и передаёте в Zabbix, а дальше Logstash забираете в Elastic?

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