Document logging architecture

[QuentinBisson]

What this PR does / why we need it

Closes https://github.com/giantswarm/giantswarm/issues/29776#issue-2122988280

This documentation explains what our logging architecture is

Things to check/remember before submitting

• If you made content changes

  • Run make dev to render and proofread content changes locally.
  • Bump last_review_date in the front matter header if you reviewed the entire page.

[QuantumEnigmaa]

Just personal suggestions, don't feel obliged to apply those :)

[QuentinBisson]

Thanks for the review @stone-z :) I always love a native speaker's nitpicking :)

[lyind]

Awesome docs 👍

Minor suggestions

[lyind]

Suggested change

	The loggings agents that we have deployed on both management and workload clusters currently send the following logs to Loki:
	The logging agents that we have deployed on both management and workload clusters currently send the following logs to Loki:

[marians]

Loki should be spelled Loki (uppercase L) everywhere.

[QuentinBisson]

Thanks @marians, it's fixed

[AndiDog]

This doesn't tell the customer much why it's helpful for them. What are operational purposes? Does that mean they or only we can make use of it? I'd recommend shortening this intro, include customer-relevant points and only describe what's important to them. I assume that customers can make use of the MC Grafana instance (see existing article How to access Grafana which btw has a misspelled title it's/its) and therefore we should strongly hint here why the architecture is important for customers (e.g. long-term storage, persistence, easy access via Grafana UI, ...) but not go into extensive detail or opinions ("the full Elastic stack is obviously out of the question").

@pipo02mix I'm very unclear what was discussed around vintage docs. Shouldn't we start from scratch rather than editing existing docs? If so, we'd better revamp the whole thing and go through the "battle card" preparation before writing full articles. Since I'm unclear about this, I'd like to have it clarified first and will stop my review here for now.

[QuentinBisson]

I may be biased but operational purposes is quite straightforward to me. We need it to operate our platform and those 2 sentences have the same meanings.
I am not talking about the customer use yet here, only that they can access it via grafana.

Now, maybe the why we use Loki instead of Grafana could be somewhere else, I wrote this under the after some discussions with @carillan81 and @pipo02mix .

The goal of this doc is to show what we have and show our expertise but maybe the battlecard approach was missed.

Regarding the structure, I put this under vintage for now because of the full revamp being done and I have no issues moving it and refining the content later on with said battlecard, but in the mean time, I think this type of doc is useful and needs to be there. I could be wrong also but it's still better than having nothing at the moment at least

[AndiDog]

Agreed – I was writing my direct thoughts to challenge and make everyone think if everything still fits what we have here. We should check from scratch which pieces we put where, and if we can make it all shorter to increase chances of reading these articles. For example, does it fit into introductional, instructional or rather advanced parts of our docs, etc.?

[QuentinBisson]

I'm always happy with any feedback :)

[marians]

I didn't expect new content to be added to the /vintage folder. Slightly confused now.

[QuentinBisson]

@marians I added it under vintage because to me, the new structure is not complete. There are no entries there yet and we needed that documentation finished to close our logging epic

[pipo02mix]

I am working to have a second-level hierarchy done to start moving/adapting content. PRs are up so I would be happy to see more reviews 🙏