ktsaou

systemd-journal has amazing logs centralization capabilities. Combined with Netdata you can get a powerful logs management solution.

Journald messages have almost infinite cardinality at their labels and all of them are indexed, even if every single message has unique fields and values.

When you send journald logs to Loki, even if you use the `relabel_rules` argument to `loki.source.journal` with a JSON format, you need to specify which of the fields from journald you want inherited by Loki. This means you loose all the flexibility journald provides: indexing on all fields and all their values.

Loki generally assumes that all logs are like a table. All entries in a stream share the same fields. But journald does exactly the opposite. Each log entry is unique and may have its own unique fields.

Of course someone could use filters and relabel rules to create multiple streams of logs out of a single journald stream (never tried it), but it sounds a lot of work and again assumes you know all the possible fields beforehand.

So, Loki and systemd-journal are good for different use cases. The good thing with systemd-journal, is that you already have it and use it. It is there inside your systems.

There are ways to put syslog messages into the journals. This plugin works with whatever logs are in the journals.

Do not compare Netdata with other monitoring solutions that centralize everything to one place, or with single installation applications.

Netdata is a distributed application, and it is installed all over the place. So we needed to find a way to provide SSO.

There are a few alternatives:

1. PAM (then LDAP or a DB), but this would significantly increase the attack surface of your Network, making Netdata an ideal component to test your security. We didn't want this.

2. LDAP, similar to the above and increased complexity. Probably too complex for the average user out there, and it would over-complicate things when you need to run Netdata in private and public clouds concurrently.

We chose to provide a free service to everyone using Netdata, where we manage all this complexity and simplify the process.

Netdata Cloud uses Google SSO, Github SSO, and email verification to authenticate users. It does not store user passwords. Combined with the claiming process of the Netdata Agents:

a) it ensures you are the admin of each server you want to manage b) it verifies your identify c) it provides centralized control on who of the authenticated users has access to your servers.

What happens when you use Netdata Cloud to access a Netdata agent, is that your web browser asks from Netdata Cloud to access this Netdata agent, Netdata Cloud verifies you and if this succeeds and you have trusted the agent before, it asks the agent (via their link) to generate a unique token for you, which is sent back to your browser and is then used as an authorization bearer to access the agent directly. So, your data do not flow through Netdata Cloud. You only get a token from the agent, via Netdata Cloud.

Thanks!

How do you use it? How big infra you monitor with it?

- Integrations Marketplace - monitoring Systemd Journal logs - Easier claiming of agents - Quickly spot anomalies across the dashboard