Azure Kubernetes - Azure Monitor & Sidecar Logshipping?

Поскольку Azure Monitor для контейнеров будет собирать базовые журналы с консоли, то есть stdout / stderr. Есть ли причина внедрять сопутствующий элемент для доставки журналов, особенно для производственных рабочих нагрузок? В настоящее время я использую следующий шаблон

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sidecar-logshipping
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sidecar-logshipping
  template:
    metadata:
      labels:
        app: sidecar-logshipping
    spec:
      containers:
      - name: main-container
        image: busybox
        args:
        - /bin/sh
        - -c
        - >
          i=0;
          while true;
          do
            echo "$i: $(date) dog" >> /var/log/mylogs/app.log;
            i=$((i+1));
            sleep 1;
          done
        resources:
          limits:
            memory: "256Mi"
            cpu: "500m"
          requests:
            memory: "64Mi"
            cpu: "250m"
        volumeMounts:
        - name: logs
          mountPath: /var/log/mylogs
      - name:  log-shipper
        image: busybox
        args: [/bin/sh, -c, 'tail -n+1 -f /var/log/mylogs/*.log']
        resources:
          limits:
            memory: "256Mi"
            cpu: "500m"
          requests:
            memory: "64Mi"
            cpu: "250m"
        volumeMounts:
        - name: logs
          mountPath: /var/log/mylogs
      volumes:
      - name: logs
        emptyDir: {}

person Karthikeyan Vijayakumar    schedule 11.09.2020    source источник


Ответы (2)


Azure Monitor собирает журналы и отправляет их в рабочую область Log Analytics. Он не может отправлять журналы в стек ELK. Так что, если вы привыкли к этим инструментам и хотите продолжать их использовать, альтернативой являются решения на основе fluentbit sidecar или fluentd daemonset. Но в этом случае управление стеком ELK лежит на вас.

Преимущество Azure Monitor заключается в том, что он объединяет ваши журналы AKS с журналами других платформ Azure, обеспечивая унифицированный опыт мониторинга.

Недостаток лазурного монитора заключается в том, что при очень больших объемах стоимость может стать существенной.

Таким образом, вы можете использовать стек ELK с открытым исходным кодом для приложений, которые создают большой объем журналов, и использовать Azure Monitor для приложений, которые создают небольшой объем журналов.

person Arghya Sadhu    schedule 11.09.2020

Просто чтобы добавить еще один вариант к ответу Аргья Садху: Elasticsearch имеет довольно большой объем памяти в готовых к эксплуатации установках. И лично я считаю излишним использовать его исключительно для агрегирования логов.

Облегченной альтернативой является то, что вы можете использовать Loki, который интегрируется непосредственно в Grafana для агрегирования ваших журналов. (См. Здесь для справки: https://grafana.com/oss/loki/)

person BeWu    schedule 14.09.2020