spring boot actuator 2を使用する.x応用モニタリング

このブログでは、spring boot actuatorを使用してWebサービスを監視する方法について簡単に説明し、インタフェースの監視に重点を置いています.spring boot actuator 1.xバージョンと2.xバージョンの差は比較的大きいが、本稿では2.x.私が現在使用しているバージョンは2.0.5.RELEASEです.
Spring boot actuatorは、モニタリングのためのendpointを暴露し、外部のモニタリングプログラムにwebサービスの現在の指標状態を収集させ、必要なインタラクションを行うことができる.
統合spring boot actuator
Spring bootプロジェクト統合actuatorは非常に簡単で、maven依存を追加するだけでいいです.

    org.springframework.boot
    spring-boot-starter-actuator

依存versionはparentによって指定されます.
spring boot actuatorの検証
プロジェクトが開始されると、'/actuator'アドレスにアクセスし、次のような内容が表示される場合は、actuatorが有効になっていることを示します.

{
    "_links": {
        "self": {
            "href": "http://localhost:8000/actuator",
            "templated": false
        },
        "health": {
            "href": "http://localhost:8000/actuator/health",
            "templated": false
        },
        "info": {
            "href": "http://localhost:8000/actuator/info",
            "templated": false
        }
    }
}

上記の出力から、actuatorはこのような3つの簡単なendpointしか露出していないことがわかり、/healthインタフェースの内容だけが少し役に立ち、spring bootサービスが健康かどうか、あるいは生きているかどうかを見ることができます.もちろん、actuatorは決してこれだけの機能ではありませんが、セキュリティ上の考慮から、残りのendpointのデフォルトは無効になっています.spring securityを使用すると、いくつかの構成を加えると、対応するロールにすべての内容を表示させることができます.
すべてのendpointを開く
簡単にするために、すべてのインタフェースを開きます.アプリケーションでのみpropertiesファイルに1行の構成を追加すればよい

management.endpoints.web.exposure.include=*

修正後にspring bootサービスを再起動し、/actuatorページをリフレッシュすると、endpointが多くなります.各endpointの説明については、以下のドキュメントを参照してください.
https://docs.spring.io/spring-boot/docs/2.0.6.RELEASE/reference/htmlsingle/#production-ready-endpoints-exposing-endpoints
httpを使用します.server.requests metricインタフェースモニタリング/actuator/metricsインタフェースにアクセスすると、actuatorが提供するすべてのmetricのnameが返されます.

{
    "names": [
        "jvm.memory.max",
        "process.files.max",
        "jvm.gc.memory.promoted",
        "tomcat.cache.hit",
        "system.load.average.1m",
        "tomcat.cache.access",
        "jvm.memory.used",
        "jvm.gc.max.data.size",
        "jvm.gc.pause",
        "jvm.memory.committed",
        "http.server.requests",
        "system.cpu.count",
        "logback.events",
        ......
    ]
}

/actuator/metricsインタフェースの後ろにmetricのnameを直接付けると、そのmetricの情報にアクセスできます.私が関心を持っているのはhttp.server.requestsというmetricです.それを利用してインタフェースの監視を完了することができるからです./actuator/metrics/http.server.requestsインタフェースにアクセスすると、次のような内容が表示されます.

{
    "name": "http.server.requests",
    "description": null,
    "baseUnit": "seconds",
    "measurements": [
        {
            "statistic": "COUNT",
            "value": 5
        },
        {
            "statistic": "TOTAL_TIME",
            "value": 0.159962364
        },
        {
            "statistic": "MAX",
            "value": 0
        }
    ],
    "availableTags": [
        {
            "tag": "exception",
            "values": [
                "None"
            ]
        },
        {
            "tag": "method",
            "values": [
                "GET"
            ]
        },
        {
            "tag": "uri",
            "values": [
                "/actuator",
                "/actuator/metrics",
                "/**/favicon.ico"
            ]
        },
        {
            "tag": "status",
            "values": [
                "200"
            ]
        }
    ]
}

measurementsの下には、すべてのインタフェースが何回アクセスされたか、すべての結果を返すのにどれくらい時間がかかったか、最も遅いインタフェースを返すのにどれくらい時間がかかったかなどが表示されます.これらの情報だけでは、それほど重要ではないと思います.しかし、後でもう1つの属性はavailableTagsで、使用可能なtag keyとtag valueがすべて与えられています.これらに基づいて、監視したい内容をさらにフィルタリングし、tagに基づいて監視情報をさらに取得する方法を見ることができます.
tagによるフィルタリング
次の構文でtagをフィルタできます

/actuator/metrics/http.server.requests?tag=uri:/actuator/metrics

上記のアドレスはuri=/actuator/metricsの指標のみに注目でき,このインタフェースが全部で何回アクセスされたか,最も遅い場合にどのくらい時間がかかったかなどを見ることができる.
同時に複数のtagに基づいてフィルタリングを行い、中間を,で仕切ればよい.このインタフェースの戻り状態が500である場合にのみ注目したい場合は、このアドレスを要求できます.

/actuator/metrics/http.server.requests?tag=uri:/actuator/metrics,status:500

tagによるフィルタリングでは、次の2つに注意する必要があります.

は、値のavailableTagsのセクションにリストされているときに現在使用可能なtagのkeyおよびvalueを返します.インタフェースが500を返していないのにtag=500をクエリーしている場合、インタフェースは

とエラーを報告します.

複数のtagに基づいてフィルタリングを行う場合、chromeブラウザで直接リクエストが失敗した場合は、curlコマンドやpostmanのようなツールで

を試してみることができます.
モニタについて
監視について、もうちょっとうるさいです.
上のインタフェースはリクエストのたびに現在の値を返し、サービスが再起動すると上の値はゼロになります.
actuatorが露出したendpointを一定の周波数で繰り返し要求し、各要求の結果をシーケンスデータベース(例えばinfluxDB、またはOpenTSDB)に保存し、grafanaで示すのが一般的な監視キットである.
httpインタフェースの設計について、最悪の設計は、すべてのresponseのcodeが200であり、インタフェースが成功したかどうか、errorMsgがresponseのbodyで与えられていることにほかならない.このような設計に基づいて監視するコストは極めて高い.比較的ポピュラーなデザインはrestfulスタイルのhttpインタフェースであり、場合によっては異なるhttp codeを返す.そうすると、インタフェースが400、401、403、404、500などのcodeを返す原因が異なり、取るべき行動も異なることがわかる.