-
Notifications
You must be signed in to change notification settings - Fork 8
update metrics ingestion doc #2538
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
Conversation
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Quentin Bisson <[email protected]>
@@ -68,14 +68,14 @@ spec: | |||
|
|||
No matter if you are using Helm Charts or GitOps and Kustomize, just put the ServiceMonitor CR next to your app and apply it in the same way. Once it's applied you can check either the _ServiceMonitors Overview_ or _ServiceMonitors Details_ dashboards, or just search for the new metrics ingested in your installation's Grafana to make sure that your containers are being scraped by the new monitoring agents. | |||
|
|||
__Warning:__ The ServiceMonitor needs to be labeled with `application.giantswarm.io/team: <YOUR-TEAM-NAME>` for the metrics agent to be able to discover it and start collecting metrics. | |||
__Warning:__ The ServiceMonitor needs to be labeled with `observability.giantswarm.io/tenant: <YOUR-TENANT-NAME>` for the metrics agent to be able to discover it and start collecting metrics. |
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.
We also need a warning to explain that the tenant needs to be in a grafana organization right?
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.
Good point
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.
That's done. WDYT ?
@@ -68,14 +68,14 @@ spec: | |||
|
|||
No matter if you are using Helm Charts or GitOps and Kustomize, just put the ServiceMonitor CR next to your app and apply it in the same way. Once it's applied you can check either the _ServiceMonitors Overview_ or _ServiceMonitors Details_ dashboards, or just search for the new metrics ingested in your installation's Grafana to make sure that your containers are being scraped by the new monitoring agents. | |||
|
|||
__Warning:__ The ServiceMonitor needs to be labeled with `application.giantswarm.io/team: <YOUR-TEAM-NAME>` for the metrics agent to be able to discover it and start collecting metrics. | |||
__Warning:__ The ServiceMonitor needs to be labeled with `observability.giantswarm.io/tenant: <YOUR-TENANT-NAME>` for the metrics agent to be able to discover it and start collecting metrics. | |||
|
|||
## ServiceMonitor vs. PodMonitor | |||
|
|||
In most cases, a ServiceMonitor should cover most of your monitoring use cases but it can happen on rare occasions that a container doesn't need a service to run and it doesn't make sense to create one just for the sake of monitoring it. That's when the PodMonitor comes into action. You can find a few other examples where PodMonitor makes sense [in this discussion](https://github.com/prometheus-operator/prometheus-operator/issues/3119) in the Prometheus Operator Project. |
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.
And I think we need to add a link to the podlogs?
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 saw that in the issue but I'm not sure what link we're trying to make between those 2
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 think the goal is more for navigation purposes, like if you want to also collect logs, go there kind of thing
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.
Oh ok
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.
✔️
Great work @QuantumEnigmaa @Rotfuks you might want to take a look once you're done with your exam :) |
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
…dex.md Co-authored-by: Quentin Bisson <[email protected]>
|
||
As we now support multi-tenancy for metrics, you __need__ to attribute a tenant name to your servicemonitors and podmonitors to have those routed to the adequate tenant. This means that you will have to replace the `application.giantswarm.io/team: <YOUR-TEAM-NAME>` label by the `observability.giantswarm.io/tenant: <YOUR-TENANT-NAME>` one. | ||
|
||
For now, servicemonitors and podmonitors that only have the `application.giantswarm.io/team` label are routed to the "Giant Swarm" tenant by default. |
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.
@pipo02mix where can we add service and podmonitors so vale accepts them?
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
LGTM but I'll let @Rotfuks give the green button because I know he has thoughts :) |
…dex.md Co-authored-by: Quentin Bisson <[email protected]>
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.
Alrighty, this is a great refactoring of the text! Only very few remarks here for better readability and being more precise with the consequenses of not using the right tenant :)
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
src/content/tutorials/observability/data-ingestion/metrics/_index.md
Outdated
Show resolved
Hide resolved
…dex.md Co-authored-by: Dominik Kress <[email protected]>
…dex.md Co-authored-by: Dominik Kress <[email protected]>
…dex.md Co-authored-by: Dominik Kress <[email protected]>
What this PR does / why we need it
Towards giantswarm/roadmap#3938
Things to check/remember before submitting
last_review_date
in the front matter header of the pages you've touched.