Hi There are not many things to discuss unless you could provide the reason for doing that before how doing this. Most log frameworks definitely could do customer JSON report, why do we have to maintain a new format? And you should know, headers are usually managed and restrict by ingress. You are proposing a way that has a higher priority to be blocked by the security team.
Sheng Wu 吴晟 Twitter, wusheng1108 Daming <[email protected]> 于2021年7月16日周五 下午6:43写道： > Hi all, > > I am writing to you for a discussion about Log Receiver over HTTP. > Currently, we have had an HTTP Receiver that required a strict message > format. That is a ProtoBuff-like JSON format[1]. > > I am thinking that is too much strict so that I am trying to add a new HTTP > Receiver to deal with the new protocol. IMO, this format is friendly with > log tools as fluentd. But it is less friendly with other applications. > Because it is hard to build the message as this format had. > > The protocol has two parts, header and content. > > header: > service: ${service} > serviceInstance: ${serviceInstance} > endpoint: ${endpoint} > Content-Type: text/plain > > content: > raw log content > [raw log content] > [raw log content] > [...] > > This sample is in text format. Surely, we also support json format like > above: > header: > service: ${service} > serviceInstance: ${serviceInstance} > endpoint: ${endpoint} > Content-Type: application/json > > content: > [ { "content": "content", ... }, ... ] > > Finally, it would be converted to LogData by the new receiver. > Looking forward to your comments. > Thanks. > > Haochao Zhuang > Apache SkyWalking >
