Compose: Feature: Möglichkeit zum Löschen des Protokollverlaufs

Ich denke nicht, dass dies eine Funktion ist, die vom Docker-Daemon unterstützt wird. In den API-Dokumenten besteht die einzige Möglichkeit darin, die zurückgegebenen Protokolle auf eine begrenzte Anzahl von Zeilen pro Container zu kürzen:

https://docs.docker.com/reference/api/docker_remote_api_v1.17/#get -container-logs

: +1: für dieses Problem. Ich benutze Compose, um eine Website in Golang, Mongodb und Nginx zu entwickeln ... 5 Tage nach Beginn habe ich lange Protokolle, die besorgniserregend werden. Bei jedem Neustart von Containern werden viele Zeilen an das Protokoll angehängt.
@dnephin Ich verstehe nicht, ob Sie eine Lösung geben (die ich nicht verstehe :)) oder ob Sie vorhaben zu prüfen, ob es mit API möglich ist. Entschuldigung für mein schlechtes Englisch.

Docker 1.6 bietet Unterstützung für Protokollierungstreiber. Weitere Informationen zur grundlegenden Protokollrotation finden Sie unter https://github.com/docker/docker/pull/10568 (derzeit: JSON, Syslog und "keine"). https://github.com/docker/docker/pull/11485

Schön das zu hören, vielen Dank :)

Vielen Dank für den Hintergrund und das Update von Docker 1.6 - ich freue mich darauf!

docker logs -c (clear) <container> wäre toll.

+1

+1 Wirklich wichtig

Heilige Kuh, ich habe gerade einige Minuten Protokolle durchgesessen, um zum Ende zu kommen. Ich würde das auch sehr schätzen, um nicht ständig Container umbauen zu müssen.

+1

+1

+1

: +1:

+1

+2

+1

Nur zur Veranschaulichung: Mit Docker 1.8 und Docker-Compose 1.4 gibt es bereits eine Methode zum Begrenzen der Protokollgröße mithilfe von https://docs.docker.com/compose/yml/#log -driver und log-opt max-size:

  log_driver: "json-file"
  log_opt:
    max-size: "100k"
    max-file: "20"

@dmage Danke, genau das was ich brauche.

+1000

+1 würde das LIEBEN

+1

Die @ dmage- Lösung funktioniert hervorragend für uns. Die anderen, die dies tun, was ist falsch an der Lösung, die er gegeben hat?

@Rodeoclash - Ich denke, ein Anwendungsfall hierfür ist die Wiederverwendung eines bestimmten Satzes von Containern für einen neuen Lauf, dh einen CI-Testlauf. Die alten Protokolle sind für den neuen Lauf irrelevant, sodass ein clear vor dem nächsten Befehl Verwirrung stiften würde.

+1

+1, gleiches Bedürfnis wie @rosskevin

Ok, um es noch einmal zusammenzufassen:

• Sie können dies aus einer Erstellungsdatei heraus tun (siehe https://github.com/docker/compose/issues/1083#issuecomment-141936600).
• # 265 behandelt die Möglichkeit, die Ausgabe des Befehls logs zu begrenzen
• # 1756 deckt den wiederverwendeten Behälter ab

Schließen Sie dies, da es bereits in anderen Problemen unterstützt oder nachverfolgt wird.

Ich verstehe nicht ganz, warum dies geschlossen wurde. Wie löscht man den Protokollverlauf?

Ich füge hinzu:

  log_opt:
    max-size: 50k

So begrenzen Sie die Länge der Protokolle.

Sie müssen das wirklich hinzufügen, es ist wichtig. Das Einschränken von Protokollen ist gut und es sollte nur einen einfachen Befehl zum Löschen von Protokollen geben.

docker logs -c <container>

Was gibt?

Ich verstehe, wie man die Protokollgröße begrenzt, aber wie löscht man das Protokoll?

Ich glaube nicht, dass das Löschen eines Protokolls von der Docker-Engine unterstützt wird, mit der die Protokolle verwaltet wurden.

Vielleicht könnten Sie das mit einem benutzerdefinierten Protokolltreiber tun, aber das wäre extern zu komponieren.

+1 für das Löschen der Protokolle ...

+1

+1

+1

+1

+1 für Befehl zum Löschen des Protokolls.

+1 für Befehl zum Löschen des Protokolls

+1

+1

+1

: +1:

+1

+1

Schauen Sie sich dieses Dokument an:
https://docs.docker.com/engine/admin/logging/overview/

docker-logs-clean.sh

#!/bin/bash

rm $(docker inspect $1 | grep -G '"LogPath": "*"' | sed -e 's/.*"LogPath": "//g' | sed -e 's/",//g');

Aufruf:

sudo ./docker-logs-clean.sh <container-name>;

@sgarbesi danke!
+1

+1 für Befehl zum Löschen des Protokolls

Geschlossen zugunsten von?

Um meinen Kommentar von https://github.com/docker/compose/issues/1083#issuecomment -149357280 zu wiederholen:

Ok, um es noch einmal zusammenzufassen:

• Sie können dies aus einer Erstellungsdatei heraus tun (siehe https://github.com/docker/compose/issues/1083#issuecomment-141936600).
• # 265 behandelt die Möglichkeit, die Ausgabe des Befehls logs zu begrenzen
• # 1756 deckt den wiederverwendeten Behälter ab

Wenn Sie nach einem Befehl wie docker logs --clear suchen, der von der Docker-Engine nicht unterstützt wird, müssen Sie diesen Befehl für Docker / Docker anfordern. Ich denke jedoch, dass die oben genannten Optionen für die meisten Fälle bereits ausreichen sollten. Die meisten Benutzer möchten nur eine Teilmenge der Protokolle anzeigen und nicht entfernen.

Vielen Dank an @dnephin und alle anderen für ihre Beiträge. Ich habe dieses Problem jetzt vor fast einem Jahr angesprochen, und nach den Kommentaren seitdem scheint mir ziemlich klar zu sein, dass die Protokollverwaltung für viele Compose-Benutzer ein Problem darstellt.

Es wurden einige Problemumgehungen erwähnt. Ich selbst verwende meistens max-size , um die Protokolle auf einer angemessenen Länge zu halten. Dies hilft sehr, und ich bin dankbar für diese Problemumgehungen, aber es ist wichtig zu bedenken, dass dies eine Problemumgehung ist, keine Lösung.

Mir ist jetzt auch klar, dass ein Teil der Verantwortung für die Behebung dieses Problems im Docker-Protokollierungssystem liegt und dass ein Befehl clear bereitgestellt werden muss, damit Compose ihn verwendet - fair genug.

Alles in allem gibt es jedoch einige Funktionen, die es seit der Erstellung dieses Tickets in die Docker-Versionen geschafft haben - nämlich --since=<timestamp> und --tail=<num-lines> , die von Compose unterstützt werden könnten, um der Realisierung näher zu kommen Lösung für dieses Problem.

Die Unterstützung von --since könnte beispielsweise Folgendes ermöglichen:

$ docker-compose logs --since=now my_container

oder

$ docker-compose logs --since=5m my_container

Unterstützung für --tail wäre ebenfalls nützlich, z

$ docker-compose logs --tail=100 my_container

und natürlich Kombinationen davon. Es mag auch sinnvoll sein, diese in docker-compose.yml als Teil des logging -Blocks zu unterstützen, aber auch ohne dies, wenn Sie nur diese beiden Optionen unterstützen, könnten Sie vermutlich die Mehrheit der Menschen mit + zufriedenstellen Ich hatte dieses Ticket.

Zusammenfassend nochmals vielen Dank für all das Feedback und die Problemumgehungen sowie für Docker und Compose selbst - beide sind großartige Produkte. Ich hoffe, Sie werden die in diesem Thread vorgebrachten Ideen berücksichtigen und diese Produkte noch weiter verbessern.

Siehe # 2227 für eine Zusammenfassung

: +1: danke @dnephin , freue mich darauf!

Ich habe die <container-id>-json.log -Dateien in /var/lib/docker/containers/<container-id>/ manuell gelöscht (verwenden Sie sudo ). Sobald ich docker-compose logs , war das Protokoll leer. Es ist keine Lösung, aber mit einer richtigen .bash -Datei können Sie die Reinigung vor jedem Build automatisieren.

Edit: So etwas macht den Trick (Verwendung auf eigenes Risiko !!):

sudo find /var/lib/docker/containers/ -type f -name '*-json.log' -delete

+1

+1

+1

+1

+2

+2

+1

+20

+1

+1

+1

+1

@sgarbesi Nach dem Ausführen dieses Bereinigungsbefehls funktioniert die Protokollfunktion normal?

+1

docker-logs-clean.sh

#!/bin/bash

for container_id in $(docker ps -a --filter="name=$name" -q);

    do file=$(docker inspect $container_id | grep -G '"LogPath": "*"' | sed -e 's/.*"LogPath": "//g' | sed -e 's/",//g');

    if [ -f $file ]
      then
          rm $file;
    fi

done

Aufruf:

chmod +x docker-logs-clean.sh

sudo ./docker-logs-clean.sh

+1 für die Befehlszeilenoption zum manuellen Löschen von Protokollen

@assanmoor Tut für mich.

+1

Vielen Dank für andere Möglichkeiten zum Reinigen von Containerprotokollen

👍

+1 👍

+1!

+1

+1

+1

Dies wäre eine großartige Funktion. Ich habe einige Container, die auf Java basieren, und nach ein oder zwei Tagen bei der Fehlerbehebung kann es 30 Sekunden oder länger dauern, bis ein docker logs -f <container> da Java diese mehrzeiligen Dateien liebt Protokolle.

Eine andere Sache, die möglicherweise einfacher zu implementieren ist, ist ein weiteres Flag in Protokollen, um einen Schwanz zu starten, ohne beispielsweise alle vorhandenen Protokolle docker logs -f -n <container> wiederzugeben (dh nur neuen Protokollen zu folgen). Dies würde nur Protokollnachrichten wiedergeben, die nach dem Ausführen des Befehls empfangen wurden.

Das Gegenteil würde auch funktionieren (und wäre näher an der Funktionsweise von Gnu Tail), wenn ein -f die letzten 5-10 Zeilen und dann standardmäßig neue Zeilen wiedergibt und ein Flag hinzufügt, um alles wie jetzt wiederzugeben (vielleicht docker logs -f -a <container> oder so).

In diesem Sinne würde ich gerne die Funktion von gnu tail haben, mit der angegeben werden kann, wie viele Zeilen wie docker logs -100 <container> die letzten 100 Zeilen ergeben sollen.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Gibt es einen Trick für Docker für Mac? Danke und +1 für eine Kommandozeilenoption dafür :)

+1

+1

+1

UPDATE: 08.10.2016 - Anforderung für "jq" entfernt, da "Docker-Protokolle" Go-Vorlagen unterstützen! (https://docs.docker.com/engine/admin/formatting/)

Hallo zusammen,

Weil das Löschen von Dateien, die geöffnet sein könnten, im Allgemeinen eine SCHLECHTE Idee ist - insbesondere, wenn Sie versuchen, Speicherplatz zu sparen! - Ich habe die anfänglichen Bemühungen von @sgarbesi , @lvitals & @wazoo (danke für die Ideen) erweitert, um das etwas funktionalere Skript unten zu erstellen.

Kopieren Sie den folgenden Code in eine Datei
vi ./docker-container-log-trim.sh
Machen Sie die Datei ausführbar
chmod +x ./docker-container-log-trim.sh
Dann ausführen mit
sudo ./docker-container-log-trim.sh

Kommentieren Sie die Zeile mit > wenn Sie dem Skript vertrauen ... hier geschieht die Magie. :-)

Feedback willkommen.
Vielen Dank.

PS. Getestet, aber nicht kampferprobt. Verwendung auf eigene Gefahr.

#!/bin/bash

# NOTES:
#  Does NOT delete logfile (BAD IDEA) - simply trims file with redirect.
#  Handles single/all-running/all-existing containers - see end of script for usage.
#  Enjoy :-)


_get_container_logfile() {

  case $1 in

    running) _trim_container_logfile "$(docker ps -q)" $2
             ;;

        all) _trim_container_logfile "$(docker ps -aq)" $2
             ;;

          *) _trim_container_logfile "$(docker ps -a | awk -v ID=$1 '$1 ~ ID || $NF ~ ID {print $1}')" $2
             ;;

  esac

}


_trim_container_logfile() {

  TEMP=$(mktemp)

  case $2 in
    *[!0-9]*) echo "[lines] must be a number - \"$2\" is not a number."
              exit 1
              ;;
        ''|*) MAX=${2:-1000}
              ;;
  esac


  if [ -z $1 ]
  then
    echo "Container name/id unknown!"
    exit 1
  else
    for container in $1
    do
      logfile="$logfile $(docker inspect --format '{{ .LogPath }}' $container)"
      echo "Keeping $MAX lines: $logfile"

      tail -n ${MAX} $logfile > $TEMP
      # Uncomment the next line when you trust the script!
      # cat $TEMP > $logfile
    done
  fi

  rm $TEMP
}


if [ -a "$(which docker)" ]
then
  case $1 in
    --trim) if [ -z $2 ]
            then
              echo "Container name/id missing!"
              exit 1
            else
              _get_container_logfile $2 $3
            fi
            ;;

    --trim-running) _get_container_logfile running $2
                    ;;

    --trim-all) _get_container_logfile all $2
                ;;

    *) echo "Usage:"
       echo "  --trim {container} [lines]   Keep [lines] of logfile for a single container"
       echo "  --trim-running     [lines]   Keep [lines] of logfile for all running containers"
       echo "  --trim-all         [lines]   Keep [lines] of logfile for all containers"
       echo "Default: lines=1000"
       exit 1
       ;;
  esac
