NETOBSERV-1322: ACM & netobserv metrics #61
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jotak
changed the title
skrthomas
reviewed
Nov 22, 2023
acm.md
Outdated
Comment on lines
9
to
11
| 1. Create 2 clusters (or more) | ||
| 2. Choose one for being the main one / hub: install ACM operator on it; Create a default MultiClusterHub | ||
| 3. In console top bar, select "all cluster" then start procedure to import an existing cluster |
There was a problem hiding this comment.
Suggested change
| 1. Create 2 clusters (or more) | |
| 2. Choose one for being the main one / hub: install ACM operator on it; Create a default MultiClusterHub | |
| 3. In console top bar, select "all cluster" then start procedure to import an existing cluster | |
| 1. Create 2 clusters (or more). | |
| 2. Choose one cluster as the main one or hub, and install the ACM operator on it. | |
| 3. Create a default MultiClusterHub. | |
| 4. In the console top bar, select "all cluster" then start the procedure to import an existing cluster. |
There was a problem hiding this comment.
A few comments about these steps:
- I think "create a default MultiClusterHub" should be its own step, or a nested step rather than a continuation of the step 3 with a semicolon.
- Is this a MultiClusterHub custom resource or Operator? I think specifying would be good.
- I'm wondering, should ACM be spelled out? Or is it an approved acronym that all readers would be familiar with? If its new, I would suggest spelling it out and putting ACM in parentheses for this first mention, then elsewhere you can just use ACM.
- Periods are needed at the end of these steps.
- I also added some "the".
acm.md
Outdated
| 3. In console top bar, select "all cluster" then start procedure to import an existing cluster | ||
|
|
||
| On each cluster: | ||
| 1. Install netobserv downstream (user workload prometheus won't work) |
There was a problem hiding this comment.
Suggested change
| 1. Install netobserv downstream (user workload prometheus won't work) | |
| 1. Install network observability operator downstream (user workload Prometheus won't work). |
|
oops I'm sorry @skrthomas I haven't been clear about that, but the |
jotak
commented
Nov 22, 2023
| @@ -0,0 +1,62 @@ | |||
| ## Setup ACM with NetObserv metrics | |||
There was a problem hiding this comment.
for reviewers: this file is just a recipe for internal purpose, not the blog post; for the blog, look at blogs/acm/leverage-metrics-in-acm.md
|
@jotak no worries at all; thanks for the context. You can disregard my ACM acronym comment in this case :) |
jpinsonneau
approved these changes
Dec 4, 2023
Co-authored-by: Julien Pinsonneau <91894519+jpinsonneau@users.noreply.github.com>
OlivierCazade
approved these changes
Dec 4, 2023
skrthomas
reviewed
Dec 4, 2023
|
|
||
| ### What is NetObserv? | ||
|
|
||
| Network Observability (NetObserv) is a Red Hat operator providing observability over all the network traffic on a cluster by installing eBPF agents per-node which generate flow logs. These flows are collected, stored, converted into metrics, queried from dashboards and so on. More observability blog posts [here](https://cloud.redhat.com/blog/tag/observability), and NetObserv documentation [there](https://docs.openshift.com/container-platform/4.14/network_observability/network-observability-overview.html). |
There was a problem hiding this comment.
Suggested change
| Network Observability (NetObserv) is a Red Hat operator providing observability over all the network traffic on a cluster by installing eBPF agents per-node which generate flow logs. These flows are collected, stored, converted into metrics, queried from dashboards and so on. More observability blog posts [here](https://cloud.redhat.com/blog/tag/observability), and NetObserv documentation [there](https://docs.openshift.com/container-platform/4.14/network_observability/network-observability-overview.html). | |
| Network Observability (NetObserv) is a Red Hat Operator providing observability over all the network traffic on a cluster by installing eBPF agents per-node which generate flow logs. These flows are collected, stored, converted into metrics, queried from dashboards and so on. More observability blog posts [here](https://cloud.redhat.com/blog/tag/observability), and NetObserv documentation [there](https://docs.openshift.com/container-platform/4.14/network_observability/network-observability-overview.html). |
blogs/acm/leverage-metrics-in-acm.md
Outdated
| - By declaring metric names to pull | ||
| - Or by declaring such recording rules | ||
|
|
||
| The former is easier to configure but in many cases, this is probably not what you want. When pulling metrics from many sources, the key concept to have in mind is [metrics cardinality](https://www.robustperception.io/cardinality-is-key/). The more metrics you configure, the bigger is the impact on Prometheus and Thanos resource usage and performance. "Cardinality" here does not refer to the number of record rules or names that we declare in this configuration - these are called _metric families_ - after all, if you look closely, we only mention four distinct metric families in this config, which isn't a lot. No, what really matters with cardinality is the distinct count of all metric families _and all their combinations of label keys and values_. |
There was a problem hiding this comment.
Suggested change
| The former is easier to configure but in many cases, this is probably not what you want. When pulling metrics from many sources, the key concept to have in mind is [metrics cardinality](https://www.robustperception.io/cardinality-is-key/). The more metrics you configure, the bigger is the impact on Prometheus and Thanos resource usage and performance. "Cardinality" here does not refer to the number of record rules or names that we declare in this configuration - these are called _metric families_ - after all, if you look closely, we only mention four distinct metric families in this config, which isn't a lot. No, what really matters with cardinality is the distinct count of all metric families _and all their combinations of label keys and values_. | |
| The former is easier to configure but in many cases, this is probably not what you want. When pulling metrics from many sources, the key concept to have in mind is [metrics cardinality](https://www.robustperception.io/cardinality-is-key/). The more metrics you configure, the bigger the impact on Prometheus and Thanos resource usage and performance. "Cardinality" here does not refer to the number of record rules or names that we declare in this configuration - these are called _metric families_ - after all, if you look closely, we only mention four distinct metric families in this config, which isn't a lot. What really matters with cardinality is the distinct count of all metric families _and all their combinations of label keys and values_. |
stleerh
reviewed
Dec 4, 2023
blogs/acm/leverage-metrics-in-acm.md
Outdated
|
|
||
| Proceed until you have created a `MultiClusterObservability` resource. | ||
|
|
||
| Before going further, makes sure the observability stack is up and running: |
examples/ACM/thanos-s3.sh
Outdated
| @@ -0,0 +1,24 @@ | |||
| #!/bin/bash | |||
|
|
|||
| if [[ "$#" -lt 1 || "$1" = "--help" ]]; then | |||
There was a problem hiding this comment.
Since two arguments are required, it should be -lt 2.
Co-authored-by: Sara Thomas <sarthoma@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Preparing blog post, and storing some examples
Preview available here: https://github.com/jotak/netobserv-documents/blob/acm/blogs/acm/leverage-metrics-in-acm.md