Use of Ntp Service

WebRTC NTP Server

googCaptureStartNtpTimeMs has nothing to do with NTP servers. It's in the local clock. "Ntp" in the name comes from the format in which time is passed in RTCP SenderReport packets, and doesn't imply that some NTP server synchronization is going on.

Your understanding of the metric definition is a little off.
It's a local (receiver's) time when the track started sending.

The clock synchronization is done internally by WebRTC using RTT estimate and RTCP SenderReport packets. Note, to have RTT estimate, the peer has to be sending something, and it takes some time (up to 20 seconds for audio tracks, based on RTCP SR sending period). Before all the estimates are available, the metric will report -1.

ntp should be installed to a web server normally?

Yes, you should always install ntp if you can on all and any servers especially production boxes. It will save you hours of pain and troubles later.

This is a quick guide to ntp setup on Linux which should give you some ideas as to how to set up, what the config options do etc.

If you only have two servers in your deployment then I'd suggest you find some 'trusted' low stratum ntp servers that you can use, and apply the same config to both servers.

Make sure you have a minimum of three upstream servers to connect to, ideally five for a robust time domain.

Once you ntp setup and running and your servers are keeping time whenever you ask for the time, it should be the correct time within a small margin of UTC. So in Ruby if you do Time.now.strftime("%Y-%m-%d %H:%M:%S") it will return the hosts time as set/clocked by ntp.

What is Clock offset in NTP server

This all is explained in detail at ntp.org; for example:

5.1.1.4. What happens if the Reference Time changes?

Ideally the reference time is the same everywhere in the world. Once synchronized, there should not be any unexpected changes between the clock of the operating system and the reference clock. Therefore, NTP has no special methods to handle the situation.
Instead, ntpd's reaction will depend on the offset between the local clock and the reference time.
For a tiny offset ntpd will adjust the local clock as usual; for small and larger offsets, ntpd will reject the reference time for a while. In the latter case the operation system's clock will continue with the last corrections effective while the new reference time is being rejected. After some time, small offsets (significantly less than a second) will be slewed (adjusted slowly), while larger offsets will cause the clock to be stepped (set anew). Huge offsets are rejected, and ntpd will terminate itself, believing something very strange must have happened.
Naturally, the algorithm is also applied when ntpd is started for the first time or after reboot.