Моніторинг розподіленої хмари: сервіси та інструменти

Вітаю, спільното! Мене звати Володимир Вишко, і вже майже 4 роки я Solution Architect у GlobalLogic. Мій шлях в ІТ розпочався понад 12 років тому з позиції Java Developer, а сьогодні я зосереджуюсь на плануванні інфраструктури для розподілених застосунків у сфері енергетики.

У цій статті разом із моїм колегою Владиславом Браницьким, Solution Architect із понад 9-річним досвідом у GlobalLogic, ми розглянемо ключові аспекти моніторингу розподілених хмарних систем.

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

Крім того, критично важливо розуміти різницю між логуванням та моніторингом — практиками, що використовуються для контролю розподіленої хмари. При моніторингу розподіленої хмари може виникнути низка проблем: несумісність різних форматів логів, проблеми з підключенням та безпекою. Проте існує безліч інструментів, які можуть допомогти розвʼязати ці проблеми. Тож розглянемо найкращі практики та інструменти для управління розподіленою хмарою.

Вступ

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

Де це може зустрічатися на практиці? Наприклад, міжнародна роздрібна мережа з магазинами по всьому світу. Для такої компанії розподілена хмара забезпечить швидкий доступ до даних про товари, ціни та складські залишки для всіх магазинів, незалежно від того, в якій країні вони розташовані. Розміщення частини інфраструктури в регіональних хмарних зонах або локальних дата-центрах поблизу магазинів зменшує затримку при роботі касових систем та інших критично важливих застосунків. Крім того, це допомагає дотримуватися місцевих вимог щодо зберігання даних про продажі та клієнтів у кожній країні. А централізована панель керування дозволяє IT-відділу контролювати всю інфраструктуру з єдиної точки.

Інший приклад — мережа заводів виробників трансформаторів, де кожна локація має свою локальну AI-модель для контролю якості. Ці edge-локації підключені до центральної хмари, але основний аналіз відеопотоків відбувається локально. У разі виявлення дефекту система надсилає сигнал до центральної хмари, зберігаючи функціональність та зменшуючи обсяги трафіку. Такий підхід не лише підвищує ефективність, а й покращує безпеку системи, оптимізуючи процеси обміну даними.

Однією з найбільших проблем є visibility (видимість) гібридної хмарної інфраструктури. Поєднання однієї або кількох хмар з локальною інфраструктурою може значно ускладнити моніторинг та додати ризиків. Організаціям же потрібен контроль для управління цією складністю та запобігання прогалинам у безпеці. Зрештою, якщо ви не можете бачити та оцінювати щось, ви, безумовно, не зможете належним чином це захистити.

Логування VS моніторинг: у чому різниця

Існують дві важливі техніки, які можуть допомогти вам у випадку відмови застосунку під час його розгортання: логування та моніторинг.

Логування — це процес запису подій, повідомлень та помилок, що виникають під час роботи застосунку, з метою відстеження його стану та діагностики проблем.

Процес логування застосунків включає наступні етапи:

• Агрегація логів (Log aggregation) — збір журналів подій з різних місць розташування та їх збереження в централізованому сховищі.
• Зберігання логів (Log storage) — визначення та впровадження стратегії зберігання файлів журналів, а також контроль їхнього видалення після завершення встановленого терміну зберігання.
• Аналіз логів (Log analysis) — перегляд даних журналів за допомогою спеціалізованих аналізаторів. Це допомагає знижувати ризики, забезпечувати відповідність політикам безпеки, аудитам і нормативним вимогам. Важливо не плутати аналіз логів з моніторингом. Аналіз логів є роботою після інциденту, тоді як моніторинг є постійним процесом.

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

Моніторинг та логування часто вважаються одним і тим же. Хоча вони тісно пов’язані, моніторинг використовує дані логування як джерело. Тому на практиці краще обʼєднувати команди моніторингу та логування.

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

Несумісність через різні формати логів

Різні хмарні або локальні середовища можуть відрізнятися форматами логів. Якщо треба здійснювати моніторинг усіх середовищ з однієї центральної точки (дашборду), необхідно зібрати та інтерпретувати всі наявні формати логів для їхнього «розуміння» та коректного відображення різних подій, що фіксуються в журналах з різних місць. Також важливо передбачити можливість розширення системи моніторингу гібридної розподіленої хмари для підтримки нових середовищ з новими форматами логів.

Наприклад, ваша компанія використовує гібридну розподілену хмару, яка включає:

• Локальний кластер Kubernetes: генерує логи у форматі CRI (JSON), де кожне повідомлення є окремим JSON-об’єктом з полями на кшталт timestamp, level, service, message.
• Хмарний сервіс в AWS: записує логи до текстових файлів в S3, де кожен рядок має формат [час] [рівень] [сервіс] — [повідомлення].
• Сервіс моніторингу від стороннього постачальника: Надсилає логи у форматі структурованого тексту з роздільниками-комами (CSV), де поля розташовані в певному порядку: час,рівень,сервіс,повідомлення.

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

1. Зібрати логи з усіх трьох джерел.
2. Інтерпретувати кожен формат:
   • Для JSON потрібно розпарсити кожен об’єкт і витягти значення полів timestamp, level та message.
   • Для текстових файлів AWS потрібно застосувати регулярні вирази або спеціальні парсери для вилучення відповідних значень з кожного рядка.
   • Для CSV потрібно розділити кожен рядок за комою та визначити, який стовпець відповідає часу, рівню та повідомленню.
3. Уніфікувати дані: перетворити дані з різних форматів до єдиного внутрішнього представлення, щоб система моніторингу могла їх обробляти та відображати. Наприклад, привести всі часові мітки до єдиного формату, а рівні логування (наприклад, «Error», «Warning», «Info») — до стандартних числових або текстових значень.
4. Створити сповіщення: налаштувати правила, які спрацьовуватимуть на основі уніфікованих даних. Наприклад, сповіщати про всі події з рівнем «Error» незалежно від того, з якого джерела вони надійшли та в якому форматі були спочатку.

Крім того, якщо ви додасте нову систему, яка генерує логи в іншому, унікальному форматі (наприклад, XML), вам потрібно буде розширити вашу систему моніторингу, додавши новий парсер та логіку інтерпретації для цього формату, щоб вона могла «розуміти» і ці логи.

Необхідність централізації систем моніторингу

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

Основна проблема полягає в об’єднанні цих розрізнених систем в одну централізовану систему моніторингу. Кожна власна система моніторингу має свої методи збору інформації, набори ключових показників ефективності (KPI), способи представлення та візуалізації даних. Завдання полягає в тому, щоб інтерпретувати всі ці відмінності між системами моніторингу та привести їх до єдиного централізованого формату.

Підключення

Наша централізована система моніторингу повинна знати, як діяти у випадках, коли втрачається підключення до окремої хмари або локальної системи. Тобто нам потрібно, щоб:

• не порушувалася робота моніторингу та візуалізація KPI інших частин системи.
• підключення автоматично відновлювалося після повернення зв’язку.
• збір інформації з відповідного елемента системи продовжувався після відновлення підключення.

І, звісно, ми маємо забезпечувати захищеність нашої моніторингової системи від доступу будь-яких сторонніх осіб.

Централізована архітектура моніторингу

Розподілена хмара створює певні виклики для централізації, цілісності, безпеки та надійності моніторингу в різних середовищах. Універсального архітектурного рішення — не існує. Його структура повинна враховувати обмеження та вимоги конкретної компанії. Розглянемо таку архітектуру:

Кожна частина архітектури може мати власний підхід до надсилання, зберігання або візуалізації даних моніторингу. Наприклад, компонент AWS може містити окремий інстанс EC2 з кастомним Java-застосунком та вбудованим хмарним клієнтом для відправки логів та даних моніторингу через публічний API. Або ж застосунок може бути складнішим і працювати в кластері EKS з кількома вузлами Kubernetes. Kubernetes API-сервер надає ряд метрик, корисних для моніторингу та аналізу.

А ще може використовуватись стороння платформа управління, яка виступає в ролі адаптуючого посередницького програмного забезпечення (middleware) для широкого спектра хмарних провайдерів. Однією з таких платформ управління є партнер Google — Blue Medora BindPlane. Вона дозволяє користувачам імпортувати дані моніторингу та логування від популярних хмарних провайдерів, включаючи AWS, GCP, IBM та Alibaba Cloud, а також з локальних віртуальних машин.

