The lightweight concurrency lets them write little (and not-so-little) bits of code that execute in parallel without incurring overhead associated with OS threads.
Edit: sorry if I'm confusing "concurrent" and "parallel", I never really liked those terms :p
For the folks using it, how do you get data to it? Curious how things have shaped up over time.
1) Sentry is not designed to replace logging therefor things like syslog will never achieve the same result. Sentry is explicitly for catching outliers and TCP is the only method able to store it's data.
2) As with CCP most people no longer use synchronous transports. We even changed the default to be the threaded worker transport. That said, when your user hits a 500 adding 50-200ms is generally acceptable as you've already put the user in a bad situation.
1) Sorry, I think I was misunderstood. Was saying I'd rather populate Sentry from logs not that I think my logs are an alternative for Sentry.
2) Awesome. I'll look at the threaded worker transport stuff. As for the 50-200MS on 500's, I totally agree. Didn't get around to sorting out making connection timeout something like a couple hundred seconds though (at the time it wasn't clear to me if that was an exposed setting for the Sentry lib), and also I was hoping to use Sentry for situations where I might give our users a 200 but warn us internally about and use Sentry to notice a large uptick in the warnings.