Prometheus: yet-another-cloudwatch-exporter – сбор метрик AWS CloudWatch

Thank you for reading this post, don't forget to subscribe!

Сей­час в Prometehus мы соби­ра­ем мет­ри­ки из AWS CLoudWatch с помо­щью CloudWatch exporter от само­го AWS,  одна­ко, у него есть несколь­ко недостатков:

  • напи­сан на Java, тяжё­лый – гру­зит хост мониторнига
  • не под­тя­ги­ва­ет теги
  • исполь­зу­ет GetMetricStatistics для полу­че­ния метрик
  • уме­ет соби­рать мет­ри­ки толь­ко из одно­го реги­о­на – для несколь­ких реги­о­нов потре­бу­те­ся запус­кать несколь­ко експортёров

Что бы изба­вить­ся от этих про­блем – исполь­зу­ем вме­сто него yet-another-cloudwatch-exporter.

AWS CloudWatch – недостатки

Tags

Пер­вое, что крайне неудоб­но – это отсут­ствие тегов в мет­ри­ках, соби­ра­е­мых дефолт­ным експортёром.

Напри­мер, Application Load Balancer воз­вра­ща­ет­ся в таком виде:

Тогда как у само­го ALB тегов намно­го больше:

И сей­час в Grafana нет ника­кой воз­мож­но­сти эти теги исполь­зо­вать для выборки.

GetMetricStatistics vs GetMetricData

Вто­рой нюанс – это то, как екс­пор­тер соби­ра­ет мет­ри­ки, т.к. он исполь­зу­ет AWS API GetMetricStatistics.

Два года тому была откры­та issue Reduce cost of api operations by using GetMetricData API instead of GetMetricStatistics API – но воз и ныне там.

Про­бле­ма заклю­ча­ет­ся в том, что при GetMetricStatistics на каж­дую мет­ри­ку выпол­ня­ет­ся отдель­ный API-запрос.

Т.е., если у вас 100 ЕС2-инстан­сов, и у каж­до­го 10 мет­рик – то cloudwatch-exporter будет выпол­нять 1000 запро­сов каж­дые 60 секунд, что в резуль­та­те выли­ва­ет­ся в при­лич­ные деньги:

 

В отли­чии от AWS cloudwatch-exporter, в yet-another-cloudwatch-exporter исполь­зу­ет­ся запрос GetMetricData, кото­рый поз­во­ля­ет полу­чить до 500 мет­рик при выпол­не­нии еди­но­го запроса.

Запуск yet-another-cloudwatch-exporter

Попро­бу­ем полу­чить данные.

Созда­ём файл с дан­ны­ми досту­па к AWS, назо­вём его alb-cred:

Либо мож­но исполь­зо­вать AWS EC2 Instance Profile, но в его поли­ти­ку надо доба­вить раз­ре­ше­ния на выпо­лен­ние таких вызовов:

Созда­ём файл настро­ек само­го експортёра:


Запус­ка­ем его:

И про­бу­ем метрики:

Теперь видим все теги.

Настройка yet-another-cloudwatch-exporter

exportedTagsOnMetrics

Спи­сок тегов, кото­рые екс­пор­тер будет полу­чать вме­сте с мет­ри­ка­ми может быть огра­ни­чен exportedTagsOnMetrics.

Напри­мер – оста­вим толь­ко теги:

SeacrhTags

Так­же, мож­но гра­ни­чить спи­сок ресур­сов, с кото­рых будем соби­рать мет­ри­ки (ана­лог tag_selections в екс­пор­тё­ре от AWS).

Напри­мер, огра­ни­чим выбор кла­сте­ром “bttrm-eks-prod-1” – при­во­дим файл к виду:

Про­ве­ря­ем

 

Теперь полу­ча­ем мет­ри­ки толь­ко с одно­го кла­сте­ра, и толь­ко нуж­ны­ми нам тегами.

Запуск в Prometheus

У нас весь стек мони­то­рин­га запус­ка­ет­ся из Docker Compose – добав­ля­ем туда новый ексопртёр:

Обнов­ля­ем кон­фиг само­го Prometheus – добав­ля­ем новый таргет:


Про­ве­ря­ем таргет:

И мет­ри­ки:

Графики в Grafana

И теперь можем исполь­зо­вать эти мет­ри­ки в Grafana с выбор­кой по, напри­мер, окру­же­нию – devstageprod

А $env фор­ми­ру­ет­ся из нашей лейб­лы ekscluster, кото­рая добав­ля­ет­ся ко всем ресур­сам во вре­мя созда­ния кла­сте­ра из CloudFormation :

Гото­во