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
As we've adopted the micro-service mind-set, we find ourselves with a larger and larger hierarchy of service calls being made from "aggregator" top-level services. For instance, since we use OAuth2 for authentication and Fortress (ANSI RBAC) for authorization, every one of these services will depend on those two. It's pretty easy to quickly have 4-5 micro-services in the hierarchy and in extreme cases these calls "fan-out" to 15 or 20 other systems.
I'd like to propose that the Checks object be aligned with the (top-level) API Health Check object and that an additional value of healthcheck be added to the pre-defined ComponentTypes listed in the specification. I'm a bit conflicted about whether another pre-defined MeasurementName (such as health) would be beneficial or if the MeasurementName should just be left off.
I do realize that it's still up to the service to determine how the healthcheck status of a subsystem affects its top-level status - some out-right failures of a subsystem will cause a degradation while others are more catastrophic - but I think there's a huge advantage in knowing that the format of the incoming data is another healthcheck.
The text was updated successfully, but these errors were encountered:
As we've adopted the micro-service mind-set, we find ourselves with a larger and larger hierarchy of service calls being made from "aggregator" top-level services. For instance, since we use OAuth2 for authentication and Fortress (ANSI RBAC) for authorization, every one of these services will depend on those two. It's pretty easy to quickly have 4-5 micro-services in the hierarchy and in extreme cases these calls "fan-out" to 15 or 20 other systems.
I'd like to propose that the
Checks
object be aligned with the (top-level)API Health Check
object and that an additional value ofhealthcheck
be added to the pre-definedComponentType
s listed in the specification. I'm a bit conflicted about whether another pre-definedMeasurementName
(such as health) would be beneficial or if theMeasurementName
should just be left off.I do realize that it's still up to the service to determine how the
healthcheck
status of a subsystem affects its top-level status - some out-right failures of a subsystem will cause a degradation while others are more catastrophic - but I think there's a huge advantage in knowing that the format of the incoming data is anotherhealthcheck
.The text was updated successfully, but these errors were encountered: