Monitoring in Cloud - what should I know?

Transcript

1. Моніторинг Та його провідна роль в роботі хмарних рішень
2. Передмова Або одна година із життя мікросервісів
3. Users Load Balancer frontend frontend Kafka ms ms Database Database Розглянемо відносно просту систему із використання мікросервісів і черги повідомлень із high available розгортанням в хмарне середовище.
4. Load Balancer Users frontend frontend Kafka ms ms Database Database Завдяки надлишковому дублюванню така система може забезпечити базовий захист від збоїв її ненадійних складових Цей інстанс буде знищено із усім вмістом Зверніть увагу, чим швидше LB зрозуміє що на цей інстанс трафік передавати не можна, тим менше запитів втратить користувач
5. Users Load Balancer frontend frontend Kafka ms ms Database Database Також така система має забезпечувати горизонтальне масштабування при збільшенні трафіку frontend frontend ms В якості метрики для масштабування може бути використано кількість запитів … або навантаження на процесор чи пам’ять робочого інстансу … та довжина черги повідомлень
6. 6 Специфіка використання хмарних рішень Досягається в основному завдяки надлишковості використаних ресурсів Логування, метрики та трейсинг є необхідною складовою Традиційні технології та інструментарій не здатні забезпечити необхідну якість роботи в динамічному хмарному середовищі Вимагає моніторингу стану системи Забезпечує стабільність, але збільшує як складність, так і кінцеву вартість Як результат усіх вище перерахованих факторів, вартість рішення суттєво збільшується Вартість Хмарні технології Дублювання Моніторинг Масштабованість Надійність
7. Проте наразі існує широкий вибір інструментів для налаштування системи моніторингу і логування
8. The Cloud Native Computing Foundation (CNCF) виділяє наступні групи інструментів Observability and Analysis Monitoring Logging Tracing Chaos Engineering
9. Демо 1: CNCF https://landscape.cncf.io/
10. Частина 1: Health check
11. Health check 101 Проблема: як визначити чи готовий сервіс обслуговувати запити? Дія: • згенерувати попередження про неробочий сервіс • Перенаправити трафік на робочі інстанси Рішення: Сервіс має REST API endpoint перевірки працездатності (наприклад, HTTP / health), яка повертає стан роботи служби. Можливі наступні варіанти перевірок: • чи доступна вся інфраструктура потрібна сервісу • статус хоста і робочого оточення, такі як вільне місце на диску • Перевірка специфічної логіки сервіса
12. Health check - приклад package main import ( "net/http" "github.com/labstack/echo" ) func main() { e := echo.New() e.GET("/", func(c echo.Context) error { return c.String(http.StatusOK, "Hello, World!") }) e.GET("/health", func(c echo.Context) error { return c.String(http.StatusOK, "OK") }) e.Logger.Fatal(e.Start(":8080")) }
13. Демо 2: Golang sample app https://github.com/SergeyDz/go-sample-rest
14. Частина 2: Logging
15. Centralized Logging 101 Опис: Система складається із кількох мікросервісів на розподілених віртуальних машинах, при цьому генеруючи логи з файл в стандартному форматі. Ці логи як правило включають повідомлення різних рівнів: debug, info, error Проблема: як визначити загальний стан системи і досліджувати збої? Додатково: • Рішення має доправляти логи в короткий час • Рішення має мінімально впливати на сервіс Рішення: Необхідно додати незалежну системи – centralized logging, яка буде збирати логи із усіх екземплярів сервісу: • Користувач має можливість шукати і аналізувати дані • Необхідний механізм генерації alerts • Необхідно передбачити механізм ротації даних для економії
16. Centralized Logging – Cloud Providers Усі хмарні провайдери пропонують власні рішення для централізованого збору і аналізу логів. Такий підхід має як правило ряд переваг: 1. Унікальна інтеграція із хмарними сервісами 2. Багатий функціонал за замовчуванням 3. Логування і метрики в одному продукті 4. Необмежений об'єм даних … і недоліків 1. Уніфікація під єдиного хмарного провайдера 2. Відсутня можливість розширення функціоналу 3. Ціна за кількість повідомлень, трафік та об'єм даних 4. Необхідність інтеграції власних сервісів
17. Демо 3: AWS Cloud Watch https://console.aws.amazon.com/cloudwatch
18. Centralized Logging – SaaS Існують рішення, які пропонують систему логування як сервіс не прив'язану до жодного хмарного провайдеру. Як правило, основна увага в них приділяється безпеці та продуктивності. Переваги: • Багатий функціонал • Не потрібно займатися інфраструктурою • Незалежність від хмарного провайдера Недоліки: • Ціна • Відправка даних на сторону провайдера
19. Centralized Logging – ELK стек як промисловий стандарт в Open Source Elasticsearch-Logstash-Kibana – наразі є одним із найбільш популярних рішень для збору, зберігання, перегляду і аналізу текстових даних для логів. Elasticsearch (ES) - масштабована утиліта повнотекстового пошуку та аналітики, яка дозволяє швидко в режимі реального часу зберігати, шукати і аналізувати великі обсяги даних. Logstash - засіб збору, перетворення і збереження в загальному сховищі даних з файлів, баз даних, логів та інших джерел в реальному часі. Logsatsh дозволяє модифікувати отримані дані за допомогою фільтрів: розбити рядок на поля, агрегувати кілька рядків, перетворити їх в JSON. Kibana - візуальний інструмент для Elasticsearch, щоб взаємодіяти з даними, які зберігаються в індексах ES. Веб- інтерфейс Kibana дозволяє швидко створювати і обмінюватися динамічними панелями моніторингу, включаючи таблиці, графіки та діаграми. FileBeat - агент на серверах для відправки різних типів оперативних даних в Elasticsearch.
20. Centralized Logging – логування з боку програмного забезпечення Варто наголосити, що всі системи сподіваються на відповідну якість логів із боку програмного забезпечення. Це питання варте окремого розділу, так як існує безліч рішень. Основні параметри якими відрізняються системи логування: • Мова програмування • Формат даних • Швидкодія • Надійність
21. Частина 3: Monitoring
22. Monitoring 101 Опис: Система складається із кількох мікросервісів на розподілених віртуальних машинах і генерує системні і бізнес метрики Проблема: як визначити загальний стан системи і діагностувати чи передбачати проблеми? Додатково: • Рішення має мінімізувати свій вплив на роботу системи Рішення: Необхідно створити службу моніторингу для збору статистики із сервісу та його оточення. Всі метрики зберігаються в системі моніторингу, яка в свою чергу забезпечує звітування та оповіщення. Існує дві моделі агрегування метрик: push - сервіс надсилає метрики до служби метрик pull - служба метрик витягує метрики із сервісу
23. Monitoring – Time Series Database (TSDB) Опис: База даних часових рядів (TSDB) - це програмна система, яка оптимізована для зберігання та обслуговування часових рядів через пов'язані пари часу (ів) та значення (значень). Кілька ранніх баз даних часових рядів пов'язані з промисловими програмами, які могли б ефективно зберігати виміряні значення з сенсорного обладнання, але зараз використовуються для підтримки набагато більш широкого кола задач. Name License Language References Druid Apache License 2.0 Java [5] eXtremeDB Commercial SQL, Python, C / C++, J ava, and C# [5] InfluxDB MIT.[6] Chronograf AGPL v3, Clustering Commercial[7] Go [5][8] Informix TimeSeries Commercial C / C++ [5][9] Kx kdb+ Commercial Q [5] Kudu Apache License 2.0 C++ [10] Prometheus Apache License 2.0 Go [5] Riak-TS Apache License 2.0 Erlang [5] RRDtool GPLv2 C [5] TimescaleDB Apache License 2.0 SQL [11] Whisper (Graphite) Apache 2 Python [12]
24. Демо 4: Metrics https://github.com/SergeyDz/go-sample-rest/blob/feature/prometheus
25. Monitoring – Prometheus Architecture
26. Monitoring – Prometheus Metrics Counter Це сукупний показник, який представляє єдиний монотонно зростаючий лічильник, значення якого може лише збільшитись або скинути до нуля при перезапуску. Наприклад, за допомогою лічильника можна вказати кількість поданих запитів, виконаних завдань або помилок. Не використовуйте лічильник, щоб виставити значення, яке може зменшитися. Наприклад, не використовуйте лічильник кількості поточно запущених процесів; замість цього використовуйте gauge. Gauge Це метрика, яка представляє одне числове значення, яке може довільно йти вгору і вниз. Як правило, використовуються для вимірюваних значень, таких як температури або поточне використання пам'яті, але також "відліків", які можуть підніматися вгору і вниз, як кількість одночасних запитів. Histograsm Гістограма відображає спостереження (як правило, такі як тривалість запиту або розміри відповідей) і підраховує їх у заданих сегментах. Він також надає суму всіх значень. # HELP go_gc_duration_seconds A summary of the GC invocation durations. # TYPE go_gc_duration_seconds summary go_gc_duration_seconds{quantile="0"} 1 go_gc_duration_seconds{quantile="0.25"} 8 go_gc_duration_seconds{quantile="0.5"} 0 go_gc_duration_seconds{quantile="0.75"} 0 go_gc_duration_seconds{quantile="1"} 1 go_gc_duration_seconds_sum 10
27. Демо 5: Grafana https://ec2-3-236-117-53.compute-1.amazonaws.com/k8s/clusters/c- xzxv4/api/v1/namespaces/cattle-prometheus/services/http:access-grafana:80/proxy
28. Monitoring – Metrics Types System metrics Platform metrics Application Purpose OS JMX, Docker, k8s, .Net runtime Business metrics Dashboards default default custom Developed By Open source Platform providers Dev team Зверніть увагу: Як правило, самими корисними є саме бізнес метрики, які є унікальними для кожного окремого програмного продукту і навіть сервісу. Але враховуючи їх специфіку, до їх розробки підходять в останню чергу.
29. Частина 4: Tracing
30. Tracing – Jaeger
31. Tracing – Jaeger
32. Tracing – Jaeger
33. Дякую за увагу. Питання і відповіді
34. Корисні посилання https://landscape.cncf.io/ https://www.elastic.co/elastic-stack https://prometheus.io/docs/introduction/overview/ https://12factor.net/ https://www.jaegertracing.io/docs/1.22/features/ https://microservices.io/patterns/index.html