Ми користуємось цими рішеннями в роботі, адже вони надають широкий спектр функцій, джерел даних, інтегрованих інформаційних панелей та інших можливостей «з коробки». З іншого боку, це також тягне за собою додаткову архітектурну складність та витрати.

* У деяких випадках журнали подій (логи) будуть важливі з різних причин. Деякі з них слід направляти до централізованого місця, інші — пропускати. Для цього теж існує кілька рішень на ринку, які пропонують таку функціональність. Найпопулярнішими серед яких є Fluent Bit та Fluentd. Вони можуть зчитувати логи та метрики з локальних файлів, мережевих пристроїв, контейнерів Docker тощо. Ось приклад роботи Fluent Bit у гібридній конфігурації EKS + ECS із централізованою агрегацією логів до бакету S3 за допомогою Firehose ETL. Ці логи можуть бути надалі проаналізовані за допомогою AWS Athena.

Ця архітектура — хороший вибір, якщо ви:

• Хочете налаштовувати журнали подій (логи) та видаляти з них конфіденційні дані.
• Маєте консистентне логування Kubernetes/ECS у хмарних та локальних середовищах.
• Не бажаєте витрачати додаткові кошти на ліцензування сторонніх сервісів.

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

Як бачите, існує безліч різних способів організації централізованої агрегації логів та метрик. Ми показали лише декілька прикладів, тепер розглянемо більше архітектур та сервісів.

Агрегація та моніторинг логів гібридної хмари на платформі AWS Cloud

Іноді нам потрібно лише збирати логи та метрики в централізованому місці в публічній хмарі, уникаючи зайвих витрат на такі розширені сервіси, як AWS Outposts, Azure Arc тощо. Розглянемо можливі рішення на базі хмарної платформи AWS.

CloudWatch Agent

Перше, що спадає на думку, коли ми говоримо про логи та хмару AWS, — це сервіс CloudWatch. Amazon CloudWatch Logs дозволяє нам моніторити, зберігати та мати доступ до файлів логів з інстансів Amazon Elastic Compute Cloud (Amazon EC2), AWS CloudTrail, Route 53 та інших джерел. Однак для його використання з приватними локальними середовищами та іншими хмарами необхідно встановити агент CloudWatch у відповідних місцях.

CloudWatch Agent дає змогу збирати метрики системного рівня з локальних серверів, які можуть включати сервери в гібридному середовищі, а також сервери, що не керуються AWS. Розглянемо одну з можливих архітектур з брокером Kafka та агентом CloudWatch як центральним вузлом для агрегації логів. Це рішення не потребує жодних змін у вихідному коді застосунку. Усі логи та метрики можуть бути зібрані за допомогою Kafka або іншої системи обміну повідомленнями (MQ) та передані до хмари AWS.

Метрики, які ви збираєте за допомогою агента CloudWatch, можна зберігати та переглядати в CloudWatch так само як і будь-які інші метрики CloudWatch. Агент CloudWatch — з відкритим вихідним кодом, розповсюджується за ліцензією MIT та розміщений на GitHub.

CloudWatch SDK

Іноді простіше розширити функціональність певних застосунків та використовувати AWS CloudWatch SDK для надсилання логів та метрик до хмари AWS.

Таке рішення не рекомендується для впровадження в бекенд-застосунках, оскільки має ряд недоліків, включаючи:

