Кожна служба AWS фіксує свою діяльність у файлах, згрупованих у лог-групи CloudWatch. Для зручності ідентифікації, лог-групи зазвичай іменуються відповідно до самої служби. Системні повідомлення служби або загальна інформація про стан за замовчуванням записуються в ці лог-файли.
Однак, можна додати кастомну інформацію до лог-повідомлень на додаток до стандартної. Грамотно створюючи такі журнали, їх можна використовувати для побудови корисних панелей моніторингу CloudWatch.
З показниками та структурованою інформацією, що надають додаткові відомості про обробку завдань, можна не лише використовувати стандартні віджети з системною інформацією про сервіс. Є можливість розширити їх за допомогою власного контенту, інтегрувавши його у власні віджети або метрики.
Аналіз лог-файлів
Джерело: aws.amazon.com
AWS CloudWatch Log Insights надає можливість пошуку та аналізу даних журналів з ресурсів AWS в режимі реального часу. Це можна порівняти з переглядом бази даних. Ви визначаєте запит на панелі моніторингу, і панель використовує його при кожному відвідуванні або у вказаний проміжок часу в минулому, як це задано у налаштуваннях панелі.
Для пошуку та аналізу лог-даних використовується мова запитів CloudWatch Logs Insights, заснована на підмножині SQL. Вона дозволяє проводити пошук та фільтрацію лог-даних, знаходити конкретні події, власний текст або ключові слова, а також фільтрувати дані на основі заданих полів. Крім того, можна об’єднувати дані з одного або декількох лог-файлів для створення зведених метрик і візуалізацій.
При виконанні запиту, CloudWatch Log Insights проводить пошук даних у лог-групі, повертаючи текстові рядки з файлів, що відповідають критеріям запиту.
Приклади запитів до лог-файлів
Розглянемо декілька основних запитів для розуміння концепції.
За замовчуванням кожна служба реєструє критичні помилки. Навіть якщо не створювати кастомний журнал для таких помилок, простий запит дозволить підрахувати їх кількість за останню годину:
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)Або, можна відстежити середній час відгуку API за останню добу:
fields @timestamp, @message
| filter @message like /API response time/
| stats avg(response_time) by bin(1d)Оскільки використання CPU є стандартною метрикою, що записується службою в CloudWatch, її також можна отримати:
fields @timestamp, @message
| filter @message like /CPUUtilization/
| stats avg(value) by bin(1h)Ці запити можна налаштувати під конкретні потреби та використовувати для створення кастомних метрик та візуалізацій на панелях CloudWatch. Для цього потрібно розмістити віджет на панелі моніторингу та вставити код всередину віджета, щоб задати необхідні параметри.
Ось деякі типи віджетів, що можна використовувати на панелях CloudWatch, наповнюючи їх даними з Log Insights:
- Текстові віджети – відображають текстову інформацію, наприклад результат запиту CloudWatch Insights.
- Віджети запитів журналу – відображають результати запиту CloudWatch Insights, наприклад кількість помилок програми.
Створення корисної лог-інформації для панелі моніторингу
Джерело: aws.amazon.com
Для ефективного використання запитів CloudWatch Insights на панелях, слід дотримуватися певних рекомендацій при створенні журналів CloudWatch для кожної використовуваної служби. Ось декілька порад:
#1. Використовуйте структуроване журналювання
Необхідно використовувати формат запису, що використовує попередньо визначену схему для реєстрації даних у структурованому вигляді. Це спростить пошук та фільтрацію даних за допомогою запитів CloudWatch Insights.
По суті, це означає стандартизацію журналів для різних служб в архітектурі. Визначення стандарту є дуже корисним на етапі розробки.
Наприклад, можна визначити, що кожна проблема, пов’язана з певною таблицею бази даних, буде реєструватися з початковим повідомленням, наприклад: “[TABLE_NAME] Попередження / Помилка: <повідомлення>”.
Або, можна розрізняти завдання повних та дельта-даних, використовуючи префікси, наприклад, “[FULL/DELTA]”, щоб вибирати повідомлення, пов’язані з конкретними процесами.
Можна визначити, що при обробці даних із певної системи, ім’я системи буде префіксом кожного запису журналу. Пізніше буде набагато простіше відфільтрувати такі повідомлення та створити на їх основі показники.
Джерело: aws.amazon.com
#2. Використовуйте узгоджені формати журналів
Необхідно використовувати єдині формати журналів для всіх ресурсів AWS, щоб спростити пошук та фільтрацію даних за допомогою запитів CloudWatch Insights.
Це тісно пов’язано з попереднім пунктом, і факт залишається фактом, що чим стандартизованіший формат журналу, тим простіше використовувати лог-дані. Розробники можуть покладатися на цей формат та використовувати його інтуїтивно.
Прикра правда полягає в тому, що більшість проектів не обтяжують себе стандартами ведення журналів, а багато проектів взагалі не створюють спеціальних лог-файлів. Це шокує, але, на жаль, є дуже поширеним явищем.
Неодноразово доводилося дивуватися, як люди можуть працювати без підходу до обробки помилок. І якщо хтось намагався це зробити, то найчастіше це було зроблено неправильно.
Отже, послідовний формат журналу є сильною перевагою, якою, на жаль, не багато хто користується.
#3. Додавайте відповідні метадані
Необхідно додавати метадані до лог-даних, наприклад, мітки часу, ідентифікатори ресурсів і коди помилок, щоб полегшити пошук та фільтрацію даних за допомогою запитів CloudWatch Insights.
#4. Увімкніть ротацію журналів
Необхідно ввімкнути ротацію журналів, щоб запобігти їх надмірному розростанню та спростити пошук і фільтрацію даних за допомогою запитів CloudWatch Insights.
Відсутність лог-даних – це погано, але їх надмірна кількість без структури – це не краще. Якщо ви не можете використовувати ваші дані, то це все одно, що їх немає.
#5. Використовуйте агенти CloudWatch Logs
Якщо ви не можете змусити себе створити свою власну систему журналювання, тоді хоча б скористайтеся агентами CloudWatch Logs. Вони автоматично надсилають лог-дані з ресурсів AWS у CloudWatch Logs. Це полегшує пошук і фільтрацію даних за допомогою запитів CloudWatch Insights.
Приклади складніших запитів Insights
Запит CloudWatch Insights може бути складнішим, ніж простий дворядковий оператор.
fields @timestamp, @message
| filter @message like /ERROR/
| filter @message not like /404/
| parse @message /.*[(?<timestamp>[^]]+)].*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/
| stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status
| sort count desc
| limit 20Цей запит робить наступне:
- Вибирає події журналу, які містять рядок «ERROR», але не містять «404».
- Розбирає повідомлення журналу, щоб отримати мітку часу, метод HTTP, шлях, код стану та час відгуку.
- Обчислює середній час відгуку та кількість подій журналу для кожної комбінації методу HTTP, шляху, коду стану та години.
- Сортує результати за кількістю у порядку спадання.
- Обмежує вивід до 20 найкращих результатів.
Цей запит визначає найбільш поширені помилки у додатку та відстежує середній час відгуку для кожної комбінації методу HTTP, шляху та коду стану. Результати можна використовувати для створення кастомних показників і візуалізацій на панелях CloudWatch, для моніторингу продуктивності веб-застосунку та усунення проблем.
Інший приклад запиту повідомлень служби Amazon S3:
fields @timestamp, @message
| filter @message like /REST.API.REQUEST/
| parse @message /.*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/
| stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status
| sort count desc
| limit 20- Запит вибирає події журналу, що містять рядок “REST.API.REQUEST”.
- Потім аналізує повідомлення журналу для отримання методу HTTP, шляху, коду стану та часу відповіді.
- Обчислює середній час відповіді та кількість подій для кожної комбінації HTTP-методу, шляху та коду стану, а також сортує результати за кількістю у порядку спадання.
- Обмежує вивід до 20 найкращих результатів.
Результати цього запиту можна використовувати для створення лінійного графіка на панелі CloudWatch, що відображає середній час відповіді для кожної комбінації методу HTTP, шляху та коду стану за певний період часу.
Створення панелі моніторингу
Щоб наповнити панелі CloudWatch показниками та візуалізаціями з результатів запитів CloudWatch Insights, потрібно перейти до консолі CloudWatch та скористатися майстром створення панелі.
Далі представлено приклад коду панелі CloudWatch з метриками, що наповнені даними з CloudWatch Insights:
{
"widgets": [
{
"type": "metric",
"x": 0,
"y": 0,
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/EC2",
"CPUUtilization",
"InstanceId",
"i-0123456789abcdef0",
{
"label": "CPU Utilization",
"stat": "Average",
"period": 300
}
]
],
"view": "timeSeries",
"stacked": false,
"region": "us-east-1",
"title": "EC2 CPU Utilization"
}
},
{
"type": "log",
"x": 0,
"y": 6,
"width": 12,
"height": 6,
"properties": {
"query": "fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)
",
"region": "us-east-1",
"title": "Application Errors"
}
}
]
}Ця панель CloudWatch містить два віджети:
- Метричний віджет, що відображає середнє використання CPU екземпляром EC2 за певний час. Віджет наповнюється даними з запиту CloudWatch Insights. Він вибирає дані про використання CPU для конкретного екземпляра EC2 та агрегує їх з 5-хвилинними інтервалами.
- Віджет журналу, що відображає кількість помилок застосунку за певний час. Він вибирає події журналу, що містять рядок “ERROR”, та агрегує їх за годинами.
Це JSON-файл із визначенням панелі та показників. Він також містить (як властивість) сам аналітичний запит.
Цей код можна розгорнути в будь-якому обліковому записі AWS. Якщо служби та повідомлення журналів є узгодженими для всіх облікових записів та етапів AWS, панель працюватиме з усіма обліковими записами без необхідності змінювати початковий код.
Підсумки
Створення надійної системи журналювання завжди було гарною інвестицією в надійність системи. Тепер вона може слугувати ще більшій меті – забезпечити корисні панелі моніторингу з метриками та візуалізаціями.
Оскільки цю роботу потрібно зробити лише один раз, команда розробників, тестувальників та кінцеві користувачі можуть скористатися одним і тим же рішенням.
Пропонуємо також ознайомитися з найкращими інструментами моніторингу AWS.