1

由于容器的 Azure Monitor 将从控制台收集基本日志，即标准输出/标准错误。是否有任何理由为日志传送实施 Sidecar，特别是对于生产工作负载？目前我正在使用以下模式

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: {}
4

2 回答 2

4

Azure Monitor 收集日志并发送到 Log Analytics 工作区。它无法将日志发送到 ELK 堆栈。因此，如果您习惯了这些工具并希望继续使用它们，那么基于 fluentbit sidecar 或 fluentd daemonset 的解决方案是替代方案。但在这种情况下，ELK 堆栈的管理由您自己负责。

Azure Monitor 的优势在于它将您的 AKS 日志与其他 Azure 平台日志整合在一起，从而提供统一的监控体验。

azure monitor 的缺点是在非常大的容量下，成本可能会成为一个考虑因素。

因此，您可能希望将开源 ELK 堆栈用于产生大量日志的应用程序，并将 Azure Monitor 用于产生少量日志的应用程序。

于 2020-09-11T09:50:06.810 回答
2

只是为 Arghya Sadhus 回答添加另一个选项：Elasticsearch 在生产就绪安装中具有相当高的内存占用。而且我个人认为仅将其用于日志聚合有点过头了。

一个轻量级的替代方案是您可以使用直接集成在 Grafana 中的 Loki 来聚合您的日志。（请参阅此处以供参考：https ://grafana.com/oss/loki/ ）

于 2020-09-14T08:10:25.383 回答