Perguntas[logging](server)

Acabei de escrever a configuração do Ansible para manter ansible.loguma linha de log por ação.

[defaults]
log_path = /var/log/ansible.log
nocows=true
stdout_callback=ansible.builtin.oneline
host_key_checking = false
inventory = /test/ansible/hosts.txt

Funciona perfeitamente com o ansible-playbookcomando.

Mas se eu quiser executar esse comando

ansible all -m ping

Obterei o registro de várias linhas no arquivo de log.

2024-11-08 10:12:41,689 p=1164 u=root n=ansible | node1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.10"
    },
    "changed": false,
    "ping": "pong"
}

Então eu tenho que sempre adicionar a -oopção para comandos que não sejam de playbooks

ansible all -m ping -o

para obter meu aconchegante registro on-line

2024-11-08 10:15:47,895 p=1181 u=root n=ansible | node1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3.10"},"changed": false,"ping": "pong","warnings": ["..."]}

Minha pergunta é "Como fazer com que o Ansible sempre use o -osinalizador em qualquer comando?" Isso é possível em geral?

Os usuários locais em nosso sistema usam o procmail para passar seus e-mails através do spamd. Usamos Postfix no Ubuntu 22.04.

A entrada de correio do Postfix mostra primeiro o ID do correio, por exemplo:

Jul 30 07:54:18 alice postfix/qmgr[235769]: 2C704BA328: from=<[email protected]>, size=61699, nrcpt=1 (queue active)

As linhas de spam no log ficam assim, mas não mencionam o ID:

Jul 30 07:54:18 alice spamd[1860392]: spamd: connection from ::1 [::1]:44212 to port 783, fd 5
Jul 30 07:54:18 alice spamd[1860392]: spamd: setuid to slucy succeeded
Jul 30 07:54:18 alice spamd[1860392]: spamd: processing message <NM63EC74D6C01FA8E1Fbootsuk_mid_prod1-Ym91bmNlQG1haWwuYm9vdHMuY29t@mail.boots.com> for sslucy:1832
Jul 30 07:54:20 alice spamd[2047327]: util: setuid: ruid=1832 euid=1832 rgid=1835 1951 egid=1835 1951 
Jul 30 07:54:23 alice spamd[1860392]: spamd: clean message (-3.1/7.8) for slucy:1832 in 5.0 seconds, 61039 bytes.
Jul 30 07:54:23 alice spamd[1860392]: spamd: result: . -3 - DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI,MIME_HTML_ONLY,RCVD_IN_DNSWL_NONE,RCVD_IN_VALIDITY_SAFE,SPF_HELO_NONE,SPF_PASS,T_KAM_HTML_FONT_INVALID scantime=5.0,size=61039,user=sslucy,uid=1832,required_score=7.8,rhost=::1,raddr=::1,rport=44212,mid=<NM63EC74D6C01FA8E1Fbootsuk_mid_prod1-Ym91bmNlQG1haWwuYm9vdHMuY29t@mail.boots.com>,autolearn=ham autolearn_force=no
Jul 30 07:54:23 alice spamd[1734900]: prefork: child states: II

Se procurarmos apenas o ID do correio, veremos:

Jul 30 07:54:18 alice postfix/smtpd[2047298]: 2C704BA328: client=r105.mail.boots.com[130.248.198.105]
Jul 30 07:54:18 alice postfix/cleanup[2046192]: 2C704BA328: message-id=<NM63EC74D6C01FA8E1Fbootsuk_mid_prod1-Ym91bmNlQG1haWwuYm9vdHMuY29t@mail.boots.com>
Jul 30 07:54:18 alice opendmarc[411763]: 2C704BA328: SPF(mailfrom): mail.boots.com pass
Jul 30 07:54:18 alice opendmarc[411763]: 2C704BA328: mail.boots.com pass
Jul 30 07:54:18 alice postfix/qmgr[235769]: 2C704BA328: from=<[email protected]>, size=61699, nrcpt=1 (queue active)
Jul 30 07:54:23 alice postfix/local[2046202]: 2C704BA328: to=<[email protected]>, orig_to=<[email protected]>, relay=local, delay=5.8, delays=0.74/0/0/5, dsn=2.0.0, status=sent (delivered to command: procmail -a "$EXTENSION")
Jul 30 07:54:23 alice postfix/qmgr[235769]: 2C704BA328: removed

De acordo com os documentos do Spamassassin , o midcampo no log de spamd significa o ID do email, mas isso parece corresponder apenas ao ID do email do Postfix em alguns casos, mas não em todos (até onde eu sei).

Existe uma maneira de associar de forma confiável o processo spamd a um determinado ID de correio Postfix para que possamos analisar todo o fluxo?

Meu servidor gera cerca de 2,5 GB de logs todos os dias e eu simplesmente não consigo armazená-los. Após alguma investigação, descobri que dos meus 854.608 logs, 394.880 deles se parecem com isto:

    The Windows Filtering Platform has permitted a connection.

Application Information:
    Process ID:     2160
    Application Name:   \device\harddiskvolume2\windows\system32\svchost.exe

Network Information:
    Direction:      Inbound
    Source Address:     192.168.15.25
    Source Port:        5353
    Destination Address:    224.0.0.251
    Destination Port:       5353
    Protocol:       17

Filter Information:
    Filter Run-Time ID: 81091
    Layer Name:     Receive/Accept
    Layer Run-Time ID:  44

e outros 185.103 são a mesma coisa, mas com Systemem vez de \device\harddiskvolume2\windows\system32\svchost.exe.

O que eu faço com isso ? E o mais importante, como faço para parar?

Estou tentando fazer com que nosso servidor Tomcat 9 registre seu login interno /var/logem vez de ${catalina.base}/logs.

Tentei alterar os destinos em logging.properties, mas o diretório de logs ${catalina.base}é na verdade um link simbólico, portanto, alterar o destino para /var/logdeve resolver. Nenhuma das duas ideias funcionou.

Além disso, estou me perguntando se isso poderia ser causado por catalina.policy, mas isso significaria que o Tomcat seria lançado com a -secureopção. Meu Tomcat é iniciado como serviço usando o systemd. Não tenho ideia de como posso verificar se -secure é usado ou não.

O Tomcat logging.propertiesé realmente usado. Quando verifico o processo com ps, recebo -Djava.util.logging.config.file=/opt/rh/jws5/root/usr/share/tomcat/conf/logging.properties, que é o arquivo correto, aquele que tentei modificar.

Estou usando o Tomcat 9 com Java 8 no RHEL 8.

Editar : também tentei adicionar ReadWritePaths=/var/log/tomcatou ReadWritePaths=/var/logno arquivo de serviço. Ainda não há mudança.

Edit2 : Alguns detalhes sobre a configuração atual. Meu CATALINA_BASE é /opt/rh/jws5/root/usr/share/tomcat. Ele contém o seguinte:

drwxr-xr-x 2 root root 134 Dec  7 16:18 bin
lrwxrwxrwx 1 root root  28 Nov 15 17:45 conf -> /etc/opt/rh/scls/jws5/tomcat
lrwxrwxrwx 1 root root  39 Nov 15 17:45 lib -> /opt/rh/jws5/root/usr/share/java/tomcat
lrwxrwxrwx 1 root root  15 Jan 31 17:42 logs -> /var/log/tomcat
lrwxrwxrwx 1 root root  39 Nov 15 17:45 temp -> /var/opt/rh/scls/jws5/cache/tomcat/temp
lrwxrwxrwx 1 root root  40 Nov 15 17:45 webapps -> /var/opt/rh/scls/jws5/lib/tomcat/webapps
lrwxrwxrwx 1 root root  39 Nov 15 17:45 work -> /var/opt/rh/scls/jws5/cache/tomcat/work

logs apontados anteriormente para /var/opt/rh/scls/jws5/log/tomcat. Com a configuração atual, o Tomcat não está mais efetuando login em /var/opt/rh/scls/jws5/log/tomcat. Mas também não efetua login em /var/log.

Aqui está o trecho do meu arquivo logging.properties com os vários caminhos:

1catalina.org.apache.juli.AsyncFileHandler.level = FINE
1catalina.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina.
1catalina.org.apache.juli.AsyncFileHandler.maxDays = 90
1catalina.org.apache.juli.AsyncFileHandler.encoding = UTF-8

