" Observability with Elasticsearch: Best Practices for High-Load Platform", Anton Pryhodko.pptx
Download as PPTX, PDF•0 likes•40 views
The session covers architectural strategies that keep Elasticsearch stable under heavy load: proper index and shard design, ILM policies, persistent queues in Logstash, metrics downsampling, and self-monitoring of the observability stack. Insights are drawn from operating platforms that handle terabytes of logs and millions of events per day.
![EPAM Proprietary & Confidential. 15
Іменування індексів
Тип даних Шаблон імені Приклад
Логи logs-[unit]-[rollout] logs-auth-2
Метрики metrics-[unit]-
[rollout]
metrics-billing-5
Трейси traces-[unit]-[rollout] traces-checkout-7
Стандартизація іменування спрощує автоматизацію. Забезпечує гранулярні права
доступу на рівні індексів.](https://image.slidesharecdn.com/epamlighthighloadfwdays25observabilitywithelasticsearchwhite-250616061118-ee37628e/85/Observability-with-Elasticsearch-Best-Practices-for-High-Load-Platform-Anton-Pryhodko-pptx-14-320.jpg)
" Observability with Elasticsearch: Best Practices for High-Load Platform", Anton Pryhodko.pptx
- 1. EPAM Proprietary & Confidential. 1
- 2. EPAM Proprietary & Confidential. 3 Команди впроваджують власні стеки моніторингу. Це створює різнорідне середовище з несумісними інструментами. Фрагментація інструментів П'ять і більше різних стеків призводять до фрагментації даних. Відсутня єдина картина системи. Розрізнені дані Труднощі з інтеграцією різних API, форматів логів та систем сповіщень. Ускладнюється аналіз інцидентів. Інтеграційні проблеми
- 3. EPAM Proprietary & Confidential. 4 Ціль — централізація Створення централізованої Observability-платформи для всіх команд та сервісів. Єдина платформа Гнучка система з можливістю інтеграції різних джерел даних. Інтеграція даних Швидка реакція на інциденти. Зменшення хаосу під час діагностики. Прозорість
- 4. EPAM Proprietary & Confidential. 5 Подій/секунду 150 000+ GB в день 10 000 Індексів 5 000+ Нові виклики централізації
- 5. EPAM Proprietary & Confidential. 6 Logstash та надійна доставка логів Забезпечення надійної передачі даних без втрат. Heap, індексація, балансування Оптимізація роботи з пам'яттю та індексами. ECS, мапінг, стандарти Впровадження єдиних стандартів для даних. ILM та моніторинг Керування життєвим циклом даних. Observability для Observability Моніторинг самої системи моніторингу.
- 6. EPAM Proprietary & Confidential. 7 Втрата логів через Logstash Проблема Стандартна конфігурація Logstash використовує оперативну пам'ять. При рестарті дані втрачаються. Під навантаженням черга переповнюється. Нові події відкидаються. Рішення Додавання черги в архітектуру рішення Це забезпечує стабільність навіть при рестартах.
- 7. EPAM Proprietary & Confidential. 8 S E C T I O N T I T L E
- 8. EPAM Proprietary & Confidential. 9 S E C T I O N T I T L E
- 9. EPAM Proprietary & Confidential. 10 Налаштування черг Logstash Типи та конфігурація черг • queue.type: persisted • queue.max_bytes: 4gb • pipeline.workers: 8 Розрахунок місця на чергу: (події/хвилину × середній розмір події) + 20-30% запас на пікові навантаження. Зберігання даних на диску підвищує надійність. Виділення 4ГБ забезпечує буферизацію піків навантаження. Workers оптимізують паралельну обробку.
- 10. EPAM Proprietary & Confidential. 11 JVM та індексація Heap-навантаження Під час індексації великих обсягів даних спостерігається значне використання пам'яті. GC-pauses Збирання сміття призводить до зупинок системи. Це викликає затримки індексації. Перегрів вузлів Один вузол отримує непропорційне навантаження. Це спричиняє уповільнення всього кластера.
- 11. EPAM Proprietary & Confidential. 12 Шардінг та індекс дизайн Малі індекси 1 шард, до 5ГБ даних Середні індекси 3 шарди, 50+ГБ даних Великі індекси 9 шардів, понад 300ГБ даних Правильний розподіл шардів зменшує heap-навантаження. Покращується паралельна індексація та пошук.
- 12. EPAM Proprietary & Confidential. 13 Відмова від dynamic mapping S E C T I O N T I T L E Проблеми dynamic mapping Конфлікти типів, непередбачуване зростання heap Статичні шаблони Чіткі типи полів, контрольоване споживання ресурсів Self-service мапінг Автоматизоване створення шаблонів для команд
- 13. EPAM Proprietary & Confidential. 14 Elastic Common Schema (ECS) Стандартизація Єдиний формат для всіх подій у системі Пошук Спрощення запитів через єдину структуру Аналітика Готові дашборди для поширених сценаріїв Сповіщення Уніфіковані правила для алертів
- 14. EPAM Proprietary & Confidential. 15 Іменування індексів Тип даних Шаблон імені Приклад Логи logs-[unit]-[rollout] logs-auth-2 Метрики metrics-[unit]- [rollout] metrics-billing-5 Трейси traces-[unit]-[rollout] traces-checkout-7 Стандартизація іменування спрощує автоматизацію. Забезпечує гранулярні права доступу на рівні індексів.
- 15. EPAM Proprietary & Confidential. 16 Проблема зберігання Зростання обсягів Кожен новий сервіс збільшує навантаження. Щоденний приріст даних перевищує оцінки. Переповнення hot tier Диски заповнюються швидше, ніж працює ILM. Виникає ризик відмови кластера. Silent failure ILM перестає працювати без явних помилок. Це виявляється лише при інциденті.
- 16. EPAM Proprietary & Confidential. 17 ILM стратегії Hot Tier Активна індексація та запити. SSD-диски для швидкості. Rollover після досягнення розміру або віку. Cold Tier Зменшення реплік, shrink операції.Downsampling для метрик. Оптимізація для зберігання. Доступ до даних за потребою. Frozen Tiers Архівні дані. Видалення за політикою retention.
- 17. EPAM Proprietary & Confidential. 18 • Автоматичні перевірки стану ILM через API • Сповіщення про проблеми з Kibana → Slack / PagerDuty • Візуалізація життєвого циклу індексів у Kibana Dashboard • Алерти, коли індекс перевищує допустимий вік чи розмір Моніторінг ILM
- 18. EPAM Proprietary & Confidential. 19 Внутрішні метрики Elasticsearch. Зберігають дані про роботу кластера, індексів та шардів. .monitoring-* індекси Збір метрик на рівні операційної системи. Моніторинг CPU, пам'яті, дисків для вузлів кластера. Metricbeat Спеціалізовані перевірки для ILM, стану черг, швидкості пошуку. Custom моніторинг Observability для Observability
- 19. EPAM Proprietary & Confidential. 20 Метрики ILM errors • Виявляти застряглі індекси • Попереджати переповнення hot tier • Підвищити надійність ILM Queue overflows Search latency Oversized shards Event volume Logstash pipeline throughput • Виявляти переповнення черг • Уникати втрати даних • Забезпечити стабільний ingest • Контролювати затримки пошуку • Виявляти перевантаження shard'ів • Підвищити якість користувацького досвіду Обмежити розмір shard'ів Покращити продуктивність пошуку Забезпечити балансування кластера Відслідковувати обсяг подій на день Прогнозувати навантаження Керувати політиками зберігання Контролювати швидкість обробки подій Виявляти вузькі місця в пайплайнах Балансувати навантаження Logstash
- 20. EPAM Proprietary & Confidential. 21 Підсумок Система моніторингу повинна мати такий же рівень надійності, як критичні бізнес-сервіси. Observability — це продакшн Під час інцидентів моніторинг має працювати стабільно. Це основа для діагностики. Власна стійкість критична Побудуйте моніторинг, який передбачуваний у роботі. Уникайте "чорних скриньок". Контрольована система
- 21. EPAM Proprietary & Confidential. 22 Поради Аудит логування Оцініть обсяги даних та необхідність кожної події. Застосуйте семплінг для високочастотних подій. Налаштування черг Впровадьте persistent queue. Розрахуйте оптимальний розмір з урахуванням піків. Статичні шаблони Відмовтесь від dynamic mapping. Розробіть темплейти на основі ECS. Моніторинг моніторингу Налаштуйте alerts для систем Observability. Регулярно перевіряйте роботу ILM.
- 22. EPAM Proprietary & Confidential. 23 Anton Prykhodko [email protected] Контакти https://www.linkedin.com/in/antonprykhodko/ Systems Architect