В версии 7.0 уже и типы выведены из эксплуатации. Остались индексы и документы. По этой книге будет невозможно работать в 7 версии эластика. Книга «Machine Learning with the Elastic Stack» по мне так была бы более интересна.
Если систем мониторинга несколько (а обычно это так и бывает), события лучше обрабатывать (коррелировать, схлопывать и т.д.) во внешнем event consolidator (или зонтичной системе). Дополнительным плюсом будет единая точка интеграции с системой инцидент-менеджмента.
Ещё одна статья о лечении при следующих сиптомах событийной усталости:
вы не успеваете реагировать на все поступающие события;
вы не знаете на кого назначить полученные события;
вы не понимаете какая должна быть реакция на события;
вы считаете, что критичность события не соответствует действительности;
избыточные события утомляют дежурную группу (история про волки-волки, но потом они на самом деле пришли).
Мне известны кейсы перехода с платного ПО на другое платное, но подешевле. А вот чтобы с платного на бесплатное… не встречался с таким, но в природе, наверняка, случаи были. New Relic — классное решение, жаль, что в России не очень хорошо относятся к облачным системам, которые хостятся за пределами страны.
Если интересует SIEM решение, присмотритесь к коммерческим Microfocus Arcsight, IBM QRadar или бесплатному Elastic Stack. Решать аналитические задачи можно во всех этих решениях.
Некоторое, что можно загнать в регламент — можно и автоматизировать.
Если причины известной проблемы рандомные, но примерно известно где копать, к системе алертинга/мониторинга привязывается база знаний/CMDB, которая обогащает события специальным полем с описанием «где копать и кому звонить, если раскопать не получилось». В более простом случае, в событие автоматически добавляется информация с телефоном ответственного.
Хороший инструмент, но я ориентировался на инструменты, которые умеют либо строить карту приложения либо заточены именно под распределённые приложения. APM от ElasticSearch скорее дополнительная фича к их основному продукту, нежели основная фича.
А расскажите на базе чего делали визуализацию топологии? Zabbix — мощный инструмент, но требует множества пристроек сбоку: от панели событий до разных визуализаций.
Интереснее было бы прочитать то же самое, но на примере реальных данных и конкретного кейса. Например, загрузили 200Гб данных в Splunk и ELK и собрались решать такую-то задачу, в Splunk она решается так, а в ELK так, столько-то времени было потрачено там и там. Ну и в этом же духе. А факты без подтверждения выглядят бледновато.
У Appdynamics есть кое-что бесплатное типа мониторинга 1 приложения. А Elastic да, крутое решение особенно в свете развития всяких там *beat расширений
Глава 4 Цели уровня обслуживания
Глава 6 Мониторинг распределённых систем
Ещё одна статья о лечении при следующих сиптомах событийной усталости:
1. Какое решение использовали в качестве CMDB?
2. Не совсем понял техническое решение
Вы анализируете лог при помощи Zabbix и в случае аварии берёт проблемную строку и передаёте в Zabbix, а дальше Logstash забираете в Elastic?
Если причины известной проблемы рандомные, но примерно известно где копать, к системе алертинга/мониторинга привязывается база знаний/CMDB, которая обогащает события специальным полем с описанием «где копать и кому звонить, если раскопать не получилось». В более простом случае, в событие автоматически добавляется информация с телефоном ответственного.
Да, желательно, чтобы был гибкий подход к группировке. Бэкэнд/фротнэнд привёл для примера.
А можете пояснить значение полей в вашей сравнительной таблице? Интересуют User, Event, Usage, Service.