Logging as a Service

Introduction

In his podcast https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/searching-in-the-chaos-with-thomas-hazel/ Corey Quinn recently said:

“You take a look at any of the log analytics companies and people can think through a wide variety of log analytics companies, it doesn't really matter which one, and at some point at scale you have to begin kidnapping princesses for ransom in order to pay for the bill."

Logging is an immensly sticky business. Once the applications are integarted with a logging-as-a-service provider it's really hard to switch and even more diffcult to extract the data.

Some places have added some intermdiary layer so it's only one place where the switch needs to happen and it's encouraging that companies like Chaossearch can use a company's S3 bucket.

Though I like new approaches like Loki (https://github.com/grafana/loki) and some had luck with running Amazon Athena to search their s3 buckets. This post is trying to look into how running elasticsearch on kubernetes compares, especially if kubernetes operators make it possible to bring things back in house.

Elasticsearch on Kubernetes

There are as many helm charts and ways to run elasticsearch in kubernetes as there are ways to structure the cluster in hot, warm, where and how to do parsing and such.

I don't want to go too much into the details of each and you should be able to find a chart which meets your needs fairly quickly. This is likely very ok for low log volumes and my back-of-the-envelope cal;calculations should get you towards $2 per GB infrastructure costs.