Hacker News new | past | comments | ask | show | jobs | submit login

For a company at their size, they probably already have those internal logs in place (for debugging, security, etc). Would be nice if they opened it up to the en d users.



Debugging/security logs are probably one of the last things that I'd want to hand over to customers without some serious scrubbing first. Either on purpose or accidentally (backtraces, var dumps) I've found things that I wouldn't want turned over to customers (passwords, access tokens, etc.) in logs of various project I've worked on. That var dump on a random object that was put in when tracking down some issue that could only reproduce on production seems innocent enough until someone adds an object to that one and all of a sudden the logs have passwords/account balances/etc. in them. Even if you are scrubbing them, handing over the debug/security logs just seems to introduce too large a point where you could accidentally leak information. The safe solution is to build out logging as a feature and then I completely agree with patio11 that if you need audit trails etc. you're in the enterprise game now and it (rightfully so) comes with a price tag to match.


They have the logs. They don't have it in a form which they can give to you, and they don't have an easy way to expose them to you.

Imagine if every piece of data that involves their cloud service is accessed using a custom piece of code and spread across a multitude of locations all over their network, unsorted. Now they have to build an application which can consolidate a specific customer's logs and provide an interface for them to download it. It's certainly "doable", but it's also probably the very last feature they're thinking about implementing.


Even ignoring other commenters' valid concerns about sensitive data stored in logs, this can be a tough thing to scale.

Say the logs live on disk on a filer somewhere. Need to do a security investigation? OK, dig up the file the logs are in for that particular user and grep around. Lots of disk seeks, but pretty fast.

Scaling that to support production-scale queries is a significant undertaking. (Oh, you can only do 100 seeks per second, need on average 100 seeks per query, and desire to service a low demand of 100 qps? Not gunna happen!)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: