Комментарии 6
- alert: HighAPIErrorRate
expr: rate(http_requests_total{status="500"}[1m]) > 5
for: 1m
labels:
severity: critical
annotations:
summary: "API ошибок больше 5 за минуту"
Это плохой алерт, если у нас 10 запросов за минуту, 5 ошибок - это плохо, если 10 миллионов - это естественный фон.
Тут лучше использовать относительные значения, если есть разбивка по эндпоинитам, то должо получиться что-то типа:
- alert: HighAPIErrorRate
expr: |
(
sum(rate(http_requests_total{status="500"}[5m])) by (endpoint)
/
sum(rate(http_requests_total[5m])) by (endpoint)
) * 100 > 5
for: 1m
labels:
severity: critical
annotations:
summary: "High 5xx error rate ({{ $value }}%) for {{ $labels.endpoint }}"
- alert: HighAPIErrorRate
expr: rate(http_requests_total{status="500"}[1m]) > 5
for: 1m
labels:
severity: critical
annotations:
summary: "API ошибок больше 5 за минуту"
Это плохой алерт, если у нас 10 запросов за минуту, 5 ошибок - это плохо, если 10 миллионов - это естественный фон.
Тут лучше использовать относительные значения, если есть разбивка по эндпоинитам, то должо получиться что-то типа:
- alert: HighAPIErrorRate
expr: |
(
sum(rate(http_requests_total{status="500"}[5m])) by (endpoint)
/
sum(rate(http_requests_total[5m])) by (endpoint)
) * 100 > 5
for: 1m
labels:
severity: critical
annotations:
summary: "High 5xx error rate ({{ $value }}%) for {{ $labels.endpoint }}"
Мониторинг должен быть комплексный whitebox и blackbox. Принято мониторить следующие паказатели: latency/traffic/errors/saturation. Есть лучшие практики по мониторингу (от google например ) в которых подробно говориться об этом:
https://sre.google/sre-book/monitoring-distributed-systems/#:~:text=The four golden signals of,traffic%2C errors%2C and saturation.
Я бы ещё добавил про событийные логи. Мы обычно пишем события через кафку в клик. Мне кажется ёлка не очень подходит для анализа данных / мониторинга за мало-мальский промежуток времени.
Мы пишем бизнес-события (добавления в корзину, создание заказа и тп), пишем все события запросов во внешние сервисы с бэка. На случай, если их начнёт лихорадить. Так же, полезно сравнивать текущие показатели метрик с предыдущей неделей/месяцем/медианой одновременно. Смотреть отклонения, допустим текущего часа с тем же часом того же дня недели от предыдущей. И не только времени ответа, но и количества и может ещё что.
В общем, мне кажется много чего ещё можно добавить.
Та же сетевая связанность. Все может быть тип-топ у вас, но пьяный Вася кабель лопатой перерубил. Надо сканить доступность своего проекта из разных точек глобуса, чучела Земли
Осталось понять, зачем бедному админу скорость доступа к иЛо, идраку и пустому ИИСу, который заинсталлился с чем нибудь?
О чем статья, я один не понял? Киллер фича какая то будет? Или посыл: короче надо мониторить хорошо, тогда мониторинг будет работать хорошо.
И что, нынче заббикс не в моде? И пртг тоже? Ну ладно. Хрен там этих девопсеров разберешь.
Короче, показываю один раз:
Гипервизоры. Мониторим cpuready, co-stop, cpu wait time per dispatch и прочее, дабы не ботлнекать проц. Рам. Линки на момент дискардов и эрроров.
Ипми: идрак, ило и еже с ними. Общий статус, диски, температура (вход, выход, процы), состояние вебки менеджмента
Кластер: csv, их статус, латенси каждого, латенси усредненный и максимальный каждого vhd (привет багу с повышением латенси на протяжении 5 лет). Иопсы средние, максимум и сумму. Тоже самое МБс
Эксч. Базы. Их статус пассив актив и нужный ответ. Сервисы. Проверка портов и ответа (снмп снмпс хттпс и т.п.). Проверка статуса ииса и кол-ва юзеров и прочее. Проверка дага на живость.
Домен: репликация. Проверка как минимум синхронизации схемы хотя бы по configuration схеме. Проверка феилд логинов и/или залоченных юзеров. Проверка новых обьектов, вроде компьютер типа.
Базы: синтетик запросы к базе с очевидным ответом + проверка его же. Состояние баз, размер. Запросы уровня "дохрелион лет назад запущено и жрет"
Сайты: состояние серта по SNI, отзыв вебки (скорость мс + респонс 200 ожидаем) + порты нужные.
Винда: проц. Рама. Диск. Нужные сервисы кастомные. Аптайм. Пинг. Линки по желанию (мне не надо)
Никсы: тоже самое
Стораджи: статус, диски, логические диски, контроллеры, менеджмент
Некритичное: просто одинокий сенсор пинга
Свитчи: состояние железа, псу, фанов, рамы, цпу + порты на момент последнего флапа/дисконнекта, вланы
Гейт: туннели, кол-во впн юзеров, траффик, остальное по мелочи
Основное перечислил, что то мог забыть. Все работает по снмп с минимумом нужных шаблонов и скриптов
А автор пусть сосет жопу с такой статьей про мониторинг ради мониторинга. Потом такие в гейте ПалоАльто или Форти включают все дебаг логи сессии, хранят полгода по 10 гб в день и не понимают зачем им эта инфа, которая уже завтра устарела
«Я сказал проще - полное гАмно» (ДМБ)
ЗЫ
А вообще дико плюсую Вам: последнее время статьи пишутся от лица какого то коня, т.е. девопса в вакууме, который типо пашет в команде в убер компании которая делает настолько секретный продукт, что и сами не знают что делают))) но главное надуть щеки поважнее, а в 90% случаев это компании на два с половиной калеки и там или онлайн сервисов мониторинга хватит с головой или zabbix с ptrg перекроют все задачи, но сейчас действительно пошла тенденция двигать графану… хм, если нужны красивые графики для клиента или директора - может быть, хотя на вкус и цвет фломастеры разные, но как сказал выше, софтверные команды как правило не страдают фигней типо автора, а админу оно нах не в парилось… так что думайте сами девопсики))) хотя мне больше нравится определение - карманные админы)))) сразу понятен уровень большинства спецов, как автор
Всё просто. Есть два разных мониторинга: ИТишный и Бизнес сервисов. Пытаться совмещать нужное ИТ и нужное менеджмент борду - утопия. В большинстве своём бизнесу и продукт овнерам нужно видеть, что сервис или жив, или мертв. И это будет отдельная структура с отдельным решением. Точно не потерю пакетов показывать придется.
Дирик мой тут как-то заикался на доступ в PRTG. Говорю "и что ты там хочешь увидеть? Ладно, увидишь, что какие-то сенсоры упали. Или даже десяток. Какая тебе инфа с этого? В сферическом коне в вакууме будешь знать, что у сенсора аптайм не 99,99999% или как? Корреляцию провести как-то сможешь? А может апдейты были или мейнтенс какой? Или может бизнес репорты должны делать бизнес аналитики или хотя бы выжимку нужного вытаскивать и представлять что это, как это и как работает?".
В итоге доступ к PRTG, даже R/O, так и не получил, т.к. выдавать всем кому не лень права - не вижу смысла. Потом больше головной боли отвечать на глупые вопросы от людей не понимающих в теме.
Как настроить мониторинг, чтобы не проспать проблему