You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This Feature Request affects these Traffic Control components:
Traffic Monitor
Description
Currently the tc-health-client is using the Traffic Monitor api/cache-statuses endpoint to find and mark down unhealthy parents. This endpoint it turns out is for local TM state and may not reflect the state as reached by consensus of all TM's. The health-client is being switched to use the publish/CrStates endpoint instead.
However, the publish/CrStates endpoint lacks the status field that is available in the api/cache-statuses endpoint. This field was logged by the health-client so that it may be understood why the parent was marked down ie, the health threshold that triggered the markdown. It would be invaluable to continue this logging if the field could be added to the publish/CrStates endpoint or a query parameter that would let the client ask for the field as part of the response. Querying both endpoints is not desirable.
Also, a date time field should be added to the publish/Crstates endpoint response that shows when the health monitor last polled the cache. This could also be added to the response only when requested with a query parameter.
Example status information from api/cache-statuses:
REPORTED - availableBandwidthInKbps too low (0.00 < 75000000.00
REPORTED - available
REPORTED - queryTime too high (1520.00 > 1500.00)
Possible new struct layout, see lib/go-tc/crstats.go:
type IsAvailable struct {
IsAvailable bool
Ipv4Available bool
Ipv6Available bool
Status string // new field status and health threshold reason when unavailable
LastHmPoll time.Time // new field last Health monitor poll`
}
The text was updated successfully, but these errors were encountered:
When the tc-health-client was switched to using the combined
TM CrStates endpoint, the ability to log the cache status was
lost, Issue apache#6448. PR apache#6612 adds the cache status field to the
TM CrStates endpoint allowing cache status to be logged again.
This PR adds back the cache status logging.
When the tc-health-client was switched to using the combined
TM CrStates endpoint, the ability to log the cache status was
lost, Issue #6448. PR #6612 adds the cache status field to the
TM CrStates endpoint allowing cache status to be logged again.
This PR adds back the cache status logging.
This Feature Request affects these Traffic Control components:
Description
Currently the tc-health-client is using the Traffic Monitor api/cache-statuses endpoint to find and mark down unhealthy parents. This endpoint it turns out is for local TM state and may not reflect the state as reached by consensus of all TM's. The health-client is being switched to use the publish/CrStates endpoint instead.
However, the publish/CrStates endpoint lacks the status field that is available in the api/cache-statuses endpoint. This field was logged by the health-client so that it may be understood why the parent was marked down ie, the health threshold that triggered the markdown. It would be invaluable to continue this logging if the field could be added to the publish/CrStates endpoint or a query parameter that would let the client ask for the field as part of the response. Querying both endpoints is not desirable.
Also, a date time field should be added to the publish/Crstates endpoint response that shows when the health monitor last polled the cache. This could also be added to the response only when requested with a query parameter.
Example status information from api/cache-statuses:
Possible new struct layout, see lib/go-tc/crstats.go:
The text was updated successfully, but these errors were encountered: