Wondering about the relation of monitoring, logging and minio charts to MLA

[almereyda]

I'm also always wondering about the relation between the monitoring, logging and minio charts and the mla repository. Right now I'm just installing all of this, but maybe I don't need to?

• https://docs.kubermatic.com/kubermatic/v2.20/architecture/support_policy/kkp_components_versioning/

This (manually generated) list suggests that the monitoring and logging components of KKP are an integral part of it.

Now there's also metering involved with the seeds, and KubeOne also knows a metrics-server, and now I'm completely lost. A whole ecosystem architecture map for KubeOne and Kubermatic, extending from the Architecture documents in the docs with few more topology examples, could help here.

We're already having a hard time in kubermatic/dashboard#4737 understanding each other's perception about a useful modularity of the documentation components, which may very well reflect intrinsic contradictions within the parts they describe, too. There, MLA is arguably a core component of a working Installation.

[embik]

I'm not sure how much it clears up things, but the various charts within KKP (monitoring and logging) are part of the Master / Seed MLA setup. This is to monitor KKP and its components itself. The installation instructions for that are linked from the general installation instructions as further steps, but it's optional. You don't need to install this if you do not want to monitor KKP. KKP works without it.

The "mla" repository contains the User Cluster MLA components, a feature that can be installed in addition the Master / Seed monitoring mentioned above.

Metering is explained in the docs and metrics-server is part of the core resource metrics pipeline in Kubernetes.

This (manually generated) list suggests that the monitoring and logging components of KKP are an integral part of it.

I don't think this can inferred. The page does not make any statements about whether a component is optional or mandatory, it just lists versions of components we ship in some way. It's just a bill of material, nothing more. It's a bit like the image-loader tool which doesn't make any distinction between optional or mandatory container images as well and just downloads everything for you.

[rastislavs]

Right, neither Master / Seed Cluster Monitoring Logging & Alerting nor User Cluster Monitoring Logging & Alerting are mandatory. You can install them in your KKP installation, but you don't have to.

[almereyda]

Thank you for all these details.

Okay, then I'm just confused, because some optional modules are packaged with the release (monitoring, logging, minio), which makes them feel as if one had to install them for best experience, while others come separately (mla).

Next to packaging, after our conversations this week, and with growing time that I have spent in the documentation, there actually is a logical context switch implied by sub-ordering all MLA instructions under different headlines, and thus repeating the sections.

Eventually, also to keep the individual docs sections shorter (the long list in the unfoldable sidebar to the left can be very distracting while reading) which are expanded at a given point in time, all Observability architectures, components descriptions and tutorials are worth their own section. Now I know why I felt I was jumping between unrelated things, because in the documentation they are!

Also a naming inconsistency, from calling the master/seed components MLA in the docs, but monitoring and logging in the charts, possibly due to historical reasons, which can be confusing, while user cluster MLA is called mla and could suggest it is reponsible for both roles.

• monitoring (+ alerting, which is implied) + logging = master / seed MLA (which also brings us to Decolonise language used for describing and explaining Kubermatic components #10743)
• mla = user MLA

• Taking the nomenclature from BIND (see the references in the linked discussion), one could simply say primary-mla and secondary-mla, and all'd be good. No confusion left.

Now let's take a look at the involved documentation pages/sections, and esp. at where they stand in the hierarchy presented to the left:

• https://docs.kubermatic.com/kubermatic/v2.20/architecture/monitoring_logging_alerting/master_seed/
  This page shows the sidebar content twice! Whyfore we find two multiples of the Architecture---Contribute to KKP list. Then the document appears somewhere in the third level, and I'm still distracted with many references that have nothing to do with my current area of work.
• https://docs.kubermatic.com/kubermatic/v2.20/architecture/monitoring_logging_alerting/user_cluster/
  When switching to this tab, now the navigation jumps back to normal. If it was such an optional feature, why is it explained in such a prominent position?
• https://docs.kubermatic.com/kubermatic/v2.20/tutorials_howtos/monitoring_logging_alerting/master_seed/installation/
  Oh, where was I again? Now there's so much noise to the left, that I almost forget how I got here. What did I want to do? Why does this page ('s navigation) look like every other('s)? Where am I, and how have I come here?

  • This is where we hint at the possibility of displaying backlinks between pages, in order to visualise their internal, non-hierarchic link relations.

If these came in their own section, their URLs would read:

• https://docs.kubermatic.com/kubermatic/v2.20/monitoring_logging_alerting/primary_seed/architecture/
• https://docs.kubermatic.com/kubermatic/v2.20/monitoring_logging_alerting/primary_seed/installation/
• https://docs.kubermatic.com/kubermatic/v2.20/monitoring_logging_alerting/secondary_user/architecture/

And to adapt that even further to the new naming scheme:

• https://docs.kubermatic.com/kubermatic/v2.22/monitoring-logging-alerting/primary-seed/architecture/
• https://docs.kubermatic.com/kubermatic/v2.22/monitoring-logging-alerting/primary-seed/installation/
• https://docs.kubermatic.com/kubermatic/v2.22/monitoring-logging-alerting/secondary-user/architecture/

That these pieces of architecture + tutorial documents are logically related is not only obvious through you mentioning them in a row, but also through the chapter cover pages:

• https://docs.kubermatic.com/kubermatic/v2.20/tutorials_howtos/monitoring_logging_alerting/master_seed/
• https://docs.kubermatic.com/kubermatic/v2.20/tutorials_howtos/monitoring_logging_alerting/user_cluster/

When browsing deep in the hierarchy, e.g. at

• https://docs.kubermatic.com/kubermatic/v2.20/tutorials_howtos/monitoring_logging_alerting/user_cluster/user_guide/

we're also already in the fourth level of the document tree, and many things will be shown to me to the right, which are not related to the current subject on my mind.
Either it would be possible to fold the long stretch away, or to only show the subsections of two levels up, in this case everything in MLA. If it was it's own primary category, that would be given.

• For all these cases, it is also important to mention that there are no breadcrumbs.

[almereyda]

As a closing remark, if one also considered Telemetry together with the above, everything "Monitoring, Logging, Alerting" could very well sit below an Observability headline and be called like that:

As a maintainer of a root cluster, I need an observability stack, in order to monitor metrics, aggregate logs and alert the team when something is off. (monitoring (+ alerting), logging)

As a maintainer of a seed cluster, I need an observability stack for the user clusters, in order to monitor the metrics, aggregate the logs and alert the team based on rules. (mla (+ mla-system))

As a maintainer of a user cluster and deployer of applications, I need an observability stack, in order to trace individual requests from ingress through to my application's code paths, and back to egress. (telemetry)

Then it's also clear why it comes after installation, but before "Tutorials & How-tos". (Which in itself is quite a Germanism, am I right? "Tutorials" seemed enough here, too.)