Add comparsion with EFK/ELK

[daixiang0]

Signed-off-by: Xiang Dai 764524258@qq.com

Fixes #94 #150

Checklist

• Documentation added

[daixiang0]

It is only my simple understand, free feel to add or modify.

[daixiang0]

@Kuqd @slim-bean any input?

[cyriltovena]

This is great stuff but I don't know if we want this on the front page. I defer to @tomwilkie on this one.

[daixiang0]

wait for feedback ;)

[daixiang0]

@Kuqd @tomwilkie any update?

[daixiang0]

@cyriltovena @slim-bean @tomwilkie any update?

[slim-bean]

I don't think this PR is in the spirit of the original issues referenced.

"If you need X then you'd typically go with grafana/loki, otherwise ELK" or "Loki is better in X, Y, Z, ELK would be preferable for X1, Y1, Z1"

Rather this seems to be mostly heavily opinionated statements which are difficult to prove:

This stack is lightweight, can be used as a simple alternative to super-heavy and full-featured search stacks such as ELK or EFK:

"Lightweight" here is not easily definable and doesn't really help people decide which to chose.

compared with elasticsearch, loki is not based on Lucene, with Golang language, it is easier to add new feature and cost less resources(whatever cpu or memory).

This is also subjective

compared with logstash, promtail is not C/S architecture, it directly gathers logs and push to loki.

C/S == Client/Server? I would say that Loki contains a client and server

compared with fluentd, promtail does not use plugins but scrape configs to handle different log sources and output which mean you do not need to learn ruby and fluentd plguin standard.

This may be an example of how they differ, although I don't think you need to learn ruby to use fluentd?

compared with kibana, grafana is a more common open platform for beautiful analytics and monitoring. It supports dozens of databases, natively.

This comparison should be limited to just Loki, not Grafana/Kibana

[slim-bean]

This is a difficult subject, and we have to be careful to make defensible statements. Be able to site code or benchmarks, etc. But I think we really want the solution to those issues to take the form of a comparison of what competing systems do well/poorly vs what Loki does well/poorly so that users can choose the right solution for their application.

[daixiang0]

@slim-bean something is my subjective look from my use case, something is not really precise.
What i think important is loki need to comment its advantage and limit compared with ELK/EFK, same as you said.

[daixiang0]

close since #982