Здравствуйте, maxkar, Вы писали:

M>Ой! Какой ужас, терабайты! Давайте посчитаем, сколько они стоят. Например, aws ec2 transfer. Самый дорогой — это первые 10Тб, отправленные в интернет. Стоит это 0.09 USD/GB. Т.е. 90 USD/TB. Это где-то 1.5-2 человекочаса. Если вдруг терабайт заголовков позволяет сэкономить 2 часа (суммарно) на координации, переключениях контекста и прочем обслуживании, мы остаемся в плюсе! Данный доступ — это плохое решение. Вместо того, чтобы иметь одну систему мониторинга (для своих сервисов) команда теперь будет вынуждена ходить в несколько различных — свою и каждой зависимости. На ровном месте мы чуть-чуть экономим на заголовках и создаем проблемы администрирования и координации!
Я не понял где и в каком месте произойдёт экономия. Джиры, емейлы, логи, мониторинг и прочее никуда не уходит. Просто появляется ещё дублирование в хедере.

M>Кроме того. Есть еще один замечательный момент. Заголовок с содержимым выглядит примерно так: "X-API-Warnings: W084,W092,W103". Округляя, 100 байт. В килобайте — 10 заголовков. В терабайте 10^10. (мега, гига, тера — 3*3 порядка). Допустим, команда все три месяца ничего не делала и перешла на новый API в последний момент. Т.е. 10^10 ответов было отправлено за 3 месяца. Это дает 10^10 / 3 / 30 / 24 / 60 / 60 = 1286 сообщений в секунду. Что-то мне кажется не очень выгодным тратить время команды, поддерживающей такую нагрузку, на административные задачи и координацию. Я думаю, разработчики будут гораздо более полезны на технических задачах и задачах бизнеса.
Осталось тебе обосновать каким образом хедер будет осуществлять административные задачи и координацию.

M>Что еще. Если у нас терабайты дополнительных заголовков, то логи не работают. Потому что логов тоже терабайты. Ну ладно, по сети они передаются сжатыми. Но обработка и хранение? Я пока не встречал ни одного предложения по обработке логов, где 1ТБ стоил бы всего 90 USD. Так что остаются только метрики. Для этого нам нужно идентифицировать клиентов. Здравствуйте, заголовки.
Это какой сценарий-то? Если не идентифицировать клиентов, то ты не сможешь писать warning-хедер нужным клиентам и не писать ненужным. А warning который пишется всем без разбору не только бесполезен, но даже немножечко вреден.

M> И я уже упоминал сценарий, где несколько deployment unit являются частью одного сервиса и используют одни и те же credentials. Коллега тут предложил использовать "User-Agent". Ну т.е. заголовок. В каждом запросе (API Warnings ходят только там, где есть предупреждения). И по размеру обычно гораздо больше, чем те же коды предупреждений. И кто из нас экономит траффик?
User-Agent это как общее решение. А раз ты как-то ты удосужился узнать где именно это "только там", то и user-agent значит не обязателен.

M>Ну и потом, гоняться по разным Jira и системам за командами — то еще удовольствие.
Хедер вас от этого не избавит.

M>Ведь нужно не только поставить тикет. Нужно, чтобы его заметили нужные люди (я себе настраиваю так, чтобы digest новых тикетов отправлялся на почту каждый день, но далеко не все так делают). Нужно, чтобы не забыли. Особенно если сейчас они заняты другим. А вот постоянно горящая лампочка check engine api usage — хорошая напоминалка. И если команда пользователей делает лампочку сама, с большой вероятностью она окажется на приборной панели (на виду) а не где-нибудь под капотом (там, куда никто из команды не заходит).
Эту лампочку можно зажигать многими другими способами, более надёжными.
Раз вы управляете мониторингом других команд (как-то же вы заставили читать хедер?), то можно сразу сделать рычажок зажечь лампочку напрямую, одной кнопкой, без хедеров в каждом респонзе.

Здравствуйте, maxkar, Вы писали:

M>Ой! Какой ужас, терабайты! Давайте посчитаем, сколько они стоят. Например, aws ec2 transfer. Самый дорогой — это первые 10Тб, отправленные в интернет. Стоит это 0.09 USD/GB. Т.е. 90 USD/TB. Это где-то 1.5-2 человекочаса. Если вдруг терабайт заголовков позволяет сэкономить 2 часа (суммарно) на координации, переключениях контекста и прочем обслуживании, мы остаемся в плюсе! Данный доступ — это плохое решение. Вместо того, чтобы иметь одну систему мониторинга (для своих сервисов) команда теперь будет вынуждена ходить в несколько различных — свою и каждой зависимости. На ровном месте мы чуть-чуть экономим на заголовках и создаем проблемы администрирования и координации!
Я не понял где и в каком месте произойдёт экономия. Джиры, емейлы, логи, мониторинг и прочее никуда не уходит. Просто появляется ещё дублирование в хедере.

M>Кроме того. Есть еще один замечательный момент. Заголовок с содержимым выглядит примерно так: "X-API-Warnings: W084,W092,W103". Округляя, 100 байт. В килобайте — 10 заголовков. В терабайте 10^10. (мега, гига, тера — 3*3 порядка). Допустим, команда все три месяца ничего не делала и перешла на новый API в последний момент. Т.е. 10^10 ответов было отправлено за 3 месяца. Это дает 10^10 / 3 / 30 / 24 / 60 / 60 = 1286 сообщений в секунду. Что-то мне кажется не очень выгодным тратить время команды, поддерживающей такую нагрузку, на административные задачи и координацию. Я думаю, разработчики будут гораздо более полезны на технических задачах и задачах бизнеса.
Осталось тебе рассказать каким образом хедер будет осуществлять административные задачи и координацию.

M>Что еще. Если у нас терабайты дополнительных заголовков, то логи не работают. Потому что логов тоже терабайты. Ну ладно, по сети они передаются сжатыми. Но обработка и хранение? Я пока не встречал ни одного предложения по обработке логов, где 1ТБ стоил бы всего 90 USD. Так что остаются только метрики. Для этого нам нужно идентифицировать клиентов. Здравствуйте, заголовки.
Это какой сценарий-то? Если не идентифицировать клиентов, то ты не сможешь писать warning-хедер нужным клиентам и не писать ненужным. А warning который пишется всем без разбору не только бесполезен, но даже немножечко вреден.

M> И я уже упоминал сценарий, где несколько deployment unit являются частью одного сервиса и используют одни и те же credentials. Коллега тут предложил использовать "User-Agent". Ну т.е. заголовок. В каждом запросе (API Warnings ходят только там, где есть предупреждения). И по размеру обычно гораздо больше, чем те же коды предупреждений. И кто из нас экономит траффик?
User-Agent это как общее решение. А раз ты как-то ты удосужился узнать где именно это "только там", то и user-agent значит не обязателен.

M>Ну и потом, гоняться по разным Jira и системам за командами — то еще удовольствие.
Хедер вас от этого не избавит.

M>Ведь нужно не только поставить тикет. Нужно, чтобы его заметили нужные люди (я себе настраиваю так, чтобы digest новых тикетов отправлялся на почту каждый день, но далеко не все так делают). Нужно, чтобы не забыли. Особенно если сейчас они заняты другим. А вот постоянно горящая лампочка check engine api usage — хорошая напоминалка. И если команда пользователей делает лампочку сама, с большой вероятностью она окажется на приборной панели (на виду) а не где-нибудь под капотом (там, куда никто из команды не заходит).
Эту лампочку можно зажигать многими другими способами, более надёжными.
Раз вы управляете мониторингом других команд (как-то же вы заставили читать хедер?), то можно сразу сделать рычажок зажечь лампочку напрямую, одной кнопкой, без хедеров в каждом респонзе.