else
  echo "Requires \"docker\""
  exit 1
fi

+1

+1

Da also mehrfach zum Ausdruck gebracht wurde, dass ein expliziter klarer Befehl gewünscht wird, und da nie einer hinzugefügt wurde, besteht eine Chance, dass dieser wieder geöffnet wird?

Es hängt natürlich von einem Docker-Engine-Wechsel ab, aber es ist immer noch etwas, das irgendwann auch in Docker-Compose behandelt werden muss - und es ist definitiv nicht behoben, was einen expliziten Befehl betrifft.

@DavidPesticcio Beim Ausführen Ihres Skripts wird folgende Fehlermeldung line 53: $logfile: ambiguous redirect (nach Entfernen des Kommentars)

Hallo @gingerlime , Scheint, als würde $ TEMP nicht

"Funktioniert gut für mich" - ja ich weiß, das hilft dir nicht viel, aber es ist wahr ... :-)

Ich habe das Skript aktualisiert, sodass Sie "jq" nicht mehr benötigen - vielleicht sollte ich ein Bail-out hinzufügen, wenn auch mktemp fehlt ... Ich dachte, es wäre ein Standard-Tool - aber vielleicht führen Sie das nicht aus Skript innerhalb einer "Standard" -Installation - wie vielleicht aus einem minimalen Container heraus? :-)

Hoffentlich hilft das!

Ich habe mktemp und benutze es häufig ... Ich habe nicht wirklich viel Zeit damit verbracht, es zu debuggen. Endete mit dem einfacheren Skript oben, das nur diese Protokolle zerstört. In unserer Entwicklungsumgebung sind sie nicht wichtig.

In meinem Setup (dh als kein Root-Benutzer ausgeführt) hilft dieses Bash-Skript nicht, wenn mir beim Versuch, die Protokolldatei zu öffnen, die Berechtigung verweigert wird.

Es ist ein bisschen komisch, dass ich als Benutzer Docker starten kann, aber seine Protokolldateien überprüfen kann ...
eher ein Grund, etwas für die Docker / Docker-Compose-Befehle auszugeben

Ich musste das Skript von @DavidPesticcio wegen der zuvor erwähnten Fehler ändern ... hier geht es:

#!/bin/bash

# NOTES:
#  Does NOT delete logfile (BAD IDEA) - simply trims file with redirect.
#  Handles single/all-running/all-existing containers - see end of script for usage.
#  Enjoy :-)


