Использование AWS CloudWatch
Когда ваше приложение готово к развертыванию в производственной среде, отслеживание каждой связанной с ним деятельности существенно влияет на его производительность. Возможно, вам потребуется проанализировать загрузку ЦП сервера, пропускную способность сети, количество подключений, которые он обслуживает одновременно, и так далее.
AWS предоставляет службу мониторинга CloudWatch, которая позволит вам отслеживать различные метрики для серверов, на которых размещено ваше приложение, и сохранять эти метрики для последующего анализа. Однако ваше приложение может создавать настраиваемые внутренние журналы, связанные с различными бизнес-событиями: выполняются ли они должным образом, как долго выполняется каждое бизнес-событие и т. Д., И вы хотите централизовать процесс мониторинга журналов, отправляя каждый журнал в тот же монитор, а также агрегировать данные для дальнейшего анализа.
Чтобы продемонстрировать эту возможность CloudWatch, я буду использовать AWS Java SDK для создания простого приложения Spring Boot, которое будет измерять время, необходимое для выполнения действия, и публиковать метрики в CloudWatch. Обратите внимание, что метрики будут доступны CloudWatch в виде временных рядов, которые вы сможете анализировать в дальнейшем. Этот вариант использования может быть полезен при создании архитектуры решения MicroService и при необходимости измерить время, необходимое для бизнес-события, которое включает в себя несколько обращений к другим службам для завершения.
Стоит отметить, что по умолчанию у нас есть разрешение на публикацию показателей через интерфейс командной строки или API AWS. Чтобы продемонстрировать это, я создал настраиваемую политику, которая будет явно отказывать в разрешении на публикацию показателей в CloudWatch, как показано ниже, и если я назначу эту политику пользователю IAM, я не смогу публиковать данные настраиваемых показателей. через интерфейс командной строки или SDK.
Сначала я создал пользователя IAM с разрешениями EC2 (так как я также собираю метрики из экземпляров EC2, но не буду показывать это в этой статье). Я также создал простое приложение Spring Boot с зависимостью AWS CloudWatch и буду использовать принципы АОП, чтобы добавить логирование в существующий код. Полный исходный код демонстрационного сервиса и функции регистрации метрик доступен по ссылке this.
Дополнительное поведение, упомянутое выше, будет измерять время, необходимое для выполнения бизнес-функции, в нашем случае симуляции функции биллинга, и публиковать эту метрику в CloudWatch.
Метрики CloudWatch сгруппированы по пространству имен, и все сервисы AWS публикуют свои метрики в пространстве имен /aws (например, экземпляры EC2 публикуют метрики в пространстве имен /aws/ec2), поэтому мы не можем использовать это пространство имен для наших настраиваемых журналов. Вместо этого мы будем использовать собственный для нашей биллинговой службы: /APP_NAME/billing-service. Обратите внимание, что в этом сценарии у нас может быть приложение с несколькими службами и сгруппировать все метрики, генерируемые каждой службой, в одном пространстве имен - имени приложения APP_NAME.
В следующем фрагменте кода показан процесс ведения журнала для настраиваемой метрики. Я постараюсь подробно объяснить каждую часть кода.
Запрос PutMetricData выполняется в описанном ранее пространстве имен. Для запроса требуется MetricDatum объект, который будет содержать данные метрики - ее имя и значение. Теперь для каждого объекта данных метрики нам нужно предоставить один или несколько Dimension, которые также будут содержать данные «ключ-значение» для дальнейшей классификации метрики. Это может быть Server Id, на котором запущена служба (поскольку мы говорим об архитектуре MicroService, эту службу можно масштабировать по горизонтали на несколько серверов для обеспечения высокой доступности).
В следующем коде показан простой тест, который вызывает метод журнала со случайными данными.
В пользовательском интерфейсе CloudWatch, как показано на изображениях ниже, в меню Metrics слева мы можем заметить настраиваемое пространство имен только с одной метрикой, которая будет ServerId и будет содержать данные, регистрируемые каждым сервером.
Как я упоминал ранее, несколько серверов с разными идентификаторами могут публиковать метрики в одном и том же пространстве имен. На следующем изображении показана панель управления CloudWatch, которая отслеживает два экземпляра биллинговой службы.
Спасибо, что прочитали эту статью, и я надеюсь, что она окажется для вас полезной.
Заботиться
Ресурсы
CloudWatch - AWS
CloudWatch Java SDK - AWS
