ocket8888 commented on code in PR #7302: URL: https://github.com/apache/trafficcontrol/pull/7302#discussion_r1083077961
########## docs/source/overview/traffic_monitor.rst: ########## @@ -56,3 +56,6 @@ Protocol Engagement ------------------- Short polling intervals of both the :term:`cache servers` and Traffic Monitor peers help to reduce customer impact of outages. It is not uncommon for a :term:`cache server` to be marked unavailable by Traffic Monitor - in fact, it is business as usual for many CDNs. Should a widely requested video asset cause a single :term:`cache server` to get close to its interface capacity, the Health Protocol will "kick in," and Traffic Monitor marks the :term:`cache server` as unavailable. New clients want to see the same asset, and now :ref:`tr-overview` will send these customers to another :term:`cache server` in the same :term:`Cache Group`. The load is now shared between the two :term:`cache servers`. As clients finish watching the asset on the overloaded :term:`cache server`, it will drop below the threshold and gets marked available again, and new clients will begin to be directed to it once more. It is less common for a :term:`Delivery Service` to be marked unavailable by Traffic Monito r. The :term:`Delivery Service` thresholds are usually used for overflow situations at extreme peaks to protect other :term:`Delivery Services` in the CDN from being impacted. +Handling Caches with same service ip +------------------- +Traffic monitor is able to direct traffic router to route traffic to groups of :term:`cache servers` with the same service ip address that is routed with qual cost multi path(ECMP) on the last hop, but not to individual :term:`cache server` within that group. To monitor :term:`cache servers` that within that group, http keep-alive header is omitted with the ``health.polling.keepalive`` and ``stat.polling.keepalive`` traffic monitor profile parameter so that the TM source port changes for those connections and the TM can get to all the servers within that group via ECMP. That it updates the responses using the via header. In the event of :dfn:`Health Protocol` determining the overall health of one of the :term:`cache servers` in a anycast group by evaluating network throughput and load against values configured in :ref:`to-overview` to exceed their limit, it declares the whole groups as unhealthy. Review Comment: Also, I see "TM" several times in there. From our documentation guidelines: > Please do **not** abbreviate Traffic Control terms e.g. [Cache Group](https://traffic-control-cdn.readthedocs.io/en/latest/glossary.html#term-Cache-Group), [Delivery Service](https://traffic-control-cdn.readthedocs.io/en/latest/glossary.html#term-Delivery-Service). See [Terms](https://traffic-control-cdn.readthedocs.io/en/latest/development/documentation_guidelines.html#terms) for the proper way to use these terms. "keep-alive" and "via" should be at least mono-spaced but preferably use the `:mailheader:` text role instead, and in canonical format (e.g. Keep-Alive). Terms like "profile" and "parameter" are ATC Terms so they should be capitalized (and ideally linked to their glossary definitions using the `:term:` text role). Are `health.polling.keepalive` and `stat.polling.keepalive` documented? If so, these should be links to that documentation, otherwise the reader doesn't know how to use them to achieve what you're describing. What is "qual cost multi path(ECMP)"? grammar: - "...not to individual :term:\`cache server\` within..." -> pluralize: "...not to individual :term:\`cache servers\` within..." - "...that within that group, http keep-alive header is omitted..." -> extra word, missing article: "...within that group, the :mailheader:\`Keep-Alive\` HTTP header is omitted..." - "...in a anycast group..." -> wrong article, need to capitalize a proper noun: "...in an Anycast group..." - "...it declares the whole groups as unhealthy." -> singularize: "...it declares the whole group to be unhealthy." ("as" -> "to be" is a stylistic choice. Both are grammatically correct, I just think "to be" reads better there) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
