Send log entries to Loki as protobuf instead of JSON

[imiric]

Feature Description

In a private conversation, @na-- brought up the possibility of sending protobuf payloads to Loki instead of the current JSON we use. This is supported according to their HTTP API documentation:

The default behavior is for the POST body to be a snappy-compressed protobuf message

This would have the benefit of being more efficient, both to encode and on the wire, and would avoid the current pains with JSON serialization. :sweat_smile:

[niuguy]

Hi @imiric @codebien I investigited this issue a little bit. My rough plan is to replace lokiPushMessage with something like promtail batch and update all is methods(add, writeTo, etc..) accordingly. This will introduce new dependency on loki "github.com/grafana/loki/pkg/logproto" Do you think it's good?

[codebien]

This will introduce new dependency on loki "github.com/grafana/loki/pkg/logproto". Do you think it's good?

It could be fine for initial development to quickly iterate for having an end-to-end solution, but I expect it will introduce a lot of indirect dependencies for k6 so it could introduce issues in maintainability in the future, especially for the extensions. It could also add a lot of overhead for the binary size. It might require a lighter solution to have a PR that we can accept. So, ideally, we should research a bit how complex could be to have a dedicated client for it in k6. We already use the Snappy compression and Protobuf in other places of the code so we already have support for them.

This feature is still something nice to have but we don't have so many critical issues with the current solution so it could be difficult to justify the benefit if the cost is too high.

[niuguy]

Thanks for the feedback. I somehow forgot k6 was supposed to be a lightweight commandline tool. Yes I agree in that case introducing a fat dependency requires extra caution. Actually I tried to import it and the go.mod became messy. Let me investigate on implementing a minimal client which just work in this scenario.

[niuguy]

Hello @codebien I had a second reading of your comment and further research on related code. Correct me if I'm wrong. I think in the case k6 sends to loki directly using Protobuf we have to rely on the same proto schema offered by loki. But as you said this will introduce indirect dependencies we probably don't want. Do you have better idea or we just put his feature on hold until we find it become necessary. Right I just thought a workaround which is to copy the exact same proto schema from loki "github.com/grafana/loki/pkg/logproto" and generate go code locally, it would not introduce new dependency but would take the risk of future server side updating , do you think it worths a try?

[Ecostack]

It seems like this issue got stale but in my opinion, this would be the best approach. The question here would be, how stable is the gRPC API from Loki?

If there are not many changes expected, this is the cleanest solution without having any dependency.