--- title: "Get the status of Chaos." method: GET path: "/Tools/Chaos" tags: ["Chaos"] --- # Get the status of Chaos. `GET /Tools/Chaos` Get the status of Chaos indicating whether or not Chaos is running, the Chaos parameters used for running Chaos and the status of the Chaos Schedule. ## Query parameters - `api-version` '6.2', required - `timeout` integer ## Response `200` A successful operation will return 200 status code and the status of Chaos. - Chaos — Contains a description of Chaos. - `ChaosParameters` ChaosParameters — Defines all the parameters to configure a Chaos run. - `TimeToRunInSeconds` string — Total time (in seconds) for which Chaos will run before automatically stopping. The maximum allowed value is 4,294,967,295 (System.UInt32.MaxValue). - `MaxClusterStabilizationTimeoutInSeconds` integer — The maximum amount of time to wait for all cluster entities to become stable and healthy. Chaos executes in iterations and at the start of each iteration it validates the health of cluster entities. During validation if a cluster entity is not stable and healthy within MaxClusterStabilizationTimeoutInSeconds, Chaos generates a validation failed event. - `MaxConcurrentFaults` integer — MaxConcurrentFaults is the maximum number of concurrent faults induced per iteration. Chaos executes in iterations and two consecutive iterations are separated by a validation phase. The higher the concurrency, the more aggressive the injection of faults, leading to inducing more complex series of states to uncover bugs. The recommendation is to start with a value of 2 or 3 and to exercise caution while moving up. - `EnableMoveReplicaFaults` boolean — Enables or disables the move primary and move secondary faults. - `WaitTimeBetweenFaultsInSeconds` integer — Wait time (in seconds) between consecutive faults within a single iteration. The larger the value, the lower the overlapping between faults and the simpler the sequence of state transitions that the cluster goes through. The recommendation is to start with a value between 1 and 5 and exercise caution while moving up. - `WaitTimeBetweenIterationsInSeconds` integer — Time-separation (in seconds) between two consecutive iterations of Chaos. The larger the value, the lower the fault injection rate. - `ClusterHealthPolicy` ClusterHealthPolicy — Defines a health policy used to evaluate the health of the cluster or of a cluster node. - `ConsiderWarningAsError` boolean — Indicates whether warnings are treated with the same severity as errors. - `MaxPercentUnhealthyNodes` integer — The maximum allowed percentage of unhealthy nodes before reporting an error. For example, to allow 10% of nodes to be unhealthy, this value would be 10. The percentage represents the maximum tolerated percentage of nodes that can be unhealthy before the cluster is considered in error. If the percentage is respected but there is at least one unhealthy node, the health is evaluated as Warning. The percentage is calculated by dividing the number of unhealthy nodes over the total number of nodes in the cluster. The computation rounds up to tolerate one failure on small numbers of nodes. Default percentage is zero. In large clusters, some nodes will always be down or out for repairs, so this percentage should be configured to tolerate that. - `MaxPercentUnhealthyApplications` integer — The maximum allowed percentage of unhealthy applications before reporting an error. For example, to allow 10% of applications to be unhealthy, this value would be 10. The percentage represents the maximum tolerated percentage of applications that can be unhealthy before the cluster is considered in error. If the percentage is respected but there is at least one unhealthy application, the health is evaluated as Warning. This is calculated by dividing the number of unhealthy applications over the total number of application instances in the cluster, excluding applications of application types that are included in the ApplicationTypeHealthPolicyMap. The computation rounds up to tolerate one failure on small numbers of applications. Default percentage is zero. - `ApplicationTypeHealthPolicyMap` ApplicationTypeHealthPolicyMapItem[] — Defines a map with max percentage unhealthy applications for specific application types. Each entry specifies as key the application type name and as value an integer that represents the MaxPercentUnhealthyApplications percentage used to evaluate the applications of the specified application type. The application type health policy map can be used during cluster health evaluation to describe special application types. The application types included in the map are evaluated against the percentage specified in the map, and not with the global MaxPercentUnhealthyApplications defined in the cluster health policy. The applications of application types specified in the map are not counted against the global pool of applications. For example, if some applications of a type are critical, the cluster administrator can add an entry to the map for that application type and assign it a value of 0% (that is, do not tolerate any failures). All other applications can be evaluated with MaxPercentUnhealthyApplications set to 20% to tolerate some failures out of the thousands of application instances. The application type health policy map is used only if the cluster manifest enables application type health evaluation using the configuration entry for HealthManager/EnableApplicationTypeHealthEvaluation. - `Key` string, required — The key of the application type health policy map item. This is the name of the application type. - `Value` integer, required — The value of the application type health policy map item. The max percent unhealthy applications allowed for the application type. Must be between zero and 100. - `NodeTypeHealthPolicyMap` NodeTypeHealthPolicyMapItem[] — Defines a map with max percentage unhealthy nodes for specific node types. Each entry specifies as key the node type name and as value an integer that represents the MaxPercentUnhealthyNodes percentage used to evaluate the nodes of the specified node type. The node type health policy map can be used during cluster health evaluation to describe special node types. They are evaluated against the percentages associated with their node type name in the map. Setting this has no impact on the global pool of nodes used for MaxPercentUnhealthyNodes. The node type health policy map is used only if the cluster manifest enables node type health evaluation using the configuration entry for HealthManager/EnableNodeTypeHealthEvaluation. For example, given a cluster with many nodes of different types, with important work hosted on node type "SpecialNodeType" that should not tolerate any nodes down. You can specify global MaxPercentUnhealthyNodes to 20% to tolerate some failures for all nodes, but for the node type "SpecialNodeType", set the MaxPercentUnhealthyNodes to 0 by setting the value in the key value pair in NodeTypeHealthPolicyMapItem. The key is the node type name. This way, as long as no nodes of type "SpecialNodeType" are in Error state, even if some of the many nodes in the global pool are in Error state, but below the global unhealthy percentage, the cluster would be evaluated to Warning. A Warning health state does not impact cluster upgrade or other monitoring triggered by Error health state. But even one node of type SpecialNodeType in Error would make cluster unhealthy (in Error rather than Warning/Ok), which triggers rollback or pauses the cluster upgrade, depending on the upgrade configuration. Conversely, setting the global MaxPercentUnhealthyNodes to 0, and setting SpecialNodeType's max percent unhealthy nodes to 100, with one node of type SpecialNodeType in Error state would still put the cluster in an Error state, since the global restriction is more strict in this case. - `Key` string, required — The key of the node type health policy map item. This is the name of the node type. - `Value` integer, required — The value of the node type health policy map item. If the percentage is respected but there is at least one unhealthy node in the node type, the health is evaluated as Warning. The percentage is calculated by dividing the number of unhealthy nodes over the total number of nodes in the node type. The computation rounds up to tolerate one failure on small numbers of nodes. The max percent unhealthy nodes allowed for the node type. Must be between zero and 100. - `Context` ChaosContext — Describes a map, which is a collection of (string, string) type key-value pairs. The map can be used to record information about the Chaos run. There cannot be more than 100 such pairs and each string (key or value) can be at most 4095 characters long. This map is set by the starter of the Chaos run to optionally store the context about the specific run. - `Map` unknown - `ChaosTargetFilter` ChaosTargetFilter — Defines all filters for targeted Chaos faults, for example, faulting only certain node types or faulting only certain applications. If ChaosTargetFilter is not used, Chaos faults all cluster entities. If ChaosTargetFilter is used, Chaos faults only the entities that meet the ChaosTargetFilter specification. NodeTypeInclusionList and ApplicationInclusionList allow a union semantics only. It is not possible to specify an intersection of NodeTypeInclusionList and ApplicationInclusionList. For example, it is not possible to specify "fault this application only when it is on that node type." Once an entity is included in either NodeTypeInclusionList or ApplicationInclusionList, that entity cannot be excluded using ChaosTargetFilter. Even if applicationX does not appear in ApplicationInclusionList, in some Chaos iteration applicationX can be faulted because it happens to be on a node of nodeTypeY that is included in NodeTypeInclusionList. If both NodeTypeInclusionList and ApplicationInclusionList are null or empty, an ArgumentException is thrown. - `NodeTypeInclusionList` NodeType[] — A list of node types to include in Chaos faults. All types of faults (restart node, restart code package, remove replica, restart replica, move primary, and move secondary) are enabled for the nodes of these node types. If a node type (say NodeTypeX) does not appear in the NodeTypeInclusionList, then node level faults (like NodeRestart) will never be enabled for the nodes of NodeTypeX, but code package and replica faults can still be enabled for NodeTypeX if an application in the ApplicationInclusionList. happens to reside on a node of NodeTypeX. At most 100 node type names can be included in this list, to increase this number, a config upgrade is required for MaxNumberOfNodeTypesInChaosEntityFilter configuration. - `ApplicationInclusionList` ApplicationName[] — A list of application URIs to include in Chaos faults. All replicas belonging to services of these applications are amenable to replica faults (restart replica, remove replica, move primary, and move secondary) by Chaos. Chaos may restart a code package only if the code package hosts replicas of these applications only. If an application does not appear in this list, it can still be faulted in some Chaos iteration if the application ends up on a node of a node type that is included in NodeTypeInclusionList. However, if applicationX is tied to nodeTypeY through placement constraints and applicationX is absent from ApplicationInclusionList and nodeTypeY is absent from NodeTypeInclusionList, then applicationX will never be faulted. At most 1000 application names can be included in this list, to increase this number, a config upgrade is required for MaxNumberOfApplicationsInChaosEntityFilter configuration. - `Status` 'Invalid' | 'Running' | 'Stopped' — Current status of the Chaos run. - `ScheduleStatus` 'Invalid' | 'Stopped' | 'Active' | 'Expired' | 'Pending' — Current status of the schedule. ## Other responses - `default` — The detailed error response. --- [API](https://skmtc.net/azure/apis/servicefabric-servicefabric.md) · [All operations](https://skmtc.net/azure/apis/servicefabric-servicefabric/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/azure/servicefabric-servicefabric/versions/6ebed3032b57/schema)