Blog on "What's new in Network Observability 1.10" #30
Conversation
|
🚀 PR Preview for netobserv.io has been successfully deployed! |
|
|
||
| ## FlowMetric Setup UI | ||
|
|
||
| Like the FlowCollector Setup, there is a new 4-step wizard for FlowMetric Setup. The FlowMetric CRD lets you define your own custom metrics. The four steps are **Overview**, **Metric** to define the metric name and type, **Data** to specify the direction and filters, and a **Review** panel before applying the change. Figure 6 shows what the first step looks like. The other steps are not shown. |
There was a problem hiding this comment.
That feels a bit strange 🤔
If you don't want to cover all the screens, let's just remove the step 1 and keep a small sentence here.
There was a problem hiding this comment.
Or perhaps say something like "we won't go into the details as these steps should be self-explanatory" ?
There was a problem hiding this comment.
I added the description. There is one image for the FlowCollector wizard and another for the FlowMetric wizard. The image contains all four steps.
|
|
||
| ## Technology Preview: Network Health Dashboard | ||
|
|
||
| The second Technology Preview is a network health dashboard. Using the same environmental variable, EXPERIMENTAL_ALERTS_HEALTH, as Custom Alerts (see listing above), it also enables this feature. |
There was a problem hiding this comment.
| The second Technology Preview is a network health dashboard. Using the same environmental variable, EXPERIMENTAL_ALERTS_HEALTH, as Custom Alerts (see listing above), it also enables this feature. | |
| The second Technology Preview is a network health dashboard. The environmental variable, EXPERIMENTAL_ALERTS_HEALTH, used for Custom Alerts (see listing above), also enables this feature. |
Would this be better?
There was a problem hiding this comment.
I changed it slightly.
The same environmental variable, EXPERIMENTAL_ALERTS_HEALTH, also used for Custom Alerts (see listing above), enables this feature.
|
Some nits, otherwise LGTM |
| privileged: true | ||
| ``` | ||
|
|
||
| Underneath the covers, it is creating a PrometheusRule object. To see what that looks like, enter `oc get prometheusrules -n netobserv -o yaml`. If you want to change some of the thresholds or the duration for these alerts, edit these rules with `oc edit prometheusrules -n netobserv`. If you get really ambitious, you can even write your own custom alerts! |
There was a problem hiding this comment.
If you want to change some of the thresholds or the duration for these alerts, edit these rules with
oc edit prometheusrules -n netobserv
That's not the correct way to do it, and changes there could be overwritten after a reconcile event. The correct way is to configure it through the FlowCollector, for example:
apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
name: flow-collector
spec:
processor:
metrics:
alerts:
- template: PacketDropsByKernel
variants:
# triggered when the whole cluster traffic (no grouping) reaches 10% of drops
- thresholds:
critical: "10"
# triggered when per-node traffic reaches 5% of drops, with gradual severity
- thresholds:
critical: "15"
warning: "10"
info: "5"
groupBy: Node(the example comes from @gwynnemonahan doc here, all available templates are listed there)
There was a problem hiding this comment.
That's too bad you can't edit it directly. I changed the text to refer to the doc.
There was a problem hiding this comment.
it's still possible to edit the resulting rule if you set it as unmanaged
But the whole point here was to avoid users having to dig into the promql, which can be complex
4 participants
No description provided.