Create admin guide#3526
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/hold |
|
/assign |
vaikas
left a comment
There was a problem hiding this comment.
Thanks!! Couple of small things.
| - /docs/serving/metrics/#admin | ||
| --- | ||
|
|
||
| Administrators can monitor the Knative Serving control plane by looking at the metrics exposed by each Knative Serving component. |
There was a problem hiding this comment.
well :) reading through these, maybe both control and dataplane? Which makes me think if they should be grouped then differently? Thinks like Controller / Webhook vs. Activator. I think some of these are more applicable for the Application developer vs. cluster admin, but just jotting it down and get somebody from serving to help :)
There was a problem hiding this comment.
Yes, always jot it down, this is all good context 😄
Is there a description of control vs dataplane anywhere that we can reuse, or can we create a blurb about each of those to explain the difference in the metrics topics? @skonto is explaining the difference between these something you could help with?
There was a problem hiding this comment.
Updated these to say data plane and control plane, can you open a follow up issue to improve these docs maybe please and loop in SMEs so we're not blocking the PR on this?
omerbensaadon
left a comment
There was a problem hiding this comment.
/lgtm
Peppered in a few references to what things would look like in mkDocs 👍🏼
This is an awesome start to make your Miro 🍝 vision into a reality.
|
|
||
| The default configuration will classify logs into: | ||
|
|
||
| - Knative apps, or pods with an `app=Knative` label |
There was a problem hiding this comment.
I think it's the same difference but I didn't write this, I'd imagine @skonto did maybe, I just cleaned it up, so let's get his opinion before we change any wording relating to components?
There was a problem hiding this comment.
I didnt write this part but I think using services is more precise, although this label is used in different places and seems a bit confusing to me eg. serving controller.
evankanderson
left a comment
There was a problem hiding this comment.
Thanks for doing this!
There are a couple places where our docs weren't in optimal places before (that you couldn't have known about, because the doc didn't say); I've left some suggestions on content reorganization that this PR made clear because of that.
Other than that, this looks great, thank you very much!
|
|
||
| * [Knative Eventing](../eventing/): Easily route events between on-cluster and off-cluster components by exposing event routing as configuration rather than embedded in code. | ||
|
|
||
| These components are delivered as Kubernetes custom resource definitions (CRDs), which can be configured by a cluster administrator to provide default settings for developer-created applications and event workflow components. |
There was a problem hiding this comment.
I think there's also some common configuration options for administrators around telemetry (config-logging, config-observability) that should probably move to the admin guide:
https://knative.dev/docs/install/collecting-metrics/
https://knative.dev/docs/install/collecting-logs/
(I'm not quite sure what to do with the "here's a local-logs-collection solution" at the end of the second; probably turn it into something real or go back and delete it.)
There was a problem hiding this comment.
Nevermind, it looks like you did this. Do you want to mention "common configuration options" as another section here, or just rely on the left-hand nav?
There was a problem hiding this comment.
I don't want to add a bunch of links to maintain really until things settle down a bit with moving stuff, but for now I've added the contents list back to the page; does that work for you?
| weight: 50 | ||
| type: "docs" | ||
| aliases: | ||
| - /docs/install/collecting-logs |
There was a problem hiding this comment.
Do we want to make "logs" a top-level next to "install", add a "configuration" sub-tree to hold all the configuration, or have a "common" sub-tree to hold configuration that's common to Serving and Eventing (off the top of my head, the high-availability configuration, logging, and monitoring)?
(I'm trying to avoid the "too many items at one level in the LHS navigation" problem we have today.)
There was a problem hiding this comment.
Can you add this as a suggestion to the Miro doc please so I can see better what you're saying / how this fits in?
We can follow it up in another PR if we want to move this
|
New changes are detected. LGTM label has been removed. |
|
/lgtm 👍🏼 |
|
FYI: This PR build is failing with: |
@abrennan89 This should fix the broken builds: knative/website#297 |
|
@abrennan89: PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
A lot of this work will be negated by the new docs structure and things like the getting started, so I'm just going to start working on the mkdocs branch instead and close this PR. |
Part of #3525