#costoptimization #aws #cloudwatch #одинденьизжизни

"Алекс, у нас снова траты по амазон, глянь по биллингу, чего можно скостить".

Иду в billing, выбираю последний месяц.
Дааа, много всего опять зачарджило. Чего можно убрать?
О, в топ 10 есть клаудвоч. Начну с него. Почему так много? Почти $2000+.
Смотрю что не так.
Внезапно много идет за графу

$0.01 per 1,000 metrics requested using GetMetricData API - US East (Northern Virginia)

200.000.000+ реквестов.
Читаю что это.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html

Ага. Какой-то сторонний механизм/утилита, которая при помощи кредов/роли подключается к AWS API и вытягивает данные по метрикам из клаудвоч.

Из известного мне есть такие два инструмента:
- https://github.com/prometheus/cloudwatch_exporter
- https://github.com/prometheus-community/yet-another-cloudwatch-exporter

Оба эти категории инструмента подключаются к AWS API, дергают метрики, экспортируют в удобный формат, чтобы можно было в victoria metrics/prometheus/grafana видеть эти новые метрики.
Почему новые? Они берут оригинальное название метрики, добавляют префикс и получается новая метрика в нашем хранилище.

Далее поиском по всем репозиториям(гит, арго, хелм) внутри компании ищу - есть ли они у нас.
Да, есть, у нас YACE.

Как оптимизировать? Мне ничего в голову не приходит, как сделать следующее:
- подключаюсь к service через порт форвард

kubectl port-forward svc/yet-another-cloudwatch-exporter 5000:5000

- вытягиваю все метрики в файл

curl localhost:5000/metrics > metrics.txt

- пишу баш скрипт, который считает количество уникальных метрик и всякое такое

Ага, у нас 54.000+ метрик. Это много.
Иду в конфиг в гите, там нечто типа

config: |-
    apiVersion: v1alpha1
    discovery:
      exportedTagsOnMetrics:
        AWS/NetworkELB:
          - tenant-id
          - type
          - cluster
      jobs:
        - type: AWS/NetworkELB
          regions:
            - us-east-1
...
            - eu-central-1
            - eu-central-2
          period: 300
          length: 300
          metrics:
            - name: ActiveFlowCount
              statistics: [Average, Minimum, Maximum]
            - name: ActiveFlowCount_TLS
              statistics: [Average, Minimum, Maximum]
...
            - name: UnHealthyHostCount
              statistics: [Average, Minimum, Maximum]
            - name: PortAllocationErrorCount
              statistics: [Sum]
...
        - type: AWS/TransitGateway
          regions:
            - us-east-1
...
          period: 300
          length: 300
          metrics:
            - name: BytesIn
              statistics: [Average, Minimum, Maximum, Sum]
            - name: BytesOut
              statistics: [Average, Minimum, Maximum, Sum]
            - name: PacketsIn
              statistics: [Average, Minimum, Maximum, Sum]
...
        - type: AWS/NATGateway
          regions:
            - us-east-1
...
            - eu-central-2
          period: 300
          length: 300
          metrics:
            - name: ActiveConnectionCount
              statistics: [Maximum, Sum]
            - name: BytesInFromDestination
              statistics: [Sum]
...

И такого там много.

По частоте опроса вроде ок - 300 секунд, около бест практис для клаудвоч экспортёров.
А чего подрезать-то тогда?
Нужен ли max? Min? Avg?
Следим ли мы за натгейтвеем?

А всё просто.
- при том же bash скрипте расписываем все уникальные метрики и их итоговое название.
- идём все репозитории с алертингом и мониторингом (alertmanager, grafana irm, vmalert, grafana dashboards etc)
- если метрика нигде в observability не используется - мы её просто убираем из конфига. Где-то только min, где-то max, где-то полностью всю метрику со всеми значениями

Даже если удастся убрать хотя бы 50% неиспользуемых метрик - это минус 50% от биллинга, а это $1000+
Пулл реквест, ревью, аппрув, раскатываем.
Всё, в следующем месяце ждём снижения костов на клаудвоч на 50%+