Chapter 6. Monitoring Distributed Systems
If a human operator needs to touch your system during normal operations, you have a bug (The definition of normal changes as your systems grow.)
SRE - хотят заниматься инженерной, а не операционной работой.
Definitions
- Monitoring - Сбор, обработка, агреггирование и отображение в реальном времени количественных показателей системы, например количество или тип http запросов, uptime системы.
- White-box monitoring - наблюдение с помощью показателей доступных внутри системы, например http handler-ы или интерфейсы ЯП.
- Black-box monitoring - наблюдение и проверка из вне (с точки зрения пользователя)
- Dashboard - приложение отображающее ключевые метрики сервиса.
- Alert - сообщения на которые должен отреагировать человек. Делятся на: tickets, email alerts, and pages.
- Root cause - ошибка в софте или допущенная человеком, после устранение которой можно быть уверенным, что аналогиченое событие не произойдет.
- Node and machine - взаимозаменяемые термины.
- Push - любые изменения, производимые в ПО работающего сервиса или его конфигурации.
Why Monitor?
- Analyzing long-term trends
- Comparing over time or experiment groups
- Alerting
- Building dashboards
- Conducting ad hoc retrospective analysis (i.e., debugging)
Эффективные системы оповещения должны иметь очень хорошее отношение сигнал / шум
Symptoms Versus Causes
Причинно-следственная связь что и почему - это то, что должна выявлять хорошо сделанная система мониторинга с максимальным соотношением сигнал / шум
| Symptom | Cause |
|---|---|
| I’m serving HTTP 500s or 404s | Database servers are refusing connections |
| My responses are slow | CPUs are overloaded by a bogosort, or an Ethernet cable is crimped under a rack, visible as partial packet loss |
| Users in Antarctica aren’t receiving animated cat GIFs | Your Content Distribution Network hates scientists and felines, and thus blacklisted some client IPs |
| Private content is world-readable | A new software push caused ACLs to be forgotten and allowed all requests |
The Four Golden Signals
latency (время отклика), traffic (величина траффика), errors (уровень ошибок), and saturation (степень загруженности)
- время отклика - время которое требуется для выполнения запроса. Важно различать для успешных и неуспешных запросов.
- величина траффика - величина нагрузки, которая приходится на вашу систему. Для web-приложений это запросы в секунду (rps). Может быть скорость передачи данных, количество сессий, количество транзакций.
- уровень ошибок - количество или частота неуспешного выполнения запросов. Явно если код ответа http 5xx и неявно если 200 - но, результат неверен.
- степень загруженности - показатель того насколько полно загружен сервис. CPU / RAM / IO / capacity и etc.
Key Insights
Symlinks
- on call duty - (1)
note
Для некоторых метрик нужно следить за хвостом (90, 95, 95 персентилем): суть если среднее время ответа на запрос x, то у 5% пользователей может быть y, который гораздо медленее
При построения правил для alert-ов нужно руководствоваться рядом рациональных вопросов.
Если сообщений слишком много и это аффектит дежрных, можно снизить SLO / отключить часть алертов (кейс Bigtable)
Необходимость грамотной системы мониторинга и оповещения легко обосновать. Такая система в первую очередь обеспечивает оповещение инженера при появлении симптомов, оставляя эвристические выводы о причинах для этапа отладки. Наблюдать за симптомами тем проще, чем выше в иерархии находится система.
Наблюдении за нагрузкой и производительностью подсистем вроде БД зачастую должно производиться на самой подсистеме.
Оповещения, отправляемые по электронной почте, не всегда эффективны и зачастую скрываются за информационным "шумом". Вместо этого для отслеживания всех существующих докритических проблем лучше пользоваться dashboard-ами, там будет видна информация, которая обычно содержится в оповещениях отправляемых по email-у. Dashboard-ы нужны для того, чтобы можно было проанализировать изменения метрики со временем.
В долгосрочной перспективе эффективная организация посменных дежурств и создание успешного продукта потребуют наличия оповещения о симптомах и приближающихся реальных проблемах. Для этого нужно установить реальные / достижимые SLO.