1. Ну да, если гипервизор вне контроля, нам приходится доверять провайдеру, тут особо ничего не придумать.
2. Насколько я понимаю, если виртуалка свою память выделила, то кэш ей уже никто вымыть не может, это скорее о процессах/контейнерах без лимитов памяти. С точки зрения гипервизора виртуалка это процесс (по крайней мере в kvm так), отобрать у него память вроде никак нельзя, а то что pagecache внутри виртуалки, для гипервизора просто used.
3. Да, это боль, но с другой стороны мы же хотели абстракции над железом — это оно и есть:)

Высокооплачиваемый девопс может делать в рабочее время что угодно, если он при этом сможет обеспечить бизнесу работу сервиса с нужным SLA. У многих компаний это стабильно-низкое время ответа, например <100ms на запрос. Вот для таких случаев нужно очень хорошо ориентироваться в самом низком уровне.

Не соглашусь с вами. "scaling_governor" в этом случае был не тюнинг, а объяснение конкретной аномалии на гистограмме. Не менее важно, что проблема была обнаружена по конкретным показателям (perf), после чего сразу было понятно, что и как нужно исправить. Поверьте, я достаточно много собеседовал админов и наслушался, как правильно настраивать серверы в production:) При этом человек естественно не понимал, что он крутит и зачем.

kubernetes естественно прокидываем лимиты в cgroups (в linux просто ничего другого нет), вот если бы он навязывал задавать лимиты (не давал запускать deployment без органичений на каждый под) — было бы совсем хорошо.

Работы много еще там, многие этого не замечают или не хотят замечать

Да, мы именно так и делаем

На самом деле это решает только часть задачи, нужно еще иногда например вызвать nginx -V в контейнере, чтобы конфиг найти, тогда setns придется делать

ну ни фига же себе! :)

Clickhouse хорошо подходит для хранения сырых событий. На мой взгляд для задачи хранения timeseries колоночная БД не дает какого-то выигрыша по производительности или удобству относительно стандартных подходов.

Эластик не очень дружелюбный в плане диагностики, профилирования, так что навешивать на него больше логики я бы не рикнул. А вот иметь event bus например на kafka и нужными сервисами фигачить свои представления, подписавшись на события — это достаточно неплохо работает. Плюс если говорить про оптимизацию производительности, это же процесс обратный к обобщению логики как правило =)

Я в mysql не силен, но слышал, что там принципиально другая схема работы с диском.

Да, latency снимается

Kibana — просто интерфейс для анализа событий, которые лежат в elasticsearch. Okmeter — сервис мониторинга, показывающий, что сломалось и где чинить.

Да, но он так же может работать и не от рута (с потерей части удобства). У нас есть такие клиенты.

В zabbix достаточно сложно положить скажем 1000 метрик, из которых хочется показать 1 график с topN метрик + other за приемлемое время.

В таком подходе много вопросов/проблем:

• платформа: zabbix не очень подходит для большого количества подробных метрик
• карма VS деньги: помимо того, что нужно выложить какие-то наработки, это нужно поддерживать и развивать, если это не монетизировать, проект быстро загнется. Такой подход могут себе позволить как правило большие компании, которым не сложно потратить пару человеко-лет на проект ради кармы.

Есть чат и есть в мониторинге кнопка Ack, которая останавливает нотификацию по алерту.

Нет, мы не понимаем друг друга, я говорю об идентификаторе метрики. Изобразить такое {name: nginx.requests.rate, url: /, method: GET, status: 400, log_file: /var/log/nginx/site.access.log, host: front1, plugin; logparser} в collectd нельзя, а например в telegraf можно.

В collectd у метрики идентификатор состоит из 4х фиксированных полей: plugin, instance, type, name. В таких рамках я не могу сделать метрику: количество GET запросов со статусом 400 к урлу / в логе /var/log/nginx/site.access.log. Именно это я имел ввиду под детализацией метрик. В prometheus это уже прекрасно ложится.

Про совместимость спорить не буду, наверное вы правы, было бы желание:)