Михаил

Половину из списка можно сразу выкинуть. Например Kibana занимается визуализацией логов, а не сбором. В ELK стэке для этого служит Logstash. А Blackfire - инструмент для перфоманс-тестирования + метрики.

Дальше нужно определиться, где вы хотите разместить сервис. Если в облаке, то New Relic, Loggly и Logentries остаются в списке (если ваш сервис на AWS, то добавляется CloudWatch), но из него уходят LogStash и GrayLog2. Но если хотите держать сервис у себя, ваш дальнейший выбор только между LogStash и GrayLog2.
В первом случае у вас продолжение поисков -- на следующем этапе уже встает вопрос цены продукта.

=====
"Так же интересно чтобы можно было собирать логи ошибок nginx/mysql/postgres, не требовало особых плясок с бубном"

Все три сервиса написаны на C-lang. Это значит, что, в отличии от Java, они не будут выкидывать ужасные стэктрейсы на 100500 строк, а всегда будут укладываться в 1024 символа. Именно этот предел есть у стандартного syslog. Поэтому пусть они и дальше пишут в syslog, а уже в нем вы настроете куда редиректить логи дальше. Таким образом вам не надо будет при смене сервиса сбора логов бегать по всем нджинкасам и постгрессам и менять настройки - достаточно будет поменять в одном месте, в syslog.
Но! Если будет Java приложение, то такое не пройдет и вам потребуется что-то типа GELF, чтобы успешно доставить полный размер exception.

Нет никаких годных материалов. Точнее они годные только для опытных DevOps. Потому что это культура подхода, а не инструментарий.
Переход на DevOps делается в три этапа:
1) Сначала полностью все автоматизируется. По поводу доставки кода вопросы врядли возникнут - Jenkins и Maven известны даже детям. Ну не обязательно они. У каждого языка свои инструменты. gradle, grunt, waf... Но автоматиризровать надо все, включая деплой SQL (LiquidBase, dbMaintain, sqitch и т.д.). Эта часть освещена очень хорошо в интернетах.
2) Затем убираются все боттл-нэки в работе админов и программистов. Например внедряется Green/Blue-деплоймент. В точках деплоя собственного ПО средства провиженинга (puppet/ansible/chef) заменяются на средства деплоймента (uDeploy например). Устанавливается мониторинг и логирование. На все это тоже есть свои инструменты (Sensu например).
3) Начинается работа с людьми - вовлечение программистов в ответственность за результат на стороне Ops и вовлечение сисадминов(operations) в результат на стороне Dev (подгон под FHS и все такое). Ключевой момент в том, что людям придется понять, что их ответственность приходит эхом оттуда, где они своими руками не трогали (для этого даже автоматически создают новые энвайронменты всякими докерами и вагрантами). Закоммитил кривой код в IDE, не учел зависимость в пропертях, поправил конфиги не для всех энвайронментов - будешь отвечать и за статический анализ кода и за проваленные интеграционные тесты и за неудачный деплоймент. В обратную сторону тоже самое. Тогда люди начнут действовать по стандартам и настанет искомый результат.

Ну и само собой надо найти сильного релиз-инженера. Потому что DevOps - это не "построил и ушел". Кто-то должен все время смотреть за новыми организационными проблемами и чтобы транк не попал на UAT, например, а на SIT ушел тот же тэгированный код, которому на DEV провели smoke-тесты, а не обновленный парой вредных коммитов, набежавших за время смоука.

Сначала скажите, как звучит конечная задача и что из этого уже есть и чего нет. Может чего детальнее посоветую.