Озон ошибка context deadline exceeded

Никогда не работал с API OZON, но написано REQUEST_TIMEOUT… т.е. сервер не смог отработать ваш запрос за отведённое время (сколько времени выполнять запрос — решает сервер). Так что от вас, думаю, ничего не зависит.

P.S. Попробуйте кешировать ответы на своей стороне, и при получении REQUEST_TIMEOUT брать старый из кэша…

И ещё, при получении REQUEST_TIMEOUT не долбите сервер снова и снова… От этого он быстрее ваш запрос не отработает, и даже наоборот…

7 ошибок в названии товара, из-за которых он не прошел модерацию на Ozon

Как уже отмечалось, загрузить товары в личный кабинет нужно еще до их поставки на склад маркетплейса и даже до выбора схемы работы с Ozon (FBO или FBS). Площадке нужно время, чтобы проверить все разрешающие документы, фото, описание и название товара. Сегодня остановимся на том, по каким причинам Ozon может отклонить ваше предложение, и как правильно составить название товара, чтобы он удачно прошел модерацию.

1. Не указан тип товара. Даже если модель товара, его обозначение или фирма известно вашей целевой аудитории, по правилам вы должны указать тип вашего товара. То есть не “Поп ит”, а “Игрушка “Поп-ит”.

2. Не указана модель товара . Если вы продаете наушники, то будет недостаточно указать бренд товара или название товара. Должны быть отличительные детали конкретной модели, чтобы покупатель мог отличить ее от других. Это может быть просто артикул товара, это может быть указание цвета или внутреннее название модели. Слова, которые лучше всего могут индексировать отдельный товар линейки.

3. Название не соответствует товару. Даже если вы владелец бренда и хотите назвать свой товар определенным образом, Ozon хочет, чтобы название не содержало лишней информации, оценочных суждений и не вводило в заблуждение покупателя. Любая субъективная информация (большое ведро, вместительная сумка) не допускается в названии, зато может быть указана в описании товара.

4 Название начинается с маленькой буквы. Даже небольшое название из 2-3 слов должно полностью соответствовать правилам русского языка и не содержать орфографических ошибок. Довольно часто поставщики не обращают внимание на регистр, но начинаться название должно именно с большой буквы. При этом Caps Lock и транслит в названии недопустим, хотя использовать английские буквы — можно.

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

6. В названии указана цена товара. Довольно часто поставщики пытаются использовать поле названия товара для того, чтобы зацепить внимание покупателя, в том числе низкой ценой. Маркетплейс запрещает это делать, в том числе добавлять словосочетания “только у нас”, “только сегодня”, “низкая цена”, “акция” и т.п.

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

При этом вы можете влиять на поисковую оптимизацию и на показы своей целевой аудиторией с помощью названия. Во-первых, вы можете указывать назначение товара — “для сухих волос”, “3-18 кг”, во-вторых, особенности товара: “жирность 3,2%”, “4-местная”, “2 упаковки по 50мл”, “1кг”. По этим параметрам покупатели могут искать именно ваш товар, поэтому обязательно указывайте основные характеристики, цвет и размер (если это важно) товара.

Что еще стоит указать в названии? Сложно рассматривать товар “в вакууме”. Вам нужно представить, как его видят покупатели среди других предложений. Сделать это вам поможет сервис аналитики Moneyplace. Введите в поиске ваш товар, и посмотрите какие фишки в названии используют продавцы с максимальной выручкой в категории.

Источник

Чиним проблемы нагрузок в Go с помощью настройки пула HTTP-соединений

Привет, меня зовут Иван, я занимаюсь бэкенд-разработкой в Ozon — пишу микросервисы для личного кабинета продавца. Сегодня я расскажу небольшую историю проблемы, вызванную неправильной настройкой пула соединений: что случилось, как мы это обнаружили и как исправлять такие проблемы в микросервисах на Go.

Проблема скрывалась внутри нашего API Gateway. Это сервис, который реализует паттерн “Фасад” и предоставляет единственное торчащее наружу окно к микросервисам.

В упрощенном виде его работу можно представить так:

Проверить аутентификацию и авторизацию с помощью HTTP-запроса в сервис аутентификации

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

Иллюстрация работы API Gateway

Конец декабря – время роста нагрузок и числа ошибок

Настал конец декабря. Вместе с ним к нам в поддержку стали приходить вот такие обращения:

При работе в ЛК возникают постоянные ошибки системные по 10-20 раз на дню и больше. Просьба исправить и наладить работу площадки.

Ошибки возникали на стороне API Gateway. Мы полезли в логи за подробностями и увидели ошибки, похожие на таймауты обращения к сервису аутентификацию:

Трейсы в Jaeger показали ровно такую же картину — мы не дожидались ответа от сервиса аутентификации за 2 секунды. Поэтому между нами и разработчиками сервиса аутентификации произошёл примерно такой диалог:

— Ребята, кажется, вы таймаутите. Вот трейс, на котором видно, что мы не дождались от вас ответа за 2 секунды.

— Ничего подобного, у нас все норм — мы за 200 миллисекунд отвечаем в 99% запросов. А вот вы по какой-то причине часто преждевременно обрываете соединение.

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

Скриншот с множеством ошибок Cancelled by client

Используемый нами сервис аутентификации стабильно отрабатывает за 200 миллисекунд.

Многие наши обращения к этому сервису таймаутят за 2 секунды.

Причина проблемы: дефолтные настройки в Go

В это время один из авторов нашего API Gateway отметил, что очень давно заметил аномалию: сервис открывает неожиданно много соединений к удаленным портам. При запуске команды из-под контейнера видно:

Эта команда показывает количество TCP-сокетов в состоянии TIME_WAIT до разных удалённых портов. Если коротко, то состояние TIME_WAIT — это де-факто закрытое клиентом соединение. Linux по возможности предотвращает повторное использование этих пар на протяжении 60 секунд, чтобы защититься от того, что старые пакеты помешают вновь установленному TCP-соединению.

Но для нас важно другое. Само существование TCP-соединения означает, что соединение установилось и закрылось. Если такая ситуация происходит массово, то мы имеем дело с накладными расходами на DNS-резолвинг и установку соединения. В результате этого время HTTP-запроса может увеличиваться. Избежать эту проблему помогают пулы соединений. В Go для этой цели используется абстракция http.Transport .

Здесь мы вплотную приближаемся к истокам проблемы. Мы для всех клиентских запросов использовали http.DefaultTransport . Он обладает следующими параметрами:

Среди перечисленных выше параметров к настройке пула соединений имеют отношения два:

MaxIdleConns — число соединений, которое разрешается иметь в состоянии Idle (т.е. открытых TCP-соединений, которые в данный момент не используются);

IdleConnTimeout — время, через которое закрываются такие неактивные соединения.

Однако в DefaultTransport совершенно не указан другой ключевой параметр — MaxIdleConnsPerHost . Он отвечает за то, сколько неактивных TCP-соединений допускается устанавливать на один хост. ​

При этом если MaxIdleConnsPerHost не указан, тогда используется значение по умолчанию:

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

Представим, что нам одновременно понадобилось установить 10 соединений до сервиса аутентификации. Тогда хотя бы для 8 из них будут открыты и вскоре тут же закрыты TCP-соединения, из-за ограничения MaxIdleConnsPerHost . Если такая ситуация будет повторяться часто, у нас будет больше накладных расходов на один HTTP-запрос, поскольку для него понадобится новое соединение. Из-за этого вероятность таймаутов возрастает.

Решение: отдельный транспорт с особенными настройками

Чтобы решить проблему, мы сделали следующее:

Выделили отдельный транспорт под сервисы аутентификации и авторизации, чтобы транспорт под сервис аутентификации не вытеснял остальные сервисы.

Утилизировали выделенный пул на полную — сделали так, чтобы значение MaxIdleConnsPerHost соответствовало значению MaxIdleConns :

График response time обращения к сервису аутентификации

Тут видно значительное уменьшение 0.99-квантиля по времени обращения графиков (голубой цвет) — с 2-3 секунд до менее 300 миллисекунд. Должен признать, даже после этого мы изредка видели таймауты при обращении к сервису аутентификации. Но теперь мы хотя бы видели эти же таймауты на графиках другого сервиса.

Но почему в Go такие настройки по умолчанию?

Возможно, у вас сейчас возник вопрос: зачем делать такие настройки, которые потом приходится исправлять? Неужели разработчики языка Go и библиотек к нему не подумали о том, как это будет использоваться на практике?

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

Если бы приложения могли говорить.

Чтобы лучше понять предназначение параметра MaxIdleConnsPerHost , представим, что компоненты системы научились говорить друг с другом. Тогда если бы мы выставили значение MaxIdleConnsPerHost равным MaxIdleConns , между нашим приложением и пулом соединений мог бы произойти такой диалог:

Приложение: http.Transport, привет! Нам тут сотня пользователей пришла одновременно и им всем вдруг срочно понадобилось посмотреть инфу о своём профиле. Установи, пожалуйста, сотню соединений к user-service ​​

http.Transport: Конечно, вот – получи сотню установленных соединений под запросы! Но я их не буду ещё полторы минуты закрывать, вдруг пригодятся ​.

Приложение: Всё сработало, спасибо! Только вот теперь им всем вдруг захотелось посмотреть информацию о товаре. Пожалуйста, установи соединение с product-service .

http.Transport: Да, не вопрос – держи. Но только я их у себя в пуле соединений хранить не буду, поскольку он уже полностью забит соединениями до user-service , которые тебе больше не нужны.

Разбираемся с непонятными таймаутами в Go: чеклист

Если вдруг вы сталкиваетесь с непонятными таймаутами, попробуйте следующее:

Проверьте метрики по скорости выполнения запросов к сторонним сервисам по HTTP. Если таких метрик нет, заведите – пригодятся.

Если видите расхождения в таймаутах клиента и сервера, проверьте количество соединений TIME_WAIT.

Если вы обнаружили много соединений в состоянии TIME_WAIT, это с высокой вероятностью означает, что пул соединений настроен неверно. Обратите внимание на то, что настройки по умолчанию в Go не очень хорошо подходят под большое количество запросов к ограниченному набору сервисов.

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

Что ещё почитать по теме

Gotchas in the Go Network Packages Defaults: какие ещё подводные камни есть в настройках сети в Golang;

демо на Github: наглядно об описанной проблеме в миниатюре

Источник

context deadline exceeded #1438

the prometheus.yml configuration is:

But, there is a error like that:

The text was updated successfully, but these errors were encountered:

This simply means that the scrape request timed out. Try setting your scrape timeout to something higher than 3s or figure out whether it will always time out for some other reason.

We can probably map the user-facing error to something clearer.

Does the prometheus scrape from target by http protocol?

On Tue, Mar 1, 2016, 12:13 PM lcbluestorm notifications@github.com wrote:

Does the prometheus scrape from target by http protocol?

—
Reply to this email directly or view it on GitHub
#1438 (comment)
.

So, for the target application with http protocol, the prometheus can not scrape from it?

The request is timing out. I cannot tell you the reason without further information.
If you click on the target link that you’ve shown us a picture above you might find out more.

You should see a text page listing metrics exposed by that target.

The curl was able to pull data less than 1 sec «time curl http://10.8.12.37:42000/metrics» . Increased METRICS_RESOLUTION=5s helped. Restart the docker for pmm-server with this option and not pmm-data

sudo docker run -d -p 80:80 —volumes-from pmm-data —name pmm-server —restart always -e METRICS_RESOLUTION=5s percona/pmm-server:1.0.3

For help with debugging for their Kubernetes Prometheus target of Prometheus pushgateway (quay image v.0.3.1 and 0.3.0) for the context deadline exceeded error.

Several things came into play for my «context deadline exceeded issue» when working in Kubernetes cluster with Prometheus Pushgateway (not Prometheus itself —> the Targets page only bubbled up the issue as the target was DOWN and had context deadline exceeded for an error message)

1. Context: Using this job_name pattern for the scrape_config in Kubernetes for Prometheus Config Map

1. The Kubernetes cluster Pushgateway Deployment YAML file, deployed in the prometheus namespace, needed an extra — in front of the startup args for the pushgateway executable as well as the — for being the member of the array.
   Example below:

Getting into the Kubernetes pushgateway pod itself, because it was busybox and a stripped down version of OS, meant that the command telnet appname.namespace 9091 will not return any code/error or state it had connected with a banner (so I assumed it had hung)

On the Kubernetes pushgateway pod itself the netstat -l -p showed the port 9091 was bound and listening for process pushgateway. Tests from other pods with telnet or curl hung.

The clincher was that the service Selector was name: and not app: —> Once that was fixed the target was discovered on the Kubernetes Dashboard because the Kubernetes service knew to look for application name pushgateway versus what would be the pod name eg: pushgateway-2976552050-nxrkb

Hope that helps someone looking for similar info.

Источник

package main

import (
    "context"
    "fmt"
    "go.etcd.io/etcd/clientv3"
    "time"
)
func main()  {
    cli,err := clientv3.New(clientv3.Config{
        Endpoints: []string{"http://192.168.11.34:2379"},
        DialTimeout: 5*time.Second,
    })
    if err != nil{
        panic(err)
    }
    fmt.Println("connect etcd success!")
    defer cli.Close()

    ctx,cancel := context.WithTimeout(context.Background(),time.Second*5)
    _,err = cli.Put(ctx,"mac","leave")
    defer  cancel()
    if err !=nil{
        fmt.Println("put etcd err:",err.Error())
        return
    }
}

connect etcd success!
{"level":"warn","ts":"2021-02-08T17:10:46.490+0800","caller":"clientv3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"endpoint://client-5b14f6c4-2395-4a15-9ebb-cadf5985fb06/192.168.11.34:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest balancer error: all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 192.168.11.34:2379: connect: connection refused""}
put etcd err: context deadline exceeded

2 ответа

Лучший ответ

DialTimeout: 5*time.Second

Current Behavior

With random frequency, an error of exceeding the timeout appears in the panel when trying to manage server power. At the same time, I can manage the server files and everything else. The error may not appear for several hours, and then appear for no reason. And it will only go away if you wait 5-10 minutes or restart wings. Also ping and curl (panel -> node and node -> panel) works fine while this error shows.

IMPORTANT!
I looked at the cloudflare and nginx logs and it turns out that requests from the node do not even come to the panel during this error. It feels like wings just doesn’t send them.

ALSO important!

• I have standard network panel and node settings
• I installed the panel and node myself without any scripts
• Node IP in the cloudflare added to whitelist and it does not block requests
• The panel and node are on different servers. This is not a local network
• I tried different DNS settings: 1.1.1.1 1.0.0.1 and 8.8.8.8 8.8.4.4
• The panel and node are not overloaded at the time of the error
• Ping and curl (panel -> node and node -> panel) works fine while this error shows.

I’m already really desperate and I don’t have any guesses left what the problem might be. I really hope for your help.

Expected Behavior

Server power management should work but it doesnt

Steps to Reproduce

I found a regularity how to reproduce this bug: restart wings, immediately start an empty server so that it gives a crash error and try to manage of power. Often a timeout error appears when the server tries to restart itself after a crash:

It doesn’t always work out the first time and you need to try to repeat it several times

Panel Version

1.11.3

Wings Version

1.11.5

Games and/or Eggs Affected

No response

Docker Image

No response

Error Logs

https://ptero.co/soxapusida

Is there an existing issue for this?

• I have searched the existing issues before opening this issue.
• I have provided all relevant details, including the specific game and Docker images I am using if this issue is related to running a server.
• I have checked in the Discord server and believe this is a bug with the software, and not a configuration issue with my specific system.