Prenez note avant d'oublier. Je faisais un échantillon pour comprendre le mécanisme d'envoi de journaux à CloudWatch Logs, mais je n'ai pas trouvé de site auquel faire référence.
Maintenant ça.
https://github.com/kojiisd/cloudwatch-logs-java-standalone
cloudwatch-logback-appender https://github.com/j256/cloudwatch-logback-appender
Si vous modifiez le contenu de logback.xml, vous pouvez librement faire circuler le journal dans une certaine mesure.
<appender name="CLOUDWATCH" class="com.j256.cloudwatchlogbackappender.CloudWatchAppender">
<region>us-east-1</region>
<accessKeyId>XXXXXXX</accessKeyId>
<secretKey>XXXXXXX</secretKey>
<logGroup>test-loggroup</logGroup>
<logStream>test-logstream</logStream>
<layout>
<pattern>[%d{HH:mm:ss.SSS} [%thread] %-5level %logger{20} - %msg%n</pattern>
</layout>
<maxBatchSize>32</maxBatchSize>
</appender>
accesskeyid
Ousecretkey
Semble aller à la awsconfig de la machine d'exécution si l'élément lui-même est supprimé (bien que je ne l'ai pas essayé)
Le journal a été correctement envoyé vers CloudWatch Logs. (Si le groupe de journaux ou le flux de journaux n'existe pas, il sera créé)
Évidemment, afin d'envoyer des données à CloudWatch Logs dans la bibliothèque, nous effectuons diverses initialisations et envois de données. Étant donné que ce processus est exécuté dans les threads, lorsque le processus de journalisation de l'appelant se termine et que l'application se termine, le côté thread enfant se termine également automatiquement et le journal n'est pas envoyé à CloudWatch Logs. (En fait, je ne pense pas qu'il soit possible d'envoyer des journaux avec une application aussi autonome, donc je ne pense pas que ce soit vraiment un problème.) J'ai remarqué en regardant la source du côté OSS.
Pour éviter cela, j'ai intentionnellement mis le traitement Sleep dans l'implémentation pendant environ 20 secondes.
C'était très facile à réaliser si je n'entrais pas dans les points de prudence.
Recommended Posts