How should signals be injected into config objects?

[sdboyer]

Signals are top-level objects in the polly schema, not owned by any particular config type from another system. The premise of signals is basically:

1. Observability is a data science, data is king
2. Queries are the way we get data
3. Abstract over "querying" in general, into the smallest possible unit
4. Reuse that abstraction across config objects
5. (...profit)

The question is that fourth item: how exactly do we inject signals into the various types of config objects polly supports?

The initial pass at polly spec defines (item 3) a signal this way:

Signal: {
	// The name of the signal. TODO constrain with regex
	name: string
	// lang indicates the language in which the query is written.
	lang: string
	// params is the set of parameters taken by the signal.
	params: {...}
	// query is the actual query string, including parameter variables that
	// need to be interpolated.
	query: string
}

There's a level to this question that's similar to #3 - what is the literal form of the CUE that constitutes 'passing in' a signal? - but also a deeper level, which deals with translating the above form into the form that is valid with respect to the schema of a particular config object. For example, if we want to make a Prometheus alert out of a signal, how exactly do we map the fields of the signal to the fields in an alert config object?

Two things are crystal clear to me at this point:

• There'll be two fundamental, not-mutually-exclusive ways of "passing a signal":
  • By translating to the native form supported by the config object (like that Prom alert example)
  • By building native support for working with signals in the config object itself. This is reasonable, if not straight up preferable, for a system like Grafana.
• Different config object types will need to be able to express a constraint on what they accept in the signal's lang field (e.g., Prometheus rules/alerts will necessarily only accept promql)

My guess is that the biggest question marks here are going to relate to signal parameters, and quickly back to the more general problem of parameter handling. Figuring out the standard way of exposing and ingesting parameters - and especially translating that to other consumption toolchains - is going to be its own thing, but it figures in significantly here. Mapping logic is logic, and the Consume phase generally treats that as the job of the toolchain, not the polly package itself. Maybe we'll have to muck around with that a bit!

I hope to use this thread to discuss possible syntaxes for the "translating" approach described above, with an eye to:

• What a particular approach would look like in the polly schema
• What different approaches might entail for how parameter injection is supposed to work
• What the impact of having mapping logic on the consumption toolchain might be