Live data from Hacker News

Saving millions on logging: Finding relevant savings

product.hubspot.com

21–24 of 24 posts

Re: Saving millions on logging: Finding relevant savings

#21
post #3

Earlier quoted context omitted.

Yes, shipping computations instead of data is a reasonable design goal. Your proposed system only works when the predicate is independent across all logs though, correct? If you have to correlate or join your logs to anything, then this model becomes more complex. Not to mention, you're adding an additional performance tax to your prod machines which could be more costly than shipping logs to a centralized store. (A…

I once worked on a system where we were told to keep 18 months of debug logs (something that would have cost about $2k/month). When we pushed back and asked why, the answer was that occasionally (every month or every other month) there would be some customer issue that would need investigation that might result in a customer refund of $20-50 dollars. Setting aside that the human time required for the investigation wa…

Seems like the kind of situation where you shrug, agree, compress and ship those logs off to cold storage to meet the requirement for a fraction of the price.

Re: Saving millions on logging: Finding relevant savings

#22
post #14

I am lost at how you can have 20% of your storage costs be for logging, and not immediately say that at minimum you are persisting too many logs, and probably logging too much in the first place. I get that modern tech companies log every movement and interaction a user has with an app, far beyond any amount that is reasonable, but surely at some point you can go “we probably don’t need this”. It shouldn’t be a matte…

Hubspot offers hosted websites and landing pages (including analytics) as part of their product, so it's not just internal facing data.

Re: Saving millions on logging: Finding relevant savings

#23
post #12

Earlier quoted context omitted.

Thanks for the response. I was responding to the comment more so than advocating for adjusting your log retention. :) Looking forward to part 2. Are you able to reconcile some of the numbers and calculations in the article for me? (Understanding that you don't want to reveal any confidential info.) I see: - 31 PB data + 10 PB application logs = 41 PB logs (uncompressed json) costs 7-figures (say ~$5M) - 41 PB logs *…

The costs I talk about in the estimate in this post are for the remaining cost of each stored file. We have S3Inventory dumping metadata of all the files in specific buckets weekly, so I had written a job that calculated the exact remaining cost of each file, accounting for lifecycle events like moving to infrequent access storage in S3 and the eventual deletion of the file. So it’s sort of the “potential energy” ver…

Thanks for the clarification!

Re: Saving millions on logging: Finding relevant savings

#24
Unlike JSON, orc requires batching of rows to write to disk. It's because it does a lot of computation - maintaining indexes, encoding columns (run-length, dictionary), calculating statistics, maintaining bloom filters, compressing columns etc. Doing this at the source where you are more interested in serving an individual request as quickly as possible doesn't look like a good idea. If you want the orc files to be useful, you need to batch a lot of rows together otherwise you don't get the benefits of columnar storage. So logs in the happy path will be delayed, and in the unhappy path if the process crashes, recent logs are gone. JSON isn't really bad as a logging format. And it can be stored temporarily to then asynchronously convert to a columnar format.

I'm looking forward to the next post.

Post reply on HN