Show HN: LogDNA – Easy logging in the cloud
logdna.com
logdna.com
We had our “slack moment” and decided to pivot. We were frustrated with the current logging landscape and built LogDNA around 3 philosophies:
1. More Storage - give away ample storage so you can log everything
2. Longer Search - faster and longer search retention
3. UI/UX - a much cleaner experience to interact with your log tails
I’m happy to answer any questions you may have!
What's the killer use case or differentiator (vs. loggly+kibana+elasticsearch for example)? With Slack, it is integrations. If you could do something similar, like a bugsnag + new relic that aggregates all of our logs and notifies us when things happen (either individual incidents or aggregates like "nginx error log above 1 event/10s), you can have all my money.
Another idea would be to standardize transactions across the stack, so I could trace a request from nginx through rails/phoenix, to postgresql, etc. Again, take my money.
A better UI only helps me if I know when to look at it or what I'm looking for.
It's not the log storage that we care about, it's what we can do with those logs.
I've been through three logging vendors in the last two years (Loggly, LogEntries, now Sumo Logic) and I'm looking to move once again. The secret sauce is not the storage volume; our volume is relatively small: 4.3 GB/day. The secret sauce is the intelligent structuring of unstructured log data, analytics+alerting on the now-structured data, and live tail'ing of logs.
Sumo Logic does an okay job at the parsing/querying/alerting/analytics piece but live tailing is a brand-new feature for them and it has limitations. Sumo Logic's pricing is also frustrating--they don't apply volume discounting until you're pushing something like 500 GB of logs each month. Again, we need affordable analytics; storage is a small piece of the puzzle.
Honestly, our next move may be to an internal "HEK" stack: Heka, Elasticsearch, and Kibana. I've looked at the cost of doing this and it's actually more expensive when you consider what we'd spend to host a big ES cluster internally, but cost is not our #1 consideration, usability is.
Congratulations to the LogDNA team on the launch. There are a lot of use cases in this field and it could use some more shaking up.
(Disclaimer: I'm the founder of Scalyr.)
Scalyr looks interesting, how does it compare to Sumo Logic feature-wise? For reference, this video has made me switch to them: https://www.youtube.com/watch?v=w5yWfYDQz2Q
Speed turns out to be surprisingly important. We've had a lot of customers report that after migrating, usage across the team goes way up, simply because it's much more satisfying to use a tool that gives quick results. See https://www.scalyr.com/case-studies/returnpath for a brief case study.
I'd be happy to discuss in more detail, but I don't want to hijack the thread - please drop me a line at steve@scalyr.com.
http://www.splunk.com/en_us/products/splunk-enterprise/featu...
Give us a try, even if you don't think you'll use the GBs. We have alerting, field parsing and live tail. Analytics is the only piece we don't have today, but we're working towards it.
The number one most important problem we're trying to solve is the actual parsing of logs during ingestion. We need logs from commonly-used apps & frameworks to be automatically identified and parsed and we need an easy way to set up a custom parser for internal logs that doesn't require crazy hand-written regex. How does LogDNA handle parsing? What apps/frameworks are supported?
We run our ELK stack (elastic search+logstash+kibana+3 days of logs) on a single EC2 ephemeral instance inside an auto-scaling group. If we lose our logs, oh well! Given that we lose this instance every two-ish years, it seems like a reasonable tradeoff.
Have you tried that? I wonder how Mozilla likes it
To be clear, I'm not asking that you have all of this out of the gate. It's that I want to see the vision and get excited about where you're heading. Your early users are investing in your future and taking a bet on what you could become.
Right now, I'm not sure what I should be dreaming about.
Obviously internally (as a fellow founder), things are always crazy and you adapt and grow. But your customers need more than the faith that you'll figure it out as you go.
I was referring to the aggregation of the logs, including taking columns / data types from different log streams and combining them (in real time) to create new objects. You can then set alerts and build dashboards on the new objects.
Additionally he mentioned standardizing the request across the stack. Since Striim can import the logs from all these types of services and combine them to create a new object that represents the request across the stack he could accomplish his second request as well.
Combine that with the ability to ingest huge amounts of data and query in real time, it sounded like what he was looking for.
At least, as a possible customer, that is one of my biggest concern.
But maybe I'm just too focused on security given that our clients ask us about it pretty much every day. So as a possible vendor (for us or other SaaS businesses) and being part of our chain of trust, I'd expect some words on how you handle security and how much it is important for you. That is lacking on the website if I'm correct.
Anyway, congrats on the service! I think that there is room for LogDNA in the logging-warehousing market
I know something of logs.
Speaking for requirements inside other's logging use cases is pointless given privacy needs vary from use case to use case. While your statement may be factual for some use cases, claiming it's "a huge oversight" is blanket blaming statement across all use cases and thus becomes worthless.
Besides, if you want search for things in the logs, things have to be kept hot and moving unencrypted. That means no at rest encrypted storage for near realtime search use cases.
I wish I had a stick I could hit people with to get them to stop creating double bind arguments. If you really want privacy for your logs, deal with them yourself on your own equipment. If you absolutely have no time to deal with your logs yourself, then get comfortable with privacy issues.
It's literally setting a policy on a bucket and a flag on object PUTs if you're not managing the keys yourself.
Is the 2 day retention time because you sync logs to the user's s3 bucket? If so then it would help conversion to say that next to the 2 days retention copy.
If you care about retention, chances are you're also building a serious product and you want to rely on LogDNA to be around. For that, we hope you'll be on a paid plan.
We want to build the best product we can and by charging appropriately, we can afford better people.
When you have a Docker/Kubernetes solution I will be (at another YC company) very interested in putting it through it's paces. Also I'd agree with others here that having a command line tail interface as well as a gui for browsing and savable queries would be bitchin.
Looks really great at first glance. Is there anything you guys do that differentiates yourself from other log management platforms (eg Kibana, Splunk, etc)
1. Really straightforward, scriptable installation 2. Intuitive view of the log data 3. Very quick and easy to select a time frame 4. UI is oriented to cope with lots of server creation/destruction (very useful for auto-scaling environments and not well handled in some of the other products)
We are very happy with the product - great job guys!
Technically, building a scalable infrastructure to ingest an order of magnitude of GBs more than other platforms was a bit challenging (and still is) but I think we're on our way to achieving that.
We will be open sourcing our agent soon, we literally launched this week...some things we couldn't get to for launch.
And yes, it currently streams /var/log/* by default and any other paths your specify to the agent.
Great! I want to stick it in a Docker container.
That would be really useful for, say, running scripts and maintenance jobs on a bunch of boxes. That would allow me to collect data and inspect it later (or tail it live).
Oh, and I see you provide an OS X package for the tool. I'd vastly prefer a Homebrew package over that.
> curl: (7) Failed to connect to heroku.logdna.com port 443: Connection refused
Might be an interesting technical challenge to the keep search fast with 100gbs of logs.
Would be nice to have a cloud log service with unlimited retention that's searchable, but for now self-hosting is the best choice using logstash [1] for logging and statsd [2] for metrics.
Also, if you are dealing with a production issue with HIPPA logs, you must keep them on the machine. You can't send anything in an email, send a stack trace over a messaging client, or put them into JIRA.
Yes, you are correct, more value for your money is our current offer. We want to build a great product and to do that, you have to hire great people, so we came up with a pricing that'll hopefully achieve that.
But it's not set in stone and we'll adjust just like any other company.
None of that is customer value. Pricing must favor my needs over any of your company's long term goals.
* Love the price
* Can or will you add name value pairs? Logging for us is no longer just a single line of text. We have attached metadata. Kibana handles this nicely.
* How good is your security? This is actually our biggest reason why would not use a service like this. Not that we put passwords or user sensitive data in logs we still have to keep them extremely secure due to compliance.
I'm sure you have decent security but I would recommend emphasizing that and/or proving it.
Yes, just send us JSON in a line and we'll parse it. You can actually search on that today, we just haven't made a way for you to see the parsed fields yet (coming soon!)
We're fully encrypted end-to-end in transit (but not at rest, currently).
Yeah we need documentation mainly and couldn't get that in time for launch.
I've definitely thought about building this myself, but haven't gotten around to it. It's just sending some text to a server, isn't it? What's so hard about it?
Obviously I'm missing something. I'd love to know what :)
I wasn't aware there were several startups every few months in logging. For us, it was an interesting space. Lots of changes happening.
Yes you are somewhat right. It is sending text to a server. But then you send more text and more text and you need to search for all this text in a split second. If you've ever run your own ELK stack for example, you'll realize quickly that you're spending most of your time scaling elastic search to handle the data volume. There is a challenge to doing that.
You've been through YC? How the hell did you graduate? Because you just did mistake number 4: http://paulgraham.com/startupmistakes.html
I used my own judgement and concluded that this is a worthless idea, as competition is high and differentiation low. I referenced that article to give credit to the original author.
But the infrastructure components are certainly there on AWS.
CloudWatch Logs will ingest tons of data at minimal cost. It has simple API for searching for events, but it's extremely slow to return results if you have lots of data in a LogGroup. It has a simple API to get the latest events but it has a 10s delay and its a bit tricky to get all the events from all the LogStreams in the right order.
Kinesis will ingest tons of data at minimal cost, and let you stream it back in real time.
Lambda can subscribe to all the CloudWatch Log or Kinesis Events for parsing, filtering, and forwarding.
AWS ElasticSearch can ingest all the logs and give you a richer query language and visualization tools.
I've been building all this into Convox, an open source AWS toolkit. Take a look at this CloudFormation template for an example of how to configure a CloudWatch Log Group and Lambda filter in your own AWS account:
https://github.com/convox/rack/blob/master/api/dist/kernel.j...
Also, we just use AWS for EC2 mainly.
echo "deb http://repo.logdna.com stable main" | sudo tee /etc/apt/sources.list.d/logdna.list
sudo apt-get update
sudo apt-get install -y --force-yes
logdna-agent sudo logdna-agent -k 6a7b7c622290d1a49bbe5a94dc6828d
That would work for the initial install but wouldn't it complain down the road when you try to update the package?
I think the missing piece of Papertrail is the ability to send JSON logs, and filter inside of a JSON documents.
I think we're pretty good on our UI/UX. Give us a try!
Does LogDNA have a shipper from syslog? Do you have a node.js client lib?
Finally can you talk about security? Is traffic encrypted over the wire? Do you encrypted disks at rest?
We do not have syslog yet or code libraries. We have an agent that ships logs today via secure web socket.
Everything is encrypted in transit, end-to-end. We haven't not researched into encryption at rest on EC2 yet.
Edit: Rsyslog can pipe data to a command-line program via the "omprog" plugin, which might be an easier option for you.
I really like the high volumes you offer; I really agree that volume should be cheaper. What Papertrail charges per GB seems really high IMO.
That said, I'm just a hobbyist doing under 1GB month of traffic. I will try to stick with the free plan for as long as possible. If you could offer some nice features for $5-10/month, I would upgrade for that.
That aside, it looks very interesting!
Would love to hear you have an aggregator/forwarding tool that I could run all my logs through to forward to your environment.
Done.
Secondly there is almost no detail so while your product sounds cool I can't see what it is like to use your product. Give me examples of creating queries or dashboards. There should definitely be a documentation section on your site!
Also, a really cool feature I can't see anywhere else is reliable journald log uploading. You can dump as JSON which does most of the work but it is a pain implementing a reliable uploader with a HTTP API.
We just built our website this week since we were heads down focused on product. Our documentation is coming soon. We just wanted to get a product into the hands of users and had to make tough decisions on what we needed.
We could be perfect and launch 2 months from now or just launch now with what we have. But you're right, we will be plugging the holes quickly.
That's why we need to encourage more kids to do STEM and tackle hard problems, rather than encouraging "makers" and getting them all to be app builders.
I have yet to live the day I will regain my faith in startups.
The current first comment:
It's a straight up ad-hominem attack against Justin Keller, instead of criticising [sic] his writing it attacks his character.
That's just as fallacious an invocation of ad hominem as your link was. Description of questionable behavior is not fallacious, in an article the purpose of which is to complain about questionable behavior. Likewise, it is entirely reasonable to expect withering unsupported criticism like yours to spring from some a personal position of some relevant experience.