2localhost.org.apache.juli.AsyncFileHandler.level = FINE
2localhost.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.AsyncFileHandler.prefix = localhost.
2localhost.org.apache.juli.AsyncFileHandler.maxDays = 90
2localhost.org.apache.juli.AsyncFileHandler.encoding = UTF-8

3manager.org.apache.juli.AsyncFileHandler.level = FINE
3manager.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.AsyncFileHandler.prefix = manager.
3manager.org.apache.juli.AsyncFileHandler.maxDays = 90
3manager.org.apache.juli.AsyncFileHandler.encoding = UTF-8

4host-manager.org.apache.juli.AsyncFileHandler.level = FINE
4host-manager.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
4host-manager.org.apache.juli.AsyncFileHandler.prefix = host-manager.
4host-manager.org.apache.juli.AsyncFileHandler.maxDays = 90
4host-manager.org.apache.juli.AsyncFileHandler.encoding = UTF-8

Edit3 : Tentei substituir os ${catalina.base}/logsdo logging.propertiesby /var/log/tomcat, ainda sem sucesso.

Sou bastante novo no syslog-ng e tenho o seguinte problema.
Eu tenho um firewall Checkpoint que envia os logs para um servidor Splunk. Devido à enorme quantidade de dados enviados pelo firewall, tentei filtrar os logs indesejados. Como isso não foi possível nem no firewall nem no Splunk, agora envio os logs do firewall para um servidor syslog-ng que filtra as mensagens indesejadas e encaminha o restante dos logs para o Splunk via Splunk-forwarder. A definição de log no servidor Syslog-ng é semelhante a esta:
log { source { network(transport(tcp) port(12001) flags(no-parse)); };
analisador { analisador de ponto de verificação(); };
filtro {não corresponde("Application_Allow_all", valor("MESSAGE")); };
destino { arquivo("/var/log/syslog-ng/checkpoint.txt"); };
};
80% dos logs do firewall contêm "Application_Allow_all" , que não precisamos no servidor Splunk. Até aí tudo bem, o filtro funciona.
Agora vamos ao problema. Preciso ter no servidor Splunk os logs do firewall contendo "acesso ao servidor Web". Mas as entradas de log do firewall contendo "Webserver access" também contêm "Application_Allow_all" .
Não sei combinar dois filtros e o que encontrei na internet até agora não funciona. Eu tentei o seguinte:
filter { match("Webserver access", value("MESSAGE")); };
filtro {não corresponde("Application_Allow_all", valor("MESSAGE")); };
Com esses filtros, agora obtenho apenas os logs que contêm "acesso ao servidor Web" e nada mais. O segundo filtro parece ser ignorado. Esta é a aparência da entrada de log no servidor Splunk:
"rule_action=Accept | Rule_name=Webserver access | Rule_name=Application_Allow_all" O que eu quero alcançar é que os logs contendo "Webserver Access" sejam encaminhados pelo syslog-ng para o servidor Splunk , enquanto todos os outros logs contendo "Application_Allow_all" são descartados.
Qualquer ideia é bem-vinda.

Na minha empresa, construí um cluster K8s com Terraform e configurei um sistema de log com EFK (Elasticsearch, Fluent-bit, Kibana).

k8s e Elasticsearch usam EKS e Opensearch Servcie da AWS (ES 7.10), e o Fluent-bit foi instalado separadamente como um Daemonset por meio do Helm.

https://artifacthub.io/packages/helm/fluent/fluent-bit

No caso do Fluent-bit Config, ele está estruturado da seguinte forma.

config:
   inputs: |
     [INPUT]
         Name tail
         Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/kube-proxy*, / var/log/containers/aws-load-balancer*, /var/log/containers/cert-manager*, /var/log/containers/coredns*, /var/log/containers/ebs-csi*, /var/ log/containers/grafana*, /var/log/containers/karpenter*, /var/log/containers/metrics-server*, /var/log/containers/prometheus*
         Path /var/log/containers/*.log
         Tag kube.*
         Mem_Buf_Limit 50MB
         multiline.parser python-custom

   outputs: |
     [OUTPUT]
         Name es
         Match kube.*
         Host ${es_domain_name}
         Port 443
         TLS On
         AWS_Auth On
         AWS_Region ${region}
         Retry_Limit 6
         Replace_Dots On
         Trace_Error On

   filters: |
     [FILTER]
         Name kubernetes
         Match kube.*
         Merge_Log On
         Merge_Log_Key log_processed
         Keep_LogOff
         K8S-Logging.Parser On
         K8S-Logging.Exclude On

   customParsers: |
     [MULTILINE_PARSER]
         name python-custom
         type regex
         flush_timeout 1000
         rule "start_state" "/stderr F(.*)/" "cont"
         rule "cont" "/stderr F(.*)/" "cont"

No geral funcionou bem, mas um dia, após uma determinada situação, percebi que todos os logs coletados pelo Fluent-bit apontavam para o mesmo timestamp.

Anteriormente, a saída do log do pod era registrada com um carimbo de data/hora preciso, mas depois que o pod é recarregado, o log continua a ser registrado com um @timestamp fixo e, como os logs são acumulados no fuso horário anterior, o seguinte fenômeno aparece quando visto em kibana.

Os logs são todos transmitidos ao ES em tempo real, mas como todos são coletados em um horário fixo, as consultas adequadas não podem ser executadas.

insira a descrição da imagem aqui

// Unlike the timestamp output in the actual application, the timestamp recorded in Fluent-bit remains the same.
Oct 16, 2023 @ 16:13:36.142 2023-10-16T09:48:55...[2023-10-16 09:48:55]... 
Oct 16, 2023 @ 16:13:36.142 2023-10-16T09:48:55...[2023-10-16 09:48:55]... 
Oct 16, 2023 @ 16:13:36.142 2023-10-16T09:53:55...[2023-10-16 09:53:55]... 
Oct 16, 2023 @ 16:13:36.142 2023-10-16T09:58:03...[2023-10-16 09:58:03]... 
Oct 16, 2023 @ 16:13:36.142 2023-10-16T09:58:03...[2023-10-16 09:58:03]... 
Oct 16, 2023 @ 16:13:36.142 2023-10-16T09:58:03...[2023-10-16 09:58:03]... 
Oct 16, 2023 @ 16:13:36.142 2023-10-16T09:58:55...[2023-10-16 09:58:55]... 
Oct 16, 2023 @ 16:13:36.142 2023-10-16T09:58:55...[2023-10-16 09:58:55]... 
Oct 16, 2023 @ 16:13:36.142 2023-10-16T10:03:03...[2023-10-16 10:03:03]...
Oct 16, 2023 @ 16:13:36.142 2023-10-16T10:03:55...[2023-10-16 10:03:55]... 

Esse problema ocorre ao atualizar e recarregar pods em execução para cada serviço. Confirmei que o log inotify_fs_add foi enviado para Fluent-bit para o pod recém-criado e nenhum outro log de erro pôde ser confirmado.

Recarregamento de pod

│ backend-api-deployment-5d9fc55496-8mppx                            ●  1/1          0 Running
│ backend-api-deployment-57d68dd4f5-djn8x                            ●  1/1          0 Terminating

Log de bits fluentes

│ Fluent Bit v2.1.8
│ * Copyright (C) 2015-2022 The Fluent Bit Authors
│ * Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
│ * https://fluentbit.io
│
│ [2023/10/16 16:05:00] [ info] [fluent bit] version=2.1.8, commit=1d83649441, pid=1
│ [2023/10/16 16:05:00] [ info] [storage] ver=1.4.0, type=memory, sync=normal, checksum=off, max_chunks_up=128
│ [2023/10/16 16:05:00] [ info] [cmetrics] version=0.6.3
│ [2023/10/16 16:05:00] [ info] [ctraces ] version=0.3.1
│ [2023/10/16 16:05:00] [ info] [input:tail:tail.0] initializing
│ [2023/10/16 16:05:00] [ info] [input:tail:tail.0] storage_strategy='memory' (memory only)
│ [2023/10/16 16:05:00] [ info] [input:tail:tail.0] multiline core started
│ [2023/10/16 16:05:00] [ info] [filter:kubernetes:kubernetes.0] https=1 host=kubernetes.default.svc port=443
│ [2023/10/16 16:05:00] [ info] [filter:kubernetes:kubernetes.0]  token updated
│ [2023/10/16 16:05:00] [ info] [filter:kubernetes:kubernetes.0] local POD info OK
│ [2023/10/16 16:05:00] [ info] [filter:kubernetes:kubernetes.0] testing connectivity with API server...
│ [2023/10/16 16:05:00] [ info] [filter:kubernetes:kubernetes.0] connectivity OK
│ [2023/10/16 16:05:00] [ info] [output:es:es.0] worker #0 started
│ [2023/10/16 16:05:00] [ info] [output:es:es.0] worker #1 started
│ [2023/10/16 16:05:00] [ info] [http_server] listen iface=0.0.0.0 tcp_port=2020
│ [2023/10/16 16:05:00] [ info] [sp] stream processor started
│ [2023/10/16 16:05:00] [ info] [input:tail:tail.0] inotify_fs_add(): inode=41916664 watch_fd=1 name=/var/log/containers/backend-api-deployment-57d68dd4f5-djn8x_backend-dev_backend-api-f950104ab9f300586803316ad7beef5c9506db9fceeb4af0dc0575b3b9bacfd7.log
│ [2023/10/16 16:05:00] [ info] [input:tail:tail.0] inotify_fs_add(): inode=17488499 watch_fd=2 name=/var/log/containers/backend-api-deployment-6dc5b97645-tqwxh_backend-staging_backend-api-23f14f74af6cc163f233499ba92a2746cb2f263c9379ba53fc47cd3d76e00bbb.log
...
│ [2023/10/17 04:49:01] [error] [output:es:es.0] HTTP status=429 URI=/_bulk, response:
│ 429 Too Many Requests /_bulk
│
│ [2023/10/17 04:49:01] [ warn] [engine] failed to flush chunk '1-1697518140.870529031.flb', retry in 6 seconds: task_id=1, input=tail.0 > output=es.0 (out_id=0)
│ [2023/10/17 04:49:01] [error] [output:es:es.0] HTTP status=429 URI=/_bulk, response:
│ 429 Too Many Requests /_bulk
│
│ [2023/10/17 04:49:01] [ warn] [engine] failed to flush chunk '1-1697518140.276173730.flb', retry in 7 seconds: task_id=0, input=tail.0 > output=es.0 (out_id=0)
│ [2023/10/17 04:49:07] [ info] [engine] flush chunk '1-1697518140.870529031.flb' succeeded at retry 1: task_id=1, input=tail.0 > output=es.0 (out_id=0)
│ [2023/10/17 04:49:08] [ info] [engine] flush chunk '1-1697518140.276173730.flb' succeeded at retry 1: task_id=0, input=tail.0 > output=es.0 (out_id=0)
│ [2023/10/17 05:08:50] [ info] [input:tail:tail.0] inotify_fs_add(): inode=37547666 watch_fd=8 name=/var/log/containers/backend-api-deployment-5d9fc55496-8mppx_backend-dev_backend-api-839c128d6227f797722496a992ca9149b95c366997c2b1ec28ceb65490582e3b.log
│ [2023/10/17 05:08:52] [ info] [filter:kubernetes:kubernetes.0]  token updated
│ [2023/10/17 05:09:25] [ info] [input:tail:tail.0] inotify_fs_remove(): inode=41916664 watch_fd=1
│ [2023/10/17 05:09:37] [ info] [input:tail:tail.0] inotify_fs_remove(): inode=17488499 watch_fd=2

O que é interessante é que se todos os Daemon Sets de bits fluentes forem eliminados manualmente e revividos por meio de autocura, todos eles serão temporariamente coletados normalmente novamente.

Depois disso, se você atualizar e recarregar o pod de serviço novamente, o mesmo problema ocorrerá novamente.

O que causa esse problema? Como posso consertar isso? E se houver alguma configuração recomendada do Fluent-bit, conselhos adicionais serão bem-vindos.

obrigado!

Digamos que eu queira logrotate quando o tamanho do arquivo for 1kb. Antes da execução, se o tamanho do arquivo de log for 4kb, espero que o logrotate crie 4 arquivos de log diferentes.

Antes:

something.log (4kb) 

O que eu espero que aconteça.

something.log (0kb) 
something.log.1 (1kb)
something.log.2 (1kb)
something.log.3 (1kb)
something.log.4 (1kb)

Mas atualmente o que está acontecendo é

something.log (0kb) 
something.log.1 (4kb)

Mesmo que eu tenha dado o tamanho para ser 1k.

O programa que lê os logs não pode lidar com arquivos maiores que um determinado tamanho, então quero usar o logrotate para manter o tamanho sob controle.

Exemplo de arquivo confing logrotate que estou usando

/pathme/something/data/*/logs/*.log {
su username1 username1
missingok
rotate 10
notifempty
size 1k
copytruncate}

Desejo rastrear as atividades dos usuários em um cluster k8s. por exemplo, quero obter o nome de usuário k8s de um usuário que executa um comando em um pod. existe uma ferramenta chamada Tetragon. ele pode usar a API k8s. O log a seguir é um exemplo de saída do Tetragon em um cluster k8s:

    {
  "process_exec": {
    "process": {
      "exec_id": "bWluaWt1YmU6NzAyMDQ2ODIyNTEwNDg6MTE5MDk1MQ==",
      "pid": 1190951,
      "uid": 0,
      "cwd": "/",
      "binary": "/bin/sh",
      "arguments": "-c \"sleep 60m\"",
      "flags": "execve rootcwd clone",
      "start_time": "2023-07-22T13:37:01.382355175Z",
      "auid": 4294967295,
      "pod": {
        "namespace": "default",
        "name": "alpine-59dcb54bd-l7dtv",
        "container": {
          "id": "docker://767327faa6bc703188e434b74e80ed29f14973556b4411060674056cf9b305d6",
          "name": "alpine",
          "image": {
            "id": "docker-pullable://alpine@sha256:82d1e9d7ed48a7523bdebc18cf6290bdb97b82302a8a9c27d4fe885949ea94d1",
            "name": "alpine:latest"
          },
          "start_time": "2023-07-22T13:37:01Z",
          "pid": 1
        },
        "pod_labels": {
          "pod-template-hash": "59dcb54bd",
          "run": "alpine"
        }
      },
      "docker": "767327faa6bc703188e434b74e80ed2",
      "parent_exec_id": "bWluaWt1YmU6NzAyMDQ1NTgzNDYxOTA6MTE5MDkzMQ==",
      "refcnt": 1,
      "tid": 1190951
    },
    "parent": {
      "exec_id": "bWluaWt1YmU6NzAyMDQ1NTgzNDYxOTA6MTE5MDkzMQ==",
      "pid": 1190931,
      "uid": 0,
      "cwd": "/run/containerd/io.containerd.runtime.v2.task/moby/767327faa6bc703188e434b74e80ed29f14973556b4411060674056cf9b305d6",
      "binary": "/usr/bin/containerd-shim-runc-v2",
      "arguments": "-namespace moby -id 767327faa6bc703188e434b74e80ed29f14973556b4411060674056cf9b305d6 -address /run/containerd/containerd.sock",
      "flags": "execve clone",
      "start_time": "2023-07-22T13:37:01.258449828Z",
      "auid": 4294967295,
      "parent_exec_id": "bWluaWt1YmU6NzAyMDQ1NTAyNzk4MDM6MTE5MDkyNA==",
      "tid": 1190931
    }
  },
  "node_name": "minikube",
  "time": "2023-07-22T13:37:01.382358135Z"
}

Agora eu quero que o nome de usuário k8s do usuário execute esses comandos. por exemplo, quero ter um campo em um json acima como:

username: minikube-user

Alguém tem alguma ideia?

Como enviar logs de auditoria do k8s para vários servidores/endpoints?
Eu tentei

• passar vários --audit-webhook-config-fileargumentos para o kube-apiserver
• adicione outro cluster ao arquivo de configuração do webhook

mas essas modificações são inválidas e o kube-apiserver não inicializa.

Estou tentando capturar texto por meio de expressão regular e substituir o texto por uma string personalizada.

Meu código atual captura endereços IP com sucesso, mas não sei como substituir o endereço IP por um texto personalizado junto com o restante da mensagem:

$Template privateIP,"%TIMESTAMP% %HOSTNAME% %syslogtag% %msg:R,ERE,0,DFLT:([0-9]{1,3}\.){3}[0-9]{1,3}--end%\n"

Meu primeiro pensamento é de alguma forma mover o regex para fora do modelo (ou seja, com algum RainerScript) e criar um novo campo/variável modded_msgque seja definido como uma msgpropriedade modificada. E então use %modded_msg%no $Template.

Eu tentei várias vezes (obrigado, ChatGPT), mas não consigo fazê-lo funcionar.