• Необхідність модифікації коду застосунку. Уявіть, що у вас є Java-застосунок. Щоб почати відправляти логи та метрики через CloudWatch SDK, вам доведеться додати до коду залежності SDK, написати код для ініціалізації клієнта CloudWatch, а потім у кожному місці, де ви хочете записати лог або відправити метрику, додати відповідний виклик API CloudWatch SDK. Це означає, що розробники повинні будуть змінювати існуючий код застосунку.
• Додаткові ризики безпеки. Якщо ви безпосередньо вбудовуєте AWS CloudWatch SDK у свій застосунок, вам потрібно буде керувати обліковими даними AWS (наприклад, ключами доступу) всередині цього застосунку або на віртуальній машині, де він працює. Неправильне керування цими обліковими даними може призвести до їх витоку та несанкціонованого доступу до ваших ресурсів AWS.
• Проблеми з горизонтальним масштабуванням. Якщо ваш застосунок масштабується горизонтально (тобто ви запускаєте кілька копій одного й того ж застосунку для обробки більшого навантаження), кожна копія буде відповідальна за надсилання власних логів та метрик безпосередньо до CloudWatch. Це може призвести до неконсистентності даних (наприклад, дублювання метрик або пропуску деяких логів, якщо одна з копій вийде з ладу) та ускладнення агрегації та аналізу даних. Крім того, кожна інстанція застосунку використовуватиме додаткові ресурси для роботи SDK та надсилання даних, що може вплинути на загальну продуктивність.

Однак, іноді використання агента CloudWatch є неможливим. У таких випадках AWS SDK може допомогти вирішити проблему. Наприклад, вам може знадобитися виконати агрегацію логів для клієнтських застосунків — настільних, браузерних JS-застосунків та мобільних застосунків. Або ж вам може знадобитися виконати певну обробку логів, наприклад, видалення конфіденційних даних, перед їх відправкою до хмари.

Рішення на базі Kibana (OpenSearch Dashboards)

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

Ви можете використовувати Kibana для візуалізації та звітування за різноманітними KPI; для прийняття бізнес-рішень у Elastic SaaS бізнесі; а також для аналітичних бізнес-задач, включаючи візуалізації, індексацію та представлення даних. Kibana має розширені можливості для пошуку та фільтрації логів. Ви можете створювати багаторазові запити для фільтрації корисної інформації у вашому конкретному випадку. Це швидко та надійно, оскільки в основі лежить Elasticsearch.

Kibana може бути тісно інтегрована з системами оркестрації, такими як Kubernetes, і навіть розгорнута в тому ж кластері K8S за допомогою Helm chart. Загалом Kibana надає певний рівень переносимості до інших хмарних провайдерів у випадку, якщо ви захочете мігрувати з AWS на щось інше, наприклад, Azure або GCP.

Зверніть увагу, що Amazon OpenSearch Service — це наступник Amazon Elasticsearch Service, і починаючи з версій OpenSearch 1.x, Kibana більше не використовується. Замість нього застосовується OpenSearch Dashboards — це відкритий форк Kibana, який має дуже схожий інтерфейс та функціональність. Якщо ви плануєте використовувати Amazon OpenSearch Service, вам слід орієнтуватися саме на OpenSearch Dashboards як основний інструмент візуалізації. Він дозволяє створювати гнучкі та інтерактивні дашборди, аналітичні панелі, а також має потужні засоби для пошуку, фільтрації й обробки логів — подібно до Kibana, але з відкритим розвитком у рамках проєкту OpenSearch.

Моніторинг розподіленого кластера Kubernetes

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

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

Не завжди можливо запустити кластер Kubernetes в одного хмарного провайдера з багатьох причин (таких як GDPR, HIPAA тощо), тому деякі частини можуть працювати локально або в інших хмарних провайдерів.

У такій архітектурі моніторинг та видимість є критично важливими аспектами стабільності всієї системи. Ось одна з можливих архітектур: розподілений кластер Kubernetes між EKS та GKE з налаштуванням сервісної сітки на базі Istio.

Istio надає розширені мережеві функції — балансування навантаження, міжсервісна автентифікація, моніторинг тощо, — без необхідності внесення будь-яких змін до коду сервісів. За допомогою Istio ви отримуєте моніторинг трафіку між мікросервісами за замовчуванням, а також можливість об’єднати два окремі кластери K8S і змусити їх працювати як один кластер.

Використовуючи Terraform (або будь-який інший інструмент IaaC), можна налаштувати все розподілене середовище за запитом, створивши нову VPC в кожній хмарі, VPN-з’єднання між ними, Kubernetes master (EKS & GKE) та запустити робочі вузли в кожній хмарі.

Потім ми можемо встановити Istio як «сервісну сітку». Це, по суті, дозволяє двом кластерам Kubernetes діяти як єдиний пул ресурсів, з телеметрією та видимістю одночасно в обох.

Istio розгортає Envoy proxy як sidecar-контейнер у кожному поді, що надає сервіс. Цей проксі-сервер виступає посередником для кожного з’єднання і, перебуваючи в цій позиції, керує вхідним/вихідним трафіком. Завдяки цьому значно розширюються можливості моніторингу трафіку.

Для моніторингу ваших мікросервісів у режимі реального часу ви можете використовувати Istio Dashboard за допомогою аддона Kiali. При цьому ви не обмежені лише Istio і можете розгорнути в розподіленому кластері Kubernetes будь-які інші інструменти, такі як Kibana або Grafana.

Зразок вихідного коду можна переглянути тут:

github.com/magic7s/k8s-hybrid-cloud

Інструменти моніторингу рішень для розподілених хмар: огляд кластерів

Google Anthos

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

Структура платформи Anthos є складною, але її можна розділити на чотири основні сервіси: керування та оркестрація контейнерів, управління інфраструктурою, застосування політик та управління сервісами.

В основі Anthos лежить Google Kubernetes Engine (GKE). Anthos GKE — це той самий дистрибутив Kubernetes, який керується Google Cloud. Anthos відповідає за оновлення та патчі безпеки для GKE. Проте чистий Kubernetes не надає можливості об’єднання кількох кластерів в один. Для досягнення цієї мети Anthos використовує сервісну сітку Istio від Google. Вона має численні переваги, але найважливішими є її гнучкість та відкритий вихідний код.

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

Крім того, Anthos пропонує безсерверний досвід для контейнерів за допомогою Cloud Run for Anthos, що базується на open-source проєкті Knative, спочатку створеному Google. Anthos Cloud Run сумісний з Anthos Service Mesh та надає вбудовані можливості балансування навантаження, автоматичного масштабування та моніторингу.

Логування та моніторинг в Anthos є однією з ключових переваг для розподіленої хмари, оскільки ми можемо керувати Anthos за допомогою тих самих інструментів, які використовуємо для управління застосунками в Google Cloud. Cloud Logging надає єдине місце для зберігання та аналізу логів. Логи, що генеруються кластером, автоматично надсилаються до Cloud Logging. Це працює «з коробки», вам не потрібно витрачати додатковий час на налаштування дашбордів для збору метрик у гібридних або мультихмарних середовищах.

Kubernetes Engine Monitoring, увімкнений за замовчуванням, забезпечує інтеграцію, яка зберігає критично важливі метрики застосунку.

Використовуючи ці інструменти, Anthos дозволяє нам застосовувати ці логи та метрики для налагодження, оповіщення та аналізу після інцидентів. Логи та метрики рівня сервісів Anthos Service Mesh та Anthos Cloud Run (затримка, помилки, кількість запитів на секунду тощо) автоматично збираються та надсилаються до Cloud Monitoring та Cloud Logging без будь-якої додаткової конфігурації.

Azure Stack та Azure Arc

Azure Stack — це апаратне рішення та розширення Azure для запуску гібридних застосунків у локальних середовищах (Azure Stack Hub та Azure Stack HCI) та на периферії (Azure Stack Edge).

Azure Stack HCI надає гіперконвергентну інфраструктуру із серверами з програмно-визначеними обчисленнями, зберіганням та нетворкінгу. Кластер Azure Stack HCI «з коробки» підтримує Azure Arc, що забезпечує інтеграцію з Azure, інструментами управління та вбудованою безпекою. Ви можете легко розгорнути кластер Kubernetes, сумісний з AKS.

Azure Stack Edge дозволяє перемістити обчислення та зберігання на периферію.

Azure Arc — це програмне рішення, яке надає сервіси та управління Azure будь-якій інфраструктурі: локальній, периферійній та мультихмарній (Azure, AWS та Google Cloud). Він дозволяє використовувати Azure Resource Manager та керувати віртуальними машинами, будь-якими CNCF-сумісними кластерами Kubernetes та базами даних. Однак, на відміну від Google Anthos, Azure Arc не прив’язаний до інфраструктури Kubernetes.

Сервіси з підтримкою Azure Arc, такі як Azure App Service, Azure Functions, Azure Logic Apps, Azure Event Grid та Azure API Management, дозволяють запускати вебзастосунки, API, безсерверні застосунки, event-based застосунки та автоматизовані робочі процеси будь-де.

Так само як і Google Anthos, Azure Arc надає готові інструменти для логування та моніторингу. Агент Log Analytics збирає дані журналів (дані про продуктивність та події), і зберігає їх у робочій області Log Analytics. Azure Monitor використовує VM insights для моніторингу процесів застосунків та їхніх залежностей з іншими ресурсами.

AWS Outposts

AWS Outposts — це апаратне рішення, що надає ту саму інфраструктуру AWS для локальних центрів обробки даних. AWS Outposts містить кілька сервісів AWS:

1. Реляційна база даних (RDS).
2. Amazon Elastic Compute Cloud (EC2).
3. Amazon Elastic Kubernetes Services (EKS).
4. Amazon S3 (локальне сховище).
5. AWS App Mesh Envoy proxy.
6. Amazon ElastiCache.
7. Elastic MapReduce (EMR).
8. Application Load Balancer (ALB).
9. AWS VPC (локальний).

Варто звернути увагу, що багато сервісів AWS не можуть бути запущені безпосередньо на Outpost. Вони будуть доступні віддалено. Наприклад є обмеження по CloudFront, AWS Fargate, Amazon Kinesis, DevOps та CI/CD.

Щоб почати роботу з AWS Outposts, вам необхідно замовити одну з повністю інтегрованих та попередньо перевірених конфігурацій Outpost. Сертифікований персонал AWS доставить та встановить стійку Outpost і підключить її до локальної мережі. Після цього ви зможете запускати свої застосунки на Outpost, використовуючи консоль AWS, CLI або SDK.

AWS Outposts інтегровані з сервісами, що пропонують можливості моніторингу та логування, тому ви можете переглядати всі логи в консолі керування AWS.

AWS CloudWatch отримує статистику про точки даних у вигляді впорядкованого набору часових рядів, відомих як метрики. AWS Outposts автоматично публікує ці метрики в AWS CloudWatch.

Ви можете відстежувати будь-які метрики з вашого Outpost за певний період часу. AWS CloudTrail збирає детальну інформацію про виклики API, таку як IP-адреса, час здійснення виклику та ідентифікатор особи, яка здійснила виклик. VPC Flow Logs збирають детальну інформацію про трафік, що надходить та виходить з вашого Outpost, а також про трафік всередині Outpost.

Висновки

Існує безліч способів забезпечити видимість інфраструктури розподіленої хмари, частину з яких ми якраз розглянули в статті. Ви можете використовувати програмне забезпечення, надане хмарним провайдером (наприклад, агент CloudWatch). Ви можете використовувати хмаро-незалежні інструменти (Kibana, ElasticSearch, Grafana), розгорнуті в контейнеризованому середовищі з оркестратором контейнерів (Kubernetes) та сервісною сіткою. І, звичайно, у вас є вибір серед численних рішень від конкретних постачальників з попередньо налаштованими сервісами для моніторингу та логування.

Microsoft Azure, Google Cloud та AWS надають чудові рішення для розподіленої хмари з вбудованими інструментами для розгортання, управління, логування та моніторингу. Ці рішення значно полегшують управління вашим розподіленим середовищем.

Microsoft Azure пропонує як апаратні, так і програмні рішення (Azure Stack та Azure Arc), тоді як AWS надає апаратне забезпечення (Outposts), а Google Cloud — програмне забезпечення (Google Anthos). Перевага Azure Arc полягає в тому, що, на відміну від Google Anthos, він не повністю прив’язаний до інфраструктури Kubernetes. Ви можете розгортати віртуальні машини та кластери Kubernetes у власному середовищі.

Логування та моніторинг реалізовані на всіх платформах схожим чином. Логи збираються автоматично та керуються вбудованими сервісами, такими як Amazon CloudWatch Logs, Cloud Logging та Azure Log Analytic. Вбудовані сервіси моніторингу дозволяють відстежувати вашу інфраструктуру та застосунки без будь-якого додаткового налаштування.

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

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті