Chapter 7 — Web3, blockchain and cryptoasset security: data and telemetry
Lesson map
Lesson 07 published. Map, example, EX025.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Telemetry sources"]
N2["7.2 Collecting metrics"]
N3["7.3 Storing telemetry safely"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX025"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Telemetry sources"]
N2["7.2 Collecting metrics"]
N3["7.3 Storing telemetry safely"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX025"]
[Learning outcomes]
|
v
[7.1 Telemetry sources]
|
v
[7.2 Collecting metrics]
|
v
[7.3 Storing telemetry safely]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX025]
Learning outcomes
You will (1) identify useful telemetry sources; (2) collect node and ledger metrics; (3) store telemetry safely.
7.1 Telemetry sources
Telemetry is the stream of data that shows how a system is behaving. For the library Aiko identifies sources: node metrics such as block height, peer count and resource use; ledger events such as transfers, locks, releases and role changes; application logs from the reservation and deposit services; and server logs for logins and system changes. She lists each source, how to read it and how often. Good telemetry lets technicians see problems early. Without it, the first sign of trouble is usually a borrower complaining at the counter.
7.2 Collecting metrics
Aiko writes a read-only collector that every minute records each node's block height, peer count, disk use and memory, and every hour exports new ledger events. Results go to the monitoring server with timestamps. She keeps collection light so it does not overload the nodes, having learned that heavy polling can itself slow a service. She tests the collector on the test ledger before using it on live nodes. Collected metrics become the input for alerts, reports and troubleshooting in later chapters of her course.
7.3 Storing telemetry safely
Telemetry can contain sensitive information, such as borrower addresses linked to loans. Aiko stores it on the monitoring server with access limited to technicians and the manager, keeps detailed events for ninety days and summaries for two years, and does not copy personal data from the database into telemetry. Logs are protected from alteration by writing daily hashes. Mr Kowal explains that telemetry is evidence, so it must be kept safely and for long enough to investigate, but not longer than needed for privacy.
Worked example
Aiko collects node metrics every minute and events hourly, stores detail for ninety days with restricted access and writes daily log hashes.
Synthetic case. The telemetry design is synthetic.
Errors and limits
Polling nodes too heavily for telemetry can slow the service being monitored.
Exercises
- EX025 — Telemetry source. Name one telemetry source. Rubric: 3 = node metrics such as block height;; 2 = ledger events;; 1 = weather data;; 0 = none.
- EX026 — Collection frequency. How often are node metrics collected? Rubric: 3 = every minute;; 2 = each minute;; 1 = yearly;; 0 = none.
- EX027 — Detail retention. How long are detailed events kept? Rubric: 3 = ninety days;; 2 = 90 days;; 1 = forever;; 0 = none.
- EX028 — Log protection. How are logs protected from alteration? Rubric: 3 = daily hashes;; 2 = hashing;; 1 = vague;; 0 = none.
Synthesis
Well-chosen, lightly collected and safely stored telemetry shows how a ledger behaves.
Continue studying — chapter 07 of 18
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →