Thank you Eric, Indeed, it seems that these 2 fields derive the following list of fields from astat: "system.proc.loadavg", "system.proc.net.dev", "system.inf.speed". Nir
On Thu, Jan 12, 2017 at 2:49 PM, Eric Friedrich (efriedri) < [email protected]> wrote: > Hey Nir, Adan- > I don’t think #2 configuration pull is actually required. The cache must > be configured in Traffic Ops, so Traffic Monitor can learn its hostname and > capacity. Other than that it should just be meeting the astats criteria. > > I think you might need interface speed and actual used bandwidth in the > astats (rather than available bandwidth in Kbps). I can’t remember if the > availableBandwidth is computed in astats or in TM. > > —Eric > > > > On Jan 12, 2017, at 4:20 AM, Nir Sopher <[email protected]> wrote: > > > > Hello, > > > > > > > > One of our team members (Adan Alper, CCed) is currently trying to > connect a > > non ATS cache to Traffic Control. > > > > In order to be able to do this, we tried to figure out what is the bare > > minimum information that needs to be sent by the cache to TC in order for > > it to consider the cache as active. > > > > Currently we found the following: > > > > 1. Monitoring file (_astat) is read from the traffic monitor ones > > every few seconds. In this file we must provide the following data: > > > > a. availableBandwidthInKbps > > > > b. loadavg > > > > 2. Configuration pull – The cache should pull configuration from > his > > queue in traffic OPS once every 15 minutes and suppose to signal traffic > > ops once it was read and applied. > > > > > > > > Our questions are: > > > > 1. Are these the only information pieces (bare minimum) that we > need > > to provide or are there any more? > > > > 2. Regarding the configuration read signaling. what exactly does > that > > cache needs to send to traffic ops for it to acknowledge that the > > configuration was read and applied? Is this a must for basic > functionality? > > > > > > > > Thanks, > > > > Nir > >
