私の連絡先情報
郵便メール:
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
目次
2. 適切なログ レベルを選択します (ここでは logbkck を例にします)。
2. Log4j 2 の ThreadContext の使用
1. ELKスタック(Elasticsearch、Logstash、Kibana)
最新のソフトウェア開発では、ログはシステムの安定性、トラブルシューティング、およびパフォーマンスの監視を確保するために重要な部分です。この記事では、プロジェクトにおけるログ収集の実践的な経験を詳しく掘り下げ、Java プロジェクトで一般的に使用されるログ収集テクノロジ、ツール、およびいくつかのベスト プラクティスを紹介します。
Java プロジェクトでは、適切なログ フレームワークを選択することがログ収集の最初のステップです。一般的なログ フレームワークには、Log4j、Logback、SLF4J などがあります。フレームワークを選択する際の考慮事項は次のとおりです。
ロギング フレームワークを選択したら、プロジェクトのニーズを満たすように適切に構成する必要があります。一般に、構成ファイルは通常、ログ レベル、出力形式、宛先の場所などに関する情報を含む XML またはプロパティ ファイルです。
Logback を例として挙げると、簡単な構成ファイルの例は次のとおりです。
- <!-- logback.xml -->
- <configuration>
-
- <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
-
- <appender name="FILE" class="ch.qos.logback.core.FileAppender">
- <file>logs/myapp.log</file>
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
-
- <logger name="com.example" level="DEBUG"/>
-
- <root level="INFO">
- <appender-ref ref="CONSOLE"/>
- <appender-ref ref="FILE"/>
- </root>
-
- </configuration>
上記の構成では、コンソール出力用とファイル出力用の 2 つのアペンダーを定義し、ログ レベルと出力形式を設定します。
プロジェクトで適切なログ レベルを使用することは、ログ システムの効率を最大限に高めるための重要な要素の 1 つです。適切なログ レベルを選択すると、さまざまな環境や段階で適切なレベルの詳細なログ情報が取得されるようになり、生成されるログが多すぎたり少なすぎたりしてシステムのパフォーマンスと保守性が向上することを回避できます。
Java ログ フレームワークでは、一般的なログ レベルには次のものがあります。
開発段階では DEBUG を使用します。 開発段階では、DEBUG レベルを使用してより詳細なログ情報を取得し、開発者がコードを追跡およびデバッグできるようにします。
- public class ExampleClass {
- private static final Logger logger = LoggerFactory.getLogger(ExampleClass.class);
-
- public void someMethod() {
- // ...
- logger.debug("Debug information for developers");
- // ...
- }
- }
運用環境では INFO が使用されます。 運用環境では、ログ レベルを INFO に設定して、冗長なデバッグ情報を減らしながら、重要なランタイム情報が確実にログに記録されるようにします。
警告とエラーの処理: 潜在的な問題やエラー状態については、WARN レベルと ERROR レベルを使用します。これらのレベルのログは、チームがシステムの問題を迅速に特定して解決するのに役立ちます。
一部のログ フレームワークでは、実行時にログ レベルを動的に調整できます。これは、アプリケーションを再起動せずにログの詳細度を調整するのに役立ちます。
適切なログ レベルを使用することで、開発チームは情報の詳細とパフォーマンスのオーバーヘッドのバランスを改善し、さまざまな環境やシナリオで最適なログ結果を確保できます。
ログ コンテキスト情報を結合すると、ログ イベントの背景をより深く理解できるように、ログ レコードに追加のコンテキスト情報が追加されます。これは、特定のリクエスト、ユーザー セッション、またはその他のビジネス プロセスを追跡するのに役立ちます。 Java プロジェクトでは、SLF4J の MDC (Mapped Diagnostic Context) または Log4j 2 の ThreadContext を使用してログ コンテキスト情報を追加するのが一般的です。
SLF4J の MDC を使用すると、リクエストまたはビジネス プロセス中にキーと値のペアの情報をログ コンテキストに追加できるため、処理全体を通じて情報が保持されます。
- import org.slf4j.Logger;
- import org.slf4j.LoggerFactory;
- import org.slf4j.MDC;
-
- public class RequestContextLogger {
- private static final Logger logger = LoggerFactory.getLogger(RequestContextLogger.class);
-
- public void processRequest(String requestId, String userId) {
- try {
- // 将请求ID和用户ID放入日志上下文
- MDC.put("requestId", requestId);
- MDC.put("userId", userId);
-
- // 处理请求
- logger.info("Processing request");
-
- // ...
- } catch (Exception e) {
- logger.error("Error processing request", e);
- } finally {
- // 清理日志上下文,确保不影响其他请求
- MDC.clear();
- }
- }
- }
Log4j 2 は、SLF4J の MDC に似た ThreadContext を提供し、スレッド スコープ内のキーと値のペアのコンテキスト情報を保存することもできます。
- import org.apache.logging.log4j.LogManager;
- import org.apache.logging.log4j.Logger;
- import org.apache.logging.log4j.ThreadContext;
-
- public class RequestContextLogger {
- private static final Logger logger = LogManager.getLogger(RequestContextLogger.class);
-
- public void processRequest(String requestId, String userId) {
- try {
- // 将请求ID和用户ID放入日志上下文
- ThreadContext.put("requestId", requestId);
- ThreadContext.put("userId", userId);
-
- // 处理请求
- logger.info("Processing request");
-
- // ...
- } catch (Exception e) {
- logger.error("Error processing request", e);
- } finally {
- // 清理日志上下文,确保不影响其他请求
- ThreadContext.clearAll();
- }
- }
- }
ログ コンテキスト情報を組み込む利点は、関連する一連のログ イベントを関連付けることができるため、特定のリクエストやユーザーのアクションのフローを追跡しやすくなることです。たとえば、分散システムでは、一意のリクエスト ID をログに追加することで、リクエスト処理プロセス全体を複数のサービスにわたって追跡できます。
- public class DistributedService {
- private static final Logger logger = LoggerFactory.getLogger(DistributedService.class);
-
- public void processDistributedRequest(String requestId) {
- try {
- MDC.put("requestId", requestId);
-
- // 处理分布式请求
- logger.info("Processing distributed request");
-
- // ...
- } catch (Exception e) {
- logger.error("Error processing distributed request", e);
- } finally {
- MDC.clear();
- }
- }
- }
コンテキスト情報を組み合わせることで、ログ レコードは孤立したイベントではなくなり、有機的に結合され、システムのトラブルシューティングとパフォーマンスの最適化のためのより強力なツールを提供します。
リアルタイムの監視と集中ストレージは、プロジェクトにおけるログ管理の重要な側面です。これらの手段を通じて、チームはシステムの実行ステータスをリアルタイムで追跡し、潜在的な問題を検出し、必要に応じてタイムリーなトラブルシューティングを実行できます。 Java プロジェクトで一般的に使用されるツールには、ELK Stack (Elasticsearch、Logstash、Kibana)、Splunk などが含まれます。
ELK Stack は、ログの収集、保存、視覚化のためのオープンソース ツールのセットです。
エラスティックサーチ: 大量のログ データを保存および取得するために使用されます。リアルタイム データの強力な検索および分析機能を提供します。
ログスタッシュ: ログの収集、フィルタリング、転送に使用されます。 Logstash は、さまざまなソースからのログ データを正規化し、保存するために Elasticsearch に送信できます。
キバナ: Elasticsearch に保存されているログ データのクエリ、視覚化、分析のための直感的なユーザー インターフェイスを提供します。 Kibana を使用すると、チームはダッシュボードやグラフを作成し、ログ データの詳細な分析を実行できます。
ログを収集するようにプロジェクトで Logstash を構成することは、ELK スタックにとって重要な手順です。 Logstash は、簡単な構成ファイルを通じて定義できるさまざまな入力ソースと出力ターゲットをサポートしています。
- # logstash.conf
-
- input {
- file {
- path => "/path/to/your/application.log"
- start_position => "beginning"
- }
- }
-
- filter {
- # 可添加过滤规则
- }
-
- output {
- elasticsearch {
- hosts => ["localhost:9200"]
- index => "your_index_name"
- }
- }
この例では、指定されたパスにあるログ ファイルを監視し、Elasticsearch に出力するように Logstash 入力プラグインを構成します。 フィルター セクションに追加のルールを追加して、ログを解析、フィルターしたり、ログに追加情報を追加したりできます。
Kibana は、Web ブラウザーからアクセスできる直感的なユーザー インターフェイスを提供します。 Kibana では、ダッシュボードやチャートを作成し、複雑なクエリや分析を実行できます。
Kibana を使用すると、次のことを簡単に実現できます。
リアルタイム監視: リアルタイムのログ データを表示し、システムの実行状況をいつでも把握できます。
トラブルシューティング: 特定の基準に基づいてログを検索し、潜在的な問題の根本原因を見つけます。
パフォーマンス分析: チャートと視覚化ツールを利用して、システム パフォーマンスのボトルネックを分析します。
Splunk も広く使用されているログ管理ツールで、ログの収集、検索、分析、視覚化のためのオールインワン ソリューションを提供します。
ログ収集: Splunk は、複数のソース (ファイル、データベース、ネットワーク トラフィックなど) からのログ データの収集をサポートしています。
リアルタイムの検索と分析: リアルタイムの検索および分析機能を提供し、複雑なクエリをサポートし、ビジュアル インターフェイスを通じて検索結果を表示します。
ダッシュボードとレポート: ユーザーは、システム パフォーマンスを監視および分析するためのカスタム ダッシュボードとレポートを作成できます。
ELK Stack と Splunk はどちらも、大量のログ データを保存できる強力な集中ストレージ メカニズムを備えています。この一元化されたストレージは、ログの取得と分析を容易にするだけでなく、システムに拡張性を提供し、大規模なアプリケーション ログを処理できます。
リアルタイムのモニタリングと集中ストレージは、プロジェクトの安定性とパフォーマンスを確保するための鍵となります。 ELK Stack や Splunk などのツールを使用することで、プロジェクト チームは複雑なシステム環境でログをリアルタイムで追跡し、タイムリーなトラブルシューティングとパフォーマンスの最適化を実行できます。これらのツールの機能により、チームの効率が向上するだけでなく、プロジェクトの保守性と拡張性も向上します。
ログのローリングとアーカイブは、プロジェクトにおける重要な実践であり、ログ ファイルの合理的な管理を確保し、過剰なログ ファイルによって引き起こされるストレージの問題を防ぎ、システムの通常の動作を維持するのに役立ちます。以下に、Java プロジェクトでログのローリングとアーカイブを実装するための一般的な方法をいくつか示します。
ほとんどのロギング フレームワークは、構成ファイルを通じて設定できるローリング戦略を提供します。これらのポリシーは、いつ新しいログ ファイルにロールオーバーするか、いつ古いログ ファイルを削除するかを決定します。 Logback を例として、基本的なローリング戦略を構成します。
- <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
- <file>logs/myapp.log</file>
- <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
- <fileNamePattern>logs/myapp.%d{yyyy-MM-dd}.log</fileNamePattern>
- <maxHistory>30</maxHistory>
- </rollingPolicy>
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
上記の構成では、TimeBasedRollingPolicy
、時間に基づいてログ ファイルをロールします。maxHistory
保持する履歴ログ ファイルの数を指定します。この数を超えるログ ファイルは削除されます。
場合によっては、時間によるローリングだけでは不十分な場合があり、ログ ファイルのサイズに基づいてローリングする必要もあります。これは、ファイル サイズを構成することで実現できます。
- <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
- <file>logs/myapp.log</file>
- <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
- <fileNamePattern>logs/myapp.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
- <maxFileSize>5MB</maxFileSize>
- <maxHistory>30</maxHistory>
- </rollingPolicy>
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
上記の構成では、SizeAndTimeBasedRollingPolicy
、ファイル サイズと時間に基づいてログ ファイルをロールします。maxFileSize
各ログ ファイルの最大サイズを指定します。
プロジェクトによっては、カスタム条件に基づいてログをロールする必要がある場合があります。この場合、カスタム スクロール戦略の実装を検討してください。たとえば、特定のビジネス ルールに基づいてログ ファイルをローリングします。
- public class CustomRollingPolicy extends TimeBasedRollingPolicy<ILoggingEvent> {
- // 实现自定义的滚动逻辑
- }
次に、構成ファイルでカスタム スクロール戦略を使用します。
- <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
- <file>logs/myapp.log</file>
- <rollingPolicy class="com.example.CustomRollingPolicy">
- <!-- 自定义配置 -->
- </rollingPolicy>
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
ログ ファイルのローリングに加えて、古いログ ファイルをアーカイブすることも一般的です。これは、古いログ ファイルがディスク領域を占有しすぎないように定期的にアーカイブ ディレクトリに移動することで実現できます。
または、プログラムによるアプローチを使用して Java コードに実装します。
- import java.io.File;
- import java.nio.file.Files;
- import java.nio.file.Path;
- import java.nio.file.StandardCopyOption;
- import java.time.LocalDate;
- import java.time.format.DateTimeFormatter;
-
- public class LogArchiver {
- public static void archiveLogFile(String logFileName, String archiveDirectory) {
- String currentDate = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));
- File logFile = new File(logFileName);
- File archiveDir = new File(archiveDirectory);
-
- if (!archiveDir.exists()) {
- archiveDir.mkdirs();
- }
-
- Path sourcePath = logFile.toPath();
- Path targetPath = new File(archiveDir, logFile.getName() + "." + currentDate + ".log").toPath();
-
- try {
- Files.move(sourcePath, targetPath, StandardCopyOption.REPLACE_EXISTING);
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- }
定期的なタスクで呼び出されるarchiveLogFile
この方法は、ログ ファイルをアーカイブするために使用できます。
ログのローリングとアーカイブを実装することで、プロジェクトはログ ファイルをより効率的に管理し、システムが長期間にわたって良好なパフォーマンスを維持できるようになります。これは、トラブルシューティングに役立つだけでなく、コンプライアンス要件にも役立ちます。
適切なログ フレームワークを選択し、適切に構成し、適切なログ レベルを使用し、コンテキスト情報を組み合わせることで、プロジェクトは、トラブルシューティング、パフォーマンスの最適化、システム監視を強力にサポートする強力なログ システムを構築できます。同時に、リアルタイム監視と集中ストレージにより、チームはシステムのステータスを追跡するためのより便利な手段を提供します。細心の注意を払ってログを記録することは、プロジェクト開発の技術的な実践であるだけでなく、チームの全体的な効率とプロジェクトの品質を向上させるための重要な保証でもあります。