-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blog on What's new in Network Observability 1.6 #71
base: main
Are you sure you want to change the base?
Conversation
Work in progress: Added "Graphs and Logs Without Loki and Storage"
blogs/whats_new_1.6/index.md
Outdated
- cidrs: | ||
- 10.129.0.73/32 # provide a name for this host | ||
name: querier | ||
openShiftAutoDetect: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As said in the bug you reported ( https://issues.redhat.com/browse/NETOBSERV-1734 ) I don't see why you need to disable the auto-detect. If it's because the CIDR that you defined is in the cluster subnets, hence overlapping with the the auto-detected ones, maybe you could use a different example, with a cluster-external workload?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to use an external cidr example.
Thanks @stleerh , love it! One thing missing and I think it's important to mention, is the global performance improvement, it's significative, especially on the CPU |
@jotak I did not do 1.5 vs 1.6 comparison per se, except one was auto-done for ingress perf, it's same as you've in this sheet. We could use this sheet to find 1.6 baselines for node-density and cluster-density baselines as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks great, thanks @stleerh
|
||
Network Observability 1.6 was released on June 17, 2024. Even though this is considered a minor version upgrade from 1.5, it is a significant release that could lower the barrier to adoption into production. | ||
|
||
But before we go further, for those of you new to Network Observability, NetObserv, for short, is an optional operator that provides a slew of capabilities to track and provide insight into your network traffic flows. While it works on any Kubernetes cluster, it works even better in an OpenShift environment, which is what I will focus on in this article. I will only discuss the new features in this release so if you want the full feature list, read the documentation on [About Network Observability](https://docs.openshift.com/container-platform/4.16/observability/network_observability/network-observability-overview.html). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we still say that netobserv is an operator or start saying that it's a set of tools ? 🙃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to leave it as operator and then when Network Observability CLI becomes GA, let's revisit!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few mostly copy edits! Really nice work, Steven!!
blogs/whats_new_1.6/index.md
Outdated
|
||
By default, Loki is enabled so set **Enable** to false. That's it! | ||
|
||
There is one other note worth mentioning. Even if you do install Loki, by default, it will favor using the metrics instead of Loki for querying whenever possible. By doing this, not only will it be faster, but it will be possible to query data over a period of weeks or months. This behavior can be changed under **Prometheus**, **Querier** in the **Enable** setting (Figure 4). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is one other note worth mentioning. Even if you do install Loki, by default, it will favor using the metrics instead of Loki for querying whenever possible. By doing this, not only will it be faster, but it will be possible to query data over a period of weeks or months. This behavior can be changed under **Prometheus**, **Querier** in the **Enable** setting (Figure 4). | |
There is one other note worth mentioning. Even if you do install Loki, by default, the Network Observability Operator favors using the metrics instead of Loki for querying whenever possible. By doing this, not only is the Operator experience faster, but it is also possible to query data over a period of weeks or months. This behavior is configurable in the **Prometheus**, **Querier** in the **Enable** setting (Figure 4). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few suggestions to update the future tense to present tense. Additionally, I think "it" needs to be clarified to "Network Observability Operator".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made most of the changes. It's not the Network Observability Operator that's doing this; it's technically the NetObserv console plugin, but I rather not say that. I will refer to it as Observe > Network Traffic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood, and that makes sense. Thank you!
@jotak Were there other changes that were made in 1.6 not mentioned that gave us this global performance improvement? |
This one is significant: https://issues.redhat.com/browse/NETOBSERV-559 (BPF maps reading optimization) |
Open issues: