| 11 Jul 2023 |
|  mranno changed their display name from mranno#0 to mranno. | 11:57:43 |
| 12 Jul 2023 |
|  vostrelt joined the room. | 03:31:55 |
| 16 Jul 2023 |
|  Helber Maciel Guerra joined the room. | 01:04:38 |
| 17 Jul 2023 |
|  Stroker joined the room. | 07:17:01 |
| 18 Jul 2023 |
|  eumel8 changed their display name from eumel8 to eumel8#0. | 13:55:23 |
| eumel8 changed their display name from eumel8#0 to eumel8. | 13:55:24 |
| eumel8 | Hello there. Is there a way for a negative watchNamespaces in Logging? It means, I have one Logging instance with watchNamespaces - namespace1 and a second Logging instance with all other namespaces in watch beside namespace1? | 13:55:25 |
 pepov | Hello there Is there a way for a | 15:23:51 |
| 20 Jul 2023 |
|  cerregulus joined the room. | 12:44:45 |
| 21 Jul 2023 |
|  y-eight joined the room. | 07:44:51 |
|  y_eight joined the room. | 07:50:48 |
|  liquidanalysator joined the room. | 08:34:16 |
| liquidanalysator | Hello guys. It's Balázs Németh from Commsignia. Sending my regards to former Balabit colleagues and also to those I do not know 🙂
One of my tasks at Commsignia is to provide a solution to historically store (and aid troubleshooting with a GUI) logs of dozens of microservices as well as some 3rd party vendor components. Of course I would like to use syslog-ng, I am biased. 🙂
I started of with logging-operator since I heard it could use syslog-ng and https://axoflow.com/axosyslog-log-collection-for-kubernetes/ explicitly mentioned it as "complete logging solution for Kubernetes".
For the record currently I am trying to put together logging-operator with Grafana Loki. ELK would be totally overkill regarding system requirements.
However as I got deeper in it I started to feel things bit overcomplicated.
Currently according to my undertstanding this is how the 'architecture' looks like.
1. fluentbit for collecting
2. syslog-ng for forwarding
3. promtail to receive via Syslog but ingest through HTTP (because afaik there is no SyslogNGOutput for loki.)
4. loki to visualize it
Too much hops to be honest.
Questions:
1. Is my understanding correct that instead of these, I could use AxoSyslog (kubernetes source) as a DaemonSet and configure syslog output directly? Without using logging-operator with its all bells and whistles?
2. Do you have plans to use syslog-ng for collection instead of fluentbit in logging-operator?
Thanks in advance
Balage | 09:02:31 |
| 24 Jul 2023 |
| pepov | Hello guys It s Balázs Németh from | 06:12:54 |
|  Tobias Müller joined the room. | 10:00:19 |
| Tobias Müller | Hello guys! 🙂
we're already using the logging operator for our cluster with the normal fluentbit/fluentd to opensearch flows/output.
No we've got an application where we've to read some log files in the container that are not delivered to stdout.
The Operator supports this with the [Tailer Webhook](https://kube-logging.dev/docs/configuration/extensions/tailer-webhook/#enable-webhooks).
So far everything is working, except that the logging operator is still running without tls. That's why i get the error: failed calling webhook "logging-webhooks.banzaicloud.com": failed to call webhook: Post "https://logging-webhooks.logging-system.svc:443/tailer-webhook?timeout=10s": http: server gave HTTP response to HTTPS client.
I din't find any information on how to enable tls on the operator. In the Helm Chart i can only enable the settings for fluentd and fluentbit, but where can i configure tls for the operator?
Greetings
Tobias | 10:22:14 |
| pepov | Tail logfiles with a webhook | 13:24:31 |
| 25 Jul 2023 |
| pepov | Hey folks! 📢
We are preparing a release this week, which is going to contain the following items:
Release flow has been changed so that now a single tag will trigger both an image and a Helm chart release from the repository using https://github.com/kube-logging/logging-operator/pkgs/container/helm-charts%2Flogging-operator as an OCI repository. PR: https://github.com/kube-logging/logging-operator/pull/1379
This also means that we don't have to sync helm chart changes between https://github.com/kube-logging/logging-operator and https://github.com/kube-logging/helm-charts anymore.
Also, the logging-operator-logging chart has been merged into logging-operator with a few fixes and dropped features that didn't work anymore correctly. The old chart is now discontinued. Any missing feature or bugs will be added/fixed in the logging-operator chart from now on. PR: https://github.com/kube-logging/logging-operator/pull/1382
Thanks to an external contribution watchNamespaces can now be controlled using a label selector instead of a static namespace list (or by default using all namespaces if nothing is set). Note: this only affects where the logging operator is looking for Flow and Output resources, but does not affect ClusterFlow and ClusterOutput resources
PRs: https://github.com/kube-logging/logging-operator/pull/1365, https://github.com/kube-logging/logging-operator/pull/1392 | 14:14:23 |
| pepov | Also:
Fix the loggingRef field for the FluentbitAgent type as accidentally it was spelled LoggingRef incorrectly. This was introduced in the last release (4.2) and is a breaking change, but it's better to fix it now than leave it there inconsistent. PR: https://github.com/kube-logging/logging-operator/pull/1390
Fix the operator to refuse reconciling multiple logging resources with the same loggingRef . Use cases with multiple logging resources involved are emerging lately. Real multi-tenant setup becomes a thing, and there are more to come. PR: https://github.com/kube-logging/logging-operator/pull/1391
Change the default behaviour of fluentbit's Kubernetes filter to enable excluding pod logs where the pod has a special annotation. This will help us to get rid of the awkward workaround with fluentd to write logs to /fluentd/log/out in the container instead of stdout (coming up in a subsequent release). PR: https://github.com/kube-logging/logging-operator/pull/1395 Fluentbit docs: https://docs.fluentbit.io/manual/pipeline/filters/kubernetes#kubernetes-annotations
Also lots of library dependencies have been upgraded.
All issues in this release (4.3): https://github.com/kube-logging/logging-operator/milestone/19
Issues anticipated in the next subsequent release (4.4) are still subject to change. If you miss something badly from the list below please let me know: https://github.com/kube-logging/logging-operator/milestone/22 | 14:14:24 |
|  dankgus joined the room. | 15:23:58 |
| 26 Jul 2023 |
|  el_satan joined the room. | 06:09:06 |
|  kefiras_32705 joined the room. | 18:18:59 |
| kefiras_32705 | CRI logs | 19:15:29 |
| 27 Jul 2023 |
|  gokhanadev joined the room. | 13:47:04 |
| 28 Jul 2023 |
| pepov | Another PR has landed and has just been tagged as a release candidate, which contains fixes around the syslog-ng aggregator setup:
https://github.com/kube-logging/logging-operator/pull/1402
The new tag is: https://github.com/kube-logging/logging-operator/tree/4.3.0-rc.1 | 08:28:43 |
| 29 Jul 2023 |
|  harmonious_guava_50390 joined the room. | 08:29:44 |
| 1 Aug 2023 |
|  taotaowang_74689 joined the room. | 02:13:48 |
|  doing_68840 joined the room. | 14:50:02 |
| 3 Aug 2023 |
| pepov | Hey, I've just tagged 4.3.0 with a few additional fixes and improvements in the e2e tests and the chart. Any critical fixes targeting this release should go into the release-4.3 branch which has it's own CI and release flow, so 4.3.X tags should go directly there.
New features and planned fixes can go to master and will be tagged with 4.4.0-dev.X for a while and then with 4.4.0-rc.X when we start preparing for a the next release.
The actual release on github and the documentation can be expected early next week. | 21:56:34 |
| pepov | * Hey, I've just tagged 4.3.0 with a few additional fixes and improvements in the e2e tests and the chart. Any critical fixes targeting this release will go into the release-4.3 branch which has it's own CI and release flow, so 4.3.X tags should be applied directly there as weel.
New features and planned fixes can go to master and will be tagged with 4.4.0-dev.X for a while and then with 4.4.0-rc.X when we start preparing for a the next release.
The actual Github release and the documentation updates can be expected early next week. | 21:58:01 |
