Сбои в работе Я.Метрика. Вопрос Дм. Громову

keepersheet
На сайте с 21.06.2016
Offline
54
1273

Вопрос ув. Дмитрию Громову, в основном. Но не только; если кто еще в теме описанного, буду благодарен за адекватный ответ. Примечание: не случайно говорю об адекватности, как показывает общение здесь - немалое количество технически безграмотного флуда имеет место быть, увы, на серче.

Дмитрий, вопрос мой о работе API Метрика. Неоднократно наблюдал сбои в работе данного интерфейса; по большей части сбои ночные. Локализовать, рассказать подробно не представляется возможным: потребовалось бы делать технический аудит ответов сервера, создавать релевантную выборку по работе endpoint, ресурсами для этого не располагаю.

Всего один только, случайно пойманный сегодня пример. Скриншот отображает состояние одного из чартов, визуализирующих JSON Яндекс.Метрики, штатную работу которого возможно наблюдать на страничке моего блога: код скрипта неизменен, а контраст, как видите, разителен. Прекрасно понимаю, сказанного недостаточно для технически компетентного утверждения, что проблемы - на стороне серверов Яндекса, а не у меня; но... располагаю также жалобами пользователей, декларирующих примерно то же самое, что уже сформулировал выше. А именно: отсутствие приемлемого уровня стабильности в работе API Metrika.

Собсно, сабж. Чарты мои кэшируют полученные данные, что в некоторой степени страхует от кратковременных сбоев в работе API, но совершенно не гарантирует от того, что будет закэширован "неверный" JSON, что и имеет место на скриншоте. Не посоветуете ли некое вхождение по строке, код ответа либо иной разумный критерий, оттолкнувшись от которого возможно было бы создать условие, позволяющее определить ошибочный ответ сервера Яндекса, который оптимально не кэшировать, не отображать? - пробую и так и эдак, и ответ вроде не пустой, и код 200 и error не содержит, а все одно, как видите, траблы.

Веб-разработка на ruby и php (https://masterpro.ws/)
Дмитрий Громов
На сайте с 15.08.2018
Offline
167
#1
keepersheet:
Вопрос ув. Дмитрию Громову, в основном. Но не только; если кто еще в теме описанного, буду благодарен за адекватный ответ. Примечание: не случайно говорю об адекватности, как показывает общение здесь - немалое количество технически безграмотного флуда имеет место быть, увы, на серче.

Дмитрий, вопрос мой о работе API Метрика. Неоднократно наблюдал сбои в работе данного интерфейса; по большей части сбои ночные. Локализовать, рассказать подробно не представляется возможным: потребовалось бы делать технический аудит ответов сервера, создавать релевантную выборку по работе endpoint, ресурсами для этого не располагаю.

Всего один только, случайно пойманный сегодня пример. Скриншот отображает состояние одного из чартов, визуализирующих JSON Яндекс.Метрики, штатную работу которого возможно наблюдать на страничке моего блога: код скрипта неизменен, а контраст, как видите, разителен. Прекрасно понимаю, сказанного недостаточно для технически компетентного утверждения, что проблемы - на стороне серверов Яндекса, а не у меня; но... располагаю также жалобами пользователей, декларирующих примерно то же самое, что уже сформулировал выше. А именно: отсутствие приемлемого уровня стабильности в работе API Metrika.

Собсно, сабж. Чарты мои кэшируют полученные данные, что в некоторой степени страхует от кратковременных сбоев в работе API, но совершенно не гарантирует от того, что будет закэширован "неверный" JSON, что и имеет место на скриншоте. Не посоветуете ли некое вхождение по строке, код ответа либо иной разумный критерий, оттолкнувшись от которого возможно было бы создать условие, позволяющее определить ошибочный ответ сервера Яндекса, который оптимально не кэшировать, не отображать? - пробую и так и эдак, и ответ вроде не пустой, и код 200 и error не содержит, а все одно, как видите, траблы.

Добрый день! В данном случае не могу предоставить какой-либо точной информации касательно такого поведения. Нужно получить более подробные технические данные об этой ситуации:

1) Полный URI запроса на сервер API Метрики;

2) Полный JSON-код ответа сервера.

В свою очередь, можно предположить, что в рамках запроса пользователя не учитывается семплирование, при котором используется только часть данных (например 0.01% от общих данных) для расчета показателей.

Больше информации о семплировании в рамках API Метрики можно узнать на странице https://yandex.ru/dev/metrika/doc/api2/api_v1/sampling-docpage/

Не бойтесь задавать вопросы или писать про свои проблемы с Директом, РСЯ или ADFOX на: dgromov@yandex-team.ru. Я передам их в Яндекс.
keepersheet
На сайте с 21.06.2016
Offline
54
#2

Доброго дня, Дмитрий. Спасибо за ответ.

Честно сказать, не думаю, что семплирование имеет отношение к описанным проблемам.

ЛОгика формирования запроса к API Metrika в данном случае такова, как показана далее. Не использовал либы Яндекса для работы с API Metrika, т.к. задачка совсем простая:

require 'typhoeus'

def referers
return Rails.cache.fetch('referers', :expires_in => 1.hours) {
authToken = ENV['AUTH_TOKEN_METRIKA']
response = Typhoeus::Request.get(
"https://api-metrika.yandex.ru/stat/v1/data",
params: {
'ids' => ENV['IDS_METRIKA'],
'metrics' => 'ym:s:visits',
'dimensions' => 'ym:s:externalRefererPathLevel1',
'date1' => '15daysAgo',
'date2' => 'yesterday'
},
headers: {
Accept: 'application/x-yametrika+json',
Authorization: 'OAuth' + authToken
}
)
JSON.parse(response.body)
}
end

Как видите, запрашивается отчет (id счетчика 4411126) о реферерах за последние две недели, и JSON должен включать не самый мизерный объем данных; что несложно увидеть, собственно, и на примере живого чарта по ссылке выше. Запрос составлен с учетом февральских изменений этого года в работе API Yandex.Metrika, теперь не принимающей токен доступа в параметрах.

Тем не менее, не выдаю себя за специалиста по API Яндекса, показанные виджеты являются плодом довольно поверхностного изучения метрик и группировок, описываемых докой сервиса. Если заметите какие-то явные ошибки/недочеты кода, буду искренне благодарен за любые ваши ремарки, либо же комментарии программистов.

Показал выше логику формирования запроса в контексте RoR, но учитывая пожелания некоторых форумчан серча, весьма отрицательно, насколько сумел понять, относящихся к фреймворкам, либам, etc... на "нативном" php то же самое вид сбоку будет следующим образом. Сразу подчеркну, curl суть штатный модуль из основного дерева сурсов :) :

<?
function curl_file_get_contents($url)
{
$authToken = '**************************';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/x-yametrika+json', 'Authorization: OAuth' . $authToken]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
$obj = curl_exec($ch);
curl_close($ch);
return $obj;
}
$url = 'https://api-metrika.yandex.ru/stat/v1/data';
$params = array(
'ids' => '*******',
'metrics' => 'ym:s:visits',
'dimensions' => 'ym:s:externalRefererPathLevel1',
'date1' => '15daysAgo',
'date2' => 'yesterday'
);
$obj = curl_file_get_contents($url . '?' . http_build_query($params));
$obj = json_decode($obj, true);

for ($i = 0;$i < count($obj['data']);$i++)
{
echo '[', "'", $obj['data'][$i]['dimensions'][0]['name'], "'", ', ', $obj['data'][$i]['metrics']['0'], '],';
}
?>
Дмитрий Громов
На сайте с 15.08.2018
Offline
167
#3
keepersheet:
Доброго дня, Дмитрий. Спасибо за ответ.

