Мы использовали https://www.loggly.com/ а сейчас в AWS все хостится там встроенный сервис CloudWatch Logs

CloudWatch Logs - по опыту - не самое лучшее и надежное решение. Очень легко напороться на авсовские лимиты и тогда ни логи не пишуться нормально, ни даже их посмотреть нельзя.

ни разу еще такого не было и первый раз слышу про лимиты в CloudWatch Logs ( а я aws certified developer то есть знаю неплохо)

+1 Пользовался 4 года CWLogs и как раз по нему проблем с потерями данных не было. Но соглашусь - интерфейс у них не самый удобный

лимиты есть. https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html я попозже поресерчу при каких нагрузках можно в них упереться но явно не при низких. у нас туда микросервисы пишут как бешеные

Значит у тебя пока не так много логов :).
Но если представить что тебе на обработку в одночасье залетает 200-500Гб сырых данных, оно все бегом раскидывается на 1000+лямб и начинает переколбашивать их параллельно записывая логи (а иногда и дебаг), то быстро упираешься в лимиты, причем такие, когда саппорт авс-а отвечает, что мол, чуваки, у вас и так повышены лимиты - больше не можем, ибо другие юзеры будут жаловаться.

В итоге у тебя на часик-другой на все запросы по клаудвотчу валятся ошибки типа превышен лимит запросов. И юайка юзает эти запросы и тоже не работает.

ого - так да. один раз у меня было что не могла найти в логах кое-что после падения. у меня было ощущение что EC2 инстанс упал и не успел последние логи отправить в CloudWatch но это было один разочек и я сомневаюсь может оно просто даже в console.log не успело написать то есть EC2/CloudWatch не виноват

кажется для такого AWS kinesis используют

Там все сложно было :). Даже было дело, что в один прекрасный вечер мы слегка положили rollbar.com на пару часиков для всех пользователей.

Пахнет так, будто у вас весь прод в рамках одного AWS-аккаунта живет. Мы разделяли нагрузку между тенантами + гоняли много регионов. В каждом аккаунте у нас не больше ~50 машин было на регион

Да, на одном, но там не машины, а лямбды которые сами себе скейлятся в зависимости от кол-ва прилетевших данных

я цифры для понимания масштаба привел. У нас ситема тоже была на лямбдах в основном. На ec2 жило только то, что в лямбду не удавалось положить

Нет, нигде пока не встречал кто логи в БД хранит. Какой в смысл усложнять себе жизнь и тем более выделять на этот процесс отдельный ресурс, когда суть хранения логов и так будет храниться на жестком диске, так зачем еще и в БД это паковать? Вам ведь потом еще их доставать от-туда нужно будет, писать запросы

что бы юзер мог их попросить

Для этого есть Elastic Search | Parsers

та вот не знаю. Там логироваться будет всего три операции. Добавлена запись, изменена запись, удалена запись. Храниться оно будет ну до трех месяцев. Есть ли смысл тащить сюда что-то гигантское?

можно заменить пострегс на какую-нибудь монгу к примеру

А ну если что-то простенькое то наверное и есть смысл

да, так не должно быть пока большой проблемы

@tshemsedinov позавчера в ноде появился пуллреквест с реализацией web locks api. можно ли на них как-то повлиять, чтобы добавили опцию { timeout: number }? или всё будет строго по спеке?

очень уж многословен этот AbortController