Айти развивается очень быстро.
Каждый день появляется много новых практик, инструментов, подходов и всё новое устаревает уже через пару лет.
Индустрия не успевает сама за собой.
Давайте поговорим о метриках.
У нас есть миллионы метрик.
Для нод, для кубера, для PV, для контейнеров, виртуальных машин и даже баз данных в кубере, для приложений.
Однако мы живём в современном мире гетерогенных сетей и несовершенстве
observability.Те метрики и подходы, которые были в 2011 году, в 2019 году и, особенно, 2025 году, безнадёжно отстали и редко показывают актуальную информацию.
Пример.
для одного только
Azure у нас есть целая матрица IOPS дисков, которая зависит от размера и сторадж класса + бёрстабл мод по времени.https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#standard-ssd-size
Штатные метрики есть, но они слишком убоги и отсталые:
- сколько осталось айнод
- сколько осталось места на диске(в нашем случае PV)
Как оперативно отслеживать нет ли где в кубернетисе ситуации, когда мы упираемся в предел по IOPS дискам?
PVC у нас несколько СОТЕН и десятки кластеров.
Везде разные классы и размеры.
Вручную прописывать это бред.
Штатно метрик у нас нет.
На помощь нам приходят
records.На стеке
victoria metrics(да вообще и в прометиусе тоже на самом деле) мы легко можем создавать такую сущность как vmalert и vmrule.ВМалёрт просто берёт правила алёртов и отправляет на ручку алёртменеджера.
У vmrule есть две функции:
- создавать
rule для алёртов- создавать новые
recordsТо есть через
records мы можем создавать свои, абсолютно удобные для нас метрики со своими лейблами. Или обогащать существущие метрики новыми лейблами.
Идея тут какая была:
- делаем матчинг между разными видами метрик(у них не матчатся лейблы)
- делаем ещё раз чтобы потом можно было матчить
- создаем матрицу "тип стораджа = максимальный IOPS для него"
- выводим новую метрику "текущий IOPS"
- выводим новую метрику "коэффициент IOPS" где 0 это 0%, а 1 это 100%.
Новую метрику можно использовать как для графиков в графане, так и для алёртов.
На базе подобного подхода мы НЕ зависим какой у нас тип сторадж класса, какой у нас размер PVC и так далее.
У нас есть матчинг POD-PVC-StorageClass-IOPS и мы просто готовую метрику получаем, а калькуляция уже внутри.
Например
pvc_iops_utilization_percent = 80 говорит о том, что мы для этого кластера/неймспейса/пода упирираемся в 80% от возможностей этого диска, использующего этот тип стораджа класса.И нам не важно какой там сторадж класс. мы просто знаем, что считаеся всё внутри Victoria metrics и мы просто на выходе получаем готовую метрику с лейблами (cluster namespace po etc) и мы дальше это где угодно используем:
- графана дашборды
- алёрты
❕Важно понимать, что это пока мой около MVP, в арифметике или логике могут быть мои ошибки, опечатки, неточности и в будущем я буду планировать это анализировать и актуализировать реальным данным.
Я могу по своему не знанию чего-то не учитывать и обязательно это поправлю в будущем.
#azure #metrics #victoriametrics