Plan

[plajjan]

Targets and considerations

• fix compilation speed, development is really PITA now with > 10 minute compilation
• need to "work around" GC
  • current GC is rather slow, we need to make the best of the situation
  • we will not be able to replace the GC during this project (before end of 2023)
  • thus, we must work with the GC we have and it might mean that our design will be influenced by the constraints of our GC, primarily by reducing heap size
  • for example, we are considering minimizing use of schema since it keeps down the heap size and thus means the GC can run faster
  • we have some room for improvement, probably more in 2x range, not 10x or so
  • incremental & generational GC
  • use GC_MALLOC_ATOMIC to mark memory as not containing pointers so GC does not have to scan them internally
    • this can be used for our bytes, str etc
• interface with NSO
  • need to read out configuration
  • config includes what devices to talk to, what protocol to use and what paths to collect (poll or subscribe using streaming telemetry)
  • initial implementation
  • eventually we want to be reactive, using CDB subscriber or kicker to get the data as it change
  • need to write oper data to NSO
  • define YANG model specifying subscriptions & triggers
• pick TSDB
  • requirements:
  • fast, high volume of inserts and relatively high read rate (depends on support for continuous queries)
  • high cardinality
    • ballpark: 25 million residential connections with 40 counters per connection = 1 billion metrics, so we want to support in the billions of time series
  • preferably redundant
  • preferably support continuous queries, alternatively we need to run queries rather frequently to emulate continuous queries
  • some options:
  • M3
  • VictoriaMetrics
  • Druid
  • Prometheus
  • InfluxDB likely has cardinality problem
• interface with TSDB
  • Prometheus, M3, VM all support PromQL for queries and Prometheus remote write API for writes, so that's a quite good starting point
  • PromQL & prom remote write is HTTP based
• implement HTTP(s)
  • new http module in acton stdlib
  • needs TLS for https support
• implement TLS
  • include OpenSSL in Acton
  • build https support
• implement SNMP
  • libsnmp?
• support IP types in Acton, add some new ipaddr or similar module to support IP addresses and conversion functions
  • currently some ext.c style in acton-streamer for checking ipv4 and ipv6 types

[plajjan]

Most of the items here are fixed. Compilation time is now in seconds-range, which is OK. We are using M3DB as TSDB. We read config from NSO via CDB subscribers. We have a HTTPS library in acton stdlib.

SNMP is not implemented but we do not need it right now.

We haven't done much on GC end but I think we're sort of OK for now.

It's better we open smaller and more specific issues going forward.