How many kinds of data should be displayed here? Could we show those props one by one in a single page just like php.ini?
I will focus on the frontend side, and will provide the UI for this feature once this mail's discussion has completed. Chao Zhang <[email protected]> 于 2020年11月20日周五 下午3:04写道： > Not necessarily to add them if it’s not appropriate put here. > > Chao Zhang > https://github.com/tokers > > On November 20, 2020 at 2:58:46 PM, Zexuan Luo ([email protected]) > wrote: > > > 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 > > >
