> 5) IP addresses, the IP addresses of current Pods/VM/Physical machine; > 6) state, the current instance state, can be “online”, “shutting down”, “offline”, which can be used to cooperate with the layer 4 Load balancer (e.g. LVS + Keepalived), we can provide admin APIs to set the state
Are these two fields required? IMHO, these two fields are controlled by the deployment mechanism, and the deployment mechanism can provide these info better. It would be better if APISIX only focus itself instead of doing everything. Chao Zhang <[email protected]> 于2020年11月20日周五 下午2:41写道： > Hi, there > > Currently some of our users often confuses their APISIX version, their etcd > version and etcd, > which is adverse for solving issues and debugging. > > So I think a status API is required to tell users the basic instance > information, just like “who am I”, which is useful when diagnosing > problems. > > The status page could be formatted as a JSON string so the output can be > piped with json parsers like jq, fx, > for now, basic fields should be put inside the status is: > > 1) APISIX version, version string of the APISIX instance itself, e.g. > “2.0”; > 2) etcd version, etcd cluster version, > e.g. {"etcdserver":"3.5.0-pre","etcdcluster":"3.5.0”}; > 3) id, id of the current APISIX instance; > 4) uptime, elapsed time (in seconds) since APISIX started; > 5) IP addresses, the IP addresses of current Pods/VM/Physical machine; > 6) state, the current instance state, can be “online”, “shutting down”, > “offline”, which can be used to cooperate with the layer 4 Load balancer > (e.g. LVS + Keepalived), we can provide admin APIs to set the state > subsequently; > > { > "id": "ddea4053-4ffd-4f09-b176-b8c5e919916b", > "hostname": "localhost.local", > "version": "2.0", > "state": "online", > "etcd_version": { > "etcdserver": "3.5.0-pre", > "etcdcluster":"3.5.0” > }, > "uptime": 3600, > "ip": ["10.0.2.15", "192.168.1.2"] > } > > Other fields can be appended in the future, the APISIX should add an API > (like /status) to output these data. > > So far what we discussed is limited in a single APISIX instance, when we > want to insight the whole APISIX cluster, we need to collect each status > data of APISIX instance, show them in APISIX Dashboard. > > The most tricky problem here is how does an APISIX instance upload its > status data, there are two options we may consider: > > 1. APISIX writes the status data into etcd periodically; > 2. Introduce another control plane component, let APISIX transmits > status data to it and the control plane component will write them to > etcd. > > The APISX Dashboard backend should also expose an API to output these > status data so the frontend can render and show these data. > > So in a nut shell, we have these stuffs to solve for implementing this > feature: > > - APISIX internally uploads these data (either to etcd or another > control plane component, we need further discuss) > - Implement an admin API in APISIX. > - Implement an admin API in Dashboard backend. > - Implement the Dashboard frontend web page. > > Let’s discuss it and realize it together! > > References: > > - https://www.envoyproxy.io/docs/envoy/latest/operations/admin > - https://doc.traefik.io/traefik/operations/dashboard/ > - https://docs.konghq.com/2.0.x/admin-api/#information-routes >