_get_container_logfile() {

  case $1 in

    running) _trim_container_logfile "$(docker ps -q)" $2
             ;;

        all) _trim_container_logfile "$(docker ps -aq)" $2
             ;;

          *) _trim_container_logfile "$(docker ps -a | awk -v ID=$1 '$1 ~ ID || $NF ~ ID {print $1}')" $2
             ;;

  esac

}


_trim_container_logfile() {

  TEMP=$(mktemp)

  case $2 in
    *[!0-9]*) echo "[lines] must be a number - \"$2\" is not a number."
              exit 1
              ;;
        ''|*) MAX=${2:-1000}
              ;;
  esac


  if [ -z "$1" ]
  then
    echo "Container name/id unknown!"
    exit 1
  else
    for container in $1
    do
      logfile="$(docker inspect --format '{{.LogPath}}' $container)"
      if [ ! -f "$logfile" ]; then continue; fi
      echo "Keeping $MAX lines: $logfile"

      tail -n ${MAX} "$logfile" > "$TEMP"
      # Uncomment the next line when you trust the script!
      # cat "$TEMP" > "$logfile"
    done
  fi

  rm "$TEMP"
}


if [ -a "$(which docker)" ]
then
  case $1 in
    --trim) if [ -z $2 ]
            then
              echo "Container name/id missing!"
              exit 1
            else
              _get_container_logfile $2 $3
            fi
            ;;

    --trim-running) _get_container_logfile running $2
                    ;;

    --trim-all) _get_container_logfile all $2
                ;;

    *) echo "Usage:"
       echo "  --trim {container} [lines]   Keep [lines] of logfile for a single container"
       echo "  --trim-running     [lines]   Keep [lines] of logfile for all running containers"
       echo "  --trim-all         [lines]   Keep [lines] of logfile for all containers"
       echo "Default: lines=1000"
       exit 1
       ;;
  esac
else
  echo "Requires \"docker\""
  exit 1
fi

@dnephin Gibt es eine Chance, dass dies wieder geöffnet wird, da es offensichtlich Löschbefehl für Protokolle zu haben?

Schneiden Sie die Protokolle für einen bestimmten Container ab (muss root sein):

cp /dev/null $(docker inspect -f '{{.LogPath}}' container_name)

Sie möchten das Abschneiden und nicht das Löschen. (Durch das Löschen der Datei, auf die durch ein geöffnetes Dateihandle verwiesen wird, wird kein Speicherplatz zurückgefordert, bis der Prozess, in diesem Fall der Docker-Dämon, vollständig beendet wurde.)

@oogali fair genug. Trotzdem wäre es schön, einen richtigen Befehl zu haben, um es auf Anfrage zu tun.

+1

wäre schön, einen richtigen Befehl dafür zu haben

+1
Es wäre schön, einen richtigen Befehl zu haben, um es auf Anfrage zu tun.

Dies ist ein Kinderspiel. Das Festlegen eines Startdatums als Filter ist mehr Arbeit als nur das Löschen, um die aktuelle Ausgabe anzuzeigen. Bitte fügen Sie diese Funktion hinzu.

+1

+1

+1

+1

+1

Tangential verwandter Vorschlag:

Wenn Sie docker-compose logs -f , wird automatisch standardmäßig --tail=30 (oder eine andere vernünftige Zahl) verwendet.

docker-compose logs -f reicht nicht aus, da es bei einer großen Anzahl von angezeigten Protokollen sehr lange dauert

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Oder es gibt auch diese Problemumgehung

logpath=`docker inspect --format='{{.LogPath}}' reveelium_metricsextraction_1` && mv $logpath $logpath".bckup"

Bitte hör auf, +1 zu kommentieren. Es macht diesen Thread wirklich schwierig, wertvolle Informationen zu lesen und zu extrahieren. Dafür gibt es auf dem OP-Post einen Daumen hoch-Button.

Hier funktioniert nichts mit Docker für Mac. Ich habe etwas zusammen gehackt, das basierend auf dem Lesen dieses Threads und der Docker-Foren funktioniert.

Das Problem mit D4M ist, dass Sie auf einem Mac die Befehle tatsächlich auf dem xhyve vm ausführen müssen. Also hier ist, was ich mir ausgedacht habe. Fügen Sie diese beiden Funktionen zu Ihrem .bash_profile .