Честно сказать, не думаю, что семплирование имеет отношение к описанным проблемам.
ЛОгика формирования запроса к API Metrika в данном случае такова, как показана далее. Не использовал либы Яндекса для работы с API Metrika, т.к. задачка совсем простая:

require 'typhoeus'


def referers
return Rails.cache.fetch('referers', :expires_in => 1.hours) {
authToken = ENV['AUTH_TOKEN_METRIKA']
response = Typhoeus::Request.get(
"https://api-metrika.yandex.ru/stat/v1/data",
params: {
'ids' => ENV['IDS_METRIKA'],
'metrics' => 'ym:s:visits',
'dimensions' => 'ym:s:externalRefererPathLevel1',
'date1' => '15daysAgo',
'date2' => 'yesterday'
},
headers: {
Accept: 'application/x-yametrika+json',
Authorization: 'OAuth' + authToken
}
)
JSON.parse(response.body)
}
end


Как видите, запрашивается отчет (id счетчика 4411126) о реферерах за последние две недели, и JSON должен включать не самый мизерный объем данных; что несложно увидеть, собственно, и на примере живого чарта по ссылке выше. Запрос составлен с учетом февральских изменений этого года в работе API Yandex.Metrika, теперь не принимающей токен доступа в параметрах.

Тем не менее, не выдаю себя за специалиста по API Яндекса, показанные виджеты являются плодом довольно поверхностного изучения метрик и группировок, описываемых докой сервиса. Если заметите какие-то явные ошибки/недочеты кода, буду искренне благодарен за любые ваши ремарки, либо же комментарии программистов.

Показал выше логику формирования запроса в контексте RoR, но учитывая пожелания некоторых форумчан серча, весьма отрицательно, насколько сумел понять, относящихся к фреймворкам, либам, etc... на "нативном" php то же самое вид сбоку будет следующим образом. Сразу подчеркну, curl суть штатный модуль из основного дерева сурсов :) :

<?

function curl_file_get_contents($url)
{
$authToken = '**************************';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/x-yametrika+json', 'Authorization: OAuth' . $authToken]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
$obj = curl_exec($ch);
curl_close($ch);
return $obj;
}
$url = 'https://api-metrika.yandex.ru/stat/v1/data';
$params = array(
'ids' => '*******',
'metrics' => 'ym:s:visits',
'dimensions' => 'ym:s:externalRefererPathLevel1',
'date1' => '15daysAgo',
'date2' => 'yesterday'
);
$obj = curl_file_get_contents($url . '?' . http_build_query($params));
$obj = json_decode($obj, true);

for ($i = 0;$i < count($obj['data']);$i++)
{
echo '[', "'", $obj['data'][$i]['dimensions'][0]['name'], "'", ', ', $obj['data'][$i]['metrics']['0'], '],';
}
?>

Добрый день! Удалось воспроизвести запрос из присланных вами данных - действительно, если появляется семплирование, то может прийти только 1 или 2 значения.

В данном случае можно дать 2 рекомендации:

1) Проверять параметр "sampled" результирующих данных. Это позволит понять было ли применено семплирование;

2) Добавлять в запрос URL параметр "accuracy=1". Этот параметр будет гарантировать, что данные будут рассчитываться без семплирования.

keepersheet
На сайте с 21.06.2016
Offline
54
#4

Повторюсь, не ставлю задачи поймать Яндекс на том или ином. Соответственно, не готов показать сегодняшний ответ API Metrica, полученный где-то около 16.00 по Москве (плюс-минус полчаса; точнее не скажу ввиду кэша), т.к. нет его у меня. Увидел случайно; просто в скриптах реализовал проверку следующим для начала образом, и она тупо сработала:

<% if @referers['data'].nil? || @countries['data'].nil? || @keywords['data'].nil? %>
<% flash[:warning] = 'No data received. Reload the page or come back later.' %>

