Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the cache status field to the Traffic Monitor CrStates endpoint #6448

Closed
jrushford opened this issue Jan 6, 2022 · 0 comments · Fixed by #6612
Closed

Add the cache status field to the Traffic Monitor CrStates endpoint #6448

jrushford opened this issue Jan 6, 2022 · 0 comments · Fixed by #6612
Assignees
Labels
new feature A new feature, capability or behavior Traffic Monitor related to Traffic Monitor

Comments

@jrushford
Copy link
Contributor

jrushford commented Jan 6, 2022

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` 
}
@jrushford jrushford added the new feature A new feature, capability or behavior label Jan 6, 2022
@rawlinp rawlinp added the Traffic Monitor related to Traffic Monitor label Jan 10, 2022
@srijeet0406 srijeet0406 self-assigned this Mar 3, 2022
jrushford added a commit to jrushford/trafficcontrol that referenced this issue Mar 21, 2022
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.
rawlinp pushed a commit that referenced this issue Mar 30, 2022
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature A new feature, capability or behavior Traffic Monitor related to Traffic Monitor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants