[v1.5]-->[v2.0] Revise Health Schema

[lydia-wu]

Due Friday 2022-02-18 @12PM

For Wednesday sync with client--

• [x] Show proof of concept of Health Schema integrated into dashboard
• [x] argue for which form of Health Schema makes more sense (JSONv CSV)

For Friday sync with client--

• [x] Refine schema with 1-2 additional parameters (specified below following meeting with client)

[lydia-wu]

HealthSchema.zip

This zip has multiple versions of the health schema (a JSON file); v01 is Hayley's first build (#36), and PROD is the latest version (aka v03). In the next slice, this will be significantly pared down. For now, the file named"HealthSchema_PROD" is fully integrated with the PBI dashboard for v1.5 (find that file here #41).

[lydia-wu]

2022-02-12 @1:30PM ET

STATUS (HealthSchema_v03):

completed: proof of concept with client satisfied: v1.5 build expectations; cleared to move to v2.0 demonstrates: parameter adjustments that are reflected in the PBI v1.5 dashboard; parameter adjustments specific to file sources

NEXT STEPS (HealthSchema_v04) [DUE Wednesday 2022-02-16 @12PM ET:

pare down Health Schema.JSON to have fewer extra values and more succinct naming conventions that are scalable.

• [ ] eliminate fluff columns/information
• [ ] adjust "operand" to be more meaningful
• [ ] incorporate "message type/class"

CONSIDER from client:

• addressing the source we are watching
• can we have a unified, general operand that can be reused generically in reports (like new value expected)?
• what are the rules for actually applying this to the files/data
  • (such as unique id to key on for expecting new value over time...how to "point" to those columns and do the right thing)
  • principle: each sourcetype will typically have it's own namespace for identities. For example, the two devices in the lab can share the identity tag. But for example, comm/msg/heartbeat only applies to appreport, not networkreport.
  • example of network/event/connectnewvalueevery 10 secno more value than 1 every 10 sec...icky format, but you get the idea.
• future: these principles should make monitoring transactions more clean. Unique id's between source types.
  • (transaction is: device thing-->network event-->appreport thing-->network event Normal is that we see these 4 things happen together.)

[lydia-wu]

biosguy — Today at 2:53 PM Idea, add source type and how to locate data columns...

ThingID (like house/livingroom/fireplace/temperature)

--> from SourceTypeID (like appreport)

--> How to locate in source type (columns, etc. What substring in log line, etc.)

--> health rules (operand, parameters, etc.)