Bot Group: Database

Example Database, to simulate requests that can back up and timeout if in a degraded state or too much traffic

Bots

Select one of the bots to see Sireus working on an individual agent level, which is where the scoring and Actions take place.

Name States
sireus Attack Risk.Default, Operation.Escalate, Traffic.Default

Configuration Data

For the purpose of the demo, these are not editable, but that will be added after the Design RFC is complete.

This is the configuration data that creates the Sireus Decision System.

Queries

Queries collect metrics from Prometheus, so we can populate variables.

Name Query Server Info
Database Wait Queue demo_req_queue_wait{bot_group="Database"} prometheus_primary Current waiting requests
Database Timeouts irate(demo_req_timeout{bot_group="Database"}[30s]) prometheus_primary Rate of timeouts over time
Database Processed irate(demo_req_success{bot_group="Database"}[30s]) prometheus_primary Rate of successful requests over time

Variables

Variables population has two phases, extracting from Queries, and synthesizing new variables by evaluating expression on from queried variables.

Name Type Query Name Query Key Range Start Range End Invert
wait_queue Database Wait Queue 1 1 false
timeout_rate Database Timeouts 1 1 false
processed Database Processed 1 1 false
request_problem 1 1 false

States

States are specialized State Machines, they only go forward or reset. They can skip entries forward. The combination of several state pipelines allows us a lot of expression about what the current state of the operational system is.

Only moving forward or resetting removes inner loops of the state machines where it can be stuck. The entire state pipeline is a loop that will find the appropriate state on reset.

Name Info States
Operation Basic operational states, to group Actions Default, Problem, Evaluate, Escalate, EscalateWait
Traffic What does our traffic situation look like? Default, High, Low, None
Attack Risk What is the likelihood we are under attack now? Default, Low, High, Critical

Lock Timers

Lock Timers can be required by Actions before they can run, so you can lock concurrency, and are given a timeout so that they will always unlock later, and the system never gets stuck.

Name Type Info
Single Bot Lock 1 Per bot lock, so that each bot can operate independently. Use for Node or Agent level control.
Full Bot Group Lock 0 Lock for controlling the entire Bot Group. Use for Service or Platform level control.