Каким образом получен @referers - показал выше; два других запроса разнятся только группировкой/метрикой (кое-где добавляется параметр 'lang' => 'en' , ну и везде добавил 'accuracy' => 'full' дабы отключить семплирование , следуя вашему, Дмитрий, совету, full и единичка в данном случае равнозначны):

'metrics' => 'ym:s:visits',
'dimensions' => 'ym:s:externalRefererPathLevel1'

'metrics' => 'ym:s:visits',
'dimensions' => ''ym:s:regionCountry''

'preset' => 'sources_search_phrases',

nil, ну т.е. объекта нет, lack of an object. Что-то можно еще улучшить? Я не стал бы столь категорично утверждать, но перед глазами работа некороткого ряда других API, начиная с тех же самых погодных станций. и на контрасте неответы серверов Яндекса довольно ощутимы.

Очень хотелось бы получить совет программистов Яндекса, непосредственно работающих с API Metrika. Учитывая все вышесказанное, если ответ сервера Яндекса не содержит данных либо ответа нет вообще, что оптимально далее? перезапросить? какую хоть примерно паузу ставить?

Дмитрий Громов
На сайте с 15.08.2018
Offline
167
#5
keepersheet:
Повторюсь, не ставлю задачи поймать Яндекс на том или ином. Соответственно, не готов показать сегодняшний ответ API Metrica, полученный где-то около 16.00 по Москве (плюс-минус полчаса; точнее не скажу ввиду кэша), т.к. нет его у меня. Увидел случайно; просто в скриптах реализовал проверку следующим для начала образом, и она тупо сработала:

<% if @referers['data'].nil? || @countries['data'].nil? || @keywords['data'].nil? %>
<% flash[:warning] = 'No data received. Reload the page or come back later.' %>


Каким образом получен @referers - показал выше; два других запроса разнятся только группировкой/метрикой (кое-где добавляется параметр 'lang' => 'en' , ну и везде добавил 'accuracy' => 'full' дабы отключить семплирование , следуя вашему, Дмитрий, совету, full и единичка в данном случае равнозначны):

'metrics' => 'ym:s:visits',
'dimensions' => 'ym:s:externalRefererPathLevel1'

'metrics' => 'ym:s:visits',
'dimensions' => ''ym:s:regionCountry''

'preset' => 'sources_search_phrases',


nil, ну т.е. объекта нет, lack of an object. Что-то можно еще улучшить? Я не стал бы столь категорично утверждать, но перед глазами работа некороткого ряда других API, начиная с тех же самых погодных станций. и на контрасте неответы серверов Яндекса довольно ощутимы.

Очень хотелось бы получить совет программистов Яндекса, непосредственно работающих с API Metrika. Учитывая все вышесказанное, если ответ сервера Яндекса не содержит данных либо ответа нет вообще, что оптимально далее? перезапросить? какую хоть примерно паузу ставить?

Нужно больше деталей. Отправьте мне, пожалуйста, полное JSON-тело ответа сервера API Метрики, когда выдавалась указанная ошибка.

keepersheet
На сайте с 21.06.2016
Offline
54
#6
Дмитрий Громов:
Нужно больше деталей. Отправьте мне, пожалуйста, полное JSON-тело ответа сервера API Метрики, когда выдавалась указанная ошибка.

Как уже сказал выше, нет у меня такового.

Но вот открываю логи и вижу 400 в ответе сервера Яндекса на один из запросов. Привожу далее как есть: после инициализации curl (в основе typhoeus все тот же самый libcurl) request, как считает сервер, содержит ошибку синтаксиса, но спустя некоторое время (после окончания TTL, когда запросы пойдут снова) сервер Яндекса ответит кодом 200, как и положено, хотя синтаксис за это время не изменится.

Скажите, в чем здесь фокус? что не так с запросом?

