E
E
Elena Stepanova2016-10-11 20:34:13
System administration
Elena Stepanova, 2016-10-11 20:34:13

Enlighten on modern services for collecting and monitoring logs, what to choose with benefit and without damaging your pocket?

Как-то выпала я из тренда в этом вопросе, loggly, logstash, logentries, graylog, sentry, blackfire, kibana, newrelic... и еще куча всего... (большая часть из хендлеров монолога) По поиску находятся только ограниченные обзоры, и vs конкретных сервисов. Из того что поняла, что некоторые просто принимают логи по апи, некоторые ставятся прямо на сервер и обрабатывают, какие- то просто повзоляют гибко искать, какие-то еще и аналитику разнообразную выдают... Что вы используете в качестве альтернативы лог-файлам/бд ? Что стоит попробовать для не особо нагруженных продакшн проектов, но на разных серверах? Хотелось бы чтобы всё было в одном месте. Так же интересно чтобы можно было собирать логи ошибок nginx/mysql/postgres, не требовало особых плясок с бубном. Длительных сроков хранения не требуется.

Answer the question

In order to leave comments, you need to log in

6 answer(s)
M
Michael, 2016-10-20
@Insolita

Half of the list can be immediately thrown out. For example, Kibana is engaged in the visualization of logs, not collection. In the ELK stack, this is done by Logstash. And Blackfire is a performance testing tool + metrics.
Next, you need to decide where you want to place the service. If in the cloud, then New Relic, Loggly and Logentries remain on the list (if your service is on AWS, then CloudWatch is added), but LogStash and GrayLog2 leave it. But if you want to keep the service on your own, your further choice is only between LogStash and GrayLog2.
In the first case, you continue to search - at the next stage, the question of the price of the product already arises.
=====
"It's also interesting to be able to collect nginx/mysql/postgres error logs, it didn't require any special dancing with a tambourine"
Все три сервиса написаны на C-lang. Это значит, что, в отличии от Java, они не будут выкидывать ужасные стэктрейсы на 100500 строк, а всегда будут укладываться в 1024 символа. Именно этот предел есть у стандартного syslog. Поэтому пусть они и дальше пишут в syslog, а уже в нем вы настроете куда редиректить логи дальше. Таким образом вам не надо будет при смене сервиса сбора логов бегать по всем нджинкасам и постгрессам и менять настройки - достаточно будет поменять в одном месте, в syslog.
Но! Если будет Java приложение, то такое не пройдет и вам потребуется что-то типа GELF, чтобы успешно доставить полный размер exception.

D
Dimonchik, 2016-10-11
@dimonchik2013

logstash + kibana распространены
также имеет смысл посмотреть в yandex click house

T
topuserman, 2020-07-09
@topuserman

Можно брать ELK-стэк + rabbitmq.
В Монологе есть Amqp-хэндлер, и logstash-форматер,
отправляете логи в очередь.
А в logtash читаете из очереди.
достаточно шустро работает на серьезных нагрузках.
UPD: только заметил, что более 3 лет назад вопрос был..

D
D', 2016-10-12
@Denormalization

А чем bugsnag не устраивает? Для средненького проекта хватит даже бесплатного аккаунта.

P
Philipp, 2016-10-12
@zoonman

Я использую Sentry, для поиска косяков и ошибок в коде просто идеально, если правильно все настроить.

M
murlogen, 2016-11-01
@murlogen

Если ставить свой, а не использовать внешние сервисы - то какой тут ущерб?

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question