influxdata / influxdata/kapacitor
kapacitor show DOT graph: map source code to labels somehow
- Dominant language
- Go
- Stars
- 2.4k
- Forks
- 479
- Avg merge
- 4d 16h
- Merged PRs (30d)
- 4
Description
I've got a script, and `kapacitor show` produces the following DOT graph:
```
DOT:
digraph api_error_count {
graph [throughput="0.00 points/s"];
stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="141"];
from1 [avg_exec_time_ns="3.261µs" errors="0" working_cardinality="0" ];
from1 -> where2 [processed="141"];
where2 [avg_exec_time_ns="20.092µs" errors="44" working_cardinality="6" ];
where2 -> count3 [processed="0"];
count3 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
count3 -> where4 [processed="0"];
where4 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
where4 -> alert5 [processed="0"];
alert5 [alerts_triggered="0" avg_exec_time_ns="0s" crits_triggered="0" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="0" working_cardinality="0" ];
}
```
This graph is the most obvious way to see how data is moving through the system and where errors may be occurring. It's not that hard to map it back to the source code -- but this is a pretty simple script, with only two `where` clauses and one alert.
In contrast, I have another, not terribly complex script, and here's a fragment of the DOT graph:
```
alert12 [alerts_triggered="0" avg_exec_time_ns="0s" crits_triggered="0" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="0" working_cardinality="0" ];
alert12 -> where13 [processed="0"];
where13 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
where13 -> influxdb_out14 [processed="0"];
influxdb_out14 [avg_exec_time_ns="0s" errors="0" points_written="0" working_cardinality="0" write_errors="0" ];
alert9 [alerts_triggered="0" avg_exec_time_ns="0s" crits_triggered="0" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="0" working_cardinality="0" ];
alert9 -> where10 [processed="0"];
where10 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
where10 -> influxdb_out11 [processed="0"];
influxdb_out11 [avg_exec_time_ns="0s" errors="0" points_written="0" working_cardinality="0" write_errors="0" ];
stats28 [avg_exec_time_ns="24.409µs" errors="0" working_cardinality="0" ];
stats28 -> derivative30 [processed="41"];
derivative30 [avg_exec_time_ns="2.681µs" errors="0" working_cardinality="2" ];
derivative30 -> alert31 [processed="39"];
alert31 [alerts_triggered="6" avg_exec_time_ns="2.982725ms" crits_triggered="3" errors="0" infos_triggered="0" oks_triggered="3" warns_triggered="0" working_cardinality="2" ];
```
Mapping each node back to a line number at a minimum would help a lot. Including the whole source snippet that the related node encompasses would be awesome, though I'd expect that to be harder to manage.
OS: Ubuntu 16.04, x86_64
Kapacitor OSS 1.4.1 (git: HEAD b05bb0f6be089d6a1a391867ad4020344ce42a53)
Contributor guide
Research direction
Start with the `kapacitor show` command and the DOT graph output it produces. Trace how graph nodes are generated and determine how source locations could be associated with them. Done means the graph provides at least line-number mapping back to the TICKscript, with any broader source-snippet support defined and tested.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100