ただ、次のコアコードを掲載、参照コードを実行し、ここで
背景
グループは、現在配置されているAPIインターフェースプラットフォームであり、インタフェースは、適切な性能監視に登録する必要があります。それがプロジェクトを引き継ぐための方法ですので、好奇心のパフォーマンスを監視するためのインタフェースは、次を理解するために少し時間を過ごし、そして最初の手を学んだ、レコードに、例を書きました。
コードの構造の概要
| ファイル名 | 説明 |
|---|---|
| LogbackMain | アプリケーションのメインクラスを開始します |
| LogPrint | ビジネスクラス（ログカテゴリを印刷する必要があります） |
| HandleAppender | カスタムアペンダでlogback治療クラス |
| MYPOLICY | カスタム処理戦略 |
HandleAppenderクラス説明
// 注意：这边的属性名一定要与logback.xml中的标签名一致
private MyPolicy myPolicy;
// 同上
private Layout<E> layout;
public void start() {
super.start();
if (this.layout == null) {
this.addStatus(new ErrorStatus("No layout set for the appender named \"" + this.name + "\".", this));
}
}
@Override
protected void append(E eventObject) {
if (this.myPolicy != null) {
this.myPolicy.handler(this.layout.doLayout(eventObject));
}
}
- クラス名と属性XML構成は、名札の注目ポイント、またはクラス属性値アペンダと同じです
null
LogPrintクラス説明
protected static final Logger mylogger = LoggerFactory.getLogger("myLogger");
private AtomicInteger count;
public LogPrint(AtomicInteger count) {
this.count = count;
}
private ScheduledThreadPoolExecutor pool = new ScheduledThreadPoolExecutor(1);
public void printInfo () {
pool.scheduleAtFixedRate(() -> {
mylogger.info("print count " + count.incrementAndGet());
mylogger.debug("print debug level log!");
}, 1000, 5000, TimeUnit.MILLISECONDS);
}
スレッドプールサービスシステムシミュレーション印刷ログの固定周波数タイミング上方用い、ログは、カスタム処理をトリガされます
MYPOLICYクラス説明
このクラスは、比較的簡単である、で説明していない
で詳しく見ることができるGithubコード
logback.xmlの設定手順
<appender name="myLog" class="com.redsun.logback.HandleAppender">
<!--A.根据设置过滤日志，此处设置的是info-->
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>INFO</level>
</filter>
<!--B.自定义设置处理策略-->
<myPolicy class="com.redsun.logback.MyPolicy">
<appName>monitor</appName>
</myPolicy>
<!--日志打印格式，m：message-->
<layout class="ch.qos.logback.classic.PatternLayout">
<pattern>%m</pattern>
</layout>
</appender>
<!--C.设置日志级别为info-->
<!--additivity=true，表示将日志输出出来，false则不会输出日志，但是appender仍可接收到输出的日志message-->
<logger name="myLogger" level="info" additivity="true">
<!--指定自定义的appender来处理-->
<appender-ref ref="myLog"/>
</logger>
いくつかの注意が必要なXMLコメントに記載されているが、ここでは繰り返しません
操作
ログを印刷するために必要とされる前に、印刷ログを送信MyPolicyするhandle処理も、この場合には、ロジックをカスタマイズすることができます
短所
私たちのプロジェクトの使用はしてあるhandle印刷されますログ（実行時間のかかるインタフェース、成功率など）に送信されredis、その後、データ取得のタスクと計算のタイミングに別のプロジェクト、最終的フィギュアこの操作インタフェースが存在します。
だからの欠点が何であるか、印刷がスレッド上で発見され、実際の印刷のビジネスを実行することができ、同じであるかの良い上の任意のブロッキング操作なしのログ処理、カスタム・ロジックが、あなたは、長い時間がかかるしたら操作は、インターフェースの性能に影響を与え、そして、そのような問題は精通していない遭遇する問題を特定することが困難な場合が多い生成する方法です。
また、悪い考えのビジネスニーズ、または非同期処理に基づいて実際のシーンは、もちろん、また、配分と資源の管理に注意を払っていない、または二次的な機能は、主要なビジネス機能に良いよりも害に影響を与えるので。