2019-08-15T12:26:51.450508+00:00 app[web.1]: D, [2019-08-15T12:26:51.450428 #4] DEBUG -- : [98f59fbd-a005-4c66-8751-317271bc3d9a] ETHON: Libcurl initialized

2019-08-15T12:27:04.239375+00:00 app[web.1]: D, [2019-08-15T12:27:04.239216 #4] DEBUG -- : [98f59fbd-a005-4c66-8751-317271bc3d9a] ETHON: performed EASY effective_url=https://api-metrika.yandex.ru/stat/v1/data?ids=4411126&metrics=ym%3As%3Avisits&dimensions=ym%3As%3AexternalRefererPathLevel1&date1=15daysAgo&date2=yesterday&accuracy=full response_code=400 return_code=ok total_time=12.787801
2019-08-15T12:27:07.485901+00:00 app[web.1]: D, [2019-08-15T12:27:07.485676 #4] DEBUG -- : [98f59fbd-a005-4c66-8751-317271bc3d9a] ETHON: performed EASY effective_url=https://api-metrika.yandex.ru/stat/v1/data?ids=4411126&metrics=ym%3As%3Avisits&dimensions=ym%3As%3AregionCountry&lang=en&date1=15daysAgo&date2=yesterday&accuracy=full response_code=200 return_code=ok total_time=3.244895
2019-08-15T12:27:11.282486+00:00 heroku[router]: at=info method=GET path="/analytics/index" host=masterpro.herokuapp.com request_id=98f59fbd-a005-4c66-8751-317271bc3d9a fwd="198.16.66.101" dyno=web.1 connect=0ms service=19835ms status=200 bytes=16158 protocol=https
2019-08-15T12:27:11.270574+00:00 app[web.1]: D, [2019-08-15T12:27:11.270435 #4] DEBUG -- : [98f59fbd-a005-4c66-8751-317271bc3d9a] ETHON: performed EASY effective_url=https://api-metrika.yandex.ru/stat/v1/data?ids=4411126&preset=sources_search_phrases&date1=15daysAgo&date2=yesterday&accuracy=full response_code=200 return_code=ok total_time=3.781459
Дмитрий Громов
На сайте с 15.08.2018
Offline
167
#7
keepersheet:
Как уже сказал выше, нет у меня такового.

Но вот открываю логи и вижу 400 в ответе сервера Яндекса на один из запросов. Привожу далее как есть: после инициализации curl (в основе typhoeus все тот же самый libcurl) request, как считает сервер, содержит ошибку синтаксиса, но спустя некоторое время (после окончания TTL, когда запросы пойдут снова) сервер Яндекса ответит кодом 200, как и положено, хотя синтаксис за это время не изменится.

Скажите, в чем здесь фокус? что не так с запросом?

2019-08-15T12:26:51.450508+00:00 app[web.1]: D, [2019-08-15T12:26:51.450428 #4] DEBUG -- : [98f59fbd-a005-4c66-8751-317271bc3d9a] ETHON: Libcurl initialized

2019-08-15T12:27:04.239375+00:00 app[web.1]: D, [2019-08-15T12:27:04.239216 #4] DEBUG -- : [98f59fbd-a005-4c66-8751-317271bc3d9a] ETHON: performed EASY effective_url=https://api-metrika.yandex.ru/stat/v1/data?ids=4411126&metrics=ym%3As%3Avisits&dimensions=ym%3As%3AexternalRefererPathLevel1&date1=15daysAgo&date2=yesterday&accuracy=full response_code=400 return_code=ok total_time=12.787801
2019-08-15T12:27:07.485901+00:00 app[web.1]: D, [2019-08-15T12:27:07.485676 #4] DEBUG -- : [98f59fbd-a005-4c66-8751-317271bc3d9a] ETHON: performed EASY effective_url=https://api-metrika.yandex.ru/stat/v1/data?ids=4411126&metrics=ym%3As%3Avisits&dimensions=ym%3As%3AregionCountry&lang=en&date1=15daysAgo&date2=yesterday&accuracy=full response_code=200 return_code=ok total_time=3.244895
2019-08-15T12:27:11.282486+00:00 heroku[router]: at=info method=GET path="/analytics/index" host=masterpro.herokuapp.com request_id=98f59fbd-a005-4c66-8751-317271bc3d9a fwd="198.16.66.101" dyno=web.1 connect=0ms service=19835ms status=200 bytes=16158 protocol=https
2019-08-15T12:27:11.270574+00:00 app[web.1]: D, [2019-08-15T12:27:11.270435 #4] DEBUG -- : [98f59fbd-a005-4c66-8751-317271bc3d9a] ETHON: performed EASY effective_url=https://api-metrika.yandex.ru/stat/v1/data?ids=4411126&preset=sources_search_phrases&date1=15daysAgo&date2=yesterday&accuracy=full response_code=200 return_code=ok total_time=3.781459

Поведение приложения при возникновении ошибки полностью зависит от самой ошибки - в данном случае HTTP-кода ошибки недостаточно.

Например, если в тексте ошибки будет указано "Запрос слишком сложный. Пожалуйста, уменьшите интервал дат или семплирование.", но вы точно уверены, что этот же запрос отрабатывал ранее, то ошибка может быть связана с резко возросшей нагрузкой на сервис. В этом конкретном случае действительно наиболее оптимальным вариантом будет повторение запроса позднее.

В общем случае мы рекомендуем вам более подробно логгировать ответы сервера API Метрики при возникновении ошибок.

foran
На сайте с 13.11.2009
Offline
223
#8
Дмитрий Громов:
Поведение приложения при возникновении ошибки полностью зависит от самой ошибки - в данном случае HTTP-кода ошибки недостаточно.
Например, если в тексте ошибки будет указано "Запрос слишком сложный. Пожалуйста, уменьшите интервал дат или семплирование.", но вы точно уверены, что этот же запрос отрабатывал ранее, то ошибка может быть связана с резко возросшей нагрузкой на сервис. В этом конкретном случае действительно наиболее оптимальным вариантом будет повторение запроса позднее.
В общем случае мы рекомендуем вам более подробно логгировать ответы сервера API Метрики при возникновении ошибок.

Дмитрий, вы реально такой умный или спрашиваете советов у программистов и они вам пишут ответы? ) не стёб ни капли, просто интересно, вы сами пишете ответы? Мне кажется невозможно знать нюансов и РСЯ, и директа и метрики, это разные разделы яндекса

Агрегатор пуш-партнерок (https://clck.ru/Evnop)
keepersheet
На сайте с 21.06.2016
Offline
54
#9

Логгировать, а к чему?

Я действительно уверен, что запрос неизменен; один и тот же request получает в ответ то код 200, то 400. Насколько я вас понял чуть ранее, имела место попытка реализовать запрос тем же способом, как описал, и она увенчалась успехом.

,

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

Собсно, если сервер Яндекса не справляется с нагрузкой, вследствие чего шлет код 400 - это уже само по себе притча во языцех, не находите? Для Яндекса совсем несолидно.

Ну чего, придется кодить следующую логику: кэшировать и отображать ответ Ya.Metrika, если он содержит данные, и использовать данные кэша любой давности, если не существует более свежих.

Дмитрий Громов
На сайте с 15.08.2018
Offline
167
#10
foran:
Дмитрий, вы реально такой умный или спрашиваете советов у программистов и они вам пишут ответы? ) не стёб ни капли, просто интересно, вы сами пишете ответы? Мне кажется невозможно знать нюансов и РСЯ, и директа и метрики, это разные разделы яндекса

Согласен с вами, невозможно знать всех нюансов. На большинство вопросов стараюсь отвечать сам. но по некоторым консультируюсь с коллегами из смежных отделов.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий