Як використовувати статистику журналів AWS для запиту показників інформаційної панелі з журналів служб AWS

| | 0 Comments| 8:31 AM
Categories:

Кожен сервіс 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)

Оскільки за замовчуванням використання ЦП є інформацією, яка реєструється службою в CloudWatch, ви також можете зібрати цей тип метрики:

fields @timestamp, @message
| filter @message like /CPUUtilization/
| stats avg(value) by bin(1h)

Ці запити можна налаштувати відповідно до конкретного випадку використання та використовувати для створення власних показників і візуалізацій на інформаційних панелях CloudWatch. Спосіб, як це зробити, полягає в тому, щоб розмістити віджет на інформаційній панелі та розмістити код усередині віджета, щоб визначити, що вибрати.

  8 найкращих програм Wi-Fi Analyzer для особистого використання

Ось деякі з віджетів, які можна використовувати на інформаційних панелях CloudWatch і заповнювати вмістом із Log Insights:

  • Текстові віджети – відображають текстову інформацію, наприклад результат запиту CloudWatch Insights.
  • Віджети запитів журналу – відображають результати запиту журналу CloudWatch Insights, наприклад кількість помилок у журналах програми.

Як створити корисну інформацію журналу для інформаційної панелі

Джерело: aws.amazon.com

Щоб ефективно використовувати запити CloudWatch Insights на інформаційних панелях CloudWatch, доцільно дотримуватися деяких найкращих практик під час створення журналів CloudWatch для кожної служби, яку ви використовуєте у своїй системі. Ось кілька порад:

#1. Використовуйте структуроване журналювання

Ви повинні дотримуватися формату реєстрації, який використовує попередньо визначену схему для реєстрації даних у структурованому форматі. Це полегшує пошук і фільтрацію даних журналу за допомогою запитів CloudWatch Insights.

По суті, це означає стандартизацію ваших журналів для різних служб у вашій платформі архітектури. Надзвичайно допомагає його визначення в стандартах розробки.

Наприклад, ви можете визначити, що кожна проблема, пов’язана з певною таблицею бази даних, буде реєструватися з початковим повідомленням на кшталт: “[TABLE_NAME] Попередження / Помилка: <повідомлення>».

Або ви можете відокремити завдання повних даних від завдань дельта даних за допомогою префіксів на зразок «[FULL/DELTA]”, щоб вибрати лише повідомлення, пов’язані з конкретними процесами даних.

Ви можете визначити, що під час обробки даних із певної вихідної системи ім’я системи буде префіксом кожного пов’язаного запису журналу. Пізніше набагато простіше відфільтрувати такі повідомлення з файлів журналу та створити для них показники.

Джерело: aws.amazon.com

#2. Використовуйте узгоджені формати журналу

Використовуйте узгоджені формати журналів для всіх ресурсів AWS, щоб полегшити пошук і фільтрацію даних журналів за допомогою запитів CloudWatch Insights.

Це цілком пов’язано з попереднім пунктом, але факт полягає в тому, що чим більш стандартизованим є формат журналу, тим простіше використовувати дані журналу. Тоді розробники можуть покластися на цей формат і використовувати його навіть інтуїтивно.

Жорстокий факт полягає в тому, що більшість проектів не обтяжуються жодними стандартами щодо лісозаготівель. Більше того, багато проектів взагалі не створюють жодних спеціальних журналів. Це шокуюче, але водночас таке поширене.

  Як перевірити блок живлення за допомогою мультиметра

Я навіть не можу сказати, скільки разів я дивувався, як люди можуть жити тут без підходу до обробки помилок. І якщо хтось намагався зробити якусь обробку помилок як виняток, він зробив це неправильно.

Отже, послідовний формат журналу є сильною перевагою. Не у багатьох вони є.

#3. Додайте відповідні метадані

Додайте метадані до даних журналу, наприклад позначки часу, ідентифікатори ресурсів і коди помилок, щоб полегшити пошук і фільтрацію даних журналу за допомогою запитів CloudWatch Insights.

#4. Увімкнути ротацію журналу

Увімкніть ротацію журналу, щоб запобігти надто великому об’єму даних журналу та спростити пошук і фільтрацію даних журналу за допомогою запитів CloudWatch Insights.

Відсутність журнальних даних — це одне, але мати занадто багато їх без структури — це так само відчайдушно. Якщо ви не можете використовувати свої дані, це ніби не маєте жодних даних.

#5. Використовуйте агенти журналів CloudWatch

Якщо ви не можете допомогти собі і просто відмовляєтесь створювати свою налаштовану систему журналу, тоді принаймні скористайтеся агентами CloudWatch Logs. Вони автоматично надсилають дані журналу з ваших ресурсів AWS до журналів CloudWatch. Це полегшує пошук і фільтрацію даних журналу за допомогою запитів 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

Цей запит робить наступне:

  • Вибирає події журналу, які містять рядок «ПОМИЛКА», але не містять «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 найкращих результатів.
      Як автоматично приймати та відхиляти запрошення на нараду в Outlook

    Ви можете використовувати результати цього запиту, щоб створити лінійний графік на інформаційній панелі 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 містить два віджети:

  • Метричний віджет, який відображає середнє використання ЦП екземпляром EC2 за певний час. CloudWatch Insights Query заповнює віджет. Він вибирає дані про використання ЦП для конкретного екземпляра EC2 і агрегує їх з 5-хвилинними інтервалами.
  • Віджет журналу, який відображає кількість помилок програми за певний час. Він вибирає події журналу, які містять рядок «ERROR», і агрегує їх за годинами.
  • Це файл у форматі JSON із визначенням інформаційної панелі та показників усередині. Він також містить (як властивість) сам аналітичний запит.

    Ви можете взяти код і розгорнути його в будь-якому потрібному обліковому записі AWS. Якщо припустити, що служби та повідомлення журналу є узгодженими для всіх ваших облікових записів і етапів AWS, інформаційна панель працюватиме з усіма обліковими записами без необхідності змінювати вихідний код інформаційної панелі.

    Заключні слова

    Створення міцної структури журналювання завжди було хорошою інвестицією в майбутнє надійності системи. Тепер це може служити ще більшій меті. Ви можете мати корисні інформаційні панелі з показниками та візуалізаціями як побічний ефект цього.

    У зв’язку з тим, що це потрібно зробити лише один раз, лише з невеликою додатковою роботою, команда розробників, команда тестування та робочі користувачі можуть скористатися одним і тим же рішенням.

    Далі ознайомтеся з найкращими інструментами моніторингу AWS.