Мы прекращаем поддержку локального API. Подробные сведения и информацию о том, как перейти на облачный API нового поколения, см. в документе Упразднение локального API.

Журналы для службы поддержки

Информацию о поддержке можно получить, используя узел support. Кроме того, для устранения неполадок можно получить журналы Docker, журналы AWS и ID HTTP-запросов.

В этом документе рассматриваются следующие темы:

Подробную информацию о том, как отправить заявку в прямую поддержку, см. в этом разделе.

Получение журналов Docker

Использование WADebug (предпочтительный способ)

С помощью инструмента WADebug можно автоматически собирать и загружать журналы. Для более быстрого поиска решения полученное в ответе значение run_id можно указать в заявке в прямую поддержку. Достаточно выполнить следующую команду:

  wadebug logs --send

Примечание. Если используется режим повышенной доступности и распределения нагрузки, необходимо войти на каждый хост, на котором установлены контейнеры, установить WADebug и выполнить показанную выше команду. Каждый раз после успешного выполнения команды вы получите одно значение run_id, которое можно указать в заявке в прямую поддержку для более быстрого поиска решения.

Использование Docker

Если инструмент WADebug недоступен, можно воспользоваться командойdocker logs и получить журналы каждого контейнера по отдельности. Например, чтобы получить журналы контейнера waweb, выполните следующую команду:

docker logs <container id of waweb> >> waweb.log

Чтобы ограничить размер файлов журналов, можно использовать различные параметры команды docker logs. Например, чтобы получить только последнюю 1 000 строк из контейнера waweb, выполните следующую команду:

docker logs <container id of waweb> --tail 1000 >> waweb.log

Чтобы получить журналы контейнера waweb за определенный период времени, выполните команду с параметрами --since и --until, например:

docker logs <container id of waweb> --since 2020-01-20T20:00:00Z --until 2020-01-21T08:00:00Z >> waweb.log

Выполните эту команду для всех контейнеров WhatsApp и отправьте эти файлы в WhatsApp для анализа и отладки. Другие параметры см. в официальной документации по docker logs.

Примечание. Все журналы контейнеров ведутся в часовом поясе GMT. В качестве параметров --since и --until необходимо передать метки времени в часовом поясе GMT.

Использование Docker Compose

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

WA_API_VERSION=new-whatsapp-version docker-compose logs > debug_output.txt

Примечание. Эта команда может генерировать очень большие файлы журналов. В разделе "Использование Docker" перечислены параметры, позволяющие получить журналы меньшего размера или более актуальные.

Полученные файлы можно отправить в WhatsApp для анализа и отладки.

Журналы сбоев

В версии 2.53 мы внедрили новую систему регистрации сбоев, которая сохраняет файлы дампа при каждом сбое. Эти файлы (они называются дампами сбоев) хранятся в каталоге logs/ в течение 30 дней. Они хранятся только на локальных машинах. Получить их можно точно так же, как файлы журналов. Дампы сбоев могут включать данные из памяти, связанные с потоком, который дал сбой.

Получение журналов Kubernetes

Использование kubectl

Чтобы получить журналы для определенной развернутой услуги, например Webapp, выполните следующую команду в программе настройки Kubernetes:

kubectl logs deployments/whatsapp-web-deployment > whatsapp-web-deployment.txt

Полученный файл затем можно отправить в WhatsApp для анализа и отладки.

Получение журналов AWS

Чтобы получить журналы развертывания в AWS, выполните следующие действия.

Установите для параметра Rollback on Failure значение No, чтобы журналы не удалялись при сбое.

Это нужно сделать при создании или обновлении стека, как показано ниже:

Получите журналы создания стеков CloudFormation и события из консоли CloudWatch.


Подключитесь к экземпляру EC2 (если он создан).

Информацию о том, как подключиться к экземпляру EC2 по SSH, см. в руководстве по AWS. Обратите внимание: во время создания или обновления стеков API WhatsApp Business можно выбрать частную или публичную службу VPC. При использовании частной службы VPC следуйте инструкциям из раздела Securely Connect to Linux Instances Running in a Private Amazon VPC (Безопасное подключение к экземплярам Linux в Amazon VPC).

Получение журналов

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

  1. sudo docker logs ecs-agent > ecs-agent.log
  2. Создайте ZIP-архив и получите /var/log для всех экземпляров EC2, созданных стеком.
  3. Установите WADebug на всех экземплярах EC2 и выполните командыwadebug logs, чтобы собрать все журналы контейнеров.
  4. Если инструмент WADebug на шаге 3 недоступен, выполните следующие команды, чтобы собрать журналы вручную:
    • выполните команду docker ps -a, чтобы получить список всех запущенных контейнеров, и внесите эту информацию в заявку;
    • выполните команду docker logs <docker container id of the core app> >> wacore.log и внесите журналы в заявку;
    • выполните команду docker logs <docker container id of the web app> >> waweb.log и внесите журналы в заявку;
    • выполните команду docker cp <docker container id of the web app>:/var/log/whatsapp/web.log ./web.log и внесите журналы в заявку;
    • выполните команду docker cp <docker container id of the web app>:/var/log/lighttpd/error.log ./error.log и внесите журналы в заявку.

История действий

Если экземпляр EC2 не создан, потребуется история действий соответствующей группы автомасштабирования. Чтобы ее найти, откройте консоль EC2 и выберите Auto Scaling (Автомасштабирование) > Auto Scaling Groups (Группы автомасштабирования). Затем выберите группу стека, в котором произошла проблема, и откройте вкладку Activity History (История действий).

Сбор ID HTTP-запросов

Начиная с версии v2.21.3 API WhatsApp Business генерирует уникальные ID для всех входящих HTTP-запросов. С помощью этих ID можно быстро находить журналы, связанные с определенным запросом, и выполнять отладку. Чтобы сообщить об ошибке, укажите в заявке значения заголовков ответа X-Request-ID и X-Internal-Request-IDS. Это поможет нам точно определить и воспроизвести проблему.