Путь мониторингамодульность, гибкость, devops

Ghbdtn!

• Всеволод Поляков

• Lead DevOps Grammarly

• поддержка около 30 сервисов на Java, erlang, python, lisp, ruby, js силами 4-х админов

Чего мы хотим?• Получать сообщения о проблемах

• Не получать сообщения когда проблем нет

• Помощь в поиске проблемы

• Предупреждение о возможных проблемах

• Не пропускать проблемы

DevOps

• Разработчики знают сервис лучше чем опсы

• Нет батлнека в опс команде

• Повышается скорость работы

Почему старое плохо?

• Свои сложные концепции

• Сложно для девелоперов

• Содержит в себе все что может пригодиться, а может и не пригодиться

• Две системы управления конфигурацией

Метрики

• env.role.node_name.metric

• Приложение пишет метрики в statsd

• Система пишет метрики в statsd

• Агрегируем и чекаем сами, без приложения

Пожелания• Простота добавления метрик и проверок по ним

• Должно скейлиться и не падать

• Хранить информацию по метрикам как можно дольше

• Хранить много метрик

• Разработчики мониторят свои сервисы без участия опсов

• Логи: 300 Gb/день

• Метрики: 120 000, обновляются раз в 10 секунд

• 300 проверок состояний

• Разработчики всех сервисов отвечают за мониторинг

• Занятость команды админов в мониторинге минимальна

Sensu

influx

• Маленькая база на go ~ 20mb RAM

• Локальная база на каждом сервере

• Хранилище метрик на два дня

Сбор метрик в ноде

Глобальное хранилище

скрин графаны

Логи

• Общий формат для всех сервисов: json

• Текстовый файл с logrotate

Мониторинг фронтенда

• Логи → nginx → logstash

• Метрики → nginx → агрегатор → statsd

• Плагин для логстеша, разворачивает сорсмап

Слайд по всяким штукам

• 500-е, уникальные юзеры

• разработчики сами все мониторят и просыпаются ночью

• сравнение времени обработки чего-то в фронтенде и на бекенде

• сквозной userID по всем сервисам

Над чем мы думаем

• Мониторинг безымянных серверов

• Хранение метрик приложений в mesos\kubernetis окружениях