feat(dgw): basic network monitoring

[philippelatulippe]

Introduces an endpoint monitor that checks the uptime of a list of hosts provided through a remotely-submitted configuration file. The monitor results are saved to a temporary in-memory buffer and can be fetched by means of a REST endpoint.

The monitor system is structured as an agent, meant to be driven by a third party (for example our DVLS), so the configuration is ephemeral and monitor results are deleted from the buffer after being fetched. Gateway is not itself the source of truth for the monitor configuration, and it does not persist the log entries.

Two authenticated endpoints are introduced:

• POST /jet/net/monitor/config
• POST /jet/net/monitor/log/drain

Example requests for testing:

curl -v http://127.0.0.1:7171/jet/net/monitor/config \
    --json '{"monitors":[{"id":"monitor1","probe":"ping","address":"localhost","interval":10,"timeout":10}]}' \
    -H "Authorization: Bearer $dgwkey"

curl  http://127.0.0.1:7171/jet/net/monitor/log/drain -X POST -H "Authorization: Bearer $dgwkey"

Remaining tasks for a basic scanner:

• We should parse the ICMP responses
• Better structuring of errors so that we can have error codes in the JSON, instead of arbitrary strings
• Upper bound on the number of log entries stored in the VecQueue

Issue: DGW-302

[github-actions]

Let maintainers know that an action is required on their side

• Add the label release-required Please cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module) when you request a maintainer to cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module)

• Add the label release-blocker Follow-up is required before cutting a new release if a follow-up is required before cutting a new release

• Add the label publish-required Please publish libraries (`Devolutions.Gateway.Utils`, OpenAPI clients, etc) when you request a maintainer to publish libraries (Devolutions.Gateway.Utils, OpenAPI clients, etc.)

• Add the label publish-blocker Follow-up is required before publishing libraries if a follow-up is required before publishing libraries

[CBenoit]

issue: Should not be part of the public API.

Suggested change

	pub struct MonitoringLogResponse {
	pub(crate) struct MonitoringLogResponse {

(Or private, but you may need that in the openapi declaration.)

[CBenoit]

Good job! I just did a very high level review, I’ll look at the details of your crate later 🙂

[allan2]

Nice PR! I left some notes.

I'd also suggest running cargo clippy -p network-monitor and fixing the lints.

[allan2]

Add #[cfg(test)].

[philippelatulippe]

This mock is created by the mock function in DgwState, which is not gated in this way. I'm not sure why though, maybe it should be? @CBenoit

[CBenoit]

The one in Devolutions Gateway is #[doc(hidden)] to express a similar intention, but if we gate with #[cfg(test)], then the function is not available for the integration tests…
It’s not ideal though, I don’t really like that. But for the purpose of getting stuff done, I would say that it’s not a big deal, and we can surely do something about that later

[CBenoit]

note: While .into() is concise, I strongly discourage its use in non-generic, concrete code because it obscures intent. Prefer TargetType::from(source_value):

• The destination type is explicit at the call site.
• It immediately signals that a conversion is taking place and to which type.
• It removes the need for type inference and reduces coupling to surrounding context, aiding readability and future refactoring.

.into() is better reserved for generic contexts or builder-style code where the target type is already constrained. Outside of those, the clarity benefit of from() is worth the extra characters.

[CBenoit]

Highlighting this comment: https://github.com/Devolutions/devolutions-gateway/pull/1446/files#r2242524595

suggestion: Look in the config module, there is a enable_unstable option. For now, I suggest we gate this feature behind this option, so you can freely change the API as necessary until the 2025.3 release.

[CBenoit]

praise: I see you are using the correct methods 💯

[CBenoit]

suggestion: Maybe use skip_serializing_if = Option::is_none in the serde annotations, we typically don’t bother returning null values in the rest of the API

[CBenoit]

question: By the way, I kind of remember you talked about that in the past, but I’m not entirely sure: is it really fine to not persist the configuration? I guess the idea is that if the Gateway is restarted, the monitor order must be reissued by DVLS?

[philippelatulippe]

That's the idea, given that the controlling server needs to be in regular contact with gateway, we might as well keep it stateless. But I've been meaning to ask you: does DVLS have an explicit way to know when the gateway comes online? It's not clear to me how these "Subscribers" work. If not I would have to rethink the approach.

[CBenoit]

The subscriber API is only used by Hub Business, so you can ignore all of that when it comes to DVLS. DVLS performs active polling in order to maintain a "one-directed communication" (Gateway inbound and DVLS outbound only). DVLS may never know that a Devolutions Gateway was restarted. Does that change the design in your mind?

[philippelatulippe]

Thanks for the deets, I'll bring back my code to save the config to disk in a follow-up PR then.