Wichtig : Vergessen Sie nicht, eine neue Shell zu starten oder Ihr Profil neu zu laden, bevor Sie fortfahren.

Nun sieht docker-logs-clean aus:

#!/bin/bash -e

if [[ -z $1 ]]; then
    echo "No container specified"
    exit 1
fi

logFile=$(docker inspect -f '{{.LogPath}}' $1 2> /dev/null)

echo -n "Cleaning ${logFile}... "
d4mexec << EOF
> $logFile
EOF
echo "done"

Beachten Sie, dass ich nicht rm der Protokolldatei bin, sondern nur > , wodurch die Datei vollständig abgeschnitten wird.

FWIW in Docker-Compose Version 2 die Funktion zum Begrenzen der Größe von Protokolldateien:

version: '2'
services:
  my-service:
    image: nginx:alpine
    restart: always
    logging:
      # limit logs retained on host to 25MB
      driver: "json-file"
      options:
        max-size: "500k"
        max-file: "50"

Es ist auf der Docker-Website nicht sehr gut dokumentiert, und dies kann für andere nützlich sein.

+1

+1

+1

+1

+1

Ich habe ein einfaches Skript docker_clear_log.sh erstellt :
sudo truncate -s 0 $(docker inspect --format='{{.LogPath}}' $1)
Verwendung: ./docker_clear_log.sh [Name-oder-ID]
Sollte funktionieren, wenn Sie Sudo-Rechte und die Einstellung log_driver: "json-file" für Ihren Docker haben (Standard).

+1

Ich habe auch versucht, die Lösung zu tempeln und es scheint zu funktionieren

Das ursprüngliche Problem wurde nie behoben und das Problem wurde trotzdem geschlossen. Interessant. @djessup , wie

Es wäre immer noch schön, ein Docker-Compose-Protokoll zu haben --clean

Warum wurde dieses Problem ohne Kommentar geschlossen, wenn das Problem an sich noch nicht gelöst wurde?

@linvi

Als ich zu diesem Thread kam, war der abschließende Kommentar in andere Kommentare gefaltet worden. Es ist genau hier:

https://github.com/docker/compose/issues/1083#issuecomment -149357280

Ich denke, sie hoffen, diesen speziellen Anwendungsfall auf indirekte Weise abdecken zu können. Erwähnen Sie, dass Sie ein besonderer Anwendungsfall sind und dass dieser nicht behandelt wird, und dass das Ticket möglicherweise wieder geöffnet werden kann. Im schlimmsten Fall könnte jemand einen einfachen Weg aufzeigen, um das zu bekommen, was Sie wollen: D.

Irgendwelche Updates?

Wenn es ein Protokoll gibt, sollten wir es auf einfache Weise löschen können.

wäre wirklich nett, wenn du den befehl einbauen könntest. das scheint nicht schwer zu sein.
Tausende von Menschen würden sich sehr freuen, wenn sie nicht alles durchblättern müssten.

Wenn Sie Docker-Compose verwenden, verwenden Sie Lazydocker zum Anzeigen von Protokollen. Dann müssen keine Protokolle mehr gelöscht werden. Sie erhalten Live-Protokolle und beginnen mit den neuesten Protokollen. Dies hilft sehr beim Debuggen.

https://github.com/jesseduffield/lazydocker
Sie können es mit einer Zeile installieren und es ist ein gutes Überwachungstool. Es ist schade, dass die Leute nicht so vernünftig verstehen, dass eine "Protokoll löschen" -Funktion eine gute Sache ist.

Aber die Problemumgehung mit Lazy Docker erledigt das für mich. Vielen Dank an jesseduffield, dass Sie uns die Möglichkeit gegeben haben, mit Ihrem Überwachungstool faul zu sein :-)
Vielleicht sollten Sie eine Spende an Lazydocker in Betracht ziehen, wenn dies auch das Debuggen / Überwachen für Sie erleichtert.
Und für Sie Docker-Entwickler / Betreuer: Warum ist die Schnittstelle von Docker nicht so?
Docker ist ziemlich großartig, aber schauen Sie sich Lazydocker an. Es gibt Raum für Verbesserungen.

+2147483647

+49324893