Standardize Time in SkyWalking

[wu-sheng]

Hi

Today, SkyWalking time mechanism relied on the agent, backend, and UI in the same time zone, but still facing issues. Because of the time in agent traces, it is hard to make it accurate in the query.

In 6.2, I want to do this, which related to agent, backend and UI changes.

1. Agent reports its timezone in register and heartbeat, in default, treated as backend timezone for back-forward compatible. But I hope Java, .net, nodejs, php, go agents could adopte this. @ascrutae @liuhaoyang @hanahmily @heyanlong
2. Service Mesh receiver, especially istio and envoy receiver need to transfer time based on timezone in the timestamp. @hanahmily
3. OAP backend will transfer time format to UTC-0 always and save in storage.
4. OAP query parameter and result are all based on UTC-0, UI needs to change time visualization based on browser timezone. Also, because of this, I think no need to choose timezone anymore. @TinyAllen

[hanahmily]

Agent reports its timezone in register and heartbeat, in default, treated as backend timezone for back-forward compatible. But I hope Java, .net, nodejs, php, go agents could adopte this.

If we use gRPC, I think the best practice is that at the first segment of streaming the agent is designed to report timezone.

…

Service Mesh receiver, especially istio and envoy receiver need to transfer time based on timezone in the timestamp. @hanahmily <https://github.com/hanahmily>For service mesh, eg. istio mixer,envoy, there’s no chance to grab timezone of senders. But a good news for us is they are both deployed in docker whose default timezone is GTM(UTC-0), especially envoy’s access log is [designed to support it](envoyproxy/envoy#3546 <envoyproxy/envoy#3546>).So the details should be declared in our documents. On Apr 30, 2019, at 8:08 AM, 吴晟 Wu Sheng ***@***.***> wrote: Hi Today, SkyWalking time mechanism relied on the agent, backend, and UI in the same time zone, but still facing issues. Because of the time in agent traces, it is hard to make it accurate in the query. In 6.2, I want to do this, which related to agent, backend and UI changes. Agent reports its timezone in register and heartbeat, in default, treated as backend timezone for back-forward compatible. But I hope Java, .net, nodejs, php, go agents could adopte this. @ascrutae <https://github.com/ascrutae> @liuhaoyang <https://github.com/liuhaoyang> @hanahmily <https://github.com/hanahmily> @heyanlong <https://github.com/heyanlong> Service Mesh receiver, especially istio and envoy receiver need to transfer time based on timezone in the timestamp. @hanahmily <https://github.com/hanahmily> OAP backend will transfer time format to UTC-0 always and save in storage. OAP query parameter and result are all based on UTC-0, UI needs to change time visualization based on browser timezone. Also, because of this, I think no need to choose timezone anymore. @TinyAllen <https://github.com/TinyAllen> — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#2560>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAO6UWNK7H3W3ZGYSAQCDR3PS6EYZANCNFSM4HJHT5KA>.

[wu-sheng]

If we use gRPC, I think the best practice is that at the first segment of streaming the agent is designed to report timezone.

But it will break all agent protocol, which will be a disaster. See what happens in 5.0->6.0, some agents are still not fitting the new protocol. I really don't want to do that.

[hanahmily]

It seems an extension far more than a breaking. I means if the agent has adopted the new protocol cloud send timezone, other agent could use old ways to send data. In other word, the oap makes an assumption that all data received is belonging to GTM unless it gets the exact timezone of the agent.

…

On Apr 30, 2019, at 8:40 AM, 吴晟 Wu Sheng ***@***.***> wrote: If we use gRPC, I think the best practice is that at the first segment of streaming the agent is designed to report timezone. But it will break all agent protocol, which will be a disaster. See what happens in 5.0->6.0, some agents are still not fitting the new protocol. I really don't want to do that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2560 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAO6UWLN6Q3U2BD6XTIK7JDPS6IOHANCNFSM4HJHT5KA>.

[wu-sheng]

It seems an extension far more than a breaking. I means if the agent has adopted the new protocol cloud send timezone, other agent could use old ways to send data. In other word, the oap makes an assumption that all data received is belonging to GTM unless it gets the exact timezone of the agent.

Then you need to extend all agent protocol as 6.0 did. Because all agent protocols include time. Also,y, you should known, in gRPC/protobuf, the naming will become very hard. Because span/segment need to be renamed again.

[wu-sheng]

In other word, the oap makes an assumption that all data received is belonging to GTM unless it gets the exact timezone of the agent.

@hanahmily You can't. Because old agents base on OS time only.