ブログELKスタック導入-1-

Cliche

2025年02月15日

394 • 0

なぜログ管理に悩むようになったのか?

たまにインスタンスにアクセスしてログを確認するのですが,ボットネットの悪意のあるリクエストがずっと入ってきていました。
問題は,私がそのログを確認するためにはsshで直接インスタンスにアクセスして docker-compose logs で確認しなければならないのですが,私が毎日ログを確認することもできないし,最近は就職準備のために機能開発をしていないため,インスタンスにアクセスすることもありませんでした。

また,現在のCDパイプラインを見ると
1.変更点のコミット
2. Github ActionsがDockerイメージをビルドしてDocker HubにPushする。
3.OCI Instanceから最新のイメージPull
4.サーバーDown & Up

このような流れですが,この流れはコンテナの再起動時,stdoutログが消えるという致命的な問題がありました。
Docker自体が/var/lib/docker/containersパスにログを残していますが,docker-compose logsでは再起動後に確認できませんでした。

最初の試み:GitHub Actionsでログを収集する

最初からELKのような大規模な修正をするつもりはなく,単純にログをCronで毎日0時にログを保存し,それをGitHub Actions Artifactsに保存するという比較的簡単な方法を試しました。

 - name: Collect logs

 uses: appleboy/ssh-action@v1.0.0

 with:

 host: ${{ secrets.OCI_HOST }}

 username: ${{ secrets.OCI_USERNAME }}

 key: ${{ secrets.OCI_SSH_KEY }}

 script: |

 cd /home/ubuntu/ && \

 mkdir -p logs && \

 docker-compose logs --no-color > logs/app-$(date +%Y%m%d).log



 - name: Create temporary SSH key file

 run: |

 echo "${{ secrets.OCI_SSH_KEY }}" > /tmp/oci_key

 chmod 600 /tmp/oci_key



 - name: Download logs to GitHub Actions

 run: |

 mkdir -p ~/.ssh

 ssh-keyscan -H ${{ secrets.OCI_HOST }} >> ~/.ssh/known_hosts

 scp -i /tmp/oci_key -r ${{ secrets.OCI_USERNAME }}@${{ secrets.OCI_HOST }}:/home/ubuntu/logs ./logs/



 - name: Upload logs as artifact

 uses: actions/upload-artifact@v4

 with:

 name: app-logs

 path: ./logs/



 - name: Clean up temporary SSH key file

 run: |

 rm /tmp/oci_key

このように修正して直接実行させてみましたが,直接テストしてみると予想してなかった問題がありました。

上で言及したように,このworkflowが実行された瞬間,サーバーはしばらくダウンして再びオンになるのですが,そのタイミングで保存されたログは驚くほどこれだけでした。

また,このworkflowは既存のworkflowにログ収集過程を追加したものなので,結局は私が一日に一回はworkflowを実行させる必要があり,これはとても非効率的だと思いました。

二度目の試み:ELKスタック導入に切り替え

そうしてふと思ったのは,最近面接を進めながらポートフォリオを整理したのですが,MusicLabプロジェクトでDBに保存されたデータを検索する時,詳細検索機能を実装するためにFull-Text Search Index,Elasticsearchなどのキーワードを検索し,実際に面接官の一人が検索パートを担当する方だったので質問したことを思い出し,どうせログ管理もしなければならないし,現在のブログの検索機能も韓国語の詳細検索をサポートできないことを確認したので,ELKスタックを導入することにしました。

ELKスタックを導入すれば,単にログの紛失問題を解決するだけでなく,リアルタイムログの可視化,検索可能なログデータ,今後のシステムモニタリング機能の拡張**まで可能です。このような強みを考えてみると,"せっかくだから最後までやってみよう"という結論が出ました。

実際,私の履歴書のポートフォリオの説明にも書いてありますが,このブログは最初から単純なポートフォリオ用ではなく,私が実際にこれから習得する技術スタックを直接適用できる自分だけのスケッチブックを目指して作られたブログです。

私はすぐに既存のdocker-compose.ymlを修正してElasticsearch,Logstash,Kibanaをそれぞれコンテナとして起動し,既存のFastAPIのuvicornの基本ログはELKで直接解析するのが難しいので,python-json-loggerを利用してELKに適したJSON形式に修正しました。

その後,NGINXの設定を行い,設定されたパスでKibanaに接続しようとしたら,私を迎